小编导读：
饿了么典型实时应用场景
饿了么典型实时应用场景
以上是饿了么在实时应用中的一些典型场景，和许多公司有相似之处。具体分为以下几个部分：
（1）实时 ETL：包括实时数据入湖入仓、实时数据建模、实时流量归因等。
（2）实时报表应用：包括营销活动直播、商家生意参谋、实时流量大盘、大促实时大屏、实时AB实验等。
（3）实时与在线应用的联动：包括商物流实时联动、实时人群特征及投放、个性化推荐、IOT信息同步、风控实时拦截等。
饿了么数据结构大图
饿了么数据结构大图
饿了么整体数据架构大图主要由三个层面组成，分别为数据采集层，数据加工层，数据服务层。相关的数据组件依托阿里云组件。整体数据采集使用 DataX 和 DRC 链路来进行数据库 Binlog 的采集。日志采集主要使用内部的Omni 平台来收集用户行为数据，而应用层的日志通过SLS和TT来进行相应的日志接入。
数据仓库这一层是一个重点。一个是存储方面可以分为两块：一块是近实时的湖仓，采用 Paimon On OSS方案来进行存储；而对于实时性要求更高的数据，使用的是 TT 和 SLS。在数仓计算层，使用的是 Dataphin、VVP 和 Flink 三件套。在数据服务层，主要的数据存储使用 ADB 和 Hologres，最近引入了 StarRocks 来结合湖仓进行落地。在这个存储基础上，通过内部的数据服务应用（包括繁星、方舟、FBI、量子等组件）来提供相应的数据服务。通过以上数据服务，构建了整体的数据产品和数据解决方案。
实时数仓1.0
实时数仓1.0
实时数仓的 1.0 版本中，这是大多数公司早期版本的典型样子。我们通过日志和数据库的 Binlog 进行数据采集，这些数据最终进入 ODS 层。在 1.0 版本的早期阶段，我们投入了大量工作来建设 DWD 层。在 DWD 层，我们对一些共性的维度和逻辑进行了扩展，并屏蔽了多余的场景，建设了完善的 DWD 层群以供下游消费使用。
对于不同的应用场景，我们开发了相对独立的 ADS 层，这一层并未进行公共层的建设。而对于核心业务场景，我们采用了 Lambda 架构将历史数据通过 T+1 的方式导入到 OLAP 引擎中，以保证数据的稳定性。在此过程中会出现几个问题：首先是研发效率较低的问题，会产生较多的重复开发工作。其次，随着业务的变化，这些逻辑往往无法及时同步更新，导致数据一致性缺乏保障。这不仅增加了整体的运维成本，也增加了计算成本。
基于上述情况，我们期望达成以下两个目标：首先是确保数据能够更快、更准、更稳、更一致；其次是提升整体的开发效率和运维效率。具体的解决方案总结为四个要点：
（1）数据产品能力升级，收敛实时需求。
（2）夯实实时的 CDM 资产，收口指标加工逻辑。
（3）实时数仓架构方案升级，获取技术红利，降低研发复杂度。
实时数仓2.0
实时数仓2.0
实时的 DWD 和离线的 DWD 通过 Dataphin 的逻辑表进行映射，在 Dataphin 上开发具体的 SQL 任务后， Dataphin 会将其翻译成 Flink 的流任务和批任务。在此基础上，结合 D2 的 Dataworks，根据每一个调度将每天的 T+1 任务触发，最终将数据回写到 Hologres 中。通过 Hologres 的 Binlog，驱动下游的具体消费。这样，下游的 ADS 层只需进行现有指标的简单行业转化或格式转化，将数据写入各自的存储，以满足不同查询场景的使用和需求。
完成这条链路后，整体的核心资产消费链路和研发效率得到了提升，数据一致性也得到了保障。然而，仍然存在一些问题。例如，对于一些新兴业务，这条链路并不适用，它主要支持存量的重要业务。另外，虽然这条链路旨在实现流批一体化，但实际上并未完全实现这一目标。因为在 DWD 层，数据实际上有两份存储，一份在 TT，一份在 ODPS。
造型与测评方案
造型与测评方案
在整个选型过程中，使用了饿了么最核心的交易、营销和流量三个域的明细数据作为测试数据，并将数据写入对应的湖存储格式中。我们当时评测选择了 Paimon + Hudi 这两种湖格式。为了方便整体验证还与现有的 OLAP 集群的内表方案进行对比。
在 OLAP 引擎方面，主要引入了 StarRocks、Trino 引擎进行对比。在存储层，我们主要关注数据写入后的膨胀系数、流读和流写的性能，以及端到端的写入延迟。在 OLAP 部分，我们重点关注查询的耗时和单次查询的开销。
Paimon VS Hudi
Paimon VS Hudi
Paimon 和 Hudi 哪个更优呢？
图中左上角展示了经过多轮测试后得出的结果，整体排名基本上都是 Paimon 优于 Hudi。同时，Paimon 的性能也接近 OLAP 集群内表方案的查询性能。但是在端到端的时效性方面，OLAP 集群内表方案仍然是最快，可以达到秒级别。Paimon 的时效性测试结果大约在1到5分钟，平均约为3分钟。Hudi 在这一块的延迟一般在10分钟左右。
StarRocks VS Trino
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 作为湖仓解决方案。
实时湖仓落地探索
实时湖仓落地探索
落地探索-DWD自助分析
落地探索-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展望
实时数仓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，显著提升查询效率。
回顾
回顾
最后回顾一下饿了么整体实时数仓的建设历程，大致可以分为几个阶段。首先是相对原始的开发阶段，这一阶段主要建设实时的 DWD 层，各个应用层通过 Flink 任务各自生成自己的 ADS 数据。在这一过程中，ADS 层出现了大量数据一致性问题和重复开发的问题。为了解决这些问题，我们构建了实时的 CDM 层，从而解决了共性问题。然而，对于新增业务和场景的支持仍显不足。因此，我们引入了实时湖仓方案。虽然该方案目前仍在探索阶段，但已经在一些具体场景中实现了落地。未来，我们希望在 Paimon 和 StarRocks 上进行更多的探索和应用。
关于 StarRocks
StarRocks 全球开源社区也正飞速成长。目前，StarRocks 的 GitHub star 数已达 8600，吸引了超过 420 位贡献者和数十家国内外行业头部企业参与共建，用户社区也有过万人的规模。凭借其卓越的表现，StarRocks 荣获了全球著名科技媒体 InfoWorld 颁发的 2023 BOSSIE Award 最佳开源软件奖项。
