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

引用Spark数据帧：

Spark中还没有包括一些配置单元优化。一些 由于Spark SQL的特性，这些（如索引）不太重要 内存计算模型。其他的将在未来发布 sparksql

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

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

即使假设数据适合内存，也需要在非常大的范围内进行完全扫描 数据集可能需要很长时间。我反对 在内存数据库中建立索引，但我不相信。榜样 这里讨论了对10000000条记录表的扫描，但不是这样 真正的大数据。扫描包含数十亿条记录的表可能会导致 而“选择x，其中y=z”类型的简单查询将永远使用 马上回来

我知道索引有一些缺点，如插入/更新速度慢、空间要求等。但在我的用例中，我首先处理大量数据并将其加载到Spark SQL中，然后将这些数据作为一个整体进行研究，无需进一步修改。Spark SQL对于数据的初始分布式处理和加载非常有用，但是缺少索引使得交互式探索比我预期的更慢、更麻烦

---

我想知道为什么Spark SQL团队认为索引不重要，以至于偏离了他们的路线图。是否有一种不同的使用模式可以提供索引的好处，而无需单独实现等效的功能？

索引输入数据

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

索引分布式数据结构：

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

也就是说，Spark生态系统中确实存在一些形式的索引结构。最值得注意的是，Databricks在其平台上提供

其他项目，如（目前大部分处于非活动状态）采用不同的方法，并使用具有随机访问支持的高级压缩技术

---

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

一般来说，索引的实用性充其量也值得怀疑。相反，数据分区更为重要。它们是非常不同的东西，仅仅因为您选择的数据库支持索引，并不意味着考虑到Spark的努力，它们是有意义的。这与“记忆中”无关

那么什么是索引呢？

在永久存储极其昂贵（而不是基本免费）的年代，关系数据库系统都是为了最小化永久存储的使用。关系模型根据需要将记录拆分为多个部分——对数据进行规范化——并将它们存储在不同的位置。要读取客户记录，可能需要读取

customer

表、

customerType

表、从

地址

表中取出几个条目等。如果您有一个解决方案，需要读取整个表才能找到所需内容，这将非常昂贵，因为您必须扫描这么多表

但这不是做事情的唯一方式。如果不需要固定宽度的列，可以将整个数据集存储在一个位置。您不需要在一堆表上执行完整的表扫描，而只需要在单个表上执行。这并不像你想象的那么糟糕，特别是如果你能对数据进行分区的话

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

计算并思考一下——这意味着如果每次磁头移动读取的数据小于300KB，则会限制驱动器的吞吐量

认真地。想一想

索引的目标是允许您将磁头移动到所需磁盘上的精确位置，然后只读取该记录——比如说作为

客户

记录的一部分加入的

地址

记录。我说，那没用

如果我在设计一个基于现代物理学的索引，它只需要在目标数据块100KB左右的范围内（假设我的数据是以大块的形式排列的——但我们在这里讨论的是理论）。根据上述数字，一个