基于火山引擎 EMR 构建企业级数据湖仓

作者：辛现银，火山引擎开源大数据平台 E-MapReduce 技术架构师

本文整理自火山引擎开发者社区技术大讲堂第四期演讲，主要为大家介绍了数据湖仓开源趋势、火山引擎 EMR 的架构及特点，以及如何基于火山引擎 EMR 构建企业级数据湖仓。

数据湖仓开源趋势

趋势一：数据架构向 LakeHouse 方向发展

什么是 LakeHouse？ LakeHouse 简言之是就是在 DataLake 基础上融合了 Data Warehouse 特性的一种数据方案，它既保留了 DataLake 分析结构化、半结构化、非结构化数据，支持多种场景的能力，同时也引入了 Data Warehouse 支持事务和数据质量的特点。

LakeHouse 定义了一种叫我们称之为 Table Format 的存储标准。Table format 有四个典型的特征：

• 支持 ACID 和历史快照，保证数据并发访问安全，同时历史快照功能方便流、AI 等场景需求。

• 满足多引擎访问：能够对接 Spark 等 ETL 的场景，同时能够支持 Presto 和 channel 等交互式的场景，还要支持流 Flink 的访问能力。

• 开放存储：数据不局限于某种存储底层，支持包括从本地、HDFS 到云对象存储等多种底层。

• Table 格式：本质上是基于存储的、 Table 的数据+元数据定义。

具体来说，这种数据格式有三个具体的实现：Delta Lake、Iceberg 和 Hudi。

三种格式提出的出发点略有不同，但是它们的场景需求里都不约而同地包含了事务支持和流式支持。而它们在具体的实现中也采用了比较相似的做法，即在数据湖的存储之上定义一个元数据，并跟数据一样保存在存储介质上面。这三者相似的需求以及相似的架构，导致了他们在演化过程中变得越来越相似。

可以看到，绝大部分特性这三者都是支持的。只不过在一些小的方面，三者之间是有一点区别的。这种相似性可能也会给用户的选型造成一些困扰。可以简单地从支持特性的区别以及对生态的支持等方面给选型做一些建议。

下面这个表格给出了三种格式在生态方面的支持情况（截止2022/8/18）：

最后有一个问题：Table Format 是不是一个终极武器？我们认为答案是否定的。主要有几方面的原因：

• 使用体验离预期有差距：由于 Table Format 设计上的原因，流式写入的效率不高，写入越频繁小文件问题就越严重；

• 有一定的维护成本：使用 Table Format 的用户需要自己维护，会给用户造成一定的负担；

• 与现有生态之间有一些 gap：开源社区暂不支持和 Table format 之间的表同步，自己做同步又会引入一致性的问题；

• 对业务吸引不够：由于以上三点原因，Table Format 对业务的吸引力就大打折扣了。

要怎么去解这些问题呢？现在业界已经有基于这些 Table Format 应用的经验、案例或者商业公司，比如 Data Bricks，基于 Iceberg 的 Tabluar，以及基于 Hudi 的 OneHouse 公司。通过这些公司的商业产品，用户无需直接接触底层组件，运维和底层优化都交由商业产品解决，负担就会减轻。而且商业公司还有能力提供上层的 ETL 管道等产品，有了这些产品，用户即可容易地从原有架构迁移到成熟产品上。

所以我们看到，LakeHouse 并不等于 Table Format，而是等于 Table Format 加上一些上层建筑。这些上层建筑可以是商业公司提供的，但我们还是期望能有一些来自社区。能提升用户体验，解决维护问题，这是我们最终期望的形态。

趋势二：计算向精细化内存管理和高效执行方向发展，榨干硬件性能

数据湖的本质是起一堆 task 然后做暴力的计算，当引擎逐渐完善之后，对于性能的需求就会上来，不可避免地要朝精细化的内存管理以及高效的执行这个方向发展。

现在我们看到在计算方面，社区出现了两个趋势：Native 化和向量化（Vectorized)。 Native 化有两个典型的代表：

• Spark：去年官宣了 Photon 项目，宣称可以在 tpcs 测试集上达到 2X 的加速效果。

• Presto：现在在做 Velox 的 native 引擎。 Velox 引擎现在还不太成熟，但是根据 Presto 社区的宣称，它可以达到原来 1/3 的成本。所以我们可以猜测，等价情况下可以获得 3X 的性能提升。

除了以上两者，近几年火起来的 ClickHouse 和 Doris 也是 Native 化的一个表现。

