schema on write vs. schema on read

随着万物互联时代的到来，大量的数字化设备每时每刻都在产生大量的数据。信息社会进入了大数据时代。

大数据包括用户产生的内容数据和机器产生的内容数据。有些数据是高度结构化的数据，比如医院病历、保险理赔申请、按揭贷款文件，等等。另一些数据则是异构的原始数据，包括传感器数据、日志文件、社交媒体产生的数据，等等。大数据的特点可以用3V概括，即容量（Volume）、速度（Velocity）和多样性（Variety）。大数据的海量容量无需过多解释；速度意味着能够快速响应数据查询和快速高效地进行数据分析；多样性则体现在不同类型的数据源和不同类型的数据格式。

应对大数据的需求带来了数据库系统的改变和革新。由于传统的关系型数据库无法满足大数据云业务的一些需求，这些云业务开始使用NoSQL数据库。传统数据库系统长期使用的写时建模模式（schema on write）擅长处理结构化的数据，而大数据中的异构数据则青睐读时建模模式（schema on read）。

数据库模式（schema）是数据库的组织和结构，是依照逻辑对数据库对象，包括表、列、数据类型、视图、存储过程、关系、主键、外键等进行分组的方法。数据库模式（database schema）也可以被视为对象的容器。写时建模模式（schema on write）是关系数据库的常用模式——我们先创建数据模式（schema），然后提取数据写入数据库，然后当我们查询读取时，数据以上传前设定的模式（schema）呈现。当我们把海量的数据从文件上传到数据库，且预先知道文件内的数据存储格式时，我们使用写时建模模式（schema on write），先确定表格的列、数据的类型和列之间的关系，再将数据导入表格，然后执行分析查询。

写时建模模式（schema on write）的优点在于，一旦我们完成数据的提取/转换/上传（ETL），后续的数据读取将非常快速和明确，每个查询数据的人都能获得与初始模式一致的严格定义的数据。

但是，写时建模模式（schema on write）有其固有的缺陷。首先，这种严格定义的数据模式意味着为了迁就某个特定的有限目标而对原始数据进行修改和建构，导致经过修改和建构的数据无法为将来未知的其它目标服务。其次，如果我们不知道数据的模式，我们就没办法创建表格，因此也就无法通过写时建模模式（schema on write）来上传数据。另外，如果源数据文件发生变化，比如新增了数据，或者数据列的类型改变，我们只能放弃原来创建的数据表格，重新上传数据——如果数据量不大，如果没有外部索引键，重新上传数据是可行的；但如果有外部索引键，如果面对的是海量数据，就会有大麻烦。

为了解决写时建模模式（schema on write）的缺陷，出现了另一种方法，即读时建模模式（schema on read）。读时建模模式（schema on read）原封不动地上传原始的数据，无需事先框定数据的模式，无需事先设计表格对原始数据进行裁剪。当查询数据时，读时建模模式（schema on read）再让数据通过特定的过滤器或者透镜呈现给用户。

读时建模模式（schema on read）能够快速地提取数据，因为不需要依照人为的模式改变数据，只需要复制或者移动数据。这种数据处理方法能够灵活地应对大数据、异构数据和数据模式的频繁改变。

由于读时建模模式（schema on read）保留了原始数据，因此，如果我们希望从另一个角度分析和理解数据，只需要修改处理数据的代码，而不需要改变提取数据的模式并重新上传数据。

但是，由于数据没有经过严格的ETL处理，没有转换成严格的数据存储模式，因此数据库中存在着大量的无效数据、不完整数据、重复数据和其它可能导致错误查询或者不完整查询的问题。

哪一种数据库模式更好呢？数据库模式就像工程领域的其它东西一样，没有包治百病的灵丹妙药，其优劣取决于如何使用它们。写时建模模式（schema on write）能够更快地执行数据查询，因为数据已经按照严格的格式上传，你可以较容易地找到需要的数据；但是，为之付出的代价是更多的前期准备和对输入数据的持续不断地转换，以及一旦需要改变数据模式而需要付出的高昂成本。

读时建模模式（schema on read）则更加灵活、更具有可扩展性、更能预防人为的错误。读时建模模式（schema on read）以原始的格式储存数据，只在需要处理数据时才以适当的格式剪裁数据。ETL可能带来不恰当的转换，而读时建模模式（schema on read）能够让用户重返原始数据，正确地处理它们。但是，由于需要在查询数据时定义模式，数据查询过程变得复杂，速度变慢。

万事有利必有弊。一定程度的模式设计无疑是必要的。为了理解数据结构以便更好地挖掘其中的信息，为了检查输入的数据，为了更好地管理数据，选择这个或者那个数据模式是必要的。但是，不是所有的数据都适合这个处理过程。有些数据还不清楚如何与商业模式对应，因此不应当急着在能够使用这些数据之前，用刻板的方式管理它们或者对它们建模。