重磅！基于Apache Hudi的商业公司Onehouse成立

Apache Hudi[1]（简称“Hudi”）于 2016 年在 Uber 创建，旨在将数据仓库功能引入数据湖以获取准实时的数据，开创了事务数据湖架构，现已在所有垂直行业中进入主流。在过去的 5 年里，围绕该项目已发展出一个丰富多彩的社区[2]，并迅速创新。Hudi 为数据湖带来了类似数据仓库及数据库的功能，并使诸如分钟级数据新鲜度、优化存储、自我管理表等新事物直接在数据湖中成为可能。来自世界各地的许多公司都为 Hudi 做出了贡献，该项目在不到两年的时间内增长了 7 倍，每月下载量接近 100 万次。我很荣幸目睹了亚马逊[3]、字节跳动、Disney+ Hotstar[4]、GE Aviation[5]、Robinhood[6]、沃尔玛[7]等更多企业采用并构建基于 Apache Hudi 的 EB (Exabyte) 级数据湖，来支持其关键商业应用。紧跟潮流，我很高兴能在这里分享过去几个月我们利用 Hudi 正在构建的公司和产品 – Onehouse。为了启动我们的征程，我们获得了 Greylock Ventures 和 Addition 的 8 百万美元的种子轮投资——这些投资公司在培育企业数据初创公司方面拥有出色的业绩记录和丰富的经验。以下是我们的旅程故事和对未来的愿景。

数据湖（Lakes）、数仓（Warehouses）、湖仓一体（Lakehouses）

在与 Hudi 社区中的不同公司合作时，我们注意到了一个共同模式。这些公司通常先采用主要支持传统 BI/Analytics 的数据仓库（简称“数仓”），主要因为数仓易于使用且通常可以完全托管。然后，随着公司业务的增长，工作负载的复杂性和规模也会随之增加，从而导致成本呈指数级增长。不断上涨的成本及在数仓中无法实现的更高级数据科学工作负载促使他们投入数据湖。而对数据湖的投入伴随着一系列全新挑战，包括并发性、性能和对成熟数据管理的缺乏。大多数公司最终在夹缝中求生存，被迫游走其中，同时使用数据湖和数仓来管理数据。然而，在过去几年里，像 Hudi 这样的新兴技术提供了解决上述一些问题的方法——通过向数据湖添加关键的数仓功能，如事务、索引和可扩展的元数据。最近，湖仓一体（Lakehouse）作为一种支持两种工作负载的新型湖而广为人知。这个术语是新的，但它蕴含了我们最初在 Uber 建立 Hudi 的初衷。

大数据管理问题依然存在

即使数据管理技术存在，湖仓一体仍然需要由专业、昂贵的工程团队，使用各种开源工具来建造。工程师需要深入了解至少 3 到 4 个分布式系统或数据库，并从头开始构建包括 CDC 摄取、数据删除/屏蔽作业、文件大小控制及数据布局优化在内的所有模块。在与 Hudi 社区互动的五年中，我观察到这一流程通常需要几个月、甚至一年多的时间，时间长短取决于数据规模和复杂性。在大多数情况下，这些公司会重复构建同样的数据基础架构的各种模块。与其它项目不同的是，Hudi 从一开始就认识到了这个问题，提供了一组丰富的开放服务，包括回收存储空间[8]、流式摄取[9]及优化表[10]以提高性能。例如，我们已经看到，依赖 Hudi 流处理工具来构建数据湖摄取的公司接踵而至，这推动了代码级别的标准化。然而，公司仍然需要针对这些服务及其相互作用来建立卓越的运维，以使其数据湖充分发挥潜力。运维数据湖及湖仓一体具有挑战性；当您拥有实时流处理和事务数据源，并且需要复杂的变更数据捕获（CDC）管道时，这项工作会变得更加艰巨。事实上，我们在 Uber 围绕 Hudi 构建了大量运维系统，这使得将数据湖作为服务提供给拥有两万多名员工的大型全球企业成为可能。在过去十年中花费了无数小时解决生产中断，恢复了五个大型分布式数据库（包括 Voldemort、ksqlDB，当然还有 Hudi）的系统稳定性，我可以肯定地说，卓越运维是成功的数据基础架构的最重要一面。由于缺乏标准化的高质量数据基础架构，围绕湖仓一体技术，许多数据湖项目从未充分发挥其潜力，而这正是我们要解决的问题。

Onehouse

