大数据架构平台搭建指南

众所周知，大数据组件繁多，百花齐放般的迷人眼。

对于没有参与建设过大数据平台的朋友来说，当前众多的大数据组件和平台架构容易让人迷失了方向。

本篇文章，首先介绍了大数据架构平台的组件架构，便于了解大数据平台的全貌，然后分别介绍数据集成、存储与计算、分布式调度、查询分析等方面的观点。最后，如果你希望对大数据平台架构有更深入的了解，欢迎找我领取集团大数据平台整体方案建议书

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，由大数据梦想家编辑排版）