为何需要对原始大数据进行分区

无论您运行的是RDBMS（关系数据库管理系统）还是大数据系统，制定您专属的数据分析news.webhostingtalk.cn/策略至关重要。随着数据量的增长，将您的数据分区方法与数据查询方法相匹配变得愈发重要了，因为这样您才能允许“修剪”优化。当您要操心大量的导入数据时，这会变得更复杂，而Bartosz向我们解释了如何正确实现这一目标，虽然他的解释并不完美，但却充满智慧。

在我们分别进入大数据和Spark世界，并对其展开特定研究之前，让我们先回顾一下关系数据库领域，看看关系数据表的分区究竟是指什么。

重中之重

在RDBMS中引入分区有几个重要原因。不过，所有这些原因都源于这样一个事实，即：在某些时候，数据库表的大小可能会增长到数百GB（千兆字节）以上，这会使得您难以：

★加载新数据

★删除旧数据

★维护索引

★查询数据

表分区会根据您所选的表格及其索引的属性（列）将它们分成更小的分区，从而使得上述操作更加易于管理。因此，您可以在逐个分区而不是整个表格的基础上应用维护操作。此外，SQL Server优化器可以生成一个执行计划，并只在您调用了适当的过滤查询时才会从所请求的分区中读取数据，而这大大提高了查询执行性能。此操作称为“分区裁剪”。

RDBMS领域存在着一些众所周知的分区策略和最佳实践，但我在本文中将不对此进行介绍（如果您有兴趣，可以阅读《使用SQL Server 2008的分区表和索引策略》白皮书）。相反，我将重点介绍一般的日常数据流，如将新数据加载到系统中以更好地了解问题，并查看我们是否可以使用Spark来实施相同的优化操作。在本文中，我将假设您至少对Spark有所了解，如果不是，那我强烈建议您阅读《Srini Penchikala——使用Apache Spark进行大数据处理》、《Adam Breindel：Spark要领》、《学习Spark》这些书或Apache Spark文档。

如何将其全部加载？

任何数据流水线最常见的日常活动是将新数据加载到任何存储系统类型中。正如我之前所说的那样，我们可以假设您可以使用以下两种方法：

★总是将数据加载到同一容器中，无论该数据是单个表文件还是文件夹

★在数据将被物理分布于各种表文件或文件夹的位置处，将数据分为不同结构（分区），而该数据同时也逻辑可见为单个实体（表）。

虽然第一种方法非常吸引人，但它却会对您造成相当大的负担。我这样说的意思是，您正在制作单个的数据堆，而当它规模越来越大时，您就越来越不能控制它了。事实证明，为了实施任何操作类型（如重复检查），您将需要读取整个现有数据。我相信您不会想要加载相同的数据两次。

您可以引入索引来克服这些问题：但是，由于索引的规模非常大，因此这也成为了与表格相同的一个问题。此外，每当数据加载完成时，您都要为整个表格重建这些大型索引。

如果您想重新加载两周前加载的数据，但当时的数据质量很差，那您该怎么办呢？您需要找到旧的数据子集，删除并最终加载一个新的子集。如果您在极其大型的数据上运行该子集，那您可能需要耗费大量时间才能完成此操作了。

那么分区究竟会如何帮助您解决这一问题呢？让我们来对此探讨一番。

简而言之，首先，您需在生产表中创建一个空白的分区3，接着仅使用一个分区来将新数据加载至临时表中。最后，您需使用一台元交换机来交换分区。而现在，您就可以删除旧分区了。其中，真正耗时的唯一操作是将新数据加载到临时分区中。不过，请记住，这是使用一个分区来将数据加载至一个空白的表格中，而不是加载至整个生产表中。

这种方法还可以提供不可改变的数据流水线，使您可以随时在任何分区基础上轻松重新加载任何快照数据。因此，这种不可变的数据流水线解决了管理现有状态（合并）的难题。

那么Spark呢？我们在使用Spark时会遇到相同的原始数据问题吗？ 我们是否可以对其使用相同的理念呢？

分割表（文件夹）是否真的很重要？

加载数据在大数据世界中有所不同，因为原始数据是直接存储于分布式文件系统之上的。然而，尽管我们无需真正操心索引，但出于同一原因，我们仍需在这里进行分区，特别是因为我们需要处理非常大型的数据。

首先，由于它们只是文件系统上的文件，所以我们需要一种同时支持文件模式、分区、压缩以及理想柱状存储的高效文件格式。幸运的是，在大数据生态系统中就存在这样的一些格式，但最具潜力且由Spark本地集成的格式为Apache Parquet，它最初是由Twitter研发而成的。

Parquet可使得您将仅在一个文件系统上设有文件转化为在文件系统上设有更多具有非常高效的柱状存储的文件表，这使得我们能进一步接触RDBMS世界，而不是仅停留在使用文件的阶段而已。

柱状存储为表格带去了两个重要的好处：

★在异类行值上有效压缩同类柱状值

★例如，如果您设有一个每隔三秒就会进行一次记录的“时间”列，那么存储初始值和固定间隔会比将所有数据存储为“时间”类型更为高效，因为这样我们就能大幅缩减所生成的文件大小，并减少硬盘驱动器上的I / O操作。

★列修剪 - 只读请求的列

Spark会利用Parquet为我们提供分区发现机制。下面，让我们来查看一个分区文件夹结构的示例：

path

└── to

└── my_table

├── Year=2016

│ ├── 。。。

│ │

│ ├── Month=4

│ │ ├── Day=15

│ │ │ └── data.parquet

│ │ └── 。。。

│ ├── Month=5

│ │ ├── Day=12

│ │ │ └── data.parquet

│ │ └── 。。。

└── Year=2015

├── 。。。

我们可以看到，分区表中的数据分布于不同的目录中，其中分区列的值是以每个分区目录的名称进行编码的，例如年份 = 2016、月份 = 04、日 = 15等。换句话说，有了这个结构之后，我们就可以确保2016年4月之后的数据只能在/ 路径 / 至 / 我的_表格 / 年份 = 2016 / 月份 = 4这一目录中找到。另外，表只是一个根文件夹而已，/ 路径 / 至 / 我的_表格。

这没有什么特别之处，而且添加一些分区模式元数据也没有什么隐藏的秘诀或代码，您只要保持文件结构的正确性即可。这意味着，您可以不使用Spark来线下准备这种结构，然后再使用Spark来加载表格。这也符合Hive分区布局，也就是说您可以一起加载现有的Hive数据及Spark集成与Hive云存储，同时也可以继续使用自己的Parquet读写器而不是Hive SerDe了。