使用 Apache Arrow 加速 MinIO 数据湖

Ravishankar Nair Ravishankar Nair @passionbytes

发表于运营指南 2020 年 9 月 17 日

Turbocharging MinIO Data Lakes with Apache Arrow

越来越多的企业已经开始或已经实施了基于我们几年前完成的一些工作的数仓策略。如果您想花点时间回顾一下 - 您可以在下面找到这些帖子这里和这里。

目标

在本文中，我将解释一种机制来加速使用 MinIO。就 MinIO 而言，没有任何变化，优化将针对我们数据的基础存储。我们将选择最新的格式之一来大幅提高敏捷性。我们将展示您的数据湖数据如何在系统之间传输而无需经历任何“转换”时间。

Apache Arrow

我相信理解本文需要一些关于 Spark 等应用程序如何工作的基本概念。让我用简单的术语解释一下。

想象一下，你在一个与你目前居住地不同的地点找到了一份不错的工作，并且你希望搬迁，因为新公司要求这样做并为此付费。你拥有最现代的电视、冰箱、超级柔软的皮革沙发、床等等。你聘请了一家搬家公司，他们过来，拆卸所有东西，方便地打包。他们还确保尽可能多地将物品装入集装箱，以填满卡车，以便他们可以一次性完成运输。一旦到达目的地，他们就会开箱、组装并恢复所有东西的原样。

数据也是如此。当我在 MinIO 中存储一些数据，并且我需要将其提供给另一个应用程序（例如 Spark）时，使用该应用程序需要从 MinIO 数据湖中拆卸数据、打包数据并通过网络（或无线）传输数据，接收、解包并重新组装数据。

让我们使用更多技术术语来描述这种拆卸和组装 - 数据的序列化和反序列化。不幸的是，这两个过程都很复杂且耗时。以下是一个简短的图表，说明 Apache Spark 读取数据时会发生什么情况

您可能以前没有注意到这个问题。假设 MinIO 位于网络上的机器上。我们编写一个 Spark Map-Reduce 应用程序。即使网络限制为 100 GbE，我们获得的速度也几乎不到 10 GbE。那么这个高速网络有什么用呢？是什么潜在的问题导致我们无法充分利用网络的潜力，或者至少无法利用 70-80% 的潜力？

问题在于 Spark 获取数据的方式。看看数据必须经过多少层。这限制了我们可以达到的吞吐量。有一些项目，如 Apache Crail，旨在解决这些问题。

优化：列式数据格式

如果我们考虑上面提到的搬迁示例，我们会发现物流公司永远不会原封不动地搬运沙发，他们会将其拆卸以便于运输。请注意，这仅用于运输目的 - 如果目标不同，则拆卸沙发可能不是正确的方法。

鉴于数据湖的目标是分析 - 而不是事务需求，我们必须考虑这一点。对于事务，我们经常使用 Oracle 或 PostGres 等 OLTP 系统 - 因为它们特别适合这项工作。可能需要快速回顾一下 OLAP 的分析需求。

让我们从最著名的 RDMBS 表之一开始 - Oracle 的“emp”表。上半部分显示了数据如何在 RDBMS 中作为“关系”或“元组”存储。我们称之为表。我为您提供了两个查询

select ename from emp where job = 'CLERK'
select sum(sal) from emp

第一个是事务查询。它必须扫描表上的每一行，并在工作为文员的任何地方查找员工的姓名。第二个是分析查询 - 目标不是原子结果，而是一般结果。不幸的是，如果我们使用 RDBMS 的数据表示方式，则第一个和第二个查询都必须扫描所有行。如果数据大小为 20 GB，则或多或少都会扫描所有 20 GB。这是上图的上半部分。

让我们进行一些更改 - 获取所有列并将它们转换为行。就像矩阵的转置一样 - 并查看上图的下半部分，您的数据将是什么样子。按照此转置，整个块仅表示一列。第二个分析查询需要扫描多少个块？只有一个块，可能大小约为 2 GB。

差异很大吗？列式表示法在 ORC（优化行列式）和 Parquet 文件中使用 - 目的是使分析更快。

列式格式更容易读取，但是，它们带来了另一个问题 - 它们通常以压缩格式存储。因此，使用应用程序在读取时需要解压缩它，并在写入时将其压缩回。

请注意这一点，因为我们稍后会重新讨论这一点。