金融级实时数仓建设实践

导读本文将分享蚂蚁集团近两三年在实时数仓领域的探索和实践。

本次分享将围绕以下四个方面展开：

1. 蚂蚁实时数仓架构

2. 实时数据质量保障

3. 流批一体应用

4. 数据湖落地展望

分享嘉宾｜马年圣蚂蚁集团实时数仓架构师，数据技术专家

编辑整理｜梁维

内容校对｜李瑶

出品社区｜DataFun

蚂蚁实时数仓架构1. 实时数仓架构设计

蚂蚁实时数仓的架构主要包括计算引擎、研发平台、计算资源、实时资产、研发工具和数据质量六大模块，这六个模块覆盖了实时数据研发的全流程，但也面临着许多问题，包括如何管理实时数据资产和口径、如何管控实时资源、平台能力是否健全等。在实时数据的应用场景中，数据的准确性和稳定性尤为重要。因此，如何持续监控和发现数据质量问题是实时数据研发过程中面临的一大挑战。同时，随着实时数据应用场景的增加和需求吞吐量的上升，还需关注实时研发流程效率如何提升和计算能力如何建设的问题，这就需要我们深入到实时研发链路中分别攻克相应的痛点。

相较于离线完善的实时计算引擎和生态，实时数据研发生态和资产相较而言还有较大的提升空间。和业界开源使用的 Hive/Spark 离线计算生态类似，阿里的 ODPS 也有一套完善的计算体系，从上到下包括客户端模块、接入层、逻辑层和存储计算层，同时还有相对应的账号和元信息服务。如果只是离线数据计算和分析的话，当数据入仓后即可在此生态内一站式地进行研发和运维。实时计算对用户而言复杂很多，其中最突出的是实时数据资产以及对应的存储。根据计算特性和方案的不同，实时计算可以对接相当多的存储引擎，每个引擎又都有相对应的计算和存储特点，如何管理好这些连接信息和其底层对应的数据语义，是实时资产模块需要建设的能力。和离线计算类似，实时资产也应该具备数据内容定义（对标 ODPS 表 Schema 定义）、生产体系（对标 ODPS 计算能力）、消费体系（应用数据的对外使用）和资产管理（实时数据的管理）等能力。综合以上的考虑，蚂蚁通过实时元表来进行实时资产的定义和管理。实时元表之上建设了元表定义、元表消费、元表管理和元表质量四块的能力，让用户基于元表便能进行实时数据的研发和运维操作。

蚂蚁实时数仓架构主要包括数据源接入、实时数据存储、实时计算引擎、实时数据研发能力、实时数据服务和实时数据质量几大模块，细节如下：（1）蚂蚁的实时计算数据源主要来源于线上日志、数据库日志和实时消息，计算引擎选用 Flink 和 ODPS（主要用于维表加工），存储引擎和业界对齐，包括消息中间层 Sls、OLAP 引擎 Explorer、OLTP 存储引擎 Hbase。（2）相较于离线计算中的统一物理文件和 Meta 信息，实时计算的存储选型是多样的，不同的实时存储引擎都有自己的文件存储模式和底层信息格式，这里使用元表维护不同的数据源、物理表、字段的定义，并做到定义可复用的能力。（3）在计算研发平台中，除了基础的实时计算能力以外，我们着重构建了低代码研发和流批一体的能力，其中低代码研发是希望用户直接进行配置即可完成实时任务的研发和上线。而流批一体主要解决实时离线数据口径、消费链路不统一的问题，期望通过一套代码和一套引擎来提升研发和运维的效率。（4）对于实时数据的消费模块，主要分为实时数据分析和实时数据服务两大场景，其中 OLAP 场景主要解决实时数据多维分析的问题，而 OLTP 场景则会和工程算法层进行联通，提供在线的实时数据服务。（5）对于实时数据质量模块，基于实时元表构建了较多的事实数据保障能力，如 DQC 监控、主备对比、异源核对等。

2. 实时数据解决方案

流量场景中转化归因是流量效能的一大重点，离线中通过流量日志和转化日志关联，并使用自定义排序算法，剔除返回的路径，最后生成用户转化的路径图。在实时计算中，双流 join 可解决此类问题，但流量过大会导致 Flink 后端状态过大，且如果多个转化事件接入后，计算成本成倍增长。亦或者将流量数据写入到诸如 Hbase 的维表中，转化事件到来时进行维表关联，但此方案需要严格的流量在前、转化在后的上报逻辑，如果流量日志延迟上报，转化数据就会失真。最终我们使用实时流图来解决此类问题：（1）首先在图数据库中，构建用户和流量日志、转化事件的关联关系，当一个转化事件触发后，会筛选用户完成转化事件之前的流量路径。（2）根据流量日志的时间生成路径的拓扑，剔除掉链路中的环，最后生成用户的访问路径图。（3）将以上生成的拓扑图打平拆成多条记录，形成实时转化归因表，进行实时分析和二次消费。当前方案主要依赖图进行归因的计算，Flink 只是做了数据入图和消费图中结果数据的工作。除此之外，还有一些后续会实践的解决方案：一是端上流量日志串联，通过在端上定义重要转化事件，实现边缘计算效果；二是数据湖准实时构建，以解决状态问题。

