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

  • Z时代
  • 2024-01-10
  • 分类：问答

引用Spark DataFrames，Datasets和SQL手册：

Spark中尚未包含一些Hive优化。由于Spark SQL的内存中计算模型，其中一些（例如索引）不太重要。其他版本已投放到Spark

SQL的将来版本中。

刚接触Spark时，我对此感到有些困惑，原因有二：

  1. Spark SQL旨在处理大数据，至少在我的用例中，数据大小远远超过了可用内存的大小。假设这并不少见，“ Spark SQL的内存中计算模型”是什么意思？仅在数据适合内存的情况下才建议使用Spark SQL吗？

  2. 即使假设数据适合存储在内存中，对非常大的数据集进行全面扫描也可能需要很长时间。我读过这种反对在内存数据库中建立索引的论点，但我没有被说服。那里的示例讨论了对10,000,000条记录表的扫描，但这并不是真正的大数据。扫描具有数十亿条记录的表可能会导致“ SELECT x WHERE y = z”类型的简单查询花费很长时间，而不是立即返回。

我知道索引具有诸如INSERT / UPDATE速度慢，空间要求等缺点的缺点。但是在我的用例中，我首先处理并将大量数据加载到Spark

SQL中，然后将这些数据作为一个整体进行研究，而无需进一步修改。Spark

SQL对于数据的初始分布式处理和加载很有用，但是缺少索引使交互式探索比我预期的要慢和麻烦。

我想知道为什么Spark SQL团队认为索引不符合他们的发展计划并不重要。是否有不同的使用模式可以提供索引的好处，而不必依靠独立实现的等同功能？

回答：

  • 外部数据源建立索引不在Spark范围内的根本原因是，Spark不是数据管理系统，而是批处理数据处理引擎。由于它不拥有正在使用的数据，因此无法可靠地监视更改，因此无法维护索引。

  • 如果数据源支持索引，则Spark可以通过谓词下推之类的机制间接使用索引。

：

  • 标准索引技术需要持久且定义良好的数据分布，但是Spark中的数据通常是短暂的，其确切分布是不确定的。

  • 通过适当的分区与列式存储和压缩相结合实现的高级数据布局可以提供非常有效的分布式访问，而无需创建，存储和维护索引。这是不同的内存中列式系统使用的常见模式。

话虽这么说，Spark生态系统中确实存在某些形式的索引结构。最值得注意的是，Databricks在其平台上提供了数据跳过索引。

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

当然，这提出了一个问题-如果您需要有效的随机访问，为什么不从一开始就使用被设计为数据库的系统。那里有很多选择，包括至少一些由Apache

Foundation维护的选择。同时，随着项目的发展，Spark也随之发展，并且您使用的报价可能无法完全反映未来的Spark方向。

以上是 为什么Spark SQL认为对索引的支持不重要？ 的全部内容， 来源链接： utcz.com/qa/404043.html

回到顶部