Flink 1.10 和 Hive 3.0 性能对比（附 Demo 演示 PPT）

作者：李劲松（之信）
如今的大数据批计算，随着 Hive 数仓的成熟，普遍的模式是 Hive metastore + 计算引擎。常见的计算引擎有 Hive on MapReduce、Hive on Tez、Hive on Spark、Spark integrate Hive、Presto integrate Hive，还有随着 Flink 1.10 发布后生产可用的 Flink Batch SQL。
Flink 作为一个统一的计算引擎，旨在提供统一的流批体验以及技术栈。Flink 在 1.9 合并了 Blink 的代码，并在 1.10 中完善了大量的功能以及性能，可以运行所有 TPC-DS 的查询，性能方面也很有竞争力，Flink 1.10 是一个生产可用的、批流统一的 SQL 引擎版本。
在搭建计算平台的过程中，性能和成本是选取计算引擎的很关键的因素。为此，Ververica 的 flink-sql-benchmark [1] 项目提供了基于 Hive Metastore 的 TPC-DS Benchmark 测试的工具，为了测试更靠近真正的生产作业：

• 测试的输入表都是标准的 Hive 表，数据全在与生产一致的 Hive 数仓中。其它计算引擎也能方便分析这些表。
• 数据的格式采用 ORC，ORC 是常用的生产文件格式，提供较高的压缩率，和较好的读取性能。
• 选取 TPC-DS Benchmark 的 10TB 数据集，10TB 的数据集是比较常见的生产规模。如果只有 1TB，完全可以在传统数据库中运行起来，不太适合大数据的测试。

我们在 20 台机器上测试了三种引擎：Flink 1.10、Hive 3.0 on MapReduce、Hive 3.0 on Tez，从两个维度测试了引擎的成绩：

• 总时长：直观的性能数据，但是可能会受到个别 queries 的较大影响。
• 几何平均：表示一组数的中心趋势，它可以更好的消除个别 queries 的较大影响，呈现较真实的平均数。

结果摘要：

• Flink 1.10 VS Hive 3.0 on MapReduce
  • Flink 总时长的性能是 Hive on MapReduce 的 8.7 倍。
  • Flink Queries 几何平均的性能是 Hive on MapReduce 的 7.8 倍。

 

• Flink 1.10 VS Hive 3.0 on Tez
  • Flink 总时长的性能是 Hive on Tez 的 2.1 倍。
  • Flink Queries 几何平均的性能是 Hive on Tez 的 2.0 倍。

 

运行总时间的对比成绩是：

Queries 几何平均的对比成绩是：

本文只测试了上述引擎和 10TB 的数据集，读者可以根据自己的集群规模，选取特定的数据集，使用 flink-sql-benchmark 工具来运行更多引擎的对比测试。
Benchmark 详情
Benchmark 环境
具体环境及调优说明：

• 计算环境：20 台机器，机器参数为 64 核 intel 处理器、256GB 内存、1 SSD 盘用于计算引擎、多块 SATA 盘用于 HDFS、万兆网卡。
• 集群环境：Yarn + HDFS + Hive。
• Flink参数：flink-conf.yaml [2]。
• Hive参数：主要调优了 MapJoin 的阈值，提高性能的同时避免 OOM。
• 选用较新的 Hadoop 版本(3.X)，并选用了较新的 Hive 和 Tez 版本

Benchmark 步骤
■ 环境准备

1. 准备 Hadoop (HDFS + YARN) 环境
2. 准备 Hive 环境

■ 数据集生成

1. 分布式生成 TPC-DS 数据集，并加载 TEXT 数据集到 Hive，原始数据是 Csv 的格式。建议分布式生成数据，这也是个比较耗时的步骤。（flink-sql-benmark 工具中集成了 TPC-DS 的工具）
2. Hive TEXT 表转换为 ORC 表，ORC 格式是常见的 Hive 数据文件格式，行列混合的存储有利于后续的快速分析，也有很高的压缩比。执行 Query：create table NAMEstoredas{FILE} as select * from SOURCE.{NAME};

如图，生成了 TPC-DS 官方说明的 7 张事实表和 17 张维表。

1. 分析 Hive 表，统计信息对于分析作业的查询优化非常重要，对于复杂的 SQL，Plan 的二手游戏账号购买平台地图执行效率有很大的差异。Flink 不但支持读取 Hive 的 Table 统计信息，也支持读取 Hive 的分区统计信息，根据统计信息进行 CBO 的优化。执行命令：analyze table ${NAME} compute statistics for columns;

■ Flink 运行 Queries

1. 准备 Flink 环境，搭建 Flink Yarn Session 环境，推荐使用 Standalone 或者 Session 模式，可以复用 Flink 的进程，加快分析型作业的速度。
2. 编写代码运行 Queries，统计执行时间等相关信息，具体代码可以直接复用 flink-sql-benchmark 里的 flink-tpcds 工程。
3. FLINK_HOME/flink run 运行程序，执行所有 queries，等待执行完毕，统计执行时间。

■ 其它引擎运行 Queries

