一、数据湖在快手的应用历程

1.业务面临的问题与挑战

快手业务发展迅速，对数据精细化运营的要求越来越高。随之而来，数仓的数据模型持续快速增长。这带来了两个主要问题：

其一，计算和存储成本也随之线性增长。在当前降本增效的大背景下，持续的成本增长与团队的目标战略相悖。

其二，庞大的数据模型给治理和运维带来了挑战。多套数据模型迭代节奏不一致，容易导致数据一致性的质量问题，运维成本越来越高。

快手是一家多元化的业务公司，不可避免地会涉及到跨部门的数据协作。以计算ROI 为例，就需要汇总收入和支出两部分数据，而这些数据掌握在不同的业务部门手中。跨部门协作时，主要会遇到两个问题：

其一，时间的匹配。由于不同部门的业务侧重点不一样，在排期上难免会有差异，影响协作效率。

其二，数据异动追踪不够敏捷。当数据发生异动时，由于联动上下游多方排查时数据连环依赖加工，造成牵连广泛、排查周期较长。

对数据时效性要求高的场景，比如活动效果监控、策略快速验证等，存在实时和离线数据误差的问题。如，实时数据显示当天目标达成或未达成，但次日离线数据结果相反，这就会影响到业务决策的及时性和准确性。

对于数仓规模为什么会持续扩涨，接下来基于真实的案例做分析。从需求交付的视角，最细粒度的目标是基于[公共模型 3]同时交付核心日报、增长钱效、增长日报 3 个需求；这样看起来最合理的数仓模型只需要 1 个模型即可；但，实际为什么不行。我个人认为原因有二，其一：面向数据应用的视角，时效 SLA 是绕不开的话题，因为用到多个数据来源，将结果整合到一起，数据的时效 SLA = 最晚的数据源就绪时间 + 任务执行时间，那么为了满足数据时效 SLA 的诉求，会建设[公共模型 1&2&3]；其二：如果将大量的业务过程的指标和纬度整合到一个模型，当前的计算引擎(Hive、Spark)的执行时长过长&优化难度较大；从而进一步带来时效 SLA 的保障压力。

那么有没有办法实现纯面向领域模型、业务过程、数据建模理论，满足计算性能要求，满足时效 SLA 要求的解决方案。经过思考，我们需要一个引擎，它支持对数仓模型的更新写。

2.架构演进：从 Hive 到 Hudi 的技术变革之路

经过调研，数据湖技术支持对数仓模型的更新写。市面上有多个引擎该如何选择？主要的评判标准有三：第一，引擎的功能丰富度，功能越丰富，就可以适配更多的业务场景，适用性更强；第二，与快手现有大数据架构和技术栈的契合度，契合度越高，引入新引擎的投入越小、时间越短，解决问题的效率越高；第三，引擎的自动化程度，自动化程度越高带来的运维成本越低。

综合对比后，Hudi 凭借其丰富的功能、与现有架构的良好适配性，以及相对较低的运维成本，成为快手大数据团队的首选。

选定引擎后，对数仓架构的规划蓝图是：按照业务实体整体设计大宽表，实现跨领域的打通(增长、商业化、电商)，跨业务的并行协作；单领域(增长)的多业务过程的团队内并行协作；业务间&团队内实施的同学关注于实体粒度下实现。依据 SLA 的诉求将模型拆成合理的子任务，通过更新的方式补充模型数据内容。

下边我们基于问题看下如何应用。

3.快手 Hudi 数据库应用推广历程

我们依赖引擎的更新能力，可以从纯数仓架构最理想模型的视角设计数仓模型。比如，我们将[数据统计]的所有指标和纬度 + 实体 ID 整合，建设跨主题的明细表，具体方案：

（1）基于时效SLA 的诉求，将子任务拆成 4、5、6、7 点执行的 4 个任。

（2）不用时间点执行的子任务，更新数据内容到跨主题的明细表。

（3）上层应用基于时效 SLA 抽取部分字段计算满足业务诉求。

综上，可以满足数据架构的合理性、数据时效 SLA 的诉求、不同数据域(团队)的协作。

对比传统的一次性更新的模型，子任务逻辑更简单、数量更小，因此任务的计算&执行效率更高，进一步提升了数据的 SLA 时效。

针对上述的建设过程，经过真实业务验证取得了一些成效。

4.快手Hudi 应用实践初见成效

（1）从数仓模型视角：引擎更新能力的支持，可以将我们过往散落的模型中的业务过程做有效的整合。能更聚焦和详细的通过数据描述业务；同时在数据的查找、使用、应用(计算)效率上有显著提升。

（2）从数仓规模视角：去掉了因时效 SLA 带来的非必要中间模型，因计算能力不足拆分的优化模型；数据规模有显著下降；规模的下降带来运维压力的减轻、存储、计算成本的下降。

（3）从数仓增量视角：除必要的新实体，绝大部分工作体现在对实体资产的迭代；使得公共数据的完备度持续完善，复用度持续提升；从而间接提升研发效率。

