Onehouse 对Apache Hudi开源社区的承诺
早些时候，我们宣布了我们的新公司 Onehouse，，它提供了一个建立在 Apache Hudi（简称"Hudi"）之上的托管 Lakehouse 基础。在此博客中，我们的创始人兼首席执行官 Vinoth Chandar（也是 Hudi 的创建者和 PMC 主席）希望透明地宣布我们的原则和计划，以有意义且不间断的方式继续为 Hudi 社区做出贡献。
1. 社区优于代码
对于不熟悉的读者，Hudi 由 Apache 软件基金会管理，任何个人或组织都不能对项目进行不公正的控制。Hudi 长期以来一直采用开放、透明的治理流程，涵盖代码审查、贡献[1]、RFC/设计提案流程、发布[2]、用户支持和路线[3]，这将继续推动该项目，我现在已经将开发开源软件作为我的日常工作，并花费了十年时间，因此没有什么能动摇我的承诺。
从长远来看，16 名成员强大的 Hudi PMC 中有 13 名目前在 Onehouse 以外的公司工作，我们的 PMC 和Committer来自世界各地的不同组织，他们都以关键任务方式依赖 Hudi，Onehouse 将加入这一长长的公司名单[4]，利用 Hudi 在我们的平台上构建服务，同时通过自身资源来加强社区来回馈社会。
支持 Hudi 社区已经四年多了，我觉得 Hudi 已经成为其自身成功的受害者，巨大的增长推动了用户支持、开发人员参与和期望，远远超出了志愿者工程师的承受能力，Onehouse 将为 Hudi 社区提供一个由全职工程师、产品经理和支持工程师组成的团队。
2. 开放服务，而不仅仅是格式
当我们研究市场并与不同的数据公司互动时，我们注意到一种趋势，即表格格式被视为"锁定"数据的新杠杆，然后在它们之上追加销售专有服务或专门针对查询引擎进行优化，大多数数据湖产品仅限于查询引擎或管道，没有成熟的自动化数据管理功能，如果没有任何开放服务来管理这些数据，即使是开放的表格格式，用户仍然被锁定或被迫进一步将自己的工程资源投入到零碎的解决方案上，我们认为这是阻止组织运营其数据湖的最大问题。
作为一个项目，Hudi 一直不仅仅是一种格式，这一原则可以追溯到 Hudi 在Uber的起源，即使是第一个版本也带有自动回滚、索引[5]和清理功能[6]，由于聚簇[7]、快照/恢复[8]、压缩[9]、文件大小调整[10]、流式摄取[11]、增量 ETL[12]、CDC 源[13]等丰富的开放服务，用户通常会选择 Hudi 而不是其他，以开源形式提供这些服务，组织可以加强并运行这些服务，从而全面减少重复的工程工作。
在 Onehouse，我们希望坚持这些原则，并贡献更多的基础 Lakehouse 组件，例如缓存服务或独立的元服务器，Onehouse 的使命是为我们的客户提供一个开放的、可互操作的数据平面，跨越众多湖引擎、仓库和其他 ML/AI 数据框架，虽然这可能需要我们构建与其他格式和系统的互操作层，但我们仍然坚信 Hudi 是当今可用于摄取、管理和优化数据湖上数据的最通用的工具包。
3. 正确获取开源基础架构
在过去 2 年中经常出现的一个问题是："你们的开源商业化战略是什么？"。一个都没有。我在这里从来没有任何策略， Hudi社区2021总结[14]刚刚发生，我们从来不想做的事情是创建某种"企业"版本来锁定所有有用的功能，通过研究不同的开源公司，我们注意到客户和开源用户都喜欢公司支持开源和商业/托管产品之间的无缝切换。
通常，当公司开始为他们的早期分析需求时，他们缺乏在不同开源项目之上构建数据湖所需的工程资源。相反，他们选择从垂直集成和完全托管的数据解决方案开始，这些解决方案通常是封闭的。随着工作负载复杂性、成本和数据规模的增加，他们最终会在生命周期的后期采用更开放的数据湖，此时他们可以证明扩展其数据工程团队是合理的。所以，我们想，为什么不在一开始就开放并一直保持开放呢？是什么阻止了这一点？
一位智者曾经说过："调试比编码难，操作比调试难"。在 Uber，我们围绕 Hudi 构建了大量基础设施，将其作为整个公司的全球平台来运营。Onehouse 将为公司提供更简单的途径来采用数据湖，而无需预先投资此类基础设施，并且他们可以从一开始就在 Hudi 中享受开放的数据格式和服务，如果公司的增长速度超过 Onehouse 或有内部数据操作的授权或出于其他任何原因，他们将能够从 Onehouse 迁移到仅由他们自己的团队运营的 Apache Hudi，我们相信这是围绕开源软件构建的基础设施服务应该带来的真正自由。
推荐阅读
引用链接
[1] 贡献: https://hudi.apache.org/contribute/how-to-contribute[2] RFC/设计提案流程、发布: https://hudi.apache.org/contribute/rfc-process[3] 路线: https://hudi.apache.org/roadmap[4] 这一长长的公司名单: https://hudi.apache.org/powered-by[5] 索引: https://hudi.apache.org/docs/indexing[6] 清理功能: https://hudi.apache.org/docs/hoodie_cleaner[7] 聚簇: https://hudi.apache.org/docs/clustering[8] 快照/恢复: https://hudi.apache.org/docs/timeline/#timeline[9] 压缩: https://hudi.apache.org/docs/compaction[10] 文件大小调整: https://hudi.apache.org/docs/file_sizing[11] 流式摄取: https://hudi.apache.org/docs/hoodie_deltastreamer[12] 增量 ETL: https://hudi.apache.org/blog/2020/08/18/hudi-incremental-processing-on-data-lakes/#traditional-data-lakes-lack-the-primitives-for-incremental-processing[13] CDC 源: https://hudi.apache.org/blog/2022/01/14/change-data-capture-with-debezium-and-apache-hudi[14] Hudi社区2021总结: https://www.onehouse.ai/blog/apache-hudi-2021-a-year-in-review[15] [email protected]: [[email protected]](mailto:[email protected])[16] 我们的 Slack: https://join.slack.com/t/apache-hudi/shared_invite/enQtODYyNDAxNzc5MTg2LTE5OTBlYmVhYjM0N2ZhOTJjOWM4YzBmMWU2MjZjMGE4NDc5ZDFiOGQ2N2VkYTVkNzU3ZDQ4OTI1NmFmYWQ0NzE[17] 参与: https://hudi.apache.org/community/get-involved