在当今数据驱动业务的时代，企业对数据应用、数据分析的需求日益增长，同时伴随着业务的快速发展带来数据规模快速增长，而且企业数据类型(文本日志、图文、音频、视频、特征、对象等)不断扩展，对企业数据的建设、管理(含治理)、应用提出更高的要求和挑战。
数仓作为承载企业数据建设、管理、应用的主要载体，其通过ETL(Extract, Transform, Load)对数据进行结构化加工，形成具有层次结构、面向主题的数据资产，借助AI/BI的产品化能力，以数据形态具象化业务事实，实现业务数据的洞察和归因，从而辅助数据使用者做出正确高效的业务决策。
但是，受限于数仓设计架构和技术水平的制约，复杂业务带来越来越多的数据类型，大模型与算法的广泛应用带来的数据特征工程的发展，因数据多样性&复杂度&模型特征给数据治理带来了新挑战和诉求，因此，需要更灵活、更普适的数据建设、运维、管理方式实现数仓的迭代升级，更好的赋能业务。数据湖对于数仓虽非新的设计理念和方法，但其架构和思想正是补充数仓不足的解决方案，同时伴随着Delta Lake、Hudi、Iceberg、Paimon技术的推出和逐渐成熟，使得数据湖技术在企业可应用于生产，帮助数据发挥更大的价值。
结合数据湖技术的迭代发展与各企业在数据湖应用上的探索与分享，我们邀请多位专家基于各自的业务应用和技术判定整理了此文，希望可以给予正在探索和应用数据湖技术解决自己业务场景问题的同学以参考和帮助。
本文是数据湖技术成熟度曲线的讲解说明，技术成熟度曲线覆盖85个数据湖关键技术点，包括技术成熟度、业务价值、技术周期、管理协作难度四大维度，评价技术点的前瞻期、成长期、热门期、衰退期、成熟期，讲述四大开源产品：Hudi、Iceberg、Delta Lake、Paimon，欢迎下载。
全文会从以下5点做阐述：
当前，各企业面临的挑战和要解决的问题各不相同。在数据湖的应用架构上也有所差异。数据湖常见的架构模式有以下几种：
1、湖上建仓，以湖的多数据类型的存储和管理优势为基础，实现将企业各类资产统一整合；结合数仓的结构化分层建设带来的性能优势；以湖、仓分层利用各自优势的方式实现企业多样性数据管理、高效数据应用。
2、仓上建湖，在固定的专业业务领域或业务相对稳定成熟的企业。数据内容相对固定，数据采集与管理相对稳定；主要挑战在于数据分析与数据应用，此时可以使用数据湖的更新、动态Schema等能力优化数据架构、数据治理，从而提升数据应用效率。
3、湖仓融合，数据仓库往往比数据湖性能更好，该架构利用与数据仓库类似的数据结构，并结合数据湖的低成本存储和灵活性，使业务能够快速、高效地存储和访问大数据；同时还能减轻潜在的数据质量风险；但，该架构成本更高，湖仓互转能力也有限。数据湖的规模和复杂性可能需要更多的技术支持(例如ACID、索引、元数据管理等)来管理和应用数据；此外，由于数据治理在这些系统的下游实施，数据湖更容易出现更多的数据孤岛，进而演变成数据沼泽。因此，在企业实践中会结合场景诉求在局部按湖模式建设、部分按照仓模式建设；来实现湖的丰富数据类型的存储优势；仓的数据应用效率优势。
4、湖仓一体，在湖仓融合的基础上更进一步。以数据湖格式(例如，Hudi、Iceberg、Deltalake的Data Format)为基础；将数据仓库和数据湖两者之间的差异进行融合，实现“湖里”和“仓里”的数据能够无缝打通，实现行数据的原子事务操作；可以借助数据分析引擎实现高效分析。
整体趋势上，各企业大多并非从0开始，基于数仓的建设服务为数据管理与应用是主要方式。因此更多的是以湖仓融合的方式切入点，慢慢迭代中向湖仓一体靠近。其中，湖上建仓实际案例不多，处于业务场景诉求探索期。在湖仓架构模式下，各组件都选择成熟稳定的Hive、Spark、Flink作为计算引擎；Sql语法支持相对普遍完善，简单易用降低了使用门槛，提升应用与推广的效率。但是，从数据生产建设的视角来看，基于列/事务/更新的生产模式带来的任务编排(基于列的生产任务的迭代、迁移、删减等操作)的迭代成本、管理复杂度还没有成熟的产品解决方案；随之带来基于列的元数据数据治理成本较高(灵活性带来复杂性)。
工欲善其事必先利其器，良好的规划和设计能有效提升数据建设的扩展性、稳定性、研发效率、应用效率；架构师要基于业务场景的特点、痛点、挑战综合考量对比行业解决方案间的差异，选择适配自己特点的体系架构。
当前主流数据湖引擎组件在功能设计会考虑以下原则：
1、一体化架构，基于湖的多数据类型存储优势，提供Data Format标准；提供基于事务的ACID能力，实现仓库对于行级数据的操作；提供高效的数据生产加工(COW、MOR、数据合并、读优化等)；以及当前热门的数据编织、统一湖仓元数据管理等；
2、弹性高可用，支持基于规模变化带来的横向的扩展或收缩，实现资源的弹性可控；计算能力绑定依赖成熟的计算引擎(Spark、Flink)提供稳定服务；
3、数据治理加强，相比基于表的一写多读的生产模式；基于列更新的生产模式，生产任务间的血缘关系粒度更细；基于列的任务在生命周期内的变更、迁移对上下游依赖迭代的成本，对血缘关系的管理会有更大的挑战；目前暂无成熟的产品解决方案，处于探索期；
4、高并发支持，得益于引擎的弹性高可用，业务可以基于规模的变化实现资源的横向扩展；良好的Data Format存储设计，可以实现基于事务的海量数据更新；
5、运维可观测，集群小文件的管理有良好的设计与实现，并能简单操作完成管理与运维。基于Metrics的运维监控与管理也在逐渐成熟；
6、高开放性，目前湖技术实现在Data Format设计与实现互不兼容。在开放与互通上还处于早期。因此也考验架构师在选型时对于业务挑战与痛点的挖掘与引擎架构的选型的适配能力。
7、全数据类型，多样的数据类型和复杂数据结构支持可以适配更多的业务场景，系统层级的支持也更容易推广和应用。目前还有一些数据类型需要逐步支持完善；
8、事务和数据一致性，湖技术对行级的更新的支持、保障事务的ACID能力，已经是当前湖技术框架的基本能力，在实际业务中得到相对广泛的应用。
存算分离作为是数据湖技术的基础核心能力单元，云存储又在成本上具有优势并且厂商可提供稳定的服务保障，使得数据湖技术在对云存储的支持上比较完善。数据湖技术成熟度曲线的讲解说明，欢迎下载
良好的文件存储格式能有效提升数据的读写性能，提升数据生产、应用的效率。其中Avro、Parquet、ORC为主流数据格式被广泛应用。
近年数据湖能在在企业广泛应用并取得成效。离不开Delta Lake、Hudi、Iceberg、Paimon在技术上的实现。Upsert能力使得数仓支持行级更新可以解决相似模型问题、迫于时效SLA压力拆分相似模型的问题；结合ACID事务能力实现高效入湖(实时化、基于更新减少操作数据)；Schema进化能力使得多团队并行&隔离&协作(基于实体的湖宽表)成为可能；Hidden Partition/Generated Column使得数据查询更加高效；批流一体使得一套代码实现实时开发与离线开的的整合，从而解决实时数据与离线数据gap的问题。在核心技术方向上Delta Lake、Hudi、Iceberg、Paimon实现路径大方向保持一致，又在各自特定的领域解决特定场景问题有所差别。增量数据的快速写入，增量数据的合并是快速入湖与高效读写的基础；Index能快速定位数据文件位置，从而实现快速更新与查询优化；Deletion Vector通过添加更新文件 + 删除标记的方式，避免数据更新/删除带来的文件更新，特别是在COW模式下能显著提升更新效率。数据湖技术成熟度曲线的讲解说明，欢迎下载
伴随着湖技术的不断更新和迭代；在离线数仓建设方向，可以使用实时入湖 + 增量分区 + Hidden Partition/Generated Column + Deletion Vector实现状态变化类实体宽表的建设，代替基于天diff计算新增、批量回刷/拉链计算更新数据；从而实现离线数据效率提升，数仓架构优化。通过批流一体的更新计算 + 实时化实现分钟级的数据服务，提升OLAP的服务效率；通过Schema进化 + 高效合并实现模型、画像特征的湖宽表实现，为机器学习、人群圈选等服务提供集成的多特征数据，简化模型数据应用方式、提升特征应用效率。出品人
陈玉兆 Onehouse Hudi Flink 负责人
作者
靳国卫 快手 数据BP负责人
翁才智 阿里云 技术专家