另外一个趋势是向量化。说到这里要提一句，Codegen 跟向量化，都是从数据仓库而不是 Hadoop 体系的产品中长出来的：Codegen 是 Hyper 提出的技术，而向量化则是 MonetDB 提出的，所以计算引擎的精细化也是沿着数仓开辟的路子在走。Spark 等 Hadoop 体系均走了 Codegen 的道路，因为 Java 做 Codegen 比做向量化要更容易一些。但是现在人们发现可能向量化是一个更好的选择，向量化可以一次处理一批数据，而不只是一条数据。其好处是可以充分利用 CPU 的一些特性，比如 SIMD，Pipeline 执行等。

趋势三：多模计算，即组件边界逐渐模糊，向全领域能力扩展

这种趋势近年来已经越来越明显了，比如 Spark ，最早它是一个批处理引擎，后来补上了 Streaming 和 AI 的能力；Trino 是一个 OLAP 引擎，现在也在大力发展批式计算；Flink 是一个流引擎，后来加上了批式计算和 AI 的能力；Doris 则在加强 multi-catalog……所以各家引擎都尽量多地去囊括用户场景。

这种多模计算产生的结果就是，领域内彼此差别不大的场景，技术会逐渐收敛到一个最优解，最终只有一两个引擎获得成功。差别相差比较大的场景，则在每个场景形成一两个寡头，寡头跨场景的能力则竞争力很弱。

趋势四： 分析实时化

大数据最早是批式计算的形式，但理想的状态是纯流式的方式。分析实时化的表现有（近）实时引擎和流引擎。

• （近）实时引擎

  • ClickHouse：近实时 OLAP 引擎，宽表查询性能优异
  • Doris：近实时全场景 OLAP 引擎
  • Druid：牺牲明细查询，将 OLAP 实时化，毫秒级返回

• 流引擎

  • Flink：流计算逐步扩大市场份额
  • Kafka SQL：基于 Kafka 实现实时化分析
  • Streaming Database：Materialize 和 RisingWave 在开发的一种产品形态，效果类似于 Data Bricks 的 Data Live Table

企业构建数据湖仓的挑战

企业在构建数据湖仓时面临的挑战我们总结了一下，主要分为以下 5 个方面：

• 整体数据链路复杂：即使是开发一个小的 APP，要搭建起整个数据链路也是很复杂的，比如数据回流需要写数据库；日志要回流，要基于回流数据做指标计算，回流数据还要转储，还要做 CDC；基于转储数据还要做 ETL 进行分析。

• 湖仓需求多样：如果有机器学习的需求，就需要进行特征工程等一系列步骤，这些步骤也催生了数据湖仓的多种需求，包括支持批式、流失计算和交互式数据科学等各种场景。

• 湖仓数据来源广泛：包括业务交易数据、业务资产数据、用户行为数据、上下游产生的中间数据等。

• 数据开发中参与角色众多：包括管理者、一线业务人员、业务开发、基础设施参与人员等等。

• 企业往往需要根据平台进行二次开发：基础设施无法直接对接业务，根据业务特点灵活定制平台，解决方案平台化、产品化等。

这样就衍生出来一系列问题，主要包括稳定性、扩展性、功能、性能、成本、运维、安全、生态这 8 个方面。企业如果要单方面解决这些问题，哪怕是其中一个，可能也要花费巨大的人力物力。火山引擎 EMR 即是这样一个平台，帮助用户解决这些挑战的开源大数据平台。

基于火山引擎 EMR 构建企业级数据湖仓

火山引擎 EMR

一句话总结来说，火山引擎 EMR 是开源大数据平台 E-MapReduce，提供企业级的 Hadoop、Spark、Flink、Hive、Presto、Kafka、ClickHouse、Hudi、Iceberg 等大数据生态组件，100% 开源兼容，支持构建实时数据湖、数据仓库、湖仓一体等数据平台架构，能帮助用户轻松完成企业大数据平台的建设，降低运维门槛，快速形成大数据分析能力。

火山引擎 EMR 有以下 4 个特点：

• 开源兼容&开放环境：100% 兼容社区主流版本，满足应用开发需求；同时提供半托管的白盒环境，支持引导操作与集群脚本能力。

• 引擎企业级优化：引入了 Spark、Flink 等核心引擎的企业级特性优化及安全管理。

• Stateless 云原生湖仓：把状态外置做成存算分离的架构。

• 云上便捷运维：提供一站式云托管运维的能力与组件，让用户能够分钟级地创建和销毁集群，同时提供精细化的集群运维监控告警能力。

Stateless、瞬态集群

Stateless 是指把所有有状态的数据外置，让用户的计算集群变成无状态的集群。这些有状态的组件包括：History Server、表的元数据、平台的元数据、审计日志、中间数据等。有了这样一个完全外置的 Stateless 集群，就可以达成极致的弹性伸缩状态。

状态外置有两个重要的组件，Hive Metastore 和 各个 Public History Server。

Hive Metastore Service: 中心化元数据托管服务

