概括
在数据平台需求层次结构的基础上，存在摄取、存储、管理和转换数据的基本需求。 Onehouse 提供这种基础数据基础架构作为服务，以在客户数据湖中摄取和管理数据。 随着数据湖在组织内的规模和种类不断增长，将基础数据基础架构与处理数据的计算引擎分离变得势在必行。 不同的团队可以利用专门的计算框架，例如 Apache Flink（流处理）、Ray（机器学习）或 Dask（Python 数据处理），以解决对其组织重要的问题。 解耦允许开发人员在以开放格式存储的数据的单个实例上使用这些框架中的一个或多个，而无需将其复制到和存储紧密耦合的另一服务中。 Apache Hudi、Apache Iceberg 和 Delta Lake 已成为领先的开源项目，为这个解耦存储层提供一组强大的原语，这些原语在云存储中围绕打开的文件提供事务和元数据（通常称为表格式）层，像 Apache Parquet 这样的格式。
背景
所有这些不同的选项都提供了混合支持，我们甚至还没有开始列出各种开源查询引擎、数据目录或数据质量产品的支持。 这种越来越大的兼容性矩阵会让组织担心他们会被锁定在一组特定的供应商或可用工具的子集中，从而在进入数据湖之旅时产生不确定性和焦虑。
为什么要建立 Onetable
Onetable 朝着这个方向迈出了一大步。
什么是 Onetable
我们为什么兴奋
例如Databricks 是运行 Apache Spark 工作负载的一个非常受欢迎的选择，其专有的 Photon 引擎可在使用 Delta Lake 表格式时提供性能加速。 为了确保使用 Onehouse 和 Databricks 的客户获得良好的体验而没有任何性能缺陷，我们使用 1TB TPC-DS 数据集来对查询性能进行基准测试。 我们比较了 Apache Hudi 和 Delta Lake 表，有/没有 Onetable 和 Databricks 的平台加速，如磁盘缓存和 Photon。 下图显示了 Onetable 如何通过基于 Delta Lake 协议转换元数据来解锁 Onehouse/Hudi 表上 Databricks 内部的更高性能。
最重要的是我们很高兴看到这如何帮助用户使用灵活的分层数据架构取得成功，这种架构已经在许多大型数据组织中流行。 Apache Hudi 为数据湖上的增量摄取/etl 提供行业领先的速度和成本效益，这是 Onehouse 的基础。 用户利用 Hudi 将这种高效、成本优化的数据摄取到原始/铜银表中。 Onehouse 的表管理服务可以直接在湖级别优化此数据的布局，以获得更好的查询性能。 然后用户可以使用 BigQuery、Redshift、Snowflake 等仓库引擎或 Databricks、AWS EMR、Presto 和 Trino 等湖引擎转换这些优化表。 然后将派生数据提供给最终用户，以构建个性化、近实时仪表板等数据应用程序。 Onetable 为用户提供了非常需要的可移植性，让他们可以根据自己的需求和成本/性能权衡来选择他们喜欢的查询引擎。 同时用户可以通过 Hudi 经验证的具有挑战性的变更数据捕获场景的效率以及 Onehouse 的表优化/管理服务来降低计算成本。
未来工作
Onehouse 致力于开源，其中包括 Onetable。 最初这将是为 Onehouse 客户保留的内部功能，因为我们会迭代设计和实施。 我们正在寻找来自其他项目和社区的合作伙伴来迭代这个共享的表标准表示，并最终为整个生态系统开源该项目。 例如当底层 Hudi 表发生变化时，Hudi 的目录同步表服务会增量维护此类目录元数据。 与 Onetable 的类似实现，将通过单个集成使不同引擎之间的元数据保持同步，从而为数据湖用户创造巨大的价值。