从结果来看，数据湖技术在生产、应用、效率、成本上是有收益的，那实际的推广策略是什么，如何评估新引擎推广的 ROI？

在推广策略上分为几个阶段。

要推广一款新的基础组件，要找准切入点。我们重点聚焦在当前 Hive 和 Spark 生态无法有效解决的"老大难"问题：活动的分钟级时效问题、状态演变的全量回刷场景、DAU 点击的时效优化场景。通过解决“老大难"问题，从业务的视角可以验证引擎可以解决过往的不可能，体现其增量价值。

在增长业务验证其 100% 支持业务的可能性，从历史任务的改造迁移、增量任务的直接应用，结果如上数据。通过整个业务方向的论证，可以认为：引擎在解决业务问题上具有普遍适用性。

（3）工具链生态建设、提升研发效率

技术落地的关键在于复用。快手内部拥很多业务部门，要做到全面普及，必须标准化使用范式，沉淀出一整套工具链。同时，我们在不断地实践中探索总结出了一些技术最佳实践，以 ShowCase 的形式推广到各个业务部门，实现了经验的快速复制。

在引擎技术的可能性基础上，加上工具生态的效率加持；公司各个团队根据自己的业务场景和业务痛点进行针对性的应用与优化；目前已经得到广泛的应用。

二、数据湖在快手的应用案例

1.业务赋能：Hudi 在快手的典型场景

在数据同步方面，Hudi 展现出了不错的效果。通过将小时或者天的定时触发同步，迭代成实时的数据同步；这种数据同步模式，为许多实时性要求高的业务提供了有力保障。业务方不必再受限于夜间批处理的时间窗口，而是可以随时消费到最新的数据，极大地提升了数据应用的灵活性。在时效上收益明显，比如，一些核心的场景有60~90 分钟的提升。

在某些场景下，仅有批处理还不够，还需要实时的流式计算能力。Hudi 通过无缝集成批处理引擎和流处理引擎，很好地满足了这一诉求。比如，除夕的红包雨，需要在两轮红包雨之间完成下一轮 Push 推送的计算，使用历史的小时计算需要 4~5 个小时的时间，但使用 Hudi 可以在上一轮红包雨期间完成参与用户的更新标记。Hudi 从技术上满足了业务的场景诉求。在活动期间高频应用，拿到了显著的结果收益。

基于宽表数据建设，将历史基于时效&计算优化的 71 个模型，设计整合为基于设备&用户为实体的 3 个模型，同时基于 SLA 的诉求拆分不同的子任务，最终在模型规模、计算成本、存储成本都拿到不错的收益。

基于引擎的更新能力，对数仓模型的设计思路和实现方式也有根本上的改变；比如，在计算 N 留存的设计，从过完多次重复的笛卡尔积计算转为简单更新计算，在时效和成本上取得显著收益。

2.快手 Hudi 应用实践的一些思考

企业级服务的推广切忌闭门造车，一定要深入了解一线的业务需求，找准痛点，才能真正发挥技术的驱动作用。快手的例子充分说明，Hudi 之所以能够在较短时间内取得骄人的成绩，正是得益于其直指业务痛点的能力。从这个意义上说，Hudi 在快手的成功首先应归功于需求的精准引领。

（2）制度先行，奠定规范基础

Hudi 在快手的推广之所以能够做到体系化，与其完善的配套制度是分不开的。通过建立统一的数据分层规范，快手为 Hudi 构建了一个蓬勃发展的良好生态。同时，将 Hudi 的最佳实践以制度的形式固化下来，又为后续的推广应用扫清了障碍。这为我们提供了一个很好的借鉴：任何新技术的引入都要考虑与现有的制度规范相配套，二者相辅相成，才能创造奇迹。

（3）打破壁垒，集体智慧方显威力

Hudi 在快手的成功应用离不开各方的通力协作。从最初由基础架构团队主导，到后来获得越来越多BU 的青睐和使用，我们越来越意识到要打破部门壁垒，让集体智慧发挥出最大的威力。正如开源界流行的 "Given enough eyeballs，all bugs are shallow" 法则，新技术能否真正落地，关键在于能否调动起全员的积极性，在实践中不断打磨，集众人之所长，补己之所短。

总而言之，快手在 Hudi 的引入和推广过程中积累了丰富的经验，也收获了不菲的回报。其成功的要义在于需求引领、制度先行、破除壁垒，我们期待 Hudi 在快手能够为业务创新和增长提供源源不断的动力。也希望我们的实践能给业界带来一些启示，为同行提供一些可资借鉴的范式。技术的进步永无止境，让我们携手共进，共创美好未来!

Q：新的 Hudi 架构后，查询速度优化可以从哪些方面来考虑？

A：对 Hudi 的查询有两种模式，第一种是在生产完成数据更新后即可以读，第二种是数据需要 merge 之后才能使用，这种情况下需要等待 merge 之后再读取数据。从生产读的话，可以基于 Hudi 无增量来消费上游的变更数据，通过变更数据加上增量计算减少开销提高性能。分析查询的话，可以加上二级索引来快速进行查询。