作者 | 浮生若梦的石头

导读

随着实时核算技能在大数据中的广泛运用，数据的时效性得到大幅度，可是实践运用场景中，除了时效性，还面对着更高的技能要求。

本文结合实时核算的水位技能在流批一体数据仓库中的探究和实践，要点论述了水位技能的概念和相关理论实践，尤其就水位在实时核算体系中的特性、鸿沟界说和运用，最后要点描述了一种改善的精准水位的规划和完成。该技能架构现在在百度实践事务场景下表现成熟和安稳，借此共享给大家，希望对大家有参考价值。

全文7118字，预计阅览时刻18分钟。

01 事务布景

为了提高产品研制、战略迭代、数据分析以及运营决议计划的功率，事务对数据的时效性要求越来越高。

尽管咱们很早就依据实时核算完成了实时数据仓库的建造，可是仍是无法代替离线数据仓库，实时和离线数据仓库各自一套开发和保护的本钱高，最重要的是事务的口径还不能100%对齐。所以咱们一向在致力于建造一套流批一体数据仓库，在完成全体数据加工功率提速的一起，还能确保数据如离线数据那样牢靠，能支撑100%事务场景，然后完成全体降本提效。

△流批一体数据仓库建造思路

02 流批一体数据仓库的技能难点

要想端到端完成流批一体数据仓库，作为底层技能架构的实时核算体系，面对着许多技能难点和挑战：

1、端到端数据的严厉不重不丢，以确保数据的完好性；

2、实时数据的窗口和离线数据的窗口，包括数据是对齐的（99.9% ~ 99.99%）；

3、实时核算需求支撑精准的窗口核算，以确保实时反作弊战略的准招作用；

4、实时核算体系和百度内部大数据生态打通，并有实践大规模线上安稳运行实践。

以上2和3点，都需求高牢靠的水位机制来确保实时数据的进展感知和精准切分。

所以本篇文章就精准水位在流批一体数据仓库中的探究和实践的经验，共享给大家。

03 水位概念和通用完成的现状

3.1 水位的必要性

在介绍水位（Watermark）的概念之前，需求先插入2个概念：

• Event time, 事情产生时刻。咱们一般理解为用户实在行为产生的时刻，详细对应是日志中记载用户行为产生的时刻戳。

• Processing time, 数据处理时刻。咱们一般理解为体系处理数据的时刻。

那水位（watermark）详细有什么用处?

在实践实时数据处理过程中，数据是无鸿沟的(Unbounded), 那么依据Window这种窗口核算或其他相似场景就面对一个实践的问题：

怎么知道某个窗口的数据是完好的？什么时分才干触发窗口核算（）？

大多数状况下，咱们运用Event Time来触发窗口核算（或许数据分区切分，对标离线）。可是实践的状况是实时日志总有不同程度的推迟（在日志收集、日志传输和日志处理等阶段），即如下图所示，实践上会产生水印的歪斜（即数据会呈现乱序）。在这种状况下 ， Watermark机制就很有必要存在，来确保数据的完好性。

△水位歪斜现象

3.2 水位的界说和特色

水位（watermark）的界说现在业界没有一致的说法，结合Streaming Systems一书（作者是Google Dataflow 研制团队）中界说，个人以为比较确切：

The watermark is a monotonically increasing timestamp of the oldest work not yet completed.

从界说咱们能够概括出水位的2大基本特性：

• 水位是接连递增的（不行回退）

• 水位是一个时刻戳

可是在实践出产体系中，水位怎么去核算，以及实践的作用是什么姿态？结合现在业界不同的实时核算体系，关于水位的支撑仍是不相同的。

3.3 现在水位现状和面对的挑战

在现在业界的实时核算体系中，比方Apache Flink（Google Dataflow的开源完成）、Apache Spark（仅局限Structured Streaming结构）中，都是支撑水位的，下面就以社区最火爆的Apache Flink罗列一下水位的完成机制：

实时核算体系	水位支撑时刻类型	水位更新规则	水位完成策
Apache Flink	事情时刻、处理时刻、注入时刻、自界说时刻	以 事情时刻（EventTime）的水位为例：水位时刻=最大时刻戳（秒） – 设置答应推迟的时刻阈值（秒）-1（毫秒）	Periodic Watermarks（周期性触发，必定时刻间隔或许达到必定的记载条数生成watermark）Punctuated Watermarks（断点式触发，每条符合条件日志都会触发watermark，不常用）

可是以上水位的完成机制和作用，在日志源端呈现大面积日志推迟传输的状况下，水位还依旧会更新（新旧数据乱序传输）推动，会导致对应的窗口数据不完好，窗口核算不准确。因而，在百度内部，咱们依据日志收集和传输体系、实时核算体系探究了一种改善的、相对精准的水位机制，以确保实时数据在窗口核算、数据落地（sink 到AFS/Hive）等运用场景下,窗口数据的完好性问题，以满意完成流批一体数据仓库的要求。

△Flink中水位生成战略

04 大局水位的规划和运用

4.1 水位中心化办理的规划

