本文来自数据湖技术成熟度曲线发布会圆桌。
Q：快手当初引入数据湖要解决什么问题，当前的现状如何？
靳国卫（快手 数据BP负责人）：
首先，从业务角度，我们当时主要面临以下几个方面的问题。
第一个问题:
是离线数据仓库规模的急速膨胀带来了巨大的存储和计算成本压力。快手的业务发展速度非常快，随着业务的扩展，离线数据仓库的规模也在迅速扩展。我们当时有大量的新表、新模型需要建设，尤其是数据量在迅速增长，这带来了计算和存储成本的急剧上升。同时，运维的复杂度也在不断增加，之前可能一个研发同学维护十几个模型，后来增长到一两百个，质检、巡检、数据保障的工作量大幅增加，这大大压缩了研发的时间，使得业务支持上的效率受到影响。
第二个问题:
是多次构建相似数据模型。随着业务的演进，我们需要快速响应不同部门的需求，构建不同的模型。例如，我们需要在每天早上8点能够看到DAU（Daily Active Users，日活跃用户）的数据，这个时间点的数据需要快速生成。其后10点的数据，业务团队可能又希望添加更多维度，于是我们需要再构建一个10点的模型，进一步细化数据。然而，业务人员后续又会提出更加复杂和定制化的需求，为了满足不同的时效性和精细化需求，我们需要构建多个相似模型，这样造成数仓不断膨胀，增加了模型维护的复杂度和存储的冗余。
第三个问题:
是数据的一致性难以保证。当业务口径发生变化时，多个相关的模型都需要同步更新。然而，由于模型数量众多，口径变化时我们很难确保所有相关模型都得到了及时更新。在交接过程中也容易出现遗漏，导致不同业务部门使用的数据存在不一致的现象。除此之外，模型之间的依赖关系也越来越复杂，尤其是在涉及多个业务线的数据时，一个模型的变动可能会影响多个依赖模型的准确性。我们有时会遇到某个叶子节点的数据计算依赖于十几层模型，这种依赖关系的复杂性增加了数据计算的难度和维护的风险。
除此之外，随着快手的业务发展，部门划分更为细化，当需要整合多部门数据时，数据中台需要与多团队逐一沟通，难度大、效率低。当遇到问题需要上下游团队联动排查时，也非常耗时。理想的情况是像服务端模式一样，在MySQL中定好主键，各方向可自行更新自己的数据。
另外，实时数据和离线数据存在gap，也对业务决策造成了影响。
为了应对这些挑战，我们调研了多种技术，最终选择了Hudi作为数仓的补充解决方案。首先，利用数据湖的特点，建好主键，针对不同时间点的不同要求，加入所需的维度即可，不再需要为每个时点构建一个新的模型，利用Hudi的Schema演进（Schema Evolution）能力可以实现相似模型的缩减，从而大大减轻了模型构建和管理的负担。
另外，在协作层面，在设计好整个模型的schema之后，各业务团队只要更新自己的内容即可。当指标出现问题时，也可以进行快速排查，提高了整体效率。
针对离线和实时数据gap的问题，我们采用实时入湖的方式，将数据导入Hudi表，通过公司one service引擎，即可实现ad-hoc查询。在此基础上，我们也在尝试利用Paimon批流一体的方式来进一步降低延迟。
以上就是快手对数据湖技术的实践。
数据湖的技术成熟度曲线，包括数据架构、设计原则、存储、文件格式、表格式、核心功能、前沿技术等接近上百个技术点，以及这些技术点各自的技术发展成熟度、业务价值和技术难度等，
欢迎大家扫码下载
。下载的文件夹里包括技术成熟度曲线、曲线的讲解视频和使用说明文档。