1. 根据其它引擎的官网提示，搭建环境。
2. 得益于标准的 Hive 数据集，可以方便的使用其它引擎来读取 Hive 数据。
3. 在运行时，值得注意的是需要达到集群的瓶颈，比如 Cpu、比如 Disk，一定是有瓶颈出现，才能证明运行方式和参数是比较合理的，为此，需要一些性能调优。

Benchmark 分析
Flink 1.10
Flink 1.9 在合并 Blink 代码的时候，就已经完成了很多工作：深度 CodeGeneration、Binary 存储与计算、完善的 CBO 优化、Batch Shuffler，为后续的性能突破打下了扎实的基础。
Flink 1.10 继续完善 Hive 集成，并达到了生产级别的 Hive 集成标准，其它也在性能和开箱即用方面做了很多工作：

• Hive 多版本的支持，支持了 Hive 1.0 以后的主要版本。
• 向量化的 ORC 读，目前只在 Hive 2.0 以上版本才会默认开启。
  • Hive 1.X 版本的支持已经在进行中：FLINK-14802 [3]
  • Parquet 的向量化读支持也已经在开发中：FLINK-11899 [4]

 

• 基于比例的弹性内存分配，这不仅利于 Operator 可以更多的使用内存，而且大大方便了用户的配置，用户不再需要配置 Operator 内存，Operator 根据 Slot 弹性的拿到内存，提高了 Flink 开箱即用的易用性。详见 FLIP-53 [5]
• Shuffle 的压缩：Flink 默认给 Batch 作业开启中间数据落盘的方式，这有利于避免调度死锁的可能，也提供了良好的容错机制，但是大量的落盘可能导致作业瓶颈在磁盘的吞吐上，所以 Flink 1.10 开发了 Shuffle 的压缩，用 Cpu 换 IO。
• 新调度框架：Flink 1.10 也引入新了的调度框架，这有利于 JobMaster 的调度性能，避免并发太大时，JobMaster 成为性能瓶颈。

Flink 参数分析
Flink 1.10 做了很多参数的优化，提高用户的开箱即用体验，但是由于批流一体的一些限制，目前也是需要进行一些参数设置的，这里本文粗略分析下。
■ Table 层参数：

• table.optimizer.join-reorder-enabled = true：需要手动打开，目前各大引擎的 JoinReorder 少有默认打开的，在统计信息比较完善时，是可以打开的，一般来说 reorder 错误的情况是比较少见的。
• table.optimizer.join.broadcast-threshold = 1010241024：从默认值 1MB 调整到 10MB，目前 Flink 的广播机制还有待提高，所以默认值为 1MB，但是在并发规模不是那么大的情况下，可以开到 10MB。
• table.exec.resource.default-parallelism = 800：Operator 的并发设置，针对 10T 的输入，建议开到 800 的并发，不建议太大并发，并发越大，对系统各方面的压力越大。

■ TaskManager 参数分析：

• taskmanager.numberOfTaskSlots = 10：单个 TM 里的 slot 个数。
• TaskManager 内存参数：TaskManager 的内存主要分为三种，管理内存、网络内存、JVM 相关的其它内存。需要理解下官网的文档，才能有效的设置这些参数。
• taskmanager.memory.process.size = 15000m：TaskManager 的总内存，减去其它内存后一般留给堆内 3-5GB 的内存。
• taskmanager.memory.managed.size = 8000m：管理内存，用于 Operator 的计算，留给单个 Slot 300 - 800MB 的内存是比较合理的。
• taskmanager.network.memory.max = 2200mb：Task 点到点的通信需要 4 个 Buffers，根据并发大概计算得出需要 2GB，可以通过尝试得出，Buffers 不够会抛出异常。

■ 网络参数分析

• taskmanager.network.blocking-shuffle.type = mmap：Shuffle read 使用 mmap 的方式，直接靠系统来管理内存，是比较方便的形式。
• taskmanager.network.blocking-shuffle.compression.enabled = true：Shuffle 使用压缩，这个参数是批流复用的，强烈建议给批作业开启压缩，不然瓶颈就会在磁盘上。

■ 调度参数分析

• cluster.evenly-spread-out-slots = true：在调度 Task 时均匀调度到每个 TaskManager 中，这有利于使用所有资源。
• jobmanager.execution.failover-strategy = region：默认全局重试，需打开 region 重试才能 enable 单点的 failover。
• restart-strategy = fixed-delay：重试策略需要手动设置，默认是不重试的。

其它 timeout 相关参数是为了避免调度和运行过程中，大数据量导致的网络抖动，进而导致作业失败的问题。
Flink 1.11 及后续规划
后续 Flink 社区会在完善功能的同时进一步夯实性能：

• • 提供 SQL Gateway 以及 JDBC Driver，目前提供独立仓库，面向 Flink 1.10。[6] [7]
  • 提供 Hive 语法兼容模式，避免 Hive 用户的困扰。
  • 完善 ORC 和 Parquet 的向量化读。
  • N-Ary stream operator [8]：开发 table 层的 chain 框架，进一步避免 Shuffle 落盘导致的开销。