为了使得水位在实时核算中更精准，咱们规划出一种中心化的水位办理思路，即实时核算的各个节点，包括source、operator、sinker等都会把自己核算的水位信息，一致上报给大局的Watermark Server，由Watermark Server 来进行水位信息的一致办理。

△中心化水位规划

Watermark Server ：保护一个水位的信息表（hash_table），包括实时核算程序（APP）全体拓扑信息（Source、Operator 和Sinker等）各个层级对应的水位信息，以便于进行大局水位（比方low watermark）的核算，Watermark Server 定时和state做交互，以确保水位信息的不丢失。

Watermark Client：水位更新客户端，在source、worker和sinker等实时算子中，担任向Watermark Server 上报和恳求水位信息（比方上游或许大局水位），经过baidu-rpc服务恳求回调。

Low watermark（低水位）：Low watermark是一个时刻戳，用来符号实时数据处理过程中最早（oldest）的没有处理的数据的时刻（Low watermark, which pessimistically attempt to capture the event time of the oldest unprocessed record the system is aware of.）。它许诺未来不会有早于该时刻戳的数据抵达。这里的时刻核算一般依据eventtime，即事情产生时刻，例如日志中用户行为产生的时刻，而较少运用数据处理时刻（processing time，某些场景也能够用），watermark核算的公式为（来自Google MillWheel 论文）：

Low Watermark of A = min(oldest work of A, low watermark of C : C outputs to A)

可是在实践体系规划中，low watermark又能够按照算子处理的鸿沟区分如下：

• Input Low Watermark: Oldest work not yet sent to this streaming stage.

  InputLowWatermark(Stage) = min { OutputLowWatermark(Stage’) | Stage’ is upstream of Stage}

  输入最低水位，能够理解为将要输入当时算子，即上游算子处理过的数据的watermark。

• Output Low Watermark: Oldest work not yet completed by this streaming stage.

  OutputLowWatermark(Stage) = min { InputLowWatermark(Stage), OldestWork(Stage) }

  输出最低水位，能够理解为当时算子未处理过数据的最早的（oldest）水位，即处理过数据的水位。

  详细如下图所示，理解会更形象些。

△Low watermark的鸿沟界说

4.2 怎么完成精准水位

4.2.1、精准水位的前提条件

现在实时核算体系在实时数据仓库的运用场景，咱们都是运用low watermak来触发窗口核算（因为这样更牢靠），从3.1中low watermark的界说咱们可知：low watermark是层级迭代核算的，水位是否精准，取决于最上游（即source）水位的精准度。所以为了提高源头水位核算的精准度，咱们需求前提条件：

• 日志在服务端的单台服务器上是按照时刻（event_time）有序出产的

• 日志在收集时分，除了实在的用户行为日志，还需求包括其他信息，比方服务器tag（hostname）和日志时刻（msg_time）等信息，如下图所示

  

  △日志打包信息

• 日志是实时点对点发布到音讯行列，以确保音讯行列单个分区（partition）内，单个服务器的日志是严厉有序的

  

  △源端日志点对点发布到音讯行列，确保单分区日志是有序的

4.2.2、水位的核算方法

1、Watermark server

初始化：

首先作为独立的线程(thread)启动。依据装备的日志传输任务的BNS（Baidu Naming Service，百度姓名服务，提供服务名称到服务端一切运行实例的映射）来解析日志源的服务器列表（hostname list)；依据装备的APP拓扑联系，初始化watermark信息表，并持久化写入Table（百度分布式kv存储引擎）。

普通水位信息更新：接收到Client到水位信息并更新对应粒度（Processor粒度或许keygroup粒度）的水位，对局部水位进行更新

精准水位核算：

实践中，假如要求源端的日志100%都准确的抵达，会形成频频的推迟或许推迟太久（假如下发选用大局Low watermark逻辑）。原因是：在日志端服务器实例太多的状况下（比方实践上咱们有的日志有实例6000 – 10000个），总有线上服务的实例会呈现日志实时上传的推迟的状况，那么这就需求在数据的完好性和时效性之间做一个折中，比方以百分比的方法来精准操控答应推迟的实例个数（比方装备99.9% 或许99.99%来设置答应源端日志呈现推迟的份额），来精准操控最源端水位的准确度。

精准水位需求特殊装备，依据Source端实时上报的服务器和日志进展的映射联系，以及装备的答应推迟实例的份额，来核算Source端的output low watermark。

核算大局low Watermark：会核算一个大局最小的水位，回来给Client端的恳求

状况持久化：定时把大局水位信息持久化写入外部存储，以便于状况康复

2、Watermark Client

Source 端：解析日志包，并获日志包里边的机器名等信息和原始的日志。原始日志经过ETL处理后，并依据原始的日志获取最新时刻戳（event_timestamps），Source经过Watermark Client API 把解析到hostname和最新时刻戳（event_timestamps）的映射联系表定时上报（现在装备的1000ms）到Watermark Server。

△Source经过解析日志获取的服务器和日志进展映射联系

Operator端：

