流批一体的近实时数仓的思考与设计

摘要：基于对数据时间旅行的思考，引出了对目前三种数仓形态和两种数仓架构的思考。结合数据湖在 Flink 的应用和数据湖元数据类型的思考，探索了基于数据湖的 Flink SQL 流批一体的实践，在流批一体 SQL 表达一致、结果一致性、流批任务分离、混合调度依赖等进行了设计和探索。同时，欢迎大家多分享具体实践，一起共筑新的数据实践方式。

一、数据的时间旅行和业务对数据的本质要求

大规模的数据处理兴起于 Hadoop 生态的发展，关键在于分布式储存和分布式计算的发展，造就了如今近百种有关大数据的生态技术。数仓理论和建模理论基于大数据技术体系得以快速发展，其中离线数仓的标准化建设得到了广泛应用。数据的本质是一种行为的具象，业务在对数据的需求，核心在于对行为的可探索和可观察。基于此，我们需要明确一点，大数据技术是否完全满足了业务对数据需求在时间维度上的确定性了呢，这点是值得思考的。那么我们先来看一下数据的时间旅行。

业务期望的数据：用户空间下的时间数据，t1时间数据，用户自然时间点或自然时间段的明细或者统计数据。

传输延迟：App 用户，数据发送到网关或者日志服务系统，或者 Server 日志落文件系统所产生的延迟。Event 进入到存储空间，可以代表数据已经是确定的，基本可观察，一般情况下，这个延迟很小。但是，在某些情况，比如 APP 的日志产生之后，但是因为网络等问题一直没有发送，或者 Server 宕机，导致延迟发送或者最终丢失。总体而言，传输延迟属于不可控延迟，暂时没有什么好的技术方案来解决。

存储空间：数据承载于实际的存储中，离线数仓承载于具体的分布式文件系统，实时数仓基于 Kafka 的消息队列系统，近实时数仓承载于数据湖存储中。这里可以抽象来看离线数仓，Event 承载于分布式文件系统，以小时分区为例，某个小时的分区本质是自然时间产生的文件的集合，时间精度退化为小时级别。

计算延迟：数据进入存储之后，与进入计算空间的时间差，t3-t2。实时数仓中，计算延迟是数据的 ProcessTime-IngestTime。离线数仓中，计算延迟是调度产生实例运行时间-数据进入存储空间的时间差。本质离线数仓和实时数仓的计算延迟在抽象上看是一致的。计算延迟在不同的数仓体系下，产生的时效不同，我们会划分为三种主流的数仓体系，秒级的实时数仓，分钟级的近实时数仓，小时级的离线数仓。可以看出，数仓的时效性差异，因为传输延迟的不可控，退化为计算延迟的差异。

二、离线、近实时、实时三种数仓在时间维度下的成因

在离线数仓和实时数仓，常常会提到数据的有界和无界，认为离线数仓的数据是有界的，实时数仓的消息流是无界的。准确与否在于数据的确定性考量。

离线数仓的确定性，在于文件自然生成时间的确定性和不可更改性，某个小时的自然文件生成，近似等于事件时间在自然时间的确定性，反例就是我们能看到数据漂移的情况，事件时间会或多或少落入上个小时或者下个小时的自然文件生成时间。那么离线数仓的确定性，实质是数据的 IngestTime 的确定性，具有天然的文件属性，易于分割。当我们说离线数仓计算的数据是准确的时候，默认了传输延迟带来的影响很小或者默认了当前小时的数据指标的标准是文件的自然形成时间。

实时数仓，常常会提及不确定性或者说 Lambda 架构实际是对实时数仓的不确定性的替代方案。这种不确定性的原因是什么呢？这里分为四类情况说明，一是 ETL 的处理，从窗口上来说，是单条数据即为一个窗口，窗口的产生和销毁在一个 Event 中完成，y=window(data)。二是基于 EventTime 的时间窗口，如果再定义延迟时间&#x