去重类指标主要应用于两个场景：一是绘制天级按分钟累计的趋势图；二是在活动期间，查看整个活动期间的用户。实时计算在活动期间可能面临状态较大的问题，一旦发生问题，回补计算将变得困难。针对这些场景，我们有以下几种解决方案：（1）对于天级按分钟累计，对用户进行去重，将去重后的分钟级新增数据分发并聚合，从而得到累计数据。但这种方法存在数据量大、难以回补的问题。（2）可以使用 Flink Cumulate Window 来计算累计 UV，这是一种渐进式窗口，能够直接计算累计数据。（3）维表 Join 也是一种常用方法，通过将用户明细流写入维表并关联，可以判断用户是否之前来过，从而计算新增数据。（4）还可以使用估算能力，如 Hyperloglog 或 Thetasketch，生成 UDF 进行聚合，得到最细粒度的累积数据，在下游使用 merge 能力达到高精度的累积 UV。如果希望得到准确的累计 UV 的实时数据，并且也希望保证查询端具有一定的灵活性，可以使用 BitMap 来实现，如计算每小时的 Bitmap Bytes，在查询时进行Merge Agg，但对于活动期较少的场景，分小时的 Bitmap 数据会有较多的小文件，影响查询的性能，是否可以将累计的 Bitmap 进行合并，这样就能保证查询是 Bitmap 文件在较小的数据量，具体细节在后续流批应用场景介绍。02

实时数据质量保障

蚂蚁的实时数据质量在事前和事中两个阶段进行针对性保障，其中：

事前首先在研发过程中进行代码的调试和诊断，重要的实时场景还会对实时任务进行压测，在观察任务的消费能力达到目标值，且上下游中间件保持稳定的前提下，设置实时任务对应的限流值。
事中则围绕任务异常监控和数据异常监控两块进行构建，其中任务异常监控主要对实时任务本身的稳定性进行监控和预警(如任务延迟、failover 次数、checkpoint 失败率等)，而数据异常监控则对数据本身进行规则校验(如跌 0、同环比波动、阈值分布等)。

相比离线可能动不动就是几十层的链路相比,实时端到端的全链路任务数是相对较少的，但因为实时资产本身的复用性和逻辑抽象，也会出现 5+ 层的情况。对于此，通过全链路基线进行端到端的实时数据时效性监控。最后则是服务异常监控，主要面向实时数据服务的可用性进行监控。通过以上研发流程的各节点的实时数据质量监控能力，来保障实时数据端到端的数据时效性和准确性。

除了围绕研发流程进行保障以外，从数据流通的全生命周期和全链路，也能够进行相对应的监控和保障，主要包括生产和消费两大环节，其中：

生产环节包括数据源监控、计算层监控和存储层监控，这三者对应实时计算任务的 Source、Runtime 和 Sink，这个数据稳定性对三者缺一不可。数据源监控包括数据上报的时效(同业务端共同监控)、采集延迟、采集服务本身的稳定性监控等;计算层则是实时计算任务以及对应的底层组件的稳定性监控;存储层则是对中间/结果数据的存储引擎进行保障。
消费端从查询层和应用层两块进行保障，其中查询层对查询引擎的稳定性进行监控，如查询服务水位监控、查询报错告警、查询耗时告警等;而应用层则需要和数据使用平台进行联合保障，对数据产品/平台进行应用角度的保障。

在对以上每一层的稳定性监控之后，可将所有的相关 Metric 信息统一收集，并配置相应的实时数据监控大盘，全方位了解实时数据质量的健康度，当前这块能力还在设计并逐步构建中。

任务粒度质量监控主要具备三个能力：任务 DQC 覆盖单任务的质量波动监控，异源核对覆盖实时和离线数据的比对，主备监控则覆盖主备链路的数据比对，以上能力基于实时的 Metric 指标采集和结果数据构建。通过 UDF 的方式，在实时任务中加入Metric 采集模块，数据异步传输到后端数据库中，监控系统根据用户配置的规则，触发 Metric 采集和校验。

实时全链路保障依赖实时任务和元表血缘，构建实时场景和实时基线能力，其中：

实时场景对实时资产使用范围进行分类，作为资产重要性评估的重要依据，同时也作为实时计算的输入项。
实时基线则对上挂的事实元表进行血缘追溯，监控全链路中实时任务的数据时效，当前有三大类实时基线：大促临时基线、以场景为依据的基线和中间层重要基线，根据基线的优先级进行不同措施的实时数据保障。

流批一体应用

在构建流批能力之前，先来看下当前实时数仓中的数据链路情况。在 Lambda 架构中，三个消费场景的实时离线数据融合方案还不统一，从数据侧到应用侧都有触发流批数据融合的逻辑，但本质上还是流批模型字段对齐的语义表达，下游便可实现字段对齐逻辑。其次在实时数仓中，大部分都是 ODS/DWD 层直接计算累计结果，而离线数仓中，应用层数据大部分都是从轻度汇总层计算得到。因此在构建流批数据时需要考虑这样的差异，可能流和批表的对齐方式就是明细和汇总。

