一文看懂大数据生态圈完整知识体系
徐葳
随着大数据行业的发展,大数据生态圈中相关的技术也在一直迭代进步,作者有幸亲身经历了国内大数据行业从零到一的发展历程,通过本文希望能够帮助大家快速构建大数据生态圈完整知识体系。
目前大数据生态圈中的核心技术总结下来如图1所示,分为以下9类,下面分别介绍。
图1
一、数据采集技术框架
数据采集也被称为数据同步。随着互联网、移动互联网、物联网等技术的兴起,产生了海量数据。这些数据散落在各个地方,我们需要将这些数据融合到一起,然后从这些海量数据中计算出一些有价值的内容。此时第一步需要做的是把数据采集过来。数据采集是大数据的基础,没有数据采集,何谈大数据!
数据采集技术框架包括以几种。
- Flume、Logstash和FileBeat常用于日志数据实时监控采集,它们之间的细节区别见表1;
- Sqoop和Datax常用于关系型数据库离线数据采集,它们之间的细节区别见表2;
- Cannal和Maxwell常用于关系型数据库实时数据采集,它们之间的细节区别见表3。
表1
表2
表3
Flume、Logstash和FileBeat的技术选型依据如图2所示
图2
Sqoop和Datax之间的技术选型依据如图3所示。
图3
Cannal和Maxwell之间的技术选型依据如图4所示
图4
二、数据存储技术框架
数据的快速增长推动了技术的发展,涌现出了一批优秀的、支持分布式的存储系统。
数据存储技术框架包括HDFS、HBase、Kudu、Kafka等。
- HDFS它可以解决海量数据存储的问题,但是其最大的缺点是不支持单条数据的修改操作,因为它毕竟不是数据库。
- HBase是一个基于HDFS的分布式NoSQL数据库。这意味着,HBase可以利用HDFS的海量数据存储能力,并支持修改操作。但HBase并不是关系型数据库,所以它无法支持传统的SQL语法。
- Kudu是介于HDFS和HBase之间的技术组件,既支持数据修改,也支持基于SQL的数据分析功能;目前Kudu的定位比较尴尬,属于一个折中的方案,在实际工作中应用有限。
- Kafka常用于海量数据的临时缓冲存储,对外提供高吞吐量的读写能力。
三、分布式资源管理框架****
在传统的IT领域中,企业的服务器资源(内存、CPU等)是有限的,也是固定的。但是,服务器的应用场景却是灵活多变的。例如,今天临时上线了一个系统,需要占用几台服务器;过了几天,需要把这个系统下线,把这几台服务器清理出来。
在大数据时代到来之前,服务器资源的变更对应的是系统的上线和下线,这些变动是有限的。随着大数据时代的到来,临时任务的需求量大增,这些任务往往需要大量的服务器资源。如果此时还依赖运维人员人工对接服务器资源的变更,显然是不现实的。因此,分布式资源管理系统应运而生,常见的包括YARN、Kubernetes和Mesos,它们的典型应用领域如图5所示。
图5
四、数据计算技术框架
数据计算分为离线数据计算和实时数据计算。
(1)离线数据计算。
大数据中的离线数据计算引擎经过十几年的发展,到目前为止主要发生了3次大的变更。
- MapReduce可以称得上是大数据行业的第一代离线数据计算引擎,主要用于解决大规模数据集的分布式并行计算。MapReduce计算引擎的核心思想是,将计算逻辑抽象成Map和Reduce两个阶段进行处理。
- Tez计算引擎在大数据技术生态圈中的存在感较弱,实际工作中很少会单独使用Tez去开发计算程序。
- Spark最大的特点就是内存计算:任务执行阶段的中间结果全部被放在内存中,不需要读写磁盘,极大地提高了数据的计算性能。Spark提供了大量高阶函数(也可以称之为算子),可以实现各种复杂逻辑的迭代计算,非常适合应用在海量数据的快速且复杂计算需求中。
(2)实时数据计算。
业内最典型的实时数据计算场景是天猫“双十一”的数据大屏。数据大屏中展现的成交总金额、订单总量等数据指标,都是实时计算出来的。用户购买商品后,商品的金额就会被实时增加到数据大屏中的成交总金额中。
- Storm主要用于实现实时数据分布式计算;
- Flink属于新一代实时数据分布式计算引擎,其计算性能和生态圈都优于Storm。
- Spark中的SparkStreaming组件也可以提供基于秒级别的实时数据分布式计算功能。
他和Storm、Flink之间的区别见表4。
表4
Storm、Spark、Flink 之间的技术选型依据如图6所示。
图6
因此,目前企业中离线计算主要使用Spark,实时计算主要使用Flink。
五、数据分析技术框架
包括Hive、Impala、Kylin、Clickhouse、Druid、Drois等,它们的典型应用场景如图7所示。
图7
Hive、Impala和Kylin属于典型的离线OLAP数据分析引擎,主要应用在离线数据分析领域,它们之间的区别见表5。
- Hive的执行效率一般,但是稳定性极高;
- Impala基于内存可以提供优秀的执行效率,但是稳定性一般;
- Kylin通过预计算可以提供PB级别数据毫秒级响应。
表5
Clickhouse、Druid和Drois属于典型的实时OLAP数据分析引擎,主要应用在实时数据分析领域,它们之间的区别见表6。
- Druid和Doris是可以支持高并发的,ClickHouse的并发能力有限;Druid中的SQL支持是有限的,ClickHouse支持非标准SQL,Doris支持标准SQL,对SQL支持比较好。
- 目前Druid和ClickHouse的成熟程度相对比较高,Doris处于快速发展阶段。
表6
六、任务调度技术框架
包括Azkaban、Ooize、DolphinScheduler等。它们适用于普通定时执行的例行化任务,以及包含复杂依赖关系的多级任务进行调度,支持分布式,保证调度系统的性能和稳定性,它们之间的区别见表7,它们之前的技术选型依据如图8所示。
表7
图8
七、大数据底层基础技术框架****
大数据底层基础技术框架主要是指Zookeeper。Zookeepe主要提供常用的基础功能(例如:命名空间、配置服务等),大数据生态圈中的Hadoop(HA)、HBase、Kafka等技术组件的运行都会用到Zookeeper。
八、数据检索技术框架
随着企业中数据的逐步积累,针对海量数据的统计分析需求会变得越来越多样化:不仅要进行分析,还要实现多条件快速复杂查询。例如,电商网站中的商品搜索功能,以及各种搜索引擎中的信息检索功能,这些功能都属于多条件快速复杂查询的范畴。
在选择全文检索引擎工具时,可以从易用性、扩展性、稳定性、集群运维难度、项目集成程度、社区活跃度这几个方面进行对比。Lucene、Solr和Elasticsearch的对比见表8。
表8
九、大数据集群安装管理框架****
企业如果想从传统的数据处理转型到大数据处理,首先要做就是搭建一个稳定可靠的大数据平台。
一个完整的大数据平台需要包含数据采集、数据存储、数据计算、数据分析、集群监控等功能,这就意味着其中需要包含Flume、Kafka、Haodop、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所示。
图9
以上内容出自于《大数据技术及架构图解实战派》一书。
目前本书已在京东平台上架,欢迎选购。
直达链接:https://item.jd.com/13264403.html
版权归原作者 bigdata1024 所有, 如有侵权,请联系我们删除。