我们把 Hive Metastore 做成了一个公共服务，用户可以选择独占或共享一个 Metastore 的实例。如果用户期望节省成本，或者是公司用户，那么两个部门之间可以使用一个 Hive Metastore service；而对于一些要求比较高的部门，可以单独建一个 Metastore Service 的实例。

持久化的 History Server 服务

我们把 YARN、Spark、Flink、Presto 这几种 History Server 都从引擎中剥离出来，做成了一个 Public History Server 的服务。该服务有几个特点：

• 它是独立于集群之外运行的一个常驻服务；

• 提供了持久化的 History 的数据存储。当该集群销毁之后，历史数据还可保存 60 天。

• 提供原生的 History Server UI，用户不会感觉生疏。

• 租户间 History 数据隔离。

• 更加友好的使用体验：由于是独立的服务，相对于组件内置 History Server 需要绑定公网并开放 8443 端口才能访问，Public History Server 真正做到了开箱即用，无需其它额外配置。同时集成 IAM SSO 准入认证，通常情况下用户从 EMR 管控端跳转到 Public History Server 可以实现无感 SSO 认证登录，无需再次输入用户登录凭证。

存算分离，弹性伸缩

这部分火山引擎 EMR 有 CloudFS 和 TOS 两个数据存储层，冷数据可以存储在对象存储 TOS 上。CloudFS 相当于构建在 TOS 层之上，提供兼容 HDFS 语义的存储，提供了缓存加速的功能，我们可以把一些温数据放在 CloudFS 上。我们在引擎内部内置一些本地缓存，用于缓存热数据。

分层缓存能够弥补企业上云之后，数据因保存在对象存储所造成的性能损失。另外 Cloud FS 提供 HDFS 的语义，可便于开源组件切入。

云托管，易运维

火山引擎 EMR 在管控面提供了很多工具，便于管理员管理整个集群，包括集群管理、服务管理、节点管理、日志中心、配置中心、用户权限、弹性伸缩等，用户可以到火山引擎上建一个最小规格集群体验一下：https://www.volcengine.com/product/emr

用户友好

在用户侧，火山引擎 EMR 也提供了一个作业管理的界面，提供全局视角查看集群资源消耗、异常情况等。同时该界面提供一键查看作业详情，作业诊断等功能，包括不限于异常探测、运行资源消耗、优化建议等。未来我们还期望能够基于作业的提供一些优化建议，比如参数调整等。

基于火山引擎 EMR 构建企业级数据湖仓

接下来我们通过几个案例来看一下构建企业级数据湖仓的最佳实践。

案例 1：多元化分析平台

多元化分析是指既有离线分析的场景，又有交互式分析的场景，最好还有高性能场景来支持应用层直接使用数据集市中的数据。

我们的用户中，某互联网企业平台部门期望基于业务数据构建分析平台，支持多种分析负载，包括可视化大屏、报表系统、自助分析，以及开发分析应用等。

要搭建这样一个多元化分析平台，可以通过 DataLeap 进行数据开发，让数据通过离线方式或实时同步的方式流入数据库仓。然后基于 Spark/Hive/Presto/Trino 进行批式数据分析和交互式分析。对于流式处理，可以把数据转储到 Cloud FS 和 TOS，基于流式做出一个计算结果，上传到 Clickhouse 和 Doris 来满足一些高性能分析的场景。

案例 2：高性能实时数仓

某头部直播业务实时数仓 100+W/s 数据入仓速度，支持横向扩展。通过流式计算引擎计算后，明细数据进入 Doris 集群 ODS 层，数据聚合计算后进入 DWS 层，数据指标经计算后存入 ADS 层。数据支撑在线更新。由 Doris 对数据应用层提供服务，支持在线、离线查询分析，支持几十万级 QPS。

该业务数据量比较大，同时对数据分析的时间性要求比较高，希望业务人员能通过实时查看业务指标的变化快速做出反应，达到精准营销的效果。

该方案是让 Flink 把数据直接流入 Doris，即原始数据直接到 Doris 的 ODS 层。然后在 Doris 里边做 ODS 到 DWD 到 DWS 到 ADS 这几层的转化。Doris 本身的性能可以提供时延很短的查询体验。

案例 3：实时计算

对性能要求再高一些的场景，我们就推荐使用实时计算的方式，数据省略掉中间各层。计算在 Flink 里完成，结果直接写到 RDS/ Redis，这是一种纯实时的方式。

某车联网公司，实时采集运营的 500 辆新能源汽车行驶和电池数据进行实时分析和告警，每 5 分钟采集一次，日增量在 10GB，数据通过消息队列 Kafka 或 Pulsar 汇聚到大数据平台，使用 Flink 流计算引擎进行毫秒级实时指标计算，计算结果存储到 RDS 中供平台进行实时数据展示。