流引擎和批引擎在落地的过程中有很多的工作量，这里主要介绍 Flink 批计算引擎的架构：

调度层：蚂蚁 Flink 的调度使用原生的 K8S 调度，同时尝试集群调度模式，在 K8S 之上直接获取机器资源，减少任务发布上线的时间，同时保障任务的稳定性。
引擎层：Flink 研发运维同学做了很多的工作，从上往下看，首先对齐 BlinkSQL 完成计算函数的新增，并优化了部分执行计划推断的逻辑，如单表抽取了 ab 字段，同样的表抽取了 bc 字段，则会对 source 表进行合并读取。批引擎执行优化方面，对批计算中的并发度、CPU 和内存进行配置，Connector的并发度根据数据量进行推断，而运行中搭配 AdaptiveBatchScheduler 进行动态调整。对于 CPU 和内存，则根据不同的算子类型进行设置，并通过线上任务的运行验证，保证批任务的运行性能和稳定性。Connector 方面则主要对齐 Blink 进行适配，考虑到批任务在计算完成之后一次性同步会产生输出洪峰，为了保护线上库，设置限流是相当必要的，引擎侧在Connector 插件中实现了限流的能力。DataStream 引擎和算子主要使用开源能力。最后在可插拔组件中，我们主要对Shuffle 组件、调度组件和后端状态进行了适配优化。批任务默认使用基于 TaskManager 本地磁盘的 Shuffle 方式，这种方式对本地磁盘的要求比较高，在上下游交互的时候存在依赖关系，我们引入了开源的 flink remote shuffle 组件，独立部分 Shuffle 组件，实现计存分离的架构。
平台层：对批任务的预编译、调试、提交、发布进行了支持，对于离线代码中的时间变量、任务参数进行解析翻译。其中最重要的是将 Flink 批计算类型加入到离线调度引擎中，依赖 Odps 等其它任务产出的数据，在调度运行时生成任务实例，并查询具体的运行日志。

对于流批表对齐的问题，我们来看以上两个 Case，在流和批都是明细的情况下，流和批的字段含义不一致和不对齐是常见的，比如离线是否打标是 Y/N，实时打标 1/0。而对于流明细批汇总的场景，比如离线时算到用户粒度的轻度汇总数据，对于 PV 这样的字段，实时肯定是没有的。对于以上这类问题，一个方案是某一方进行数据的改造，保证两侧的数据字段对齐，但是成本相当高。因此，我们设计了虚拟列字段，对于某一方不存在的情况下，使用虚拟列标识，同时对流表和批表进行参数定义，这样就能在代码中显式的判断和处理，以此来解决流批字段不对齐的问题，在这样的能力支撑下，即使是流和批表字段完全不一致的极端情况，也能进行特判和处理。

过去如果需要计算实时长周期累计指标(如活动期累计 PV/UV、视频累计观看次数)，一般会使用离线 Odps 任务计算好 T-1 的累计值，并回流到 Lindorm 中，实时任务计算当天的数值，关联 Lindorm 中的 T-1 累计值进行相加，得到截至当前的实时累计汇总值。对于此套方案，实时和离线任务需要分别开发，并且根据计算引擎的特性会有不一样的计算逻辑。在应用流批一体能力后，其计算方案如下：首先通过混合元表将实时和离线数据源进行绑定,流批任务基于混合元表进行分天汇总指标的研发，同时在批代码分支上增加离线累计指标的计算(简单的 T-2 累计 + T-1 分天的计算)，并将计算好的指标直接写入到 Odps(用于下一次计算)/Lindorm(用于实时关联)，最终实时分支将实时天级汇总关联 T-1 累计汇总，求解得到实时累计汇总值。此套方案在保障数据口径一致性的前提下,只需要一个任务即可完成实时累计指标的计算，得益于 Flink 强调的实时研发生态，可以直接将结果数据回流到所有需要用到的存储中，便于多场景的数据使用。04

数据湖落地展望

以上的流批一体方案还只是计算层的流批，在代码中需要明确区分流任务和批任务的处理方式。流数据一般存储在消息中间件中，而批数据则存储在 ODPS 中。研发时需要感知流和批任务的不同特性，并进行针对性的处理。在计算流批之上可以通过存储的流批一体,通过将实时数据和离线历史数据回流到数据湖中，来实现最终的流批一体计算存储方案。蚂蚁当前选用的是 Paimon 作为数据湖组件，基于 Paimon 可以实现从 ODS 到 ADM 层进行数据准实时的计算和消费。蚂蚁当前主要有三条不同时效性的调度任务，分别是：天级调度、小时级调度和实时任务，综合三者的数据基本可完成所有的数据需求研发，但在开发过程中需要进行数据的来回同步，计算链路相当复杂。在引用 Paimon 作为进行实时数据湖研发之后，可在 Paimon 这一组件中完成全链路的准实时数据研发，大大简化了实时研发的链路和复杂度，并可实现一套计算引擎、一份存储、一份资产。