本章的目的是演示如何将数据从其原始格式加载到不同的模式，从而使各种不同类型的下游分析能够在同一数据上运行。 在编写分析甚至更好地构建可重用软件的库时，通常必须使用固定输入类型的接口。 因此，根据目的，灵活地在模式之间转换数据的方式可以带来可观的下游价值，既可以扩展可能的分析类型，又可以重新使用现有代码。
我们的主要目标是学习Spark随附的数据格式功能，尽管我们还将通过引入行之有效的方法来深入研究数据管理的精髓，这些方法将增强您的数据处理能力并提高您的生产率。 毕竟，很可能在某个时候您将被要求正规化工作，并且在编写分析以及以后编写分析的过程中，如何避免潜在的长期陷阱是非常宝贵的。
考虑到这一点，我们将使用本章介绍传统上易于理解的数据模式领域。 我们将涵盖传统数据库建模的关键领域，并解释其中的一些基石原理如何仍适用于Spark。
此外，在磨练我们的Spark技能的同时，我们将分析GDELT数据模型，并展示如何以有效和可扩展的方式存储此大型数据集。
我们将涵盖以下主题：
尺寸建模：与Spark相关的优点和缺点
专注于GDELT模型
抬起读取模式的盖子
Avro对象模型
实木复合地板储物型号
让我们从一些最佳实践开始。
有条理的生活是美好的生活
在了解Spark和大数据的好处时，您可能听说过有关结构化数据与半结构化数据与非结构化数据的讨论。尽管Spark促进了结构化，半结构化和非结构化数据的使用，但它也为其一致的处理提供了基础。唯一的限制是它应该基于记录。如果它们是基于记录的，则无论其组织如何，都可以以相同的方式来转换，丰富和操纵数据集。
但是，值得注意的是，拥有非结构化数据并不一定要采用非结构化方法。在上一章中已经确定了探索数据集的技术之后，很容易直接进入将数据存储在可访问的位置并立即开始简单的概要分析。在现实生活中，此活动通常优先于尽职调查。再一次，我们鼓励您考虑几个关键的感兴趣领域，例如文件完整性，数据质量，计划管理，
版本管理，安全性等，然后再进行此探索。这些不容忽视，许多本身就是大话题。
因此，尽管我们已经在第2章“数据获取”中讨论了许多这些问题，并将在以后进行更多研究，例如在第13章“安全数据”，但在本章中，我们将重点关注数据输入和输出格式，我们可以采用的一些方法，以确保更好的数据处理和管理。
GDELT空间建模
由于我们已选择在本书中使用GDELT进行分析，因此，我们将介绍使用该数据集的第一个示例。 首先，让我们选择一些数据。
有两种可用的数据流：全球知识图（GKG）和事件。
在本章中，我们将使用GKG数据创建可从Spark SQL查询的时间序列数据集。 这将为我们创建一些简单的入门分析提供一个很好的起点。
在接下来的第4章“探索性数据分析”和第5章“地理分析Spark”中，我们将更详细地介绍GKG。 然后，在第7章，构建社区中，我们将通过生成自己的人员网络图并将其用于一些很酷的分析中来探索事件。
GDELT模型
GDELT已经存在20多年了，在那段时间里，它进行了一些重大的修改。 对于我们的入门示例，为了简化起见，让我们限制从2013年4月1日开始的数据范围，当时GDELT对文件结构进行了大修，引入了GKG文件。 值得注意的是，本章讨论的原理适用于所有版本的GDELT数据，但是，此日期之前的特定模式和统一资源标识符（URI）可能与所描述的不同。 我们将使用的版本是GDELT v2.1，它是撰写本文时的最新版本。 但是，再次值得注意的是，这与GDELT 2.0略有不同。
GKG数据中有两个数据轨道：
1.整个知识图及其所有字段。
2.图的子集，其中包含一组预定义的类别。
我们将看第一首曲目。
首先查看数据
我们在第2章“数据采集”中讨论了如何下载GDELT数据，因此，如果您已经配置了NiFi管道来下载GKG数据，只需确保它在HDFS中可用即可。 但是，如果您还没有完成本章，那么我们建议您首先这样做，因为它解释了为什么您应该采用结构化的方法来获取数据。
尽管我们竭尽全力阻止使用临时数据下载，但本章的范围是众所周知的，因此，如果您有兴趣按照此处显示的示例进行操作，则可以跳过使用NiFi并获得 直接获取数据（以便尽快上手）。
如果您确实希望下载示例，这里提醒您在哪里可以找到GDELT 2.1 GKG主文件列表：
记下几个匹配的最新条目。 gkg.csv.zip，使用您喜欢的HTTP工具将其复制，然后将其上传到HDFS。 例如：
http: //data. gdeltproject. org/gdeltv2/masterfilelist. txt记下几个匹配的最新条目。 gkg.csv.zip，使用您喜欢的HTTP工具将其复制，然后将其上传到HDFS。 例如：
wget http: //data. gdeltproject. org/gdeltv2/20150218230000.gkg.csv.zip -o log. txt
unzip 20150218230000.gkg.csv.zip
hdfs dfs -put 20150218230000.gkg.csv /data/gdelt/gkg/2015/02/21/
记下几个匹配的最新条目。 gkg.csv.zip，使用您喜欢的HTTP工具将其复制，然后将其上传到HDFS。 例如：
注意
在加载到HDFS之前，实际上并不需要解压缩数据。 Spark的TextInputFormat类支持压缩类型，并将透明地解压缩。 但是，由于我们在上一章中解压缩了NiFi管道中的内容，因此在此处执行解压缩是为了保持一致性。
核心全球知识图模型
有一些重要的原则需要理解，无论从计算还是在人工方面，从长远来看肯定可以节省时间。 像许多CSV一样，此文件隐藏了一些复杂性，如果在此阶段无法很好地理解，则可能在稍后的大规模分析中成为一个真正的问题。 GDELT文档描述了数据。 可以在这里找到：http://data.gdeltproject.org/documentation/GDELT-Global_Knowledge_Graph_Codebook-V2.1.pdf。 它表示每条CSV行都是换行符分隔符，其结构如图1所示：
从表面上看，这似乎是一个很好的简单模型，通过该模型，我们可以简单地查询字段并使用封闭的数据，就像每天导入和导出到Microsoft Excel的CSV文件一样。 但是，如果我们更详细地检查这些字段，那么很明显，某些字段实际上是对外部源的引用，而其他字段是扁平化的数据，实际上是由其他表表示的。
隐藏的复杂性
GKG核心模型中的扁平化数据结构表示隐藏的复杂性。 例如，查看文档中的字段V2GCAM，它概述了以下概念：这是一系列逗号分隔的块，其中包含冒号分隔的键值对，代表GCAM变量的对及其各自的计数。 像这样：
如果我们参考GCAM规范http://data.gdeltproject.org/documentation/GCAM-MASTERCODEBOOK.TXT，我们可以将其翻译为：
还有其他以相同方式工作的字段，例如V2Locations，V2Persons，V2Organizations等。 那么，这到底是怎么回事？ 这些嵌套结构都是什么？为什么选择这种方式表示数据？ 实际上，事实证明，这是折叠维模型的一种便捷方法，这样它可以在单行记录中表示，而不会丢失任何数据或交叉引用。 实际上，这是一种常用的技术，称为非规范化。
标准化模型
传统上，维模型是一种包含许多事实和维表的数据库表结构。由于它们在实体关系图中的出现，它们通常被称为具有星型或雪花型方案。在这样的模型中，事实是可以被计数或求和的值，并且通常在给定的时间点提供度量。由于它们通常基于交易或重复事件，因此事实的数量倾向于变得非常大。另一方面，维度是信息的逻辑分组，其目的是限定事实或将事实上下文化。它们通常为通过分组或汇总来解释事实提供一个切入点。同样，维度可以是分层的，一个维度可以引用另一个维度。我们可以在图2中看到扩展的GKG尺寸结构图。
在我们的GCAM示例中，事实是在上表中找到的条目，而维度是GCAM参考本身。尽管这看起来像是一个简单的逻辑抽象，但这确实意味着我们有一个值得关注的重要领域：维度建模对于传统的数据库非常有用，在传统的数据库中，数据可以拆分成表格-在这种情况下，是GKG和GCAM表-这些类型的数据库，就其本质而言，已针对该结构进行了优化。例如，用于查找值或汇总事实的操作是本地可用的。但是，在使用Spark时，我们认为理所当然的某些操作可能会非常昂贵。例如，如果我们想对数百万个条目的所有GCAM字段取平均值，那么我们将需要执行非常大的计算。我们将在下图中更详细地讨论这一点：
复杂数据带来的挑战
探索了GKG数据模式后，我们现在知道分类法是典型的星形模式，其中单个事实表引用了多个维度表。 有了这种层次结构，如果我们需要以传统数据库所允许的相同方式对数据进行切片和切块，那么我们一定会很费力。
但是，是什么使得在Spark上进行处理如此困难？ 让我们看一下这种类型的组织固有的三个不同问题。
问题1-上下文信息丢失
首先，在数据集的每个记录中使用的各种数组都有问题。 例如，V1Locations，V1Organizations和V1Persons字段都包含一个0或更多对象的列表。 因为我们没有用于获取此信息的文本的原始正文（尽管如果源是WEB，JSTOR等，我们有时可以获取它，因为它们将包含到源文档的链接），所以我们失去了上下文 实体之间的关系。
例如，如果我们的数据中包含[巴拉克·奥巴马，戴维·卡梅伦，弗朗索瓦·奥朗德，美国，法国，GB，德士古，埃索，壳牌]，那么我们可以假设源文章与各国元首之间的会议有关 石油危机的国家。 但是，这仅是一个假设，可能并非如此，如果我们确实是客观的，我们可以同样地认为该文章与拥有著名雇员的公司有关。
