大数据生态圈核心技术盘点（附：各技术对比及选型建议）

作者：hangge | 2024-03-04 09:20

一、大数据介绍

1，大数据的 4V 特征

（1）目前，业界对大数据的特征还没有统一的定义，但是大家普遍认为，大数据应该具备 Volume、Velocity、Variety 和 Value 这 4 个特征，简称“4V”特征，即数据体量巨大、数据类型繁多、数据价值密度低和数据速度快。

Volume：数据体量巨大，包括采集、存储和计算的量都非常大。大数据的起始计量单位至少是 PB（等于 1000 个 TB）、EB（等于 100 万个 TB）或 ZB（等于 10 亿个 TB）。
Velocity：数据速度快，包括增长速度快、处理速度快、时效性要求高。比如，搜索引擎要求几分钟前的新闻能够被用户查询到，个性化推荐算法要求尽可能实时完成推荐。这是大数据区别于传统数据挖掘的显著特征。
Variety：数据类型繁多，包括结构化、半结构化和非结构化数据，具体表现为网络日志、音频、视频、图片和地理位置信息等。多类型的数据对数据的处理能力提出了更高的要求。
Value：数据价值密度低，但是这些数据又很珍贵。随着互联网及物联网的广泛应用，信息量大，但价值密度较低。如何结合业务逻辑并通过强大的机器算法来挖掘数据价值，是大数据时代最需要解决的问题。

（2）最近，IBM 提出了大数据“5V”的概念，即在“4V”的基础之上多了一个特征：Veracity，表示数据的准确性和可信赖度（数据的质量）。

2，大数据的典型应用场景

（1）大数据目前已经广泛应用在各行各业中，包括金融大数据、医疗大数据、零售大数据、电商大数据、交通大数据、智慧城市大数据等应用场景。

（2）我们平时生活中接触得比较多的大数据应用场景有：

淘宝、天猫、京东等购物网站中的“猜你喜欢”功能。
百度地图、高德地图中的“实时路况”功能。
今日头条、抖音、直播平台中的“推荐”功能。
美团、饿了么等外卖平台中的“订单实时分配”功能。

二、大数据生态圈核心技术

随着大数据行业的发展，大数据生态圈中相关的技术也在一直迭代进步，目前大数据生态圈中的核心技术总结下来如下图所示，分为 9 类：

①数据采集技术框架：包括 Flume、Sqoop、Logstash、Filebeat、DataX、Canal、Maxwell 等。
②数据存储技术框架：包括 Kudu、HBase、HDFS、Kafka 等。
③分布式资源管理框架：包括 YARN。
④数据计算技术框架：包括 MapReduce、Tez、Spark、Storm、Flink 等。
⑤数据分析技术框架：包括 Hive、Impala、Kylin、Druid、ClickHouse、Doris 等。
⑥任务调度技术框架：包括 Azkaban、Ooize、DolphinScheduler 等。
⑦大数据底层基础技术框架：包括 Zookeeper。
⑧数据检索技术框架：包括 Elasticsearch、ELK 等。
⑨大数据集群安装管理框架：包括 CDH、HDP、CDP 等。

1，数据采集技术框架

（1）数据采集也被称为数据同步。随着互联网、移动互联网、物联网等技术的兴起，产生了海量数据。这些数据散落在各个地方，我们需要将这些数据融合到一起，然后从这些海量数据中计算出一些有价值的内容。此时第一步需要做的是把数据采集过来。数据采集是大数据的基础，没有数据采集，何谈大数据！

（2）常见的日志数据采集工具有如下几种：

Flume：Apache 开源的日志采集工具，它是一个高可用的、高可靠的、分布式的海量日志采集、聚合和传输的系统。
Logstash：Elastic 公司旗下的一款日志采集工具，Logstash 属于 ELK（Elasticsearch + Logstash + Kibana）组件中的一员，主要负责日志数据采集。
Filebeat：Elastic 公司开发的一款轻量级的日志采集工具，只能采集保存在文件中的日志数据。

（1）根据前面的对比，可以看出：

Flume、Logstash 的功能比较丰富，支持各种常见的数据源及目的地，应用场景比较广泛，但是属于重量级组件，性能消耗相对较高。
Filebeat 只能采集文件中的数据，但是性能消耗较低。

（2）在实际工作中可参考下图选择合适的日志数据采集工具：

（3）数据库常见的离线数据采集工具有：

