随着大数据行业的发展，大数据生态圈中相关的技术也在一直迭代进步，目前大数据生态圈中的核心技术总结下来如图所示
1、数据采集技术框架 (参见：flume 前世今生 / 开源数据采集组件比较: scribe、chukwa、kafka、flume)
数据采集也被称为数据同步。随着互联网、移动互联网、物联网等技术的兴起，产生了海量数据。这些数据散落在各个地方，我们需要将这些数据融合到一起，然后从这些海量数据中计算出一些有价值的内容。此时第一步需要做的是把数据采集过来。
数据采集是大数据的基础，没有数据采集，何谈大数据！数据采集技术框架包括以几种
- Flume、Logstash 和 FileBeat 常用于日志数据实时监控采集，它们之间的细节区别见表1；
-
Sqoop 和 Datax 常用于关系型数据库离线数据采集，它们之间的细节区别见表2
-
Cannal 和 Maxwell 常用于关系型数据库实时数据采集，它们之间的细节区别见表3
2、数据存储技术框架 （参见：hadoop(一):深度剖析hdfs原理 / HBase(六): HBase体系结构剖析（上) ）
数据的快速增长推动了技术的发展，涌现出了一批优秀的、支持分布式的存储系统，数据存储技术框架包括 HDFS、HBase、Kudu、Kafka 等
- HDFS 它可以解决海量数据存储的问题，但是其最大的缺点是不支持单条数据的修改操作，因为它毕竟不是数据库。
- HBase 是一个基于HDFS的分布式NoSQL数据库。这意味着，HBase可以利用HDFS的海量数据存储能力，并支持修改操作。但HBase并不是关系型数据库，所以它无法支持传统的SQL语法。
- Kudu 是介于HDFS和HBase之间的技术组件，既支持数据修改，也支持基于SQL的数据分析功能；目前Kudu的定位比较尴尬，属于一个折中的方案，在实际工作中应用有限。
- Kafka 常用于海量数据的临时缓冲存储，对外提供高吞吐量的读写能力。
3、分布式资源管理框架
在传统的IT领域中，企业的服务器资源（内存、CPU等）是有限的，也是固定的。但是，服务器的应用场景却是灵活多变的。例如，今天临时上线了一个系统，需要占用几台服务器；过了几天，需要把这个系统下线，把这几台服务器清理出来。
在大数据时代到来之前，服务器资源的变更对应的是系统的上线和下线，这些变动是有限的。
随着大数据时代的到来，临时任务的需求量大增，这些任务往往需要大量的服务器资源。如果此时还依赖运维人员人工对接服务器资源的变更，显然是不现实的。
因此，分布式资源管理系统应运而生，常见的包括 YARN、Kubernetes 和 Mesos，它们的典型应用领域如图5所示。
4、数据计算技术框架 （参见： Spark(一): 基本架构及原理 / 流式处理框架对比 / 六：大数据架构 - Flink + AI / 一：大数据架构回顾-Lambda架构 ）
数据计算分为离线数据计算和实时数据计算；大数据中的离线数据计算引擎经过十几年的发展，到目前为止主要发生了3次大的变更
- MapReduce 可以称得上是大数据行业的第一代离线数据计算引擎，主要用于解决大规模数据集的分布式并行计算。MapReduce计算引擎的核心思想是，将计算逻辑抽象成Map和Reduce两个阶段进行处理。
- Tez 计算引擎在大数据技术生态圈中的存在感较弱，实际工作中很少会单独使用Tez去开发计算程序。
- Spark 最大的特点就是内存计算：任务执行阶段的中间结果全部被放在内存中，不需要读写磁盘，极大地提高了数据的计算性能。Spark提供了大量高阶函数（也可以称之为算子），可以实现各种复杂逻辑的迭代计算，非常适合应用在海量数据的快速且复杂计算需求中。
实时数据计算：业内最典型的实时数据计算场景是天猫“双十一”的数据大屏。数据大屏中展现的成交总金额、订单总量等数据指标，都是实时计算出来的；用户购买商品后，商品的金额就会被实时增加到数据大屏中的成交总金额中；用于实时数据计算的工具主要有以下3种
- Storm 主要用于实现实时数据分布式计算。
- Flink 属于新一代实时数据分布式计算引擎，其计算性能和生态圈都优于Storm。（高吞吐、低延时）
- SparkStreaming 组件也可以提供基于秒级别的实时数据分布式计算功能。
Spark Streaming和Storm、Flink之间的区别见表
目前企业中离线计算主要使用Spark，实时计算主要使用Flink（高吞吐、低延时）
5、数据分析技术框架 （参见: Hive(一):架构及知识体系 / StarRocks / Durid(一): 原理架构 / 一、Doris演进史 / kylin(一): 原理架构 ）
数据分析技术框架包括 Hive、Impala、Kylin、Clickhouse、Druid、Doris等，它们的典型应用场景如图7所示。
分类：
Hive、Impala和Kylin属于典型的离线OLAP数据分析引擎，主要应用在离线数据分析领域，它们之间的区别见表5。
- Hive 的执行效率一般，但是稳定性极高；
- Impala 基于内存可以提供优秀的执行效率，但是稳定性一般；
- Kylin 通过预计算可以提供PB级别数据毫秒级响应。
Clickhouse、Druid 和Doris属于典型的实时OLAP数据分析引擎，主要应用在实时数据分析领域，它们之间的区别见表6
- Druid和Doris是可以支持高并发的，ClickHouse的并发能力有限；Druid中的SQL支持是有限的，ClickHouse支持非标准SQL，Doris支持标准SQL，对SQL支持比较好。
- Druid和ClickHouse的成熟程度目前相对比较高，Doris处于快速发展阶段
6、任务调度技术框架 (参见：2021~2022Apache大数据相关项目盘点)
务调度技术框架包括Azkaban、Ooize、DolphinScheduler等。它们适用于普通定时执行的例行化任务，以及包含复杂依赖关系的多级任务进行调度，支持分布式，保证调度系统的性能和稳定性，它们之间的区别见表7
它们之前的技术选型如图8所示
7、大数据底层基础技术框架 (参见：Zookeeper中的角色)
大数据底层基础技术框架主要是指Zookeeper。Zookeepe主要提供常用的基础功能（例如：命名空间、配置服务等），大数据生态圈中的Hadoop（HA）、HBase、Kafka等技术组件的运行都会用到Zookeeper。
8、数据检索技术框架 （参见：ES(一): 架构及原理 ）
随着企业中数据的逐步积累，针对海量数据的统计分析需求会变得越来越多样化：不仅要进行分析，还要实现多条件快速复杂查询。例如，电商网站中的商品搜索功能，以及各种搜索引擎中的信息检索功能，这些功能都属于多条件快速复杂查询的范畴。
在选择全文检索引擎工具时，可以从易用性、扩展性、稳定性、集群运维难度、项目集成程度、社区活跃度这几个方面进行对比。Lucene、Solr和Elasticsearch的对比见表8。
9、大数据集群安装管理框架 （参见：从大数据平台CDP的架构看大数据的发展趋势）
企业如果想从传统的数据处理转型到大数据处理，首先要做就是搭建一个稳定可靠的大数据平台。
一个完整的大数据平台需要包含数据采集、数据存储、数据计算、数据分析、集群监控等功能，这就意味着其中需要包含Flume、Kafka、HaDoop、Hive、HBase、Spark、Flink等组件，这些组件需要部署到上百台甚至上千台机器中。
如果依靠运维人员单独安装每一个组件，则工作量比较大，而且需要考虑版本之间的匹配问题及各种冲突问题，并且后期集群维护工作也会给运维人员造成很大的压力。
于是，国外一些厂商就对大数据中的组件进行了封装，提供了一体化的大数据平台，利用它可以快速安装大数据组件。目前业内最常见的是包括CDH、HDP、CDP等。
- HDP：全称是 Hortonworks Data Platform。它由 Hortonworks 公司基于 Apache Hadoop 进行了封装，借助于 Ambari 工具提供界面化安装和管理，并且集成了大数据中的常见组件， 可以提供一站式集群管理。HDP 属于开源版免费大数据平台，没有提供商业化服务；
- CDH：全称是 Cloudera Distribution Including Apache Hadoop。它由 Cloudera 公司基于 Apache Hadoop 进行了商业化，借助于 Cloudera Manager 工具提供界面化安装和管理，并且集成了大数据中的常见组件，可以提供一站式集群管理。CDH 属于商业化收费大 数据平台，默认可以试用 30 天。之后，如果想继续使用高级功能及商业化服务，则需要付费购买授权，如果只使用基础功能，则可以继续免费使用；
- CDP：Cloudera 公司在 2018 年 10 月份收购了 Hortonworks，之后推出了新一代的大数据平台产品 CDP（Cloudera Data Center）。CDP 的版本号延续了之前 CDH 的版本号。从 7.0 版本开始， CDP 支持 Private Cloud（私有云）和 Hybrid Cloud（混合云）。CDP 将 HDP 和 CDH 中比较优秀的组件进行了整合，并且增加了一些新的组件。
三者的关系如图9所示
10、大数据可视化 （参见：大数据可视化工具）
数据可视化是大数据『最后一公里』，BI唤醒沉睡的数据。传统型BI力求大而全的统一综合型报表和分析平台，侧重传统式报表开发，俨然一把屠龙刀。现互联网公司快速迭代的业务发展，需要的却是倚天剑，促使自助式BI和敏捷BI得以迅速发展。
时代召唤，传统BI巨头也逐渐向自助式BI和云BI转型。
参考资料：
