数据湖在快手的运行通常

一、数据湖在快手的运行历程

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 无增量来消费抢先的变卦数据，经过变卦数据加上增量计算缩小开支提高性能。剖析查问的话，可以加上二级索引来极速启动查问。