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