就在一年前，我们发布了 Onehouse——一种开放的、完全托管的、云原生的lakehouse服务——以从根本上缩短最先进的数据湖的价值实现时间。Onehouse 提供在开放格式之上构建和运营数据湖所需的核心数据基础设施服务，让原本艰巨的旅程变得轻松。
自推出以来，我们与几位早期用户合作，将我们的产品愿景变为现实，并为他们的生产数据湖提供动力。我们的目标是在 lakehouse 技术之上提供云数据仓库堆栈的易用性和自动化，反过来也为用户提供急需的成本效益和性能优势。作为这一旅程的重要里程碑，我很高兴地宣布由 Addition 和 Greylock 合作伙伴领投的 2500 万美元 A 轮融资。我很荣幸 Jerry Chen (Greylock) 和 Aaron Schildkrout (Addition) 加入我们的董事会。
在此期间，我们还与 100 多家组织就其数据湖和数据仓库挑战进行了接触。在下面的部分中，我们分享了它们如何帮助塑造我们的路线图，以及行业趋势和我们对云数据基础架构的长期愿景。
Lakehouse架构站稳脚跟
早在 2021 年，我们采访过的大多数组织都对新的 Lakehouse 技术感到好奇。然而，从许多方面来说，2022 年是 lakehouse 取得突破的一年，我们与之交谈的几乎所有组织都在积极评估这一转变。作为一个在 lakehouse 技术被称为“lakehouse”之前就一直在研究它的人，看到该类别令人难以置信的增长和势头，我感到无比兴奋。Apache Hudi 去年的参与度创下历史新高，因为大大小小的公司都使用该平台来构建他们的数据湖。现在几乎所有主要的云仓库和云数据湖引擎都集成了三大 Lakehouse 存储项目。Ahana、Dremio 和 Starburst 等许多供应商都围绕 Lakehouse 重新命名了他们的整个云产品。
总而言之，Gartner 仍然正确地将 Lakehouses 置于炒作周期的顶峰，在没有完全提炼出技术可以或不能支持的工作负载的情况下，人们对此持乐观态度。在 Onehouse，我们有一个团队一直在运营可以说是地球上最大的交易数据湖。我们想从最初的 Hadoop EDW 愿景的缺点中吸取教训，其中的欣快和乐观最终未能交付快速采用该技术所需的成熟、易于使用的软件服务。我们正在接近 lakehouse 不可避免的平台化，基于我们来之不易的经验，我们将重点关注必要的自动化、卓越运营和技术创新。
垂直整合是错误的选择
几乎一致的是，用户对从一个垂直技术堆栈转移到另一个垂直技术堆栈持谨慎态度。这些用户中的许多人在几年前才从本地数据仓库迁移到云数据仓库，现在正面临一些关键的业务问题。随着数据量和管道数量的增加，成本也在激增。当这些组织希望开始他们的数据科学工作时，他们还需要不同开放数据格式和编程访问的数据，这在这些仓库中很难实现。最后，即使使用基于开放格式构建的替代技术堆栈，也担心会因各种专有服务而被锁定。在管理底层数据时，大多数引擎供应商只关注自己引擎的工作负载或数据格式。这让用户只能自己照顾自己，导致分析瘫痪或代价高昂的数据迁移。我们已经生活在一个不断发展的多引擎世界中，用户正在为传统分析、流处理、数据科学、机器学习和人工智能选择不同的引擎。现在查询 Apache Parquet/Orc 的最流行引擎与五年前不同。Onehouse 认为正确的以用户为中心的方法是为数据引入不同的引擎，而不是相反。Onehouse 支持将不同的引擎横向集成到一个管理良好的公共云数据存储中，这样就可以执行一次标准服务，如数据摄取、数据集群、索引和 GDPR 删除，并跨多个引擎使用。事实上，我们可以通过明智地将工作负载从云仓库中移出并减少使用高成本的专有托管服务来直接解决上面提到的一些成本问题。今天，我们通过宣布 Onetable[3] 功能在 Apache Hudi、Delta Lake 或 Iceberg 之间无缝互操作来解锁 Databricks 或 Snowflake 等供应商内部的专有性能优化，从而加倍兑现我们解锁这个多引擎生态系统的承诺。我们的后续工作将强调哪些引擎最适合哪些工作负载以及原因。
数据湖需要简单，而不仅仅是高效
我们遇到的许多用户都非常精明，并且完全了解围绕垂直云仓储数据堆栈与更分散、更灵活的数据湖架构的所有权衡[4]。他们只是开始使用云仓库，因为它是一项完全托管的服务，可以减轻他们数据团队的运营负担。他们的想法是，在足够大的规模下，他们可以通过经验丰富的数据工程师来扩展他们的数据团队，这些数据工程师可以使用 Apache Hudi 等技术构建他们的lakehouse。然而数据具有巨大的惯性，成功执行公司范围内的数据迁移的现实证明是一项艰巨的多年项目。
尽管去年全世界都对生成式人工智能着迷，但基本的数据湖基础设施仍然是手动的。我们公司最重要的创始目标之一就是改变这种现状。我们每天都在挑战自己，构建产品和技术，只需轻松点击几下，即可在几分钟内启动并运行数据湖。然后用户应该能够将各种查询引擎连接到他们的数据湖，执行工作负载评估并在几天后上线。当我们的第一个用户能够在几天内上线时，我们感到非常惊喜，其中有一个复杂的用例，例如近实时 CDC 到 AWS 上的数据湖。最后，通过 Apache Hudi 的综合数据服务集，甚至非 Onehouse 用户也可以获得这些好处。展望未来，我们希望做出更多贡献，使 Onehouse/Apache Hudi 成为用户云数据之旅的第一站。
批量数据处理有更好的选择
虽然使用开放表格式来扩展大型不可变表的元数据的想法在去年获得了很多关注，但这仅仅触及了像 Apache Hudi 这样的技术可以带来多大变革的皮毛。2016 年在Uber创建该项目的最初动机[5]围绕着一个大胆的新愿景，即取代湖/仓库上的批处理数据，这需要数据湖上更快的可变性。当时由于陷入批处理数据处理，我们 Uber 的梦想是将可变事务数据流近乎实时地增量处理到数据湖。如今，Apache Hudi 用户可以在任何云提供商上使用几条命令轻松完成此操作[6]。Hudi 通过围绕索引、合并读取存储格式、异步表服务、可扩展元数据、非阻塞并发控制以及对变更数据捕获的内置支持进行创新来实现这一目标，这些问题优化了所有需要可变性的用例。在过去的一年里，我们汇总了经过同行评审的全面比较[7]，这些比较提出了这些设计选择和技术差异化因素，并表明几家大型企业正在 Hudi 上运行高级增量处理工作负载。我们也为 Onehouse 带来了相同的增量处理魔力，用户可以在其中以完全增量的方式构建各层架构[8]，几乎不需要任何代码，避免了任何数据重新计算。在市场供应商和行业专家做出 2023 年预测之际，我们也想发表自己的看法。我们预测 Lakehouse 技术将遵循 Lindy 效应[9]，绘制出与主要关系数据库类似的路径，该效应表明一项技术存在的时间越长，它在未来出现的可能性就越大。Onehouse 旨在通过对 Apache Hudi 项目和产品创新的持续贡献来进一步推进增量处理愿景。我们打算在今年晚些时候就此分享更多信息。
向前
在我们开启公司生活的新篇章之际，我要衷心感谢我们所有早期的设计合作伙伴、用户和客户的支持和反馈。我还要感谢我们这个规模虽小但才华横溢的团队，感谢他们的奉献精神和辛勤工作。最后感谢 Apache Hudi 社区的持续合作和推动开源数据湖平台的创新。
可以毫不夸张地说，Onehouse 的成功可能会对行业产生深远影响，我们最终可以将数据存储和管理与操作数据的不同计算引擎分离，让我们永远摆脱数据锁定。我们将以诚意和我们的首要原则来实现这一愿景，向前。