我们从用户的角度，重新思考了整套数据基础架构。例如，假设我要加入下一个 LinkedIn 或 Uber，我会如何架构数据为其成功铺路，我们学到什么经验教训以及我们会改变什么。我们认为数据不应该被锁定在特定的查询或计算引擎中，而是可以在不同的 BI、AI 工具和框架中普遍接入，位于供应商中立的标准化数据基础架构之上，无需再次投资 3 到 4 年。Onehouse 就这样诞生了。 Onehouse[11] 是您的湖仓一体（Lakehouse）的云原生托管基础，可自动摄取、管理和优化您的数据以加快处理速度。Onehouse 并不是一个新的查询引擎；它是一个自我管理的数据层，可与任何流行的查询引擎或数据/表格式及供应商无缝互操作，因此您可以选择最适合您需求的组合。通过将突破性技术与全面托管且易于使用的服务相结合，企业可以在几分钟而不是几个月内构建数据湖，实现大量成本节约，并仍然拥有开放格式的数据。Onehouse 旨在成为您的数据基础架构的基石，作为您所有数据的归宿。宏观上我们从应对以下类别的挑战开始。持续数据交付：基于 Hudi 的增量存储和处理能力，Onehouse 将用增量管道取代老式的批处理。只有处理发生变化的数据才能节省大量成本和实现低延迟管道，让您的数据始终保持最新。魔力数据架构：Onehouse 可大规模提供魔力性能提升，无需人工调参。使繁琐的数据杂务自动化，包括聚合、缓存、小文件合并、目录同步和扩展表元数据，让数据工程师和科学家专注于创造商业价值。真正开放与互操作：有时您需要 Spark，有时您需要 Presto，有时您仍然需要一个数仓。现代数据生态系统的发展速度如此之快，以至于与许多具有相同水平性能和功能的引擎的互操作性是达成可扩展性上唯一要考虑的。虽然开放格式是必要的第一步，但如果没有开放数据服务来管理数据，用户将面临同样的风险，即被锁定在提供这些服务的少数供应商中。通过复用 Hudi 的开放服务，Onehouse 提供了真正的开放性和灵活性。大规模节省成本：Onehouse 帮助公司采用面向未来的架构，而不是在后期为复杂工作负载进行改造以导致数据迁移项目及昂贵的数据基础设施费用。Onehouse 在用户开启分析之旅时尽早实现易用性，同时随着数据量的增长或复杂性的增加，以具有成本效益的方式进行扩展。

Hudi 不是真正的产品

那么，这对 Hudi 有什么影响呢？实际上，比以往任何时候都好！我们不是来照搬开源来实现企业版的 Hudi。有了这笔资金，我们现在可以将全职、全身心投入的工程师团队的精力带到 Hudi 社区。在支持 Hudi 社区四年多后，我认为 Hudi 的巨大增长推动了用户支持、开发人员参与和社区期望，远远超出了志愿者工程师或不同公司的单个工程团队所能承受的范围。我们将成为 Hudi 的狂热用户、社区的积极贡献者，并继续作为该项目的拥护者。我们计划贡献更多来自 Onehouse 的核心开源功能，以帮助 Hudi 这个已经优秀的平台服务变得更好。作为 Onehouse，我们的重点将是利用我们在大规模数据系统方面的集体运维经验，帮助那些无法负担如此大量工程投资的公司。我们单独在这篇 Blog[12] 中清晰地阐述了更多我们对于开放的承诺。

下一步

在过去的几个月里，我们一直在努力对这一愿景进行初步迭代。如果您正处于建造湖仓一体（Lakehouse）的风口浪尖，或者正在积极寻求面向未来的数据架构，那么我们很乐意与您合作，将这个产品和平台变为现实。可以通过如下方式之一与我们联系：

1.加入我们的试点！[13] 在我们早期试点计划的第一批中，我们有少量名额。如果您有兴趣成为设计合作伙伴，请点击上方的“Request A Demo”或直接联系 info@onehouse.ai[14]。2.加入我们的团队！[15] 我们正在招聘一支由世界级人才组成的多元化团队，并正在寻找对我们的使命充满热情的人。3.通过请求演示了解更多信息或将任何问题发送至 info@onehouse.ai[16]。

最后，我想借此机会感谢我们的投资人一直以来的不懈支持，尤其是在我经历了一年半的漫长而艰辛的绿卡之路。作为一个通过工作签证将四年的周末和夜晚投入社区的人，这是我所期待的最好的结果——能够全职工作让 Hudi 和数据湖变得更好。

继续构建…