为什么 Spark SQL 认为索引的支持不重要？

Question

引用 Spark DataFrames，Datasets and SQL manual：

少数 Hive 优化尚未包含在 Spark 中。一些 由于 Spark SQL 的原因，这些（例如索引）不太重要 内存计算模型。其他的被安排在未来的版本中 Spark SQL。

作为 Spark 的新手，我对此感到有些困惑，原因有两个：

1. Spark SQL 旨在处理大数据，至少在我的使用中 如果数据大小远远超过可用内存的大小。 假设这种情况并不少见，那么“Spark SQL 的 内存计算模型”？Spark SQL 是否仅推荐用于 数据适合内存的情况？

2. 即使假设数据适合内存，对一个非常大的 数据集可能需要很长时间。我读了this argument反对 在内存数据库中建立索引，但我不相信。这个例子 那里讨论了对 10,000,000 条记录表的扫描，但这不是 真正的大数据。扫描具有数十亿条记录的表可能会导致 “SELECT x WHERE y=z”类型的简单查询需要永远代替 立即返回。

我了解索引有一些缺点，例如较慢的 INSERT/UPDATE、空间要求等。但在我的用例中，我首先将大量数据处理并加载到 Spark SQL 中，然后将这些数据作为一个整体进行探索，没有进一步的修改。 Spark SQL 对于数据的初始分布式处理和加载很有用，但缺乏索引使得交互式探索比我预期的更慢和更麻烦。

我想知道为什么 Spark SQL 团队认为索引在某种程度上不重要，以至于超出了他们的路线图。是否有不同的使用模式可以提供索引的好处，而无需独立实现等效的东西？

Answer 1

索引输入数据

• 对外部数据源进行索引不在 Spark 范围内的根本原因在于 Spark 不是数据管理系统，而是批处理数据处理引擎。由于它不拥有正在使用的数据，因此无法可靠地监控更改，因此无法维护索引。
• 如果数据源支持索引，Spark 可以通过谓词下推等机制间接利用它。

索引分布式数据结构：

• 标准索引技术需要持久且定义明确的数据分布，但 Spark 中的数据通常是短暂的，其确切分布是不确定的。
• 通过适当的分区与列存储和压缩相结合实现的高级数据布局可以提供非常高效的分布式访问，而无需创建、存储和维护索引的开销。这是不同内存中列系统使用的常见模式。李>

话虽如此，Spark 生态系统中确实存在某些形式的索引结构。最值得注意的是 Databricks 在其平台上提供Data Skipping Index。

其他项目，如Succinct（今天大部分不活动）采用不同的方法并使用具有随机访问支持的高级压缩技术。

当然，这提出了一个问题——如果您需要有效的随机访问，为什么不使用从一开始就设计为数据库的系统。那里有很多选择，其中至少有一些是由 Apache 基金会维护的。同时 Spark 随着项目的发展，您使用的报价可能无法完全反映 Spark 未来的发展方向。

Answer 2

一般来说，索引的实用性充其量是值得怀疑的。相反，数据分区更为重要。它们是非常不同的东西，仅仅因为您选择的数据库支持索引并不意味着考虑到 Spark 正在尝试做的事情，它们是有意义的。而且和“记忆中”没有任何关系。

到底什么是索引？

在永久存储非常昂贵（而不是基本上免费）的时代，关系数据库系统都是为了尽量减少永久存储的使用。关系模型必然会将记录拆分为多个部分——对数据进行规范化——并将它们存储在不同的位置。要读取客户记录，您可能会读取 customer 表、customerType 表、从 address 表中取出几个条目等。如果您有一个解决方案要求您读取整个表以找到你想要的，这是非常昂贵的，因为你要扫描这么多的表。

但这不是做事的唯一方法。如果您不需要固定宽度的列，则可以将整组数据存储在一个位置。无需对一堆表进行全表扫描，您只需对单个表进行扫描即可。这并不像您想象的那么糟糕，尤其是如果您可以对数据进行分区。

40 年后，物理定律发生了变化。硬盘随机读/写速度和线性读/写速度已经发生了巨大的分歧。基本上每个磁盘每秒可以进行 350 次磁头移动。 （或多或少，但这是一个很好的平均数字。）另一方面，单个磁盘驱动器每秒可以读取大约 100 MB。这是什么意思？

算一算，想一想——这意味着如果每次磁头移动读取的数据少于 300KB，则说明您正在限制驱动器的吞吐量。

说真的。想一想。

索引的目标是允许您将磁盘磁头移动到您想要的磁盘上的精确位置并读取该记录——比如作为customer 记录的一部分加入的address 记录。我说，那没用。

如果我基于现代物理学设计一个索引，它只需要让我在目标数据的 100 KB 左右（假设我的数据已经被大块布局——但我们在谈论理论反正在这里）。根据上面的数字，比这更高的精度只是浪费。

现在回到您的规范化表格设计。假设customer 记录实际上被拆分为 5 个表中的 6 行。总共 6 次磁盘磁头移动（我假设索引缓存在内存中，因此没有磁盘移动）。这意味着我可以读取 1.8 MB 的线性/非规范化客户记录并且同样高效。

那么客户历史呢？假设我不仅想查看客户今天的样子——想象一下我想要完整的历史记录，还是历史记录的子集？将以上所有内容乘以 10 或 20 即可得到图片。

比索引更好的是数据分区——确保所有客户记录最终都在一个分区中。这样，只需移动一次磁盘磁头，我就可以读取整个客户历史记录。一个磁盘磁头移动。

再告诉我你为什么需要索引。

索引与___？

不要误会我的意思——“预先准备”您的搜索是有价值的。但是物理定律提出了一种比传统索引更好的方法。与其将客户记录存储在一个位置，并创建一个指向它的指针（索引），不如将记录存储在多个位置？

请记住，磁盘空间基本上是空闲的。与其尽量减少我们使用的存储量（关系模型的过时产物），不如将您的磁盘用作您的搜索缓存。

如果您认为有人希望查看按地理位置和销售代表列出的客户，则以优化这些搜索的方式存储您的客户记录的多个副本。就像我说的，像使用内存缓存一样使用磁盘。与其通过将不同的持久数据组合在一起来构建内存缓存，不如构建持久数据来镜像内存缓存，这样您所要做的就是读取它。事实上，甚至不必费心尝试将它存储在内存中 - 每次需要时直接从磁盘读取它即可。

如果您认为这听起来很疯狂，请考虑一下——如果您将其缓存在内存中，您可能会缓存两次。您的操作系统/驱动器控制器可能使用主内存作为缓存。不要费心缓存数据，因为其他人已经在缓存了！

但我离题了...

长话短说，Spark 绝对支持正确的索引类型 - 能够从原始数据创建复杂的派生数据，以提高未来的使用效率。它只是没有按照您想要的方式进行。