Input low Watermark核算 : 获取上游（Upstream）的output low watermark，作为input low watermark来决议是否触发窗口核算等操作；

output low Watermark核算：依据日志、状况（state）等处理进展（oldest work）来核算自己的output low watermark，并上签到Watermark Server，以便于下流算子（Download Processor）运用。

△Watermark Client 作业流程

Sinker端：

Sinker端和上面的普通实时算子（Operator）相同，会核算Input Low Watermark和 Output Low Watermark来更新自己的水位，

额外需求恳求一个大局的Low Watermark 来决议数据的输出窗口是否封闭。

4.3 精准水位在体系间的传递

水位传递的必要性

许多时分，实时体系并不是孤立的，多个实时核算体系之间存在着数据的交互，最为常见的方法是两个实时数据处理体系是上下流的联系。

详细表现为：两个实时数据处理体系之间经过音讯行列（比方社区的Apache Kafka）来完成数据的传递，那么在这种状况下，怎么完成精准水位的传递呢？

详细完成过程如下：

1、上游实时核算体系的日志源，确保日志是点对点发布的，这样能够确保大局水位的精准度（详细份额是可调的）；

2、在上游实时核算体系的输出端（sinker/exporter 到音讯行列端），需求确保运用大局low watermark的下发，现在咱们选用把大局水位信息打印到每条日志上面来完成传递；

3、在下流实时数据核算体系的Source端，需求解析日志携带的水位信息字段（来自上游实时核算体系），并开端作为水位的输入（Input Low Watermark），开启层层水位的迭代核算和大局水位的核算；

4、在下流实时数据核算体系的Operator/Sinker端，可依旧能够用日志的Event Time来完成详细数据切分，来作为窗口核算的输入，可是触发窗口核算的机制，依旧以Watermark Server 回来的大局Low Watermark为准，以确保数据数据的完好性。

△精准水位在实时核算体系之间的传递机制

05 实践作用和后续展望

5.1 实践线上作用

3.1.1 落地数据的实测作用（完好性）

实践线上测验，选用精准水位（装备水位精度99.9%,即只答应千分之一的源端实例推迟），在日志没有推迟的状况下，实时落地的数据和离线数据，在同一个时刻窗口（Event Time）下作用比照方下（基本都是十万分以下）：

△源端日志没有推迟的状况下数据完好性作用

在源端日志呈现推迟的状况下(<=0.1%源端日志实例推迟的状况下，水位还会持续更新),数据diff作用全体基本在千分之1 左右(受到日志源端点对点日志自身可能存在数据不均状况的影响):

在源端日志呈现大面积推迟的状况下(>0.1%源端日志实例推迟的状况下)，由于运用了精准的水位机制（水位精度99.9%），大局水位不会更新，实时数据写AFS的窗口不会封闭，一向等待推迟数据的到来和大局水位得更新才会封闭窗口，以确保数据的完好性，实践测验结果如下（在千分之1.1-千分之1.2之间，受到日志源端实例自身存在不均状况的影响）：

5.2 总结和展现

经过实践精准水位的研究和实践线上的运用，依据精准水位的实时数据仓库，在具有时效性提高的一起，具有了更高、灵活数据的精度机制，在安稳性优化后，实践上完全已经代替之前的离线和实时两套数据仓库体系，完成了真正意义上的流批一体数据仓库。

一起依据中心化的水位机制，也后续面对着功能优化、高可用（毛病康复机制的完善）和更精细粒度精准水位的挑战（在窗口核算触发机制下）。

——END——

参考文献：

[1] T. Akidau, A. Balikov, K. Bekirolu, S. Chernyak, J. Haberman, R. Lax, S. McVeety, D. Mills, P. Nordstrom, and S. Whittle. Millwheel: Fault-tolerant stream processing at internet scale. Proc. VLDB Endow., 6(11):1033–1044, Aug. 2013.

[2] T. Akidau, R. Bradshaw, C. Chambers, S. Chernyak, R. J. Fernndez-Moctezuma, R. Lax, S. McVeety, D. Mills, F. Perry, E. Schmidt, et al. The dataflow model: a practical approach to balancing correctness, latency, and cost in massive-scale, unbounded, out-of-order data processing. Proceedings of the VLDB Endowment, 8(12):1792–1803, 2015.

[3] T. Akidau, S. Chernyak, and R. Lax. Streaming Systems. O’Reilly Media, Inc., 1st edition, 2018.

[4] “Watermarks – Measuring Time and Progress in Streaming Pipelines”, Slava Chernyak , Google Inc

[5] P. Carbone, A. Katsifodimos, S. Ewen, V. Markl, S. Haridi, and K. Tzoumas. Apache flink: Stream and batch processing in a single engine. Bulletin of the IEEE Computer Society Technical Committee on Data Engineering, 36(4), 2015.

推荐阅览： 视频修改场景下的文字模版技能计划

浅谈活动场景下的图算法在反作弊运用

Serverless：依据个性化服务画像的弹性弹性实践

图片动画化运用中的动作分化方法

功能渠道数据提速之路

采编式AIGC视频出产流程编排实践