1. 序列化

1.1. 仅仅通过从CSV转换到Parquet序列化，任务性能就提高了上百倍

1.2. 基于行的序列化

• 1.2.1. 基于行的序列化是按行来组织数据

• 1.2.2. 对于那些半结构化的数据（支持嵌套和模式变化的数据对象）​，基于行的序列化需要将每个对象作为一个单元来存储

• 1.2.3. CSV格式是一种典型的基于行的格式

  • 1.2.3.1. CSV：不是标准的标准

  • 1.2.3.2. CSV本质上是分隔符文本的总称，但不同的CSV文件在转义、引号字符、分隔符等的使用上会有所变化

  • 1.2.3.3. 应该避免在管道中使用CSV文件，因为它们非常容易出错，而且性能很差

  • 1.2.3.4. 使用CSV进行归档，要附带上文件的序列化配置的完整技术描述，以便未来的数据消费者获取数据

• 1.2.4. XML

  • 1.2.4.1. XML是数据工程师在与传统系统和软件交换数据时经常必须处理的另一种标准

• 1.2.5. JSON和JSONL

  • 1.2.5.1. JSON已经在纯文本对象序列化上很大程度地取代了XML

  • 1.2.5.2. JavaScript对象表示法(JSON)已经成为通过API数据交换的新标准，以及一种非常流行的数据存储格式

  • 1.2.5.3. JSON Lines(JSONL)是JSON的一个专门版本，用于将批量半结构化数据存储在文件中

  • 1.2.5.4. JSONL是一种非常有用的格式，可以在从API或应用程序获取数据后立即存储数据

• 1.2.6. Avro

  • 1.2.6.1. Avro是一种面向行的数据格式，用于远程过程调用和数据序列化

  • 1.2.6.2. Avro将数据编码为二进制格式，其模式的元数据为JSON形式

1.3. 列序列化

• 1.3.1. 通过列序列化，每列数据都会分为多个文件

• 1.3.2. 列存储的一个明显优势是，它从字段的子集中读取数据，而不是一次性读取整行数据

  • 1.3.2.1. 分析应用程序常用列序列化，它可以大大减少执行查询时必须扫描的数据量

• 1.3.3. 将数据存储为列还可以将相似的值聚集，让每列数据的排列更有效率

• 1.3.4. 一种常见的压缩技术是寻找重复的值并对其进行标记，对于有大量重复数据的列来说简单又高效

• 1.3.5. 列式数据库对于事务性工作负载来说是非常不合适的，所以事务数据库通常会利用一些面向行或记录的存储方式

• 1.3.6. Parquet

  • 1.3.6.1. Parquet以列格式存储数据，旨在实现数据湖环境中的出色读写性能

  • 1.3.6.2. 与CSV不同，Parquet方式储存的数据建立在模式信息中，并原生支持嵌套数据

  • 1.3.6.3. 与Parquet相比，虽然BigQuery和Snowflake等数据库以专有的列格式序列化数据，并为其内部存储的数据提供很好的查询性能，但在与外部工具互操作时会产生巨大的性能下降

  • 1.3.6.4. 存储的数据需要被反序列化，并重新序列化为可交换的格式，才能使用如Spark和Presto等数据湖工具操作

• 1.3.7. ORC

  • 1.3.7.1. 行优化列存储(Optimized Row Columnar，ORC)是一种类似于Parquet的列存储格式

• 1.3.8. Apache Arrow

  • 1.3.8.1. 利用二进制数据格式来重新设计序列化，这种格式既适合在内存中处理，也适合在系统间传输

  • 1.3.8.2. Arrow使用列存储，其中每一列基本上都有自己的内存块

  • 1.3.8.3. 对于嵌套的数据，我们会使用一种叫作粉碎的技术，将JSON文档模式中的每个位置都映射成单独的列

  • 1.3.8.4. 意味着数据文件可以存储在磁盘上，通过使用虚拟内存将其直接交换到程序地址空间并运行数据查询，没有反序列化的开销

  • 1.3.8.5. 为各种编程语言（包括C、Go、Java、JavaScript、MATLAB、Python、R和Rust）创建了库，允许这些语言与在内存中的Arrow数据互通

  • 1.3.8.6. Dremio，它是一个基于Arrow序列化，支持高速查询的查询引擎和数据仓库

