Iceberg、Hudi、Delta Lake 等表格式在数据湖的应用现状如何？各自有哪些侧重点，存在哪些挑战？
💬 专家观点：
这里只讨论 Iceberg 和 Delta Lake。Iceberg 和 Delta Lake 这两个项目的竞争是比较激烈的。它们的侧重点一样，都是为了解决在巨量存储上如何搭建能够保证 ACID 的技术架构。
它们的架构思路也非常类似，即通过 log 的方式来记录一张表的数据文件路径和历史变更，而不是依赖文件系统的 List API。List API 会带来不确定性，会有不一致的结果产生。数据湖格式一般都会基于 log 做一些优化，比如会同时记录一些额外的数据结构来做索引，比如某些列的最大最小值，用来过滤数据文件。
特性上，它们也是比较接近的。比如用索引加速查询，ACID、时间旅行等也都有。
它们主要的不同点，是在目前的生命周期阶段上。Delta Lake 整个社区更偏向于产品化的功能，更易用。因为 Delta Lake 已经在 Databricks 上线了好几年了，服务了很多客户。
而 Iceberg，如果你很懂它的代码，可以把它调校得非常高效和好用。但对于新兴公司，就会发现它比较难上手。
应用上，如果是大公司准备大力投资在数据湖上，那可以采用 Iceberg，深入研究源码。但如果是一个小公司，没有足够多的资源，可能就不好直接拿来用。
性能上，至少根据目前第三方的 benchmark，Delta Lake 在很多场景比 Iceberg 更快，特别是在写场景。因为在写场景，一般需要更多调校。比如说每个写文件的大小，什么时候要做 compaction，什么时候可以做逻辑删除而不是直接重写一个文件等等各种各样的小细节。这方面目前 Delta Lake 估计更成熟一些。
数据湖架构结合数据存储、数据开发、数据治理等方面的应用现状如何？数据湖给这些模块带来的收益各自有哪些？
💬 专家观点：
数仓是一个非常成熟的市场。目前在数仓领域，Databricks 正在基于数据湖来重新构建一套数仓架构。这样用户可以使用数仓的性能和功能，同时数据本身可以自己掌控。因为文件不是私有的，而是放在数据湖上面，可以随时取用，这也是我们推荐的 Lakehouse 架构。甚至云数仓的一个领头羊 Snowflake，他们也支持 Iceberg 来打造 Lakehouse 架构。因为用户觉得数据自己保管更有安全感，所以这个理念还是非常深入人心的。
如果能够在开放的数据格式和数据存储上面，构建一个高效的数仓架构和系统，吸引力也是非常大的。
数据治理也可以在 Lakehouse 中进行统一。通过这些新兴的数据湖格式，我们可以把数据湖上的数据资产也包装成表的形式，使用跟数仓统一的接口进行治理。
数据湖的性能优化方向（upsert、Schema Evolution、变更数据流、ACID 事务、高效并发更新、时间旅行、文件大小调整、统一元数据）中，每个方向的应用现状如何？每个方向的重要性如何，存在的挑战有哪些？
💬 专家观点：
性能方面还是数据湖落地的主要挑战。数据湖原本的目标是储存大量的数据，性能一般并不是它特别看重的点，存储成本相对来说更加重要。目前数据湖的基本功能都实现了，能够支持一些原子性的操作，但是性能一直存在瓶颈，特别是写性能。
因为数据流水线总归最后还是要落地的，数据处理完后，总归要存起来。所以 Iceberg、Delta Lake 两边都是在发力优化写性能。
写性能的一个主要场景就是 UPSERT。这里有很多细节，比如文件大小问题，文件太大，那读的时候过滤数据的能力就会下降。文件太小，打开和关闭文件的开销会非常的大。
读的性能优化主要涉及索引、缓存等方面。缓存跟 Iceberg、Delta Lake 这些表格式关系不大，架构上主要是搭建一个分级缓存来存储数据文件。但对这些表格式而言，主要关注的还是格式的定义，即怎么设计能够更好地支撑读写性能。相对而言，写性能还是更有挑战性。但索引是表格式关心的，表格式是以自己的格式来定义索引，从而关联文件或者数据块。目前来说，这些表格式基本上都能够做好索引。比如这些表格式有文件级别的索引，通过分区来做目录级别索引等。数据提前布局好的话，还可以省掉 shuffle，特别是 group by 和 join 这种复杂的 query。
ACID 的挑战挺大，目前来讲，各个不同的表格式都支持了 ACID 事务，但是事务的性能还是会有很大的不同。一个是高效并发更新，就是假设很多 client 同时提交事务的话，需要考虑怎么尽量避免冲突。如果冲突很频繁，经常会有写操作提交失败重试，那写性能就比较糟糕了。这时候就需要有个 commit service 来做协调，引入一些更高效的算法来避免事务冲突。
元数据管理方面，目前很多项目也正在开发数据湖上的统一 Catalog，是一个非常大的挑战。
总体而言，写性能以及相关的高并发、原子性，以及统一元数据等是最重要的挑战。
Schema Evolution、变更数据流、时间旅行没有什么性能优化点，更多在于功能实现，其中 Schema Evolution 是比较重要的方向。
数据湖在湖仓一体、流批一体方面的应用现状如何？存在哪些挑战？
💬 专家观点：
湖仓一体的一个核心点是数据资产的所有权，把数据所有权给到用户，并且提供比传统数仓比肩甚至更好的性能。同时用数据湖统一储存层，简化上层应用的开发和交互。
流批一体更多是计算引擎方面的设计，数据湖格式只要支撑好流式的数据读写就行，所以话题又回到了写性能上面。
湖仓一体的挑战，主要就是数仓的功能实在太多了。需要把它全部重新实现一遍，成本是比较大的。
▼
国内外数据湖的应用现状如何？两者之间有什么相同和不同之处？
💬 专家观点：
目前来看，国内外都有非常火的数据湖产品，并广泛应用在各行各业。因为现在的数据分析的应用场景很多跟 AI 相关，而以前主要是统计分析。
AI 兴起之后，我们拥有了更多的半结构化数据和结构化数据，这些数据是没法在数仓或数据库中挖掘价值的，数据湖便是唯一的选择。
技术理念上，两边非常接近，都拥抱了对象存储。对象存储就是把数据文件系统的功能给拆开来，只关注数据结构，通过文件名就能直接对应数据内容，不需要关心数据的布局，这样能够简化系统实现，来让数据系统更加高效和便宜。当然，传统的文件夹这种数据组织方式，也有一些可用的系统或插件。比如国内的 juice FS 提供了 posix 协议兼容的 API，可直接用它对接不同的对象存储系统，从而像管理本地文件一样操作 OSS 对象。这使得我们完全可以使用第三方的系统来支撑基于公有云的对象存储，搭建一个稳定系统。
但另一方面，现在的数据湖格式都是适配对象存储的，不需要复杂的文件系统功能也能实现 ACID。
国内外的不同，主要还是在渗透率方面。对于公有云的市场规模，欧美和国内的差距还是非常大。国内更多是大厂自建数据系统，上公有云的厂商相对较少。
国内外数据湖的未来发展方向有哪些？可否从相关内核技术、学术成果、业界最新进展的角度进行解答？
💬 专家观点：
在内核层面，数据湖本身并没有太多新的技术出现，目前比较稳定。
现在更多是在于业务方面甚至是使用体验方面的创新，就是怎么把数据湖的生态打造好。基于数据湖把各种各样的周边系统搭建起来，支撑各种应用，包括湖仓一体、智能数仓、流式数仓、AI 等应用，它们都环绕数据湖来展开生态构建。
应用上面，一旦技术成熟之后，就是考虑市场化，以及如何服务好用户，提升用户体验，这是目前的一个重要发展方向。各家企业都是在努力提升自己的产品体验，而不是搞更多高精尖技术的突破。
数据湖落地挑战的方方面面有哪些？ 
306
0
