更多技术交流、求职机会,欢迎关注字节跳动数据平台微信公众号,回复【1】进入官方交流群
本文整理自火山引擎开发者社区技术大讲堂第四期演讲,主要介绍了数据湖仓开源趋势、火山引擎 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 化。
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构建企业级数据湖仓
火山引擎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。
HiveMetastore 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 提供了很多工具,便于管理员管理整个集群,包括集群管理、服务管理、节点管理、日志中心、配置中心、用户权限、弹性伸缩等,用户可以到火山引擎上建一个最小规格集群体验。
用户友好
在用户侧,火山引擎 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 本身性能可以提供时延很短的查询体验,因此基于Doris 完成 ODS > DWD > DWS > ADS 的转化。
案例 3:实时计算
对性能要求高的场景,目前推荐使用实时计算方式,让数据省略中间各层。在 Flink 里完成计算,结果直接写入 RDS/ Redis。以某车联网公司为例,实时采集运营的 500 辆新能源汽车行驶和电池数据进行实时分析和告警,每 5 分钟采集一次,日增量在 10GB,数据通过消息队列 Kafka 或 Pulsar 汇聚到大数据平台,使用 Flink 流计算引擎进行毫秒级实时指标计算,计算结果存储到 RDS 中供平台进行实时数据展示。
案例 4:在线机器学习
在在线机器学习场景下,数据通过离线的方式存到数据湖仓。离线数据可以通过 Spark 进行特征抽取及特征工程,并把提取出来的特征返存到湖仓或者 HBase 等键值存储。
基于离线的数据可以进行离线训练,如通过 Spark MLlib 搭建传统的机型学习模型,或者通过 TensorFlow 进行深度模型的训练,把深度训练出来的模型部署到模型服务中。在在线方面,数据通过 Kafka 流入 Flink 进行在线特征抽取,然后把在线特征放在 Redis。同时在线部分的增量数据可用 TensorFlow 进行增量训练,把增量模型也导入模型服务里。模型服务根据原来批式训练出来的模型和增量模型做成实时的 AI 服务,可满足实时风控等对时间要求比较高的场景。
火山引擎EMR湖仓方向未来规划
最后与大家分享火山引擎 EMR 在湖仓方向未来的规划。
- 数据加速:期望进一步加速数据分析。企业上云之后,痛点之一为数据放到对象存储之后性能是否会下降。要解决该问题,主要在数据缓存(包括文件级 Cache 和 Page 级 Cache)和索引方面(包括 Bitmap、Bloom Filter)做一些工作。
- 解决刚需痛点场景:分析 CDC 数据和多路径,解决数据湖仓割裂的问题。对于后者,可以尝试:Doris 直接加速访问 HMS 中的 Hive/Iceberg/Hudi 表,实现湖仓互通。持续优化基于 Iceberg 数据湖方案,使得性能接近仓的体验。
- 拥抱开源:希望将工作合入到开源社区,包括 Data Block Alluxio 的功能和性能优化;Doris MultiCatalog、元数据服务化、冷热分离优化;Iceberg 二级索引等。
- AI4Data(数据智能管家):我们长期规划是成为一个智能数据管家,具体包括:自动诊断高频低性价比 SQL 及作业;自动优化用户 SQL 及作业,智能地从数据分布、Cache、Index、物化视图等维度来优化用户账单;智能运维:集群负载过高时,自动扩容;负载降低时,自动收缩。集群节点故障时,做到用户完全无感知地 Failover。自动地实现数据均衡分布。
- 产品打磨:在产品侧,第一目标是打磨产品,先把产品底座做坚实,并在管控方面(包括创建集群体验优化、弹性伸缩优化等)、作业开发与管理方面与周边生态方面做进一步打磨。
活动推荐
12月20日19:00,《火山引擎VeDI数据中台架构剖析与方案分享》
本期直播分享将聚焦字节跳动数据中台建设经验,在存算分离、湖仓一体、ServerLess等技术发展趋势下,从企业数仓架构选择、数据湖解决方案与应用实践,以及一站式数据治理等角度,为企业构建自身数据中台提供思路和启发。
戳链接,立即进群、观看直播、赢取好礼:11dr.cn/d/5xvloe9D7
立即跳转 开源大数据平台 E-MapReduce -火山引擎了解详情!
版权声明:内容来源于互联网和用户投稿 如有侵权请联系删除