Sqoop：由 Apache 开源的一个可以将 Hadoop 和关系型数据库中的数据相互转移的工具，可以将关系型数据库（例如 MySQL、Oracle 等）中的数据导入 Hadoop，也可以将 Hadoop 中的数据导出到关系型数据库中。
DataX：由阿里巴巴开源的一个异构数据源离线同步工具，用于实现包括关系型数据库（例如 MySQL、Oracle）、HDFS、Hive、HBase、FTP 等各种异构数据源之间稳定且高效的数据同步。

（4）数据库常见的实时数据采集工具有：

Canal：由阿里巴巴开源的一个基于 MySQL 数据库的增量日志（Binary Log）解析工具，可以提供增量数据订阅和消费，支持将 MySQL 中的增量数据采集到 Kafka、RabbitMQ、Elasticsearch 及 HBase 中。
Maxwell：由 Zendesk 开源的一个基于 MySQL 数据库的增量日志（Binary Log）解析工具，可以将 MySQL 中的增量数据以 JSON 格式写入 Kafka、Kinesis、RabbitMQ 及 Redis 中。

提示：bootstrap 功能可以导出数据库表的完整历史数据用于初始化。

2，数据存储技术框架

（1）HDFS

Hadoop 中的 HDFS（Hadoop Distributed File System，分布式文件系统），它可以解决海量数据存储的问题，但是其最大的缺点是不支持单条数据的修改操作，因为它毕竟不是数据库。

（2）HBase

随着业务的发展，企业对海量数据的修改需求越来越多，此时急需一个可以支撑海量数据修改需求的存储系统。
HBase 应运而生，它是一个基于 HDFS 的分布式 NoSQL 数据库。这意味着，HBase 可以利用 HDFS 的海量数据存储能力，并支持修改操作。但 HBase 并不是关系型数据库，所以它无法支持传统的 SQL 语法。

（3）Kudu

随着业务的继续发展，在数据修改的基础上，企业还希望能够提供基于 SQL 的统计分析功能。

HDFS 不支持单条数据的修改操作，随机读写性能差，适合离线统计分析，在获取大批量数据时性能比较高。
HBase 支持数据修改操作，随机读写能力强，不支持基于 SQL 的统计分析，在获取大批量数据时性能较差。

这时 Kudu 出现了，它介于 HDFS 和 HBase 之间，支持数据修改，也支持基于 SQL 的统计分析。

Kudu 不及 HDFS 批处理速度快，也不及 HBase 随机读写能力强。
但是，在 SQL 统计分析场景下，Kudu 比 HBase 的批处理速度快；在实时写入或更新的场景下，Kudu 比 HDFS 的随机读写能力强。

提示：目前 Kudu 的定位比较尴尬，属于一个折中的方案，在实际工作中应用有限。

（4）Kafka

Kafka 是一个高吞吐量、持久性的分布式发布/订阅消息系统。常用于海量数据的临时缓冲存储，对外提供高吞吐量的读写能力。

（5）Redis

Redis 是基于内存的 NoSQL 数据库。它支持分布式集群，可以实现海量数据存储。其最大的特点是可以支持 100 000 次/s 的随机读写能力，常用于大数据的实时计算场景中。

3，分布式资源管理框架

（1）YARN

YARN 是 Apache Hadoop 中的分布式资源管理系统，用于将作业（如 MapReduce，Spark 等）提交到计算机集群上，并管理资源。

（2）Mesos

Mesos 是一种多个作业调度框架的资源管理系统，它可以分配资源，从而使集群上运行的不同应用程序之间共享计算机资源。

（3）Kubernetes

Kubernetes 是一种集群管理系统，用于部署，运行和管理容器化应用程序。

4，数据计算技术框架

（1）大数据中的离线数据计算引擎经过十几年的发展，到目前为止主要发生了 3 次大的变更：

MapReduce 可以称得上是大数据行业的第一代离线数据计算引擎，主要用于解决大规模数据集的分布式并行计算。MapReduce 计算引擎的核心思想是，将计算逻辑抽象成 Map 和 Reduce 两个阶段进行处理。
Tez 计算引擎在大数据技术生态圈中的存在感较弱，实际工作中很少会单独使用 Tez 去开发计算程序。
Spark 最大的特点就是内存计算：任务执行阶段的中间结果全部被放在内存中，不需要读写磁盘，极大地提高了数据的计算性能。Spark 提供了大量高阶函数（也可以称之为算子），可以实现各种复杂逻辑的迭代计算，非常适合应用在海量数据的快速且复杂计算需求中。

