也是知识，要了解
URL：
https://zhuanlan.zhihu.com/p/459444652
为什么我们需要不同的文件格式？
对于 MapReduce 和 Spark 等支持 HDFS 的应用程序来说，一个巨大的瓶颈是在特定位置查找相关数据所需的时间以及将数据写回另一个位置所需的时间。这些问题随着管理大型数据集的困难而变得复杂，例如不断发展的模式或存储限制。
在处理大数据时，存储此类数据所需的成本更高（Hadoop 冗余存储数据以实现容错）。除了存储成本之外，处理数据还伴随着 CPU、网络、IO 成本等。随着数据的增加，处理和存储的成本也随之增加。
各种 Hadoop 文件格式在 数据工程解决方案中得到了发展，以缓解许多用例中的这些问题。
选择合适的文件格式可以带来一些显着的好处：
- 更快的读取时间
- 更快的写入时间
- 可拆分文件
- 模式演变支持
- 高级压缩支持
一些文件格式是为一般用途而设计的，另一些是为更具体的用例而设计的，还有一些是为特定数据特征而设计的。所以有相当多的选择。
Avro 文件格式
[图片上传失败...(image-1ec66-1649317507854)]
Avro 格式是 Hadoop 的一种基于行的存储格式，被广泛用作序列化平台。
Avro 格式以 JSON 格式存储模式，使其易于被任何程序读取和解释。
数据本身以二进制格式存储，使其在 Avro 文件中紧凑且高效。
vro格式是语言中立的数据序列化系统。它可以被多种语言处理（目前是 C、C++、C#、Java、Python 和 Ruby）。
Avro 格式的一个关键特性 是对随时间变化的数据模式的强大支持，即模式演变。Avro 处理模式更改，例如缺少字段、添加的字段和更改的字段。
Avro 格式提供了丰富的数据结构。例如，您可以创建包含数组、枚举类型和子记录的记录。
[图片上传失败...(image-aa93b7-1649317507854)]
Avro 格式是在数据湖登陆区存储数据的理想选择，因为：
1.落地区的数据通常被整体读取，以供下游系统进一步处理（这种情况下基于行的格式效率更高）。
2. 下游系统可以轻松地从 Avro 文件中检索表模式（无需将模式单独存储在外部元存储中）。
3. 任何源模式更改都很容易处理（模式演变）。
列式存储格式
为了更好地理解 Hadoop 中的 Parquet 和ORC 文件格式，首先我们来看看什么是列式存储格式。在面向列的格式中，记录中相同类型的每一列的值存储在一起。
例如 ，如果有一条记录包含 ID、员工姓名和部门，则 ID 列的所有值将存储在一起，Name 列的值将存储在一起，等等。如果我们采用与上述相同的记录模式，具有三个字段 ID (int)、NAME (varchar) 和 Department (varchar)，则该表将如下所示：
[图片上传失败...(image-c1bf62-1649317507854)]
<figcaption style="margin-top: calc(0.666667em); padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">添加图片注释，不超过 140 字（可选）</figcaption>
对于此表，按行存储格式的数据将按如下方式存储：
[图片上传失败...(image-b537ba-1649317507854)]
<figcaption style="margin-top: calc(0.666667em); padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">添加图片注释，不超过 140 字（可选）</figcaption>
然而，面向列的存储格式中的相同数据将如下所示：
[图片上传失败...(image-7a4f5d-1649317507854)]
<figcaption style="margin-top: calc(0.666667em); padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">添加图片注释，不超过 140 字（可选）</figcaption>
当您需要从表中查询几列时，列式存储格式更有效。它将只读取所需的列，因为它们是相邻的，从而最小化 IO。
例如，假设您只需要 NAME列。 在行存储格式中，必须加载数据集中的每条记录，将其解析为字段，并提取名称的数据。面向列的格式可以直接转到 Name 列，因为该列的所有值都存储在一起。它不需要遍历整个记录。
因此，面向列的格式提高了查询性能，因为转到所需列所需的查找时间更少，并且由于只需要读取需要数据的列，因此需要更少的 IO。
Parquet文件格式
[图片上传失败...(image-a510fc-1649317507854)]
Parquet 是 Hadoop 的一种开源文件格式，以扁平列格式存储嵌套数据结构。
Parquet文件格式优点
- 与以行方式存储数据的传统方法相比，Parquet文件格式在存储和性能方面更高效。
- 这对于从“宽”（具有许多列）表中读取特定列的查询特别有用，因为只读取需要的列，并且最小化 IO。
- Parquet的独特功能之一是它也可以以柱状方式存储具有嵌套结构的数据。这意味着在 Parquet 文件格式中，即使是嵌套字段也可以单独读取，而无需读取嵌套结构中的所有字段。Parquet 格式使用记录分解和组装算法以柱状方式存储嵌套结构。
[图片上传失败...(image-c3759b-1649317507853)]
Parquet 文件格式结构组成
[图片上传失败...(image-41c9ac-1649317507854)]
Header： 包含一个幻数“PAR1”（4 字节），用于将文件标识为 Parquet 格式文件。
Row group（行组）：将数据逻辑水平划分为行。行组由数据集中每一列的列块组成。
Column chunk（列块）：特定列的数据块。这些列块存在于特定的行组中，并保证在文件中是连续的。
Page（页面）：列块被分成背靠背写的页面。这些页面共享一个标准标题，读者可以跳过他们不感兴趣的页面。
Footer（页脚）：
文件元数据- 文件元数据包含所有列元数据起始位置的位置。它还包括格式版本、架构和任何额外的键值对。读者应该首先读取文件元数据以找到他们感兴趣的所有列块。然后应该顺序读取列块。
文件元数据的长度（4 字节）
幻数“PAR1”（4 字节）
ORC 文件格式
[图片上传失败...(image-f37441-1649317507854)]
优化行列式 ( ORC ) 文件格式提供了一种高效的数据存储方式。 它旨在克服其他文件格式的限制。ORC 文件格式理想地存储紧凑的数据，并允许跳过不相关的部分，而无需大型、复杂或手动维护的索引。ORC 文件格式解决了所有这些问题。
ORC 文件格式优点
- 单个文件作为每个任务的输出，减少 NameNode 的负载
- Hive 类型支持，包括 DateTime、decimal 和复杂类型（结构、列表、映射和联合）
- 使用单独的 RecordReader 并发读取同一文件
- ORC 文件格式能够在不扫描标记的情况下拆分文件
- 根据文件页脚中的信息估计 Reader/Writer 的堆内存分配上限
- 使用协议缓冲区存储的元数据，允许添加和删除字段
[图片上传失败...(image-a34fff-1649317507854)]
ORC 文件格式将行集合存储在一个文件中，并且在集合中，行数据以列格式存储。
ORC 文件包含称为stripe的行数据组和File footer（文件页脚）中的辅助信息 。默认stripe大小为 250 MB。大stripe大小支持从 HDFS 进行大量、高效的读取。
ORC 文件格式结构组成
**Index data（索引数据）： **包括每列的最小值和最大值以及行在每列中的位置。ORC 索引仅用于stripe和行组的选择，而不用于回答查询。
Row data（行数据）：用于表扫描。
stripe footer（页脚）：包含流位置的目录。它还包含列级聚合计数、最小值、最大值和总和。
File footer（文件页脚）：
文件中的stripe列表。
每个stripe的行数。
每列的数据类型。
Postscript：附有压缩参数和压缩页脚的大小，在文件的末尾。
不同文件格式之间的比较
Avro 与 Parquet
- Avro是一种基于行的存储格式，而 Parquet是一种基于列的存储格式。
- Parquet 对于分析查询要好得多，即读取和查询比写入效率高得多。
- Avro中的编写操作比Parquet 中的要好。
- 在模式演变方面，Avro比 PARQUET 成熟得多。Parquet 仅支持模式追加，而 Avro支持功能强大的模式演变，即添加或修改列。
- PARQUET 非常适合查询多列表中的列子集。Avro是 ETL 操作的理想选择，我们需要查询所有列。
ORC 与 Parquet
- Parquet更能存储嵌套数据。
- ORC 更有能力进行谓词下推。
- ORC 支持 ACID 属性。
- ORC 的压缩效率更高。
