（一）技术架构
（二）数据开发的日常工作及特点
数据开发岗位的日常工作流程为：
1. 开会，了解产品需求，进行开发排期；
2. 模型设计，了解依赖关系与约束原则，与产品二次核对；
3. ETL开发，沟通其他部门，导入数据；
4. SQL/MR开发，编写业务逻辑；
5. 测试，测试人员检查逻辑，并核对结果准确性；
6. 发布上线，加入日常监控报警。
数据开发岗位的几大特点：
1. 业务需求众多，业务逻辑变更频繁；
2. 极度强调快速交付，大多数情况下会要求先出小批量数据看效果；
3. 沟通范围广泛，需要与数据、平台、测试、产品等多方沟通，会议频繁；
4. 运维压力较大，需要7*24监控数据运行情况，数据故障计入年度KPI；
5. 系统环境复杂，大多数系统为自研，约束较多，且会面临数据迁移的情况；
6. 理论更新频繁，随着OneData理论的成熟，经常要重构底层逻辑。
（三）以Hadoop为基础的数据平台搭建
一张图预览全景生态：
最基础的是基础设施层，由两部分组成：Zookeeper集群和Hadoop集群。它为基础平台层提供基础设施服务，比如命名服务、分布式文件系统、MapReduce等。其次是基础平台层，由三个部分组成：任务调度控制台、HBase和Hive，它为用户网关层提供基础服务调用接口。最后是用户网关层，用于为终端客户提供个性化的调用接口以及用户的身份认证，是用户唯一可见的大数据平台操作入口。终端用户只有通过用户网关层提供的接口才可以与大数据平台进行交互。目前网关层提供了三个调用接口：Hadoop客户端是用户提交MapReduce作业的入口，并可从其UI界面查看返回的处理结果；Hive客户端是用户提交HQL查询服务的入口，并可从其UI界面查看查询结果；Sqoop是关系型数据库与HBase或Hive交互数据的接口，可以将关系型数据库中的数据按照要求导入到HBase或Hive中。
（四）MapReduce的作用
首先来看MapReduce的两张过程图：
在实际的开发场景中，由于真正面对海量数据，例如每次任务计算都是几十上百TB的数据量，Impala等引擎是无法处理如此庞大数据量的，因而必然采用MapReduce来进行数据的预处理，并根据后续业务场景采用HiveSQL以简化开发，或者继续使用MapReduce以进行更加复杂的逻辑运算。由于大部分的场景：统计、排序、指标计算等都可以通过HiveSQL来实现，故数据开发的流程也是以HiveSQL为主，辅助以少量的MapReduce开发，以支持个性化的计算逻辑。
MapReduce的调优是一个复杂的过程，是一种长期积累的经验总结。主要包括以下四个部分：
1. 硬件调优：内存、磁盘io以及网络等；
2. 参数调优：缓冲区、磁盘读写、增加JVM内存、增加运行个数等；
3. 代码调优：编写Combiner、重新设计Key、合并小文件、数据压缩等；
4. 作业调优：合理规划运行依赖、调整作业优先级等。
其中MapReduce的效率问题主要由以下原因造成，在优化时注意即可；
1. 数据倾斜；
2. Map或Reduce数量不合理；
3. Map或Reduce运行时间过长；
4. 小文件过多；
5. 大量的不可分超大文件；
6. Spill次数过多；
7. Merge次数过多。
（五）Hive与Impala的适用场景
先看Impala的架构图：
再谈Impala的优点：
1. 支持SQL查询，快速查询大数据；
2. 可以对已有数据进行查询，减少数据的加载，转换；
3. 多种存储格式可以选择（Parquet, Text, Avro, RCFile, SequeenceFile）；
4. 可以与Hive配合使用。
再是Impala的缺点：
1. 不支持用户定义函数UDF；
2. 不支持text域的全文搜索；
3. 不支持Transforms；
4. 不支持查询期的容错。
由于Hive的底层实现是MR，所以看一下Impala与MR的运行优势比较：
1. 在查询过程中，没有容错逻辑，如果在执行过程中发生故障，则直接返回错误（这与Impala的设计有关，因为Impala定位于实时查询，一次查询失败，再查一次就好了，再查一次的成本很低）；
2. Impala不需要把中间结果写入磁盘，省掉了大量的I/O开销。（减少了I/O开销因此执行速度快）；
3. 省掉了MapReduce作业启动的开销。MapReduce启动task的速度很慢（默认每个心跳间隔是3秒钟），Impala直接通过相应的服务进程来进行作业调度，速度快了很多（减少了MapReduce的执行过程）；
4. Impala完全抛弃了MapReduce这个不太适合做SQL查询的范式，而是像Dremel一样借鉴了MPP并行数据库的思想另起炉灶，因此可做更多的查询优化，从而省掉不必要的shuffle、sort等开销（借鉴了MPP并行数据库的思想另起炉灶，因此可做更多的查询优化，从而省掉不必要的shuffle、sort等开销）；
5. 通过使用LLVM来统一编译运行时代码，避免了为支持通用编译而带来的不必要开销（使用LLVM来统一编译运行时代码）；
6. 用C++实现，做了很多有针对性的硬件优化，例如使用SSE指令；
7. 使用了支持Data locality的I/O调度机制，尽可能地将数据和计算分配在同一台机器上进行，减少了网络开销（将数据和计算相分离，减少了网络开销）。
下图为Impala的数据格式Parquet与Hive的ORC数据格式对比：
综上：如果查询数据量以GB为单位，那么采用Impala速度更快；如果查询数据量以TB为单位，还是老老实实用Hive吧。
（六）统一开发平台
在需求开发的初始阶段，采用分散的开发方式，直接将代码部署在服务器上是一种非常快速和高效的做法；但当任务数量爆炸后，任务变得非常多，再采用原始的开发方式很容易搞乱头脑，因而特别有必要来建设一个开发平台，让我们的开发任务能够像列表一样被查询，这样非常便于任务的管理。同时，可以继承很多其他的开发插件，通过工具来优化我们的开发代码，避免浪费时间的Code Review环节频繁进行。可以说，将一些典型的代码Code Review之后，剩下的校验工作就可以交给平台来进行了。
典型的统一开发平台场景如下：
1. 任务开发：包括ETL工具的使用（Sqoop导入数据等）、MR代码的开发（支持Java版本或Python，支持自动部署）、HiveSQL开发（由平台统一提交和调度）、数据导出（运行结果导入到平台组的Mysql库中）；
2. 数据监控：在任务运行的关键节点，需要添加一些监控任务，包括监控数据波动、是否准时完成任务、上游数据是否失败等；
3. 任务触发方式：可以选择采用定时调度、单次调度、重跑数据等方式来执行任务，一般会通过Java平台开发成日期控件的形式，底层是linux系统任务调度crontab的时间规则；
4. SQL SCAN：尽管开发人员都是经过严格培训的，但仍无法避免一些日常的工作失误，例如sql质量差、性能低、不遵循规范等问题，通过总结常见问题，形成开发规则，便可以开发SQL SCAN工具，在提交代码时即发现问题，提示报警；主要校验规则有三类：代码规范（表命名、生命周期、注释等）、代码质量（参数错误、分母为0、NULL值等）、代码性能（扫描大表、重复计算、分区选择错误等）；
5. 权限管理：根据数据安全的规则，设定不同人员只能够看到自己权限下的数据情况。
（七）任务调度
任务调度的本质，是一个非常复杂有向无环图。
在传统的数据仓库中，任务是依赖Crontab来定时执行的，存在许多的弊端，例如：各任务之间依赖定时执行，容易造成前面的任务未结束或者失败，而后面任务继续运行，导致失败的情况；任务无法设置并发执行；任务无法设置运行优先级；任务多了看起来太乱，无法管理维护；任务开发方式多种多样，包括MapReduce、Hive、SQL、Java、Shell、Spark等，无法统一维护。
任务调度系统的核心有两个模块：调度引擎和执行引擎。简单来讲，就是调度引擎根据任务节点数据及依赖关系进行实例化，生成各类参数，并生成调度树；执行引擎根据具体任务，分配CPU、运行节点等资源，在任务对应的执行环境中运行相关代码。
下图为调度关系依赖图：
下图为任务状态机模型关系图：
任务调度实现的基本功能如下：
1. 定时调度：可以根据实际需求，设定精确的运营时间，包括分钟、小时、日、周、月，具体可以精确到几点几分几秒运行；
2. 周期调度：按照小时、日等时间周期运行任务，并自动重复执行；
3. 手动运行：主要用于补数据等环节，例如一次性运行最近三年的数据，可以单独生成一个低优先级的任务流；
4. 调度管理：可以选择依赖运行任务，当上游任务结束时，自动触发下游任务的执行，并可以选择多个上游；
5. 监控报警：在主要任务节点后配置报警信息，如果任务运行失败或超时，则通过电话、短信、邮件等方式来提醒开发者。
实际上，最主要的周期调度，能够根据依赖关系，按照调度树从上向下依次运行，并通过依赖图来完整直观的看到所有任务的运行情况。
（八）血缘关系
在现实世界中，我们每个个体都是祖先通过生育关系一代代孕育而来，这样就形成了我们人类的各种血缘关系。在数据信息时代，我们庞大的数据在每时每刻产生，这些数据又经过各种加工组合、转换，又会产生新的数据，这些数据之间就存在着天然的联系，我们把这些联系称为数据血缘关系。
大数据数据血缘是指数据产生的链路。直白点说，就是我们这个数据是怎么来的，经过了哪些过程和阶段。举个例子，比如在生产系统如淘宝网中，客户在淘宝网页中购买物品后，数据就被存到后台数据库表A中。当我们领导需要查看某个月卖的最火的是哪些物品时，我们需要对存入的这些数据进行加工汇总，形成一张新的表B来存储我们处理的数据，最后我们会根据B表进一步处理成我们前台展现使用的表C。那么A表是C表数据最初的来源，是C表数据的祖先。从A表数据到B表数据在到C表数据，我们认为这条链路就是C表的数据血缘。
在数据的处理过程中，从数据源头到最终的数据生成，每个环节都可能会导致我们出现数据质量的问题。比如我们数据源本身数据质量不高，在后续的处理环节中如果没有进行数据质量的检测和处理，那么这个数据信息最终流转到我们的目标表，它的数据质量也是不高的。也有可能在某个环节的数据处理中，我们对数据进行了一些不恰当的处理，导致后续环节的数据质量变得糟糕。因此，对于数据的血缘关系，我们要确保每个环节都要注意数据质量的检测和处理，那么我们后续数据才会有优良的基因，即有很高的数据质量。
