数据湖屋即将到来，但并非一路坦途

数据仓库（Data Warehouses）和数据湖（Data Lake）目标非常明确。通常，数据仓库根据预定义的模式存储结构化数据，以便快速查询生成报告。而数据湖存储和处理各种数据类型，包括非结构化数据，并支持高级分析、数据发现以及人工智能和机器学习工作负载。

“数据湖屋”（Data Lakehouse）的概念出现了，它结合了这两者优点。

理论上，数据湖屋可以避免使用两个独立的系统进行数据存储和分析。它将两者集成，消除在系统之间数据移动，并支持跨所有数据集的无缝查询。此外，随着公司开始寻求利用人工智能，数据湖屋可以为人工智能模型提供单一的事实来源和更全面的数据视图。数据湖屋也会降低成本。今天的企业客户抱怨费用飞涨，因为他们必须付出高昂的代价才能同时使用数据仓库和数据湖。

当然，像Snowflake(数据仓库的领导者)和Databricks(数据湖的领导者)这样的供应商都渴望扩展到彼此快速增长的市场，随着公司争夺AI（人工智能）/ML（机器学习）工作负载，竞争只会加剧。从2022年到2026年，这些行业预计将以25%的复合年增长率增长，比整体数据分析市场的速度快1.7倍。按照预期的增长率，合并后的市场将成为数据分析领域最大的细分市场，超过关系数据库和非关系数据库的支出。这两家公司都在积极开发产品和技术，以扩大能力，并在寻求构建数据湖屋的过程中进入对方的核心领域。

然而，尽管数据湖屋的想法很吸引人，但在目前这可能更多的是一种愿景而不是现实。是的，将数据仓库的查询速度与数据湖的数据结构灵活性相结合将会改变游戏规则。问题在于它们的底层架构在结构上是不同的。

目前研发人员正通过开发特定技术，努力实现从数据湖到数据湖屋的转变。其中一个进步涉及新的查询引擎设计，它促进了数据湖上的高性能SQL执行。这些查询引擎加速器在开放表格式(如Delta Lake、Apache Hudi和Apache Iceberg)之上创建了一个软件层，并带来了接近数据仓库查询速度的改进性能。

不过这些查询引擎加速器的一个限制是，当成千上万的并发用户试图访问相同的数据时，它们往往会出现问题。这种可伸缩性问题可能会阻碍它们在大型企业场景中的广泛采用和应用。因此，尽管这些查询引擎可以显著提高数据湖的价值，但它们不太可能完全取代数据仓库的功能。

另一边，数据仓库则采用开放表格式来启用数据湖功能，并促进向数据湖的过渡。例如，AWS和Google Cloud利用开放表格式的Apache Iceberg作为他们的“数据湖引擎”。它们将非结构化数据存储在AWS的S3或Google Cloud Storage中，而结构化数据驻留在Redshift或BigQuery中。

与此同时，Snowflake正试图通过Snowpark在其平台上直接处理Spark数据，从而降低对Databricks的需求。然而，现实情况是，Snowflake还没有实现与Databricks相同的功能。特别是，Databricks在其核心领域保持优势，因为它开发了特定用例的引擎加速器。

数据湖屋概念的另一个主要缺点是供应商锁定。现实情况是，大多数公司都不希望严重依赖单一的技术提供商来满足他们的数据存储、处理和分析需求。从长远来看，这种依赖关系可能会限制组织的灵活性，因为在没有重大努力、成本和潜在的操作中断的情况下切换到其他供应商是具有挑战性的。

谁先到数据湖屋?

虽然考虑到单一平台的潜在好处，人们确实希望创建一个数据湖屋，但对于数据湖还是数据仓库是实现数据湖屋范式的最佳选择，目前还没有明确的共识。

一些人认为，云数据仓库已经解决了数据并发性这一最棘手的问题，允许成千上万的用户同时访问数据。其他人则认为，分层进行数据优化比复制数据灵活性更容易，从而为数据湖提供了优势。

因此，虽然数据湖屋的概念仍然具有吸引力，但我们相信，在可预见的未来，客户将继续并行运行数据湖和数据仓库技术。