《数据密集型应用系统设计》章节总结 第四章 数据编码与演化

数据编码:指将程序中的对象转换为字节序列的过程

模式:数据的规则,可以理解为数据中包含的字段,以及字段的类型

模式演化:随着需求的变化,对于数据模式要求的变化

兼容性:模式演化带来了代码的兼容性问题

  • 向后兼容:新代码可以读取旧代码编写的数据
  • 向前兼容:旧代码可以读取新代码编写的数据

数据编码格式

程序中至少有以下两种数据的保存形式:

  • 保存于内存:数据保存在对象、结构体、树等数据结构中
  • 保存于文件/通过网络传输:必须将数据编码为字节序列

两种形式需要相互转化,则出现了编码(序列化)和解码(反序列化)两个概念:

  • 编码(序列化):内存内容->字节序列
  • 解码(反序列化):字节序列->内存内容

语言特定的格式

诸多编程语言自带编码方式,如python的pickle,java的java.io.Serializable,这些编码方式很方便调用,但是有以下问题:

  • 耦合性强:编码方式与语言强绑定,另一种语言很难读取一种语言编码的文件
  • 兼容性差:编码方式适应模式演化的能力较差
  • 安全性差:由于解码可以实例话任意的类,将带来一系列安全问题

JSON、XML与二进制变体

为解决语言特定编码格式带来的问题,出现了跨语言的编码方案,典型的有JSON、XML以及CSV,他们的特点在于,通常具有较好的可读性,适合人类阅读,但是他们也有一系列问题:

  • 数字编码模糊
  • 二进制字符串支持差
  • 模式支持问题

二进制编码

JSON、XML适合人类阅读,但是较为冗长,而二进制编码能够较好的解决这些问题。

Thrift与Protocol Buffers

相比于JSON和XML,Thrift和Protocol Buffers是两种二进制编码方式,具有类似的机制,都通过自身的接口定义语言描述数据的模式,然后通过代码生成工具生成各种编程语言中的类。他们在编码的方式上有近似有差异,两种编码方式都通过标签(tag)记录数据中的键,都会记录值的类型、长度以及具体内容。不过Protocol Buffers将tag和type合并为一个字节,并且在列表和整形数字的编码上有差异。

字段标签和模式演化

由于Thrift和Protocol Buffers都只存储标签(tag)以代替字段名,因此两种编码都需要适应模式变化带来的字段名增加、删除、修改问题。

一方面,代码会忽略未设置字段值的tag,另一方面,会为新的字段分配新的tag,为了保证兼容性,新的字段必须是可选的或者具有默认值的。

数据类型和模式演化

如果某个字段的类型改变,会不出出现丢失精度或者截断的问题。

Avro

另一种二进制编码模式,变态的地方在于,用来标记键的标签(tag)都不需要了,只保存类型、长度以及具体内容。在解析编码后的二进制数据时,按照模式依次解析各个字段。

写模式与读模式

写模式:数据编码为字节序列时遵从的模式

读模式:字节序列解码为数据时遵从的模式

在Avro中,读模式和写模式不需要完全一致,只需要保持兼容即可。

模式演化规则

为保持兼容性,只可以增加或删除具有默认值的字段对于采用不同模式进行读写的情况,Avro对比新旧模式消除差异。

Avro中对于能否使用null值的规定较为特殊,null被视为和int、string并列的类型,若需使用null值,则需要构建null和其他类型的联合体。

另外,Avro通过字段别名实现字段名的修改,但是不具有向前兼容性。

那么writer模式又是什么?

负责解码的一方如果和确定应该使用哪种模式进行解码,通常有以下情况:

  • 具有多条记录的大文件:此时可以只在文件开头表明模式,就仿佛是表格的表头
  • 具有单独记录的记录:若各个记录总是符合几种特定的模式,则可通过模式版本列表配合标签即可
  • 通过连接网络发送的记录:在连接建立之初指定模式

动态生成的模式

Avro中不具有标签号具有一定的优势,在对于关系型数据进行编码时并且模式发生改变时,无需小心处理tag与字段名的对应关系,只需要维持好模式即可。

代码生成与动态语言

Avro和Protocol buffers一样为静态类型语言提供了代码生成,而其无tag的设计也更适合动态类型。

模式的优点

相比于JSON、XML和CSV,Protocol buffers、Trift、Avro 的优点:

  • 无需储存字段名,节省存储空间
  • 易于通过模式控制数据的版本
  • 易于通过模式检查前后兼容性
  • 代码生成机制

模式提供了对于数据兼容性、版本的保障,而模式提供了灵活性。

数据流模式

数据流动往往基于以下三种方式:

  • 数据库
  • 服务调用
  • 消息队列

基于数据库的数据流

数据库可以视为个未来的自己发送消息,未来的代码可能读取现在的数据,应当具有向后兼容性;旧的代码可能读取到当前写入的数据,应当具有当前兼容性。

不同的时间写入不同的值

避免使用重写或者迁移操作进行模式的演化,应当在改变模式时尽量避免重写现有数据。

归档存储

数据库可能基于备份等需求简历快照,因此在这个过程中可以对于快照进行模式统一的编码。

基于服务的数据流:REST和RPC

客户端和服务器具有多种不同的通信方式,服务器通过网络公布API,客户端调用相应的API。Web服务就是一种典型的服务,除此之外,服务器本身可以作为另一项服务的客户端,这称为微服务架构

网络服务

通常网络服务中客户端有以下几类

  • 运行于用户设备的客户端:比如浏览器、手机APP
  • 面向同一组织的另一服务:例如阿里、字节的中台设计
  • 面向其他组织的另一服务:例如各种在线服务提供的接口,如身份证号认证等

REST是一种基于HTTP原则的设计理念,强调简单的数据格式,利用URL对于数据进行标记

远程过程调用(RPC)的问题

远程过程调用(Remote Procedure Call, RPC),通过网络执行远端的函数,仿佛是调用程序本地的函数,但是相比于调用本地函数具有以下差异:

  • 网络调用存在调用失败的可能
  • 网络调用存在延迟带来的影响
  • 网络调用不可采用指针或引用传参
  • 网络调用适合跨语言调用

RPC的发展方向

REST更多作为公共API的请求,RPC用于处理同一组织内的请求

RPC的数据编码和演化

gRPC,模式版本号等。

基于消息传递的数据流

消息队列的优势:削峰、解耦、异步、支持多个订阅、发送者无需知道接受者IP与Port

消息代理

RabbitMQ、Kafka等

分布式Actor框架

没看

小结

本章讨论遵循以下逻辑进行:

  • 编码方式
    • 可读性较好的编码方式:JSON、XML、CSV
    • 二进制编码方式:Protocol Buffers、Thrift、Avro
  • 编码方式的模式演化问题
  • 编码的应用场景
    • 数据库
    • 网络服务
    • 消息队列

你可能感兴趣的:(《数据密集型应用系统设计》章节总结 第四章 数据编码与演化)