1.4. 混合序列化

• 1.4.1. Hudi

  • 1.4.1.1. Hadoop Update Delete Incremental的缩写

  • 1.4.1.2. 一种表管理技术结合了多种序列化技术，让分析查询拥有列式数据库的性能，同时能进行原子式的、事务性的记录更新

• 1.4.2. Iceberg

  • 1.4.2.1. 一种表管理技术

2. 数据库存储引擎

2.1. 存储引擎通常是独立于查询引擎的一个软件层

2.2. 存储引擎管理数据在磁盘上存储的所有相关信息，包括序列化方式、数据的最底层排布和索引

2.3. 另一个主要发展方向是服务于分析和数据仓库应用程序的列存储

• 2.3.1. SQL Server、PostgreSQL和MySQL都有强大的列存储支持

3. 压缩算法

3.1. 无损压缩算法

• 3.1.1. 用无损算法解压缩编码的数据会完整恢复到原始数据

• 3.1.2. 在对数据保真度有要求的分析序列化过程中使用无损压缩算法

3.2. 音频、图像和视频的有损压缩算法旨在实现感官上的保真，解压缩恢复的东西听起来像或看起来像原件，但不精确

• 3.2.1. 数据工程师可能会在媒体处理管道中使用有损压缩算法

3.3. 传统的压缩引擎如gzip和bzip2非常适合处理文本数据

• 3.3.1. 经常被应用于JSON、JSONL、XML、CSV和其他基于文本的数据格式

3.4. 新一代的压缩算法，将速度和CPU效率置于压缩率之上

• 3.4.1. 主要有Snappy、Zstandard、LZFSE和LZ4等

4. 云网络

4.1. 云网络拓扑结构描述了云中各种组件的排列和连接方式，如云服务、网络、位置（区域）等

4.2. 数据出口费用

• 4.2.1. 在网络定价方面，云提供商会让入站流量免费但对出站流量收费

• 4.2.2. 出站流量本身并不比入站便宜，但云提供商用这种方法在它们的服务周围创造了一条护城河，并且增加了所存储数据的黏性

• 4.2.3. 数据出口费也适用于云的可用区或区域之间的数据传输

• 4.2.4. 数据出口费是阻碍互操作性、数据共享和数据向云端移动的重要因素

• 4.2.5. 数据出口费是云供应商的护城河，防止公有云客户离开或在多个云中部署

4.3. 可用区是公有云向客户暴露的最小的网络拓扑单元

• 4.3.1. 一个区内的系统和服务之间一般会有最高的网络带宽和最低的延时

• 4.3.2. 发送到区内虚拟机的网络流量是免费的，但有明显的限制：流量必须发送到私有IP地址

4.4. 区域是两个或多个可用区的集合

• 4.4.1. 数据中心的运行需要依赖许多资源（电力、水等）

• 4.4.2. 各个可用区的所用资源是独立的

• 4.4.3. 多区域意味着资源可以放在靠近用户的地方

• 4.4.4. 区域在可用区之间支持快速、低延迟的网络

• 4.4.5. 可用区间的网络性能将比单个可用区内的差，并在虚拟机之间产生名义上的数据输出费用

4.5. 谷歌实际上拥有比其他云提供商多得多的全球规模网络资源，它可以给用户提供高级网络服务

• 4.5.1. 高级网络的区域之间流量可以只走谷歌的网络，不走公网

4.6. 流的公有云都提供加强版连接的选项，客户可以将自己的网络与云的某个区域或VPC直接集成

4.7. 内容分成服务可以为向公众或客户传送数据资产提供巨大的性能提升和折扣