案例4：在线机器学习

还有一种是在线机器学习的场景。在这种场景下，数据通过离线的方式存到数据湖仓。基于离线的数据，可以通过 Spark 进行特征抽取及特征工程，然后把提取出来的特征再返存到湖仓或者 HBase 等键值存储。 基于这些离线的数据可以进行离线训练，比如通过 Spark MLlib 搭建传统的机型学习模型，或者通过 TensorFlow 进行深度模型的训练，把深度训练出来的模型部署到模型服务中。

在线这一侧，数据通过 Kafka 流入 Flink 进行在线特征抽取，然后把在线特征放在 Redis。同时在线部分的增量数据可用 TensorFlow 进行增量训练，把增量模型也导入模型服务里。模型服务根据原来批式训练出来的模型和增量模型做成实时的 AI 服务，可满足实时风控等对时间要求比较高的场景。

火山引擎 EMR 湖仓方向未来规划

最后将和大家分享火山引擎 EMR 在湖仓方向未来的规划。

1. 数据加速：我们期望进一步加速数据分析。因为企业上云之后，第一痛点就是数据放到对象存储之后性能是否会下降。要解决这个问题，我们希望能够在数据缓存（包括文件级 Cache 和 Page 级 Cache）和索引方面（包括 Bitmap、Bloom Filter）做一些工作来弥补这个 gap。

2. 解决刚需痛点场景：我们也期望能够解决一些刚需的用户痛点场景，比如：分析 CDC 数据和多路径解决数据湖仓割裂的问题。对于后者，可以尝试：

   1. Doris 直接加速访问 HMS 中的 Hive/Iceberg/Hudi 表，实现湖仓互通。
   2. 持续优化基于 Iceberg 的数据湖方案，使得性能接近仓的体验。

3. 拥抱开源：我们希望将工作合入到开源社区，包括 Data Block Alluxio 的功能和性能优化；Doris MultiCatalog、元数据服务化、冷热分离优化；Iceberg 二级索引等。

4. AI4Data（数据智能管家）：我们的长期规划是做一个智能数据管家，能做到：

   1. 自动诊断高频低性价比 SQL 及作业；

   2. 自动优化用户 SQL 及作业，智能地从数据分布、Cache、Index、物化视图等维度来优化用户账单；

   3. 智能运维：

      1. 集群负载过高时，自动扩容；负载降低时，自动收缩。
      2. 集群节点故障时，做到用户完全无感知地 Failover。
      3. 自动地实现数据均衡分布。

5. 产品打磨：在产品侧，我们的第一目标是打磨产品，先把产品底座做坚实。对新功能持比较谨慎的态度。我们会在管控方面（包括创建集群体验优化、弹性伸缩优化等）、作业开发与管理方面与周边生态方面做进一步的打磨。

Q&A

Q：可否详细介绍一下火山引擎 EMR 的学习成本、易用性、兼容性、性能方面的内容。
A：火山引擎 EMR 100% 兼容开源社区主流版本，所以在引擎方面的学习是零成本的。在页面管控上，因为它是一种交互式的应用体验，所以学习成本也非常低。

在性能方面，我们在引擎侧做了很多的特性优化。前面在未来规划里也提到了，我们会在缓存和索引方面做大量的工作。

Q：EMR 具体的应用场景有哪些，涉及到哪些行业？
A：EMR 的应用场景范围可非常大，因为 EMR 是一个大数据技术栈，所以大数据的应用场景就是 EMR 的应用场景，也 cover 批式、流式、交互式还有机器学习的场景。

Q：目前主流的数据湖技术只解决了更新大表、访问性能、流式消费的问题，仍然遗留了小文件，导致性能损耗兼容性和流式更新等性能易用性相关的问题。火山引擎 EMR 构建数据湖仓是否解决了这些问题？
A：我们知道小文件问题是数据湖新 table format 的一个本质问题，所以在本质上解决它是不太可能的，但是火山引擎 EMR 做了一些列内部特性的开发，最大程度弥补这样一些使用上的问题。

Q：Stateless EMR 支持计算存储分离，但是 ClickHouse、Doris 都是存储计算一体的 OLAP 数据库。那存储计算分离和不分离的利弊有哪些，选型的时候有没有一些关键的考量？
A：ClickHouse 和 Doris 很难做到存储计算分离，那么我们在具体在做选型的时候就要考虑到这一点：你是否需要一个极致的分析引擎。如果是，就要选择 Doris；如果不是，可以选择存储计算分离的 Presto。此外还需要综合考虑成本，比如 Presto 存储计算分离，成本是比较极致的；Doris 的弹性伸缩可能就不是很方便了。所以选型方面需要综合考虑这些点。