（2）实时数据计算经过几年的发展，到目前为止主要发生了 3 次大的变更：

Storm：Storm 可以称得上是大数据行业的第一代实时数据计算引擎，主要用于处理海量数据的实时计算需求。
Spark Streaming：属于 Spark 生态圈，它在 Spark 离线计算的基础上实现了微批处理，可以实现“秒”级别延迟的近实时数据计算。在实际工作中，“秒”级别的延迟其实是可以满足大部分的实时计算需求的。
Flink：Flink 是新一代的实时数据计算引擎，最近这几年在企业中应用得越来越多，它包含 Storm 和 Spark 的优点。它既可以实现真正意义上的实时数据计算，也有自己的生态圈，以及支持 ON YARN、高级 API 等特性。目前在实时数据计算领域，Flink 是最优的选择。

（1）表格内容说明：

Native：来一条数据处理一条数据，真正意义上实现了实时数据计算。
Mirco-Batch：将数据划分为小批，一小批一小批地处理数据，近实时数据计算。
At-Least-Once：至少一次，表示数据至少被处理一次，可能会重复处理。但是在数据累加场景中，它无法保证数据的准确性。
Exectly-Once：仅一次，表示数据只被处理一次。严谨来说这里的“仅一次”表示对最终结果的影响只有一次。
Ack：Storm 中的一种消息确认机制，可以保证数据不丢，但是无法保证不重复，为 At-Least-Once 语义提供支持。
Checkpoint：数据快照机制，为 Exectly-Once 语义提供支持。
组合式：基础 API，使用不方便。
声明式：提供的是高级 API，例如 filter()、count() 等函数可以被直接使用，比较方便。

（2）在实际工作中选择何种实时数据计算引擎建议：

需要关注实时数据是否需要进行状态管理。
语义级别是否有特殊要求，例如：At-Least-Once 或 Exectly-Once。
如果是独立的小型项目且需要低延迟的场景，则建议使用 Storm。
如果在项目中已经使用了 Spark，并且“秒”级别的实时处理可以满足需求，则建议使用 Spark Streaming。
如果要求语义级别为 Exectly-Once，并且数据量较大，要求高吞吐低延迟，需要进行状态管理，则建议使用 Flink。

5，数据分析技术框架

（1）典型的离线 OLAP 数据分析引擎如下：

Hive：主要提供通过 SQL 分析 HDFS 中海量数据的能力。HDFS 中存储的都是离线数据，所以 Hive 适合做海量数据的离线统计分析。Hive 的 SQL 语句在底层会被转化为 MapReduce 任务去执行，MapReduce 任务的特点是稳定和可靠。不过由于 MapReduce 是基于磁盘的，计算效率相对较低，所以如果你对计算速度要求不是特别高，但是对计算的稳定性要求比较高，那 Hive 是非常合适的。企业在构建离线数据仓库时，Hive 是首选的工具。在离线 OLAP 分析领域，Hive 是必不可少的。
Impala：功能类似于 Hive，可以直接兼容 Hive 的元数据，即在 Hive 中创建的表可以在 Impala 中直接使用，两者可以无缝集成。

Impala 的优点是：底层不需要经过 MapReduce，它自己实现了底层的计算引擎，主要是以内存的代价换取查询效率的提高。如果要在 Web 页面中提供一个海量数据统计分析功能，肯定希望在输入 SQL 语句后很快看到返回的结果，那对计算的效率要求就比较高了，使用 Hive 就不太合适了，比较适合使用 Impala 这种基于内存的计算引擎。
Impala 也有缺点：因为它是基于内存的，所以稳定性相对比较差，如果查询的数据量比较大，则内存可能扛不住，最终导数内存溢出，无法计算出结果。

Kylin：主要是为了解决 TB 级别数据的 SQL 分析需求。其核心是预计算，需要我们提前配置好计算规则，每天定时将计算结果存储在 HBase 中。在使用时，直接查询聚合后的结果数据，这样速度会很快（因为聚合后的数据量没有那么大了）。所以，Kylin 适合用于一些需求固定的报表类分析需求。如果需求灵活多变，则 Kylin 就无法发挥最优性能了。

说明：

