Posted by Socrates on | Featured
2024 年及以后的数据管理会是什么样子仍然悬而未决。开放数据格式能否带来最佳的数据管理平台？它将实现跨云、跨格式、以及语义和治理层的互操作性。
第六平台。阿特拉斯.德贝西姆。 DCAT。伊吉利亚。尼斯湖水怪。网。派蒙。变形。
这个名副其实的单词汤听起来像是从角色扮演游戏中跳出来的东西。实际上，这些都是与数据管理相关的术语。这些术语可能会告诉我们一些有关数据管理工具和术语相关人员的思维方式，但这是一个不同的故事。
数据管理是一项长期存在且不断发展的实践。 “大数据”的时代早已过去，数据现在在炒作和关注方面已经退居二线。生成式人工智能是人们兴奋的新玩具，它为大众照亮了人工智能和机器学习的大门。
相比之下，数据管理可能显得乏味。然而，有一些事情，在人工智能流行之前就已经接触过它的人都非常了解，而刚刚接触它的人最终也会意识到：人工智能的好坏取决于它所运行的数据。
有一个从数据到分析到人工智能。一些组织十年前就清楚地意识到了这一点。其他人今天将不得不经历惨痛的教训。
探索和理解数据的存储、管理、集成和使用方式、地点和时间，以及数据格式、互操作性、语义和治理的相关方面，可能是一项艰巨而乏味的工作。但它与类似角色扮演游戏一样为组织创造价值词汤。
Peter Corless 和 Alex Merced 明白这一点。他们对数据的参与远远早于他们目前在 StarTree 和开发者倡导者，位于 Dremio。我们采访了 2024 年数据管理的状况及其可能的发展方向。
第六数据平台
对于当今的许多组织来说，数据管理归结为将数据移交给“5 大”数据供应商之一：Amazon、Microsoft Azure 和 Google，以及 Snowflake 和 Databricks。然而，分析师 David Vellante 和 George Gilbert 认为，现代数据应用的需求加上开放存储管理的发展可能会导致“第六数据平台”的出现。
“第六个数据平台”的概念是与 Corless 和 Merced 对话的起点。 第六个数据平台假设是开放数据格式可以实现互操作性，从而导致从垂直集成的供应商控制平台向数据存储和权限的独立管理转变。
这是一个有趣的场景，通过迫使供应商根据交付的业务价值来竞争每个工作负载（无论锁定如何），将使用户受益。但我们离实现这一点还有多远？
为了回答这个问题，我们需要检查开放数据格式及其属性。反过来，为了理解数据格式，需要简要的历史概述。
我们可以称之为赌注，这不仅仅是一个双关语。从历史上看，组织会诉诸使用数据仓库来满足其分析需求。这些是专门为分析而设计的数据库，而不是事务性应用程序。正如 Merced 指出的那样，传统的数据仓库是有效的，但扩展它们是一个问题。
扩展传统数据仓库既昂贵又麻烦，因为这意味着需要购买捆绑存储和计算的新硬件。这就是 Hadoop 在 2010 年代初期推出时旨在通过分离存储和计算来解决的问题。
Hadoop 使扩展变得更容易，但使用起来很麻烦。这就是为什么最终通过 Apache Hive，使其更易于访问。 Hive 使用元数据并引入了一种协议，用于将 Hadoop 所操作的文件映射到 SQL 所操作的表。这就是开放数据格式的开始。
数据湖、数据湖屋和开放数据格式
Hadoop也标志着数据湖的出现。由于存储现在变得便宜且易于添加，这开启了将所有数据存储在一个大型 Hadoop 存储中的可能性：数据湖。然而，最终，
Hadoop 和本地计算和存储让位于云，这是“Big 5”的领域操作。
<块引用>
“数据湖屋的想法是，嘿，你知道吗？我们喜欢这种计算和存储的解耦。我们喜欢云。但是，如果我们不必复制数据，我们可以只需要复制数据，那不是很好吗？”操作您已经拥有的数据存储、数据湖，然后就采用所有数据仓库功能并开始尝试将其转移到那里？”，正如默塞德所说。
然而，正如他补充的那样，事实证明这是一项艰巨的任务，因为缺少传统数据管理的元素。其他基于云的数据管理平台引入了自动分片、分区、分发和复制等概念。这是从数据中心和文件系统转向云和 API 来访问数据的过程的一部分。但对于 数据湖屋，这些东西不是给定的。
这是开放数据格式的地方，例如 Apache Iceberg，Apache Hudi 和 Delta Lake 登场。它们都有一些共同点，例如使用元数据来抽象和优化文件操作以及对存储不可知。然而，Hudi 和 Delta Lake 都继续在 Hive 的基础上进行构建，而 Iceberg 则背离了这一点。
详细的开放数据格式比较是一项细致入微的工作，但也许最重要的问题是：开放数据格式之间是否存在互操作性，如果存在，互操作性处于什么级别？为了使第六个数据平台愿景成为现实，云之间、格式之间、语义和治理层面都应该存在互操作性。
不同云存储供应商之间相同格式的互操作性是可能的，但并不容易。这是可以做到的，但这不是数据格式本身的固有特征。它是在应用程序级别完成的，可以通过自定义集成或使用 Dremio 之类的工具。将文件传输到其所在的云之外会产生出口和网络成本。
不同格式的互操作性也是可能的，但并不完美。它可以通过使用第三方应用程序来完成，但还有一些其他选项，例如 Delta Uniform 或 OneTable。两者都不能 100% 工作，因为 Delta Uniform 批量事务和 OneTable 都是用于迁移目的。
正如 Merced 指出的那样，创建 100% 有效的解决方案可能会产生大量开销和复杂性，因为元数据必须跨格式同步。 Merced 认为这些解决方案至少部分是由于 Iceberg 的增长以及确保第三方工具能够与 Iceberg 生态系统配合使用的愿望所推动的。
联合还是不联合？
可以肯定的是，其他系统或多个云中总会有少量数据。正如 Corless 指出的那样，这就是为什么需要能够大规模运行的联合和虚拟化。一个系统上的架构管理已经足够复杂，尝试管理三个不同系统之间的更改并不会让事情变得更容易。
数据是留在原来所在的位置并通过联合查询使用，还是摄取到一个存储位置是一个关键的架构问题。因此，需要理解所涉及的权衡。即使在联盟内部，也有不同的方法来实现这一点——Dremio、GraphQL、Pinot、Trino 等等。
<块引用>
“数据消费者想要如何评估这些问题？我们如何为他们提供预测方法来规划这些权衡？他们可以使用联合查询，或者实时和批量数据的混合表。我们甚至没有Corless 说：“现在有一个语法来描述这些类型的混合或复杂的数据产品。”
Corless 的观点略有不同，专注于实时数据和处理。这就是 StarTree 所做的事情，因为它是建立在它的基础上的。 Pinot 是一个实时分布式 OLAP 数据存储，旨在以低延迟响应 OLAP 查询。
Corless 还指出，数据格式的选择取决于许多参数。某些格式针对内存中使用进行了优化，例如 阿帕奇之箭。其他，例如 Apache Parquet，针对磁盘存储进行了优化。
出于利用分层存储的需要，人们尝试在内存和存储中使用通用的数据表示形式。分层存储可以利用不同的介质，从内存到 SSD 再到某种 Blob 存储。
“人们希望在存储数据的位置和方式方面具有灵活性。如果他们必须实时进行变形，那么这在很大程度上就违背了他们尝试使用分层存储的目的。有没有最好的东西，最通用的格式？
每当您针对某些事物进行优化时，您就在远离其他事物进行优化。但我非常渴望看到这种数据的通用表示现在将带我们走向何方。”Corless 说道。
语义和治理
然而，无论数据存储在何处或如何存储，真正的互操作性还应包括语义和治理。这就是目前的事态还有很多不足之处。
正如 Merced 所分享的，所有表格式的工作方式是元数据包含有关表的信息，但不包含有关表的整体目录的信息。这意味着他们无法记录表的语义以及它们之间的关系。执行此操作的标准格式尚不存在。
Merced 还指出，有一些东西可以解决这个问题，但它只适用于 Iceberg 表。 Nessie 项目是一个开放的项目-创建目录的源平台，从而使 Iceberg 表和视图的跟踪和版本控制成为可能。
Nessie 还融入了治理元素，Merced 指出 Nessie 最终也将获得 Delta Lake 的支持。 Databricks 就其本身而言，提供 Unity Catalog，可与 Delta Lake 配合使用，但它是专有产品。市场上不乏数据目录产品，但没有一个能真正被认为是语义和数据互操作性的解决方案。
Corless 则指出，有一个名为 DCAT。 DCAT（数据目录词汇表）是一种 RDF 词汇表，旨在促进 Web 上发布的数据目录之间的互操作性。 DCAT 最近更新至 v.3。它已经存在十多年了，正是针对互操作性。
根据 Corless 的说法，DCAT 未得到广泛使用的事实可能更多地与供应商重新发明轮子和/或旨在锁定有关，以及客户没有比 DCAT 本身更主动地要求互操作性标准。不幸的是，对于大多数组织来说，数据之于人工智能治理就像是数据之于：充其量只是第二位。
默塞德认为我们已经开始看到这一点。在他看来，使用 Apache Iceberg、Apache Arrow 和 Apache Parquet 等开放格式可以创建更高级别的互操作性。他指出，这种互操作性仍然不完善，但情况比过去好得多。 Dremio 的论文是成为一个开放的数据湖屋，不仅在数据湖上运行，而且跨工具和数据源运行。
Corless 认为我们将看到集群集群或系统系统的发展趋势。集成自动化将会得到加强，就像乐高积木一样可以轻松地拼在一起，而不是带有六角扳手的宜家家具。但他指出，要做到这一点，我们需要一种语言和语法，以便系统和人们都能相互理解。
第六个数据平台的要素要么已经存在，要么足够接近。随着复杂性和碎片化的爆炸性增长，用于互操作性的语言和语法听起来是一个不错的起点。诚然，互操作性和语义很难。然而，即便如此，可能更多的是人员和市场问题，而不是技术问题。
