大数据技术体系
来一起认识下大数据的技术框架有哪些，它们分别用于解决哪些问题？它们的内在逻辑和适用场景有哪些？OK，一起去探索下。
生态架构
首先，看一下大数据技术体系的整体架构图。根据数据流转的方向，从下而上进行介绍。
在前面，我们了解到，大数据的数据存储是分布式的，而且能够接受任务调度，与传统的数据存储存在差异。所以离线方式处理的数据，需要通过ETL模块，导入到大数据的数据存储系统进行存储；其中Sqoop是常见的抽取结构化数据工具；而Flume和Logstach是用于抽取非结构化、半结构化数据工具。
大数据的数据存储系统，最常见的就是分布式文件系统HDFS；如果需要使用NoSQL数据库功能，HBase是基于HDFS实现的一个分布式NoSQL数据库。
存储起来的数据，使用大数据的通用计算引擎MapReduce或Spark进行计算，这些计算任务会由资源管理框架——Yarn进行调度。将任务分发到数据的存储位置——HDFS中。
但使用通用计算引擎MapReduce或Spark编写处理任务，需要使用特定的语法；这样一来，原有的特定领域的传统业务，进行迁移时就会带来很多问题。比如原有的数据仓库，使用SQL进行数据处理任务，但迁移到大数据平台之后，原来的SQL业务需要全部转换为MapReduce、Spark语法，迁移成本太大。其次，图计算、机器学习等其他领域，在MapReduce、Spark语法基础上，实现起来非常困难，且易用性很差。
于是在通用计算引擎之上，针对不同的领域，诞生了很多提升易用性的产品；以使得对存储在大数据平台上的数据进行数据分析，变得更加容易。
比如在Hadoop生态圈的Hive，它的作用就是将SQL转化成MapReduce任务，减少了数据仓库迁移成本，虽然它的SQL支持率只有60%左右，而且有特定的语法HQL（Hive SQL），但已经极大的简化了结构化数据的处理过程。当然它现在也支持底层计算引擎转换为Spark，以便提升处理性能。
Hadoop生态圈的Pig的功能和Hive类似，但它是将MapReduce封装为自己的API，使用起来比原生的MapReduce更易用一些；在早期，使用的公司较多，现在基本已很少被使用。
Hadoop生态圈的Malhot是机器学习的一个框架，可以完成机器学习的任务，底层将任务转换为MapReduce，从而实现分布式运算。
除了Hadoop生态圈，Spark引擎也有自己的生态圈，其中Spark SQL和Hive功能类似，将SQL转换为Spark任务，提升结构化数据处理的易用性。MLlib提供机器学习的功能，GraphX完成图计算功能，Spark Streaming完成流计算任务。
在架构图中的数据分析层中，有一个产品比较特殊——ElasticSearch，它是用于大数据下的搜索与检索场景的产品。但它是独立运行的，将数据存储于本地磁盘，不依赖于HDFS；有自己的计算引擎，不依赖于MapReduce、Spark。所以，除了在大数据领域，其它很多场景中也能见到它的身影。
大数据实时流处理
在大数据实时运算这里，半结构化、非结构化数据先通过实时ETL工具，如Flume、Logstash进行数据的实时采集；结构化数据，一般会采用监控数据库预写日志的方式，通过CDC或者OGG等工具进行实时抽取。
实时抽取的数据，首先会进入到消息队列中，完成削弱峰值和解耦合的功能，之后便交于流处理引擎进行处理。常见的流处理引擎有Spark Streaming、Flink。
其中Spark Streaming是将实时处理任务转换为Spark这种离线批处理任务进行处理，它的原理就是将一定时间间隔内的数据，转换为离线批处理任务，只要时间间隔足够短，它就可以近似于实时处理。所以Spark Streaming的处理方式也被称为微批处理模式。
而Flink，它有自己的运算引擎，所以是真正意义上的实时计算，而不需要转换为批处理任务。
数据经过处理之后，最终的结果会被存储到数据库集群中，企业常用的选型是HBase，因为它有一个较好的特性：高并发读，可以满足前端系统结果的实时查询。当然，Druid、Clickhouse也是常用的选型产品。
分布式协调服务
大数据的产品，都是分布式架构，以集群的形式部署和运算。于是，分布式集群的管理便成了一个问题，比如节点间的发现、主从的切换等。而Zookeeper，就是为了解决这些问题而存在的，它提供分布式协调服务。
Zookeeper本质上是一个特殊的文件系统，加上消息通知机制，来完成分布式协调。比如节点间的发现，当某个集群在第一次启动时，假设为Kafka，它会在Zookeeper上的文件系统中创建自己的目录——Kafka；其中Kafka每个节点启动成功后，假设为Node01，会在Zookeeper上的Kafka目录中注册，即创建自己的节点文件——Node01，Zookeeper检测到Kafka目录创建了Node01，便会通知Kafka中的所有节点，Node01加入到集群中了；而Node01超过一定时间没有向Zookeeper进行通信，Kafka目录下的Node01文件便会被删除，于是Zookeeper便又会通知所有Kafka节点，Node01节点被移除了。
在很多大数据产品中，都会依赖Zookeeper集群，用于实现分布式协调服务。
分布式任务调度
大数据分析任务，一般都会有多个产品协同完成，并且存在严格的先后顺序。比如，要完成对当天数据的处理，首先需要通过ETL组件，将数据抽取到HDFS中进行存储，之后再由Hive或Spark SQL将数据接入进行处理，处理完成之后，为了保证前端的查询效率，可能再通过ETL组件将结果表存储到其它数据库中。
其次，大数据任务的执行，如离线数据仓库，一般会选择定时执行；如凌晨零点，对昨天的数据统一进行抽取，并处理计算。
大数据的分布式任务调度组件Azkaban、Oozie就是来完成这些任务的，它们可以完成控制任务的执行顺序、定时执行等功能。
而Azkaban相对Oozie来说，它的功能相对丰富，Web界面也较为美观，在企业选型中比较常见。
结束语
如果有帮助的，记得点赞、关注。在公众号《数舟》中，可以免费获取专栏《数据仓库》配套的视频课程、大数据集群自动安装脚本，并获取进群交流的途径。
我所有的大数据技术内容也会优先发布到公众号中。如果对某些大数据技术有兴趣，但没有充足的时间，在群里提出，我为大家安排分享。