计算引擎：Hive 的计算引擎默认是 MapReduce，也支持 Tez 或者 Spark。Impala 的计算引擎是通过 C++ 自研的 MPP 引擎。Kylin 的计算引擎可以使用 MapReduce 或者 Spark。
计算性能：Hive 底层会使用 MapReduce，所以计算性能相对一般，不过可以考虑使用 Tez 或者 Spark 引擎来提高性能。Impala 是基于内存计算的，计算性能比较好。Kylin 底层可以使用 MapReduce 或者 Spark 引擎，使用 Spark 引擎时计算性能也比较好。
稳定性：Impala 是全部基于内存的，所以稳定性较差。Hive 和 Kylin 底层都可以使用 MapReduce，所以稳定性相对较高。
数据规模：Hive 比较适合 TB 级别的数据分析，数据规模太大会导致计算时间过长。Impala 也比较适合 TB 级别的数据分析，如果数据规模太大则内存会出现瓶颈。 Kylin 比较适合 TB 和 PB 级别的数据分析，因为它会提前对数据进行预计算，在海量数据下也可以提供较好的性能。
SQL支持程度：在 Hive 中定义了简单的类 SQL 查询语言（HQL）。Impala 可以兼用 HQL。Kylin 支持标准 SQL。

（2）典型的实时 OLAP 数据分析引擎如下：

Druid：主要针对时间序列数据提供低延时的数据写入及快速交互式 SQL 查询，适合被应用在海量实时数据的交互式分析场景中。其可以基于时间维度对实时产生的明细数据自动实时聚合，提高查询效率。它有一个比较明显的缺点——对 SQL 支持有限。在 Druid 0.18 版本之前它是不支持 JOIN 操作的，从 0.18 版本开始它有限支持 JOIN 操作，目前主要支持 INNER JOIN、LEFT JOIN 和 CROSS JOIN。
ClickHouse：可以提供海量实时数据的快速写入，以及基于 SQL 的快速实时查询，适合应用在海量实时数据的交互式分析场景中。其支持非标准 SQL，有限支持 JOIN 操作，目前在实时数据仓库领域应用得比较广泛。
Doris：可以通过 SQL 实现实时数据分析，适合应用在海量实时数据的交互式分析场景中。其对 SQL 支持比较好，支持 JOIN 操作。Doris 和 ClickHouse 是比较类似的，但是 Doris 目前的成熟度暂时还不如 ClickHouse。

说明：

查询性能：这 3 个组件的查询性能都比较高。
高并发：Druid 和 Doris 可以支持高并发，ClickHouse 的并发能力有限。
实时数据摄入：因为都属于实时 OLAP 引擎，所以它们都支持实时数据摄入。
实时数据更新：Druid 是不支持实时更新的，只能通过后台批处理任务实现覆盖更新。ClickHouse 支持实时更新，只是功能比较弱。Doris 可以正常支持实时更新。
支持 JOIN 操作：在基于 SQL 实现统计分析时，是否支持 JOIN 操作是一个比较重要的指标。Druid 和 ClickHouse 都支持 JOIN 操作，但是支持度有限。Doris 可以正常支持 JOIN 操作。
SQL 支持程度：Druid 对 SQL 的支持度是有限的，ClickHouse 支持非标准 SQL，Doris 支持标准 SQL（相对较好）。
成熟程度：Druid 和 ClickHouse 的成熟程度比较高，Doris 目前正处于快速发展阶段。
运维复杂度：ClickHouse 运维比较复杂，Druid 运维难度中等，Doris 运维最简单。

6，任务调度技术框架

（1）常见的分布式任务调度系统有：

Azkaban：Azkaban 是由 Linkedin 开源的一个批量工作流任务调度器，用于在一个工作流内以一个特定的顺序运行一组工作和流程。
Oozie：Oozie 是由 Cloudera 公司贡献给 Apache 的基于工作流引擎的开源框架，主要用于 Hadoop 平台的开源工作流调度。
DolphinScheduler：DolphinScheduler（原 EasyScheduler）是由中国易观公司开源的一款分布式、去中心化、易扩展的可视化 DAG 工作流任务调度平台。该平台致力于解决数据处理流程中错综复杂的依赖关系，使调度系统在数据处理流程中“开箱即用”。DolphinScheduler 于 2021 年 3 月 18 日正式成为 Apache 顶级项目，中文名为“海豚调度”。

（2）三者比较：

比较项	Azkaban	Oozie	DolphinScheduler
任务类型	Shell脚本及大数据任务	Shell脚本及大数据任务	Shell脚本及大数据任务
任务配置	通过自定义DSL语法配置	通过XML文件配置	通过页面拖拽方式配置
任务暂停	不支持	支持	支持
高可用 (HA)	通过DB支持HA	通过DB支持HA	支持HA(多Master和多Worker)
多租户	不支持	不支持	支持
邮件告警	支持	支持	支持
权限控制	粗粒度支持	粗粒度支持	细粒度支持
成熟度	高	高	中
易用性	高	中	高
所属公司	Linkedin	Cloudera	中国易观

