众所周知,大数据组件繁多,百花齐放般的迷人眼。
对于没有参与建设过大数据平台的朋友来说,当前众多的大数据组件和平台架构容易让人迷失了方向。
本篇文章,首先介绍了大数据架构平台的组件架构,便于了解大数据平台的全貌,然后分别介绍数据集成、存储与计算、分布式调度、查询分析等方面的观点。最后,如果你希望对大数据平台架构有更深入的了解,欢迎找我领取集团大数据平台整体方案建议书
1. 大数据平台架构
从图上可以看出,大数据架构平台分为:数据集成、存储与计算、分布式调度、查询分析等核心模块。我们就沿着这个架构图,来剖析大数据平台的核心技术 。
2. 数据集成
2.1 日志同步
开源日志收集系统有 Sqoop、Flume、Logstash、Filebeat、Vector 等,其中 Flume 在云原生场景用得多,Vector 是一个很高效的日志同步工具,刚开源不久。
专家观点:
日志同步系统虽然本身比较成熟,但在平时工作中也属于重点,一是因为需要同步的数据量比较大,二是要保证日志输出的持续性,有 缓存机制最大限度保障不丢日志,始终保持平稳的运行状态。
2.2 数据抽取工具
大数据分析不能直接在原始的业务数据库上直接操作,所以需要抽取想要的数据到分析数据库或者分布式存储系统(例如 HDFS),常见数据抽取工具包括:DataX、BitSail 等 。
DataX 是阿里开源的一个异构数据源离线同步工具,致力于实现包括关系型数据库(MySQL、Oracle 等)、HDFS、Hive、ODPS、HBase、FTP 等各种异构数据源之间稳定高效的数据同步功能 。
BitSail 项目是头条刚开源的,基于 Flink 开发,在自己内部业务应用广泛。BitSail 支持多种异构数据源间的数据同步,并提供离线、实时、全量、增量场景下的全域数据集成解决方案。
专家观点:
数据集成非常重要,因为跟业务方相关的第一个环节就是数据集成,数据集成如果出现问题比如速度慢、丢数据等,都会影响到业务方数据的使用,也会影响业务方对大数据平台的信任度。
2.3 数据传输队列
数据传输有三种:
- Kafka:流式传输
- RabbitMQ:队列传输
- Pulsar:流式传输+队列传输
专家观点:
Kafka是Hadoop组件全家桶,名气更大,但是易用性还是差一点 。
Pulsar 跟Kafka很像,不过架构比Kafka更先进,属于后起之秀 。
3. 数据处理:数据存储、计算
3.1 数据存储:HDFS
HDFS 特点:横向扩展,数据容错性高。
专家观点:
对于 HDFS 来说,优化是一个很重要的事情,因为 HDFS 的集群规模比较大,又要稳定,又要持续不断的应对业务挑战,优化这一块还是很重要的。如果集群负载大时,访问延迟,会影响集群整体使用效率 。
HDFS 的优化趋势包括:架构改进、读写分离、读写优化等。
虽然 HDFS 是 分布式文件系统,但在实际场景中,由于 NameNode 的单点和小文件过多导致的压力过大问题,其管理的数据节点是有限的。分布式文件系统的新趋势类似 JuiceFS 的架构,采用「数据」与「元数据」分离存储的架构,从而实现文件系统的分布式设计,利用 元数据缓存极大提升整体文件系统的性能,同时兼容大数据和云原生场景的应用 。
3.2 数据计算
(1)离线计算引擎
在众多的计算引擎中,MapReduce、Hive、Spark 等通常用于离线处理,即批计算。Storm、Spark Steaming 等处理实时计算的场景较多,即流计算。不得不说的是,Flink 既可以用于流计算,也可以用于批计算 。
其中 Hive 的用途很广,也很可靠,底层基于 MapReduce 的封装,属于 Hadoop 全家桶组件之一,缺点是只能实现离线批处理 。
Spark 是非常高效的批处理工具,成熟,稳定,比 Hive 快很多,并且还能实现近实时的数据处理能力。Spark 功能全,架构新,基于 RDD,计算过程中优先利用内存,并优化中间的计算步骤。
专家观点:
Spark+ 数据湖是未来的发展方向。
离线的场景很丰富,但是缺乏处理的非常好的统一的计算引擎, hive和spark都无法做到,所以这一块未来还有很大的发挥空间。
(2)实时计算引擎优缺点及适用场景
实时计算引擎大体经过了三代,依次是:storm、spark streaming、Flink。其中 storm 和 spark streaming 现在用的很少,大部分公司都在用 Flink 。
专家观点:
Flink的优点是:可以实时的进行计算,在 处理流计算这个方向上是最好的组件,而且几乎可以替代近实时的业务场景。
缺点是对离线处理会略显不足,不太适合处理大批量的 离线数据集
Flink的优化方向很多:a. Flink在流处理稳定性上,虽然已经做到极细粒度,但是遇到阻塞时,会存在丢失数据的问题。需要加强稳定性。b. 实时性的提升:实时的优化是无底洞,业务需求能到秒级别、毫秒级别,怎么能让Flink在业务场景用得好,提升速度的同时,保持数据一致性,是Flink面临的挑战。
4. 数据调度
4.1 常用任务调度系统
提到常用的任务调度系统,大家都会想到非常多,包括但不限于:Crontab、Apache Airflow、Oozie、Azkaban、Kettle、XXL-JOB、DolphinScheduler、SeaTunnel 等,五花八门。
专家观点:
Apache DolphinScheduler(海豚调度)更专注于大数据场景,调度功能不复杂,但是足够把任务管理起来。并且它是中文的,这一点对于中文用户较友好。
Apache Airflow 国外用得多。
4.2 资源调度系统
资源调度系统主要包括 Yarn 和 Azkaban。
Yarn 用得广泛,上层很多组件都要支持,所以很受欢迎,对其优化很多。
Azkaban 是资源调度的小众分支,用的人不多。
5. 大数据查询
5.1 大数据查询引擎
常用的OLAP引擎对比:
专家观点:
曾经用 Presto 和 StarRocks 做过对比 Impala 的性能测试,结论如下:
结果上看 StarRocks 的性能确实很强大,速度最快,但三者对比提升相同量级的性能需要更多的 CPU、内存资源等;
Impala 在开启各项优化之后,效果是可以接近 StarRocks 的;
Presto 性能一般,而且发现跑部分 TPC-DS 测试时,调用 HMS API 的频率偶尔很高,曾经把 HMS 搞挂过。但是 Presto 的易用性感觉最好,差不多就是 开箱即用,配置很简单。并且支持 多源数据(多Catalog)的接入,但是随着数据湖对底层数仓存储层的统一,加上各个其他高效分析引擎对数据湖的支持,这块的优势也会被逐步抹平。
专家对查询引擎优化的观点:
查询引擎优化在大数据平台架构只算一环,不算难点,但确实很重要。整个大数据生态的上下游优化应该是逐步协同进行的,查询引擎上游的数据是需要下功夫治理的,不然 Impala 遇到比如小文件问题是很拖累性能的;查询引擎下游需要一个合适的平台作为数据的展示窗口,比如 BI 工具,或用协议比较通用的 客户端,像支持 MySQL 协议的 SR 和 Doris 这些,如果下游没法做比较好的数据展示,查询引擎再牛也没法让大家用起来。
5.2 大数据查询优化工具
大数据查询优化工具包括 Alluxio、JuiceFS 和 JindoFS。
专家观点:
Alluxio:
数据编排最为强大,市面上常见的存储系统、 云存储服务均可以直接接入,也可以自行实现相关 api 以接入其他自研存储系统,可以说 Alluxio 最为通用,既可用于云存储服务的缓存接入或数据编排,也可作为传统 HDFS 的 多集群数据编排。
JuiceFS:
提供了和 Alluxio 非常相似的功能,如元数据与数据分离的存储、 数据编排、与 Hadoop API 兼容、Fuse 等特性;
JuiceFS 也有不错的数据编排特性,元数据存储的方式比 Alluxio 更多元,主要用于云存储场景。
JindoFS:
局限于阿里云 oss 场景的分布式存储系统;
支持与 Alluxio 非常相似的功能,也能提供内存级的缓存加速;
但场景局限于 oss 内。
(本文部分文字来源 DataFunPro,由大数据梦想家编辑排版)