作者：王沛斌@饿了么
小编导读：
本文整理自饿了么大数据架构师、Apache Flink Contributor 王沛斌老师在8月3日 Streaming Lakehouse Meetup Online（Paimon x StarRocks，共话及时湖仓架构）上的分享。紧张分为以下三个内容：
1. 饿了么及时数仓演进之路
2. 及时湖仓方案选型与探索
3. 及时湖仓规划及展望
饿了么及时数仓演进之路
饿了么典范及时应用场景
以上是饿了么在及时应用中的一些典范场景，和很多公司有相似之处。具体分为以下几个部分：
（1）及时 ETL：包括及时数据入湖入仓、及时数据建模、及时流量归因等。
（2）及时报表应用：包括营销活动直播、商家生意顾问、及时流量大盘、大促及时大屏、及时AB实行等。
（3）及时与在线应用的联动：包括商物流及时联动、及时人群特征及投放、个性化保举、IOT信息同步、风控及时拦截等。
（4）及时监控与补偿：包括及时数据查对与订正、业务诊断预警、服务器非常监控等。
饿了么数据结构大图
饿了么整体数据架构大图紧张由三个层面组成，分别为数据采集层，数据加工层，数据服务层。干系的数据组件依托阿里云组件。整体数据采集使用 DataX 和 DRC 链路来进行数据库 Binlog 的采集。日志采集紧张使用内部的Omni 平台来网络用户行为数据，而应用层的日志通过SLS和TT来进行相应的日志接入。
数据仓库这一层是一个重点。一个是存储方面可以分为两块：一块是近及时的湖仓，采用 Paimon On OSS方案来进行存储；而对于及时性要求更高的数据，使用的是 TT 和 SLS。在数仓盘算层，使用的是 Dataphin、VVP 和 Flink 三件套。在数据服务层，紧张的数据存储使用 ADB 和 Hologres，迩来引入了 StarRocks 来团结湖仓进行落地。在这个存储基础上，通过内部的数据服务应用（包括繁星、方舟、FBI、量子等组件）来提供相应的数据服务。通过以上数据服务，构建了整体的数据产物和数据办理方案。
最核心的两个点是盘算和存储。上图右边展示了整体盘算变革的环境。右边第一张图显示了我们内部 Blink 和 Flink 的用量曲线。可以观察到，早期更多使用的是 Blink，随着 Flink 的进一步拓展，到 2023 年左右，开始大规模切换到 Flink。计划在今年将所有 Blink下线，全部统统统换到 Flink。第二张图显示的是存储层的环境。存储层早期更多使用的是 ADB，现阶段更多使用 Hologres 来支持。将来 Hologres 的用量也会逐步扩大，并引入类似 StarRocks 这样的 OLAP 引擎，以提升团队整体研发服从。
及时数仓1.0
基于上述的两个背景，接下来介绍一下我们内部当前及时数仓建设的环境。
及时数仓的 1.0 版本中，这是大多数公司早期版本的典范样子。我们通过日志和数据库的 Binlog 进行数据采集，这些数据最终进入 ODS 层。在 1.0 版本的早期阶段，我们投入了大量工作来建设 DWD 层。在 DWD 层，我们对一些共性的维度和逻辑进行了扩展，并屏蔽了多余的场景，建设了完善的 DWD 层群以供卑鄙消费使用。
对于不同的应用场景，我们开辟了相对独立的 ADS 层，这一层并未进行公共层的建设。而对于核心业务场景，我们采用了 Lambda 架构将历史数据通过 T+1 的方式导入到 OLAP 引擎中，以包管数据的稳定性。在此过程中会出现几个题目：首先是研发服从较低的题目，会产生较多的重复开辟工作。其次，随着业务的变革，这些逻辑每每无法及时同步更新，导致数据一致性缺乏保障。这不仅增加了整体的运维成本，也增加了盘算成本。
基于上述环境，我们盼望达成以下两个目标：首先是确保数据能够更快、更准、更稳、更一致；其次是提升整体的开辟服从和运维服从。具体的办理方案总结为四个要点：
（1）数据产物能力升级，收敛及时需求。
（2）夯实及时的 CDM 资产，收口指标加工逻辑。
（3）及时数仓架构方案升级，获取技能红利，低沉研发复杂度。
（4）研发规范化及工具沉淀（流程卡点&及时基线等）。
及时数仓2.0
上述第二点对应的是及时数仓 2.0 的具体方案。具体方案是建设核心的 CDM 层，将常见的共性维度和指标加工成 DWS 资产。这个方案是在去年年初提出的，整体方式是借助 Dataphin 来构建一个流批一体化的体系。
及时的 DWD 和离线的 DWD 通过 Dataphin 的逻辑表进行映射，在 Dataphin 上开辟具体的 SQL 使命后， Dataphin 会将其翻译成 Flink 的流使命和批使命。在此基础上，团结 D2 的 Dataworks，根据每一个调度将天天的 T+1 使命触发，最终将数据回写到 Hologres 中。通过 Hologres 的 Binlog，驱动卑鄙的具体消费。这样，卑鄙的 ADS 层只需进行现有指标的简朴行业转化或格式转化，将数据写入各自的存储，以满足不同查询场景的使用和需求。
完成这条链路后，整体的核心资产消费链路和研发服从得到了提升，数据一致性也得到了保障。然而，仍然存在一些题目。例如，对于一些新兴业务，这条链路并不适用，它紧张支持存量的紧张业务。别的，虽然这条链路旨在实现流批一体化，但现实上并未完全实现这一目标。由于在 DWD 层，数据现实上有两份存储，一份在 TT，一份在 ODPS。
此外，及时中央层更多使用的是 TT，但 TT 不支持检索和更新。在研发或数据订正的过程中，这会带来较高的成本。同时，TT 也不支持列裁剪。以流量中央层为例，每次消费都会产生单列巨额的费用。再者，Hologres 的存储成本非常高。因此，无论是从低沉成本还是提升服从的角度来看，我们都希望引入更好的数据架构。因此，我们找到了当前比力热门的办理方案 —— Streaming Lakehouse。
及时湖仓方案选型与探索
那么我们想引入 Streaming Lakehouse 要如何实行呢？首先要做的就是具体的选型和探索落地的实践。
造型与测评方案
在整个选型过程中，使用了饿了么最核心的生意业务、营销和流量三个域的明细数据作为测试数据，并将数据写入对应的湖存储格式中。我们当时评测选择了 Paimon + Hudi 这两种湖格式。为了方便整体验证还与现有的 OLAP 集群的内表方案进行对比。
在 OLAP 引擎方面，紧张引入了 StarRocks、Trino 引擎进行对比。在存储层，我们紧张关注数据写入后的膨胀系数、流读和流写的性能，以及端到端的写入延迟。在 OLAP 部分，我们重点关注查询的耗时和单次查询的开销。
上图左边展示了我们在整个评测中所使用的版本。整体使用的集群规模约莫为 200CU。由于规格的原因， StarRocks 的集群总共是 192CU。在这些组件中，大家比力关注的 StarRocks 和 Trino 我们是直接采用了阿里云的 EMR 5.15.1 版本进行摆设的。
Paimon VS Hudi
Paimon 和 Hudi 哪个更优呢？
图中左上角展示了经过多轮测试后得出的效果，整体排名基本上都是 Paimon 优于 Hudi。同时，Paimon 的性能也靠近 OLAP 集群内表方案的查询性能。但是在端到端的时效性方面，OLAP 集群内表方案仍然是最快，可以到达秒级别。Paimon 的时效性测试效果约莫在1到5分钟，平均约为3分钟。Hudi 在这一块的延迟一般在10分钟左右。
基于上述测评效果，选择 Paimon 作为后续的湖存储格式。团结前面提到的三个月具体场景，上图可以看到对应的 Paimon 表的创建方式。对于生意业务和营销数据，由于需要及时更新，因此我们使用了一个PK表，指定了 Bucket 并同时开启了 ZSTD 压缩。在这个过程中，还需要通过 Sequence Field 进行版本控制。流量表则是一个 Append Only 表，基本上设置为 Bucket=-1，以支持主动化扩展。同时为了保障读写的性能平衡，以是每一个文件大概需要控制在一个 GB 范围内。
StarRocks VS Trino
在对比 StarRocks、Trino 的性能时，StarRocks 在各个方面都表现比力出色。是什么原因使得 StarRocks 的性能云云出色呢？首先，StarRocks 的 JNI Connector 对 Paimon 进行了良好的适配。其次，StarRocks 支持过滤下推。上图右下展示了饿了么基于 StarRocks 的一个 profile 截图，可以看到 “city_id” 和 “is_valid_order” 这两个字段实现了有效的下推。此外，StarRocks 还具备高效的向量化实行引擎，并且可支持对 Paimon 的 RO 表进行查询。末了，虽然我们目前还没有正式使用物化视图 +SQL 透明改写和 Data Cache 这两个功能，但可以预见一旦投入使用性能将会进一步提升。在这样的背景下，饿了么最终选择使用 StarRocks 和 Paimon 作为湖仓办理方案。
及时湖仓落地探索
经过多次探索，我们确定了如上图所示的湖仓建设架构。紧张的数据处理惩罚链路使用 Flink 进行 Paimon 的流读流写，Paimon 的数据存储在内部 OSS 集群上，并通过 DLF（Data Lake Formation）进行元数据管理。通过 Paimon 的流读流写功能，支持及时数仓的分层建模。在特定场景下，利用 StarRocks 的物化视图进行应用层或汇总层的盘算。同时基于明细数据通过 StarRocks 和 Hologres 的数据湖外表查询能力支持自助洞察分析的需求。具体应用场景包括：流量宝洞察分析、及时生意业务补贴自助分析以及客满的服务大屏等。
落地探索-DWD自助分析
接下来紧张介绍基于生意业务和补贴的自助分析场景。首先，数据源提供订单流和补贴流两个及时流。在传统方案中，这两个流在Flink使命中进行双流 Join 处理惩罚后写入 OLAP 集群内表，再基于 OLAP 集群内表提供自助分析服务。引入 Paimon 之后，两条流直接写 Paimon 的 Partial-update 表，指定不同流中的 Sequence Group 来进行对应字段的版本控制。在这种情场景下，整体 Flink 的资源开销相比原来的双流 Join 方案减少了约莫50%，同时体系的整体稳定性也显著提升。
然后在 StarRocks 这一层，通过 StarRocks 来读 Paimon 外表这块来支持的。上图右上角是整体的 Profile 的效果，可以看到大部分的瓶颈其实还是在 IO 这一层的。以是后续如果做数据湖的加速分析的话，IO 这一层还是优化的重点。
上图右下角展示了整个自助分析的效果示意图。与之前基于 OLAP 集群内表的及时数仓方案相比，这个方案在写入时效性上牺牲了1到5分钟，同时单次查询的耗时增加了约5%。然而，整体存储成本较原有的 OLAP 集群内表减少了约90%，Flink 使命的资源开销也减少了约莫50%。
及时湖仓规划与展望
及时数仓3.0展望
如果建设了及时湖仓，后续的加工链路可以进一步丰富，从而构建不同场景下的数据办理方案。相比之前的及时数仓2.0版本，DWD 层和 TT 层将逐步更换为数据湖。使用数据湖后，可以针对低频场景构建准及时或及时的物化视图，通过物化视图进行分层建模。同时，还可以利用 Flink 的流读流写能力进行分层建模。在数据服务层，可以根据业务需求，查询对应的 DWD、DWS 或 ADS 层，从而构建多元化的交付方案。
具体的交付方案如上图左下角所示，不同场景可以选择不同的交付方案，利用现有的及时数据资产，提升研发服从，不需要为每个需求重新开辟具体的 Flink 使命。然而仍会遇到一些题目：OSS 带宽瓶颈在压测过程中已经显现出来需要办理，同时 OSS 上的小文件题目也是需要办理的。Paimon 的时效性目前为1到5分钟，这限制了及时数仓的分层，无法实现多层依赖，只管也不保举过多层数。虽然 Paimon 和 StarRocks 现有的元数据可以通过 DLF 管理，但与内部原有的元数据管理缺乏买通，需要进一步拓展。此外，目前集群的权限控制相对较弱的，需要进行强化。
右边展示了后续希望重点推进的几个方面。首先是 StarRocks 物化视图，之前进行了轻度测试，因遇到一些题目，暂时未能显著提升研发服从，将来希望重点完善这一方案。此外，在 Flink 写入 Paimon 时，常因 Compaction 题目导致显著抖动，计划采用异步 Compaction 机制，以保障整个实行链路的稳定性。此外，诸如盼望引入 Deletion Vector，显著提升查询服从。
目前，Paimon 及时中央层已应用于一些核心链路，将来希望将其推广到更多数据场景。还计划与 DataWorks 和 MaxCompute 进行集成，这属于生态体系建设的一部分。在 OSS 方面，我们希望通过冷热分层能力进一步低沉成本。之前尝试团结 Paimon 的 Tag 机制来实现这一目标，但暂时还未找到理想的办理方案。
回顾
末了回顾一下饿了么整体及时数仓的建设历程，大致可以分为几个阶段。首先是相对原始的开辟阶段，这一阶段紧张建设及时的 DWD 层，各个应用层通过 Flink 使命各自天生自己的 ADS 数据。在这一过程中，ADS 层出现了大量数据一致性题目和重复开辟的题目。为了办理这些题目，我们构建了及时的 CDM 层，从而办理了共性题目。然而，对于新增业务和场景的支持仍显不足。因此，我们引入了及时湖仓方案。虽然该方案目前仍在探索阶段，但已经在一些具体场景中实现了落地。将来，我们希望在 Paimon 和 StarRocks 上进行更多的探索和应用。
https://www.bilibili.com/video/BV1eRYNe7EZA/?vd_source=1cb452610138142d1300dd37a6162a88
更多交流，联系我们：StarRocks
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