说明：

任务类型：Azkaban、Oozie 和 DolphinScheduler 都可以支持传统的 Shell 任务，以及大数据任务，包括 MapReduce、Hive、Sqoop、Spark 等。
任务配置：Azkaban 中任务的配置需要自定义 DSL 语法，这有点类似于 Properties 配置文件（先通过 Key-Value 的形式定义具体的任务，以及任务之间的依赖关系；然后将配置好的文件压缩成 Zip 包上传到 Azkaban 平台中；最后在 Azkaban 平台中配置任务触发时间）。Oozie 中的任务配置是通过 XML 文件进行的，直接在 XML 文件中指定具体的任务、任务之间的依赖关系和任务触发时间。DolphinScheduler 中的任务配置是比较简单的：直接在可视化页面中通过拖拽的方式配置任务相关信息。
任务暂停：Azkaban 中的任务一旦启动，则不能暂定，只能停止这个任务流再重新执行。Oozie 和 DolphinScheduler 支持任务暂停功能。
高可用：Azkaban 中包括 Web Server 和 Executor Server。其中，Executor Server 可以有多个，Web Server 只有一个。Web Server 主要提供 Web 页面服务，存在单点故障。Executor Server 主要负责执行任务，通过底层 DB 实现数据共享，可以支持 HA。Oozie 也是通过底层 DB 支持 HA。DolphinScheduler 通过多个 Master 和多个 Worker 可以支持 HA。
多租户：Azkaban 和 Oozie 不支持多租户，DolphinScheduler 支持多租户。
邮件告警：Azkaban、Oozie 和 DolphinScheduler 都可以提供任务失败时通过邮件告警，如果有更多告警需求，则可以支持二次开发。
权限控制：Azkaban 和 Oozie 只提供了粗粒度的权限控制，可以支持“用户”“用户组”级别的访问权限控制。DolphinScheduler 提供了细粒度的权限控制，可以进行“资源”“项目”“数据源”级别的访问权限控制。
成熟度：Azkaban 和 Oozie 已经在企业中广泛应用很长时间了，DolphinScheduler 是在 2021 年才正式开源的，所以目前 Azkaban 和 Oozie 的成熟度要高于 DolphinScheduler。
易用性：Azkaban 的任务配置相对来说是比较简单的——只需要定义简单的 Properties 配置文件即可。Oozie 的任务配置需要编写 XML 文件，支持的功能比较完善，但是配置过程比较复杂。DolphinScheduler 的任务配置是基于页面的，也比较简单。
所属公司：Azkaban 是 Linkedln 公司开源的。Oozie 是 Cloudeara 公司贡献给 Apache 的开源顶级项目。DolphinScheduler 是中国易观公司贡献给 Apache 的开源顶级项目。相对而言，DolphinScheduler 更加符合中国人的使用习惯。

（3）在企业中进行分布式任务调度系统技术选型时，在基础核心功能区别不大的情况下，企业一般会重点考虑组件的成熟度和易用性这两个因素。

7，大数据底层基础技术框架

（1）大数据底层基础技术框架主要是指 Zookeeper。

（2）ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现，大数据生态圈中的 Hadoop（HA）、HBase、Kafka 等技术组件的运行都会用到 Zookeeper。

8，数据检索技术框架

（1）常见的全文检索引擎有：

Lucene 起步比较早，是 Java 家族中最为出名的一个开源搜索引擎，在 Java 世界中属于标准的全文检索程序，在全文检索领域属于标杆工具。它提供了全文检索的完整底层核心功能，功能短小精悍。但是，它提供的都是一些基础 API，使用起来比较烦琐，易用性较差。
Solr 是一个高性能、采用 Java 开发、基于 Lucene 的全文搜索服务器。它对 Lucene 做了封装，使用起来更加的方便，并且对外提供类似于 WebService 的接口，可以通过 HTTP 请求进行操作。最初 Solr 仅支持单机模式，在 2013 年，Solr 也跟进了分布式架构，推出了 Solr Cloud，支持海量数据下的全文检索需求。
Elasticsearch 是一个分布式的全文检素引擎。它同样对 Lucene 的功能做了封装，具有实时搜索、稳定、可靠、快速等特点。