SQL Shell加载数据与Schema on Read

加载数据

打开另外一个shell，写入一个txt：

cat << EoF > /tmp/employee.txt
Michael,29
Andy,30
Justin,abc
EoF

image-20240218110748972

将txt中的数据加载到employees表：

load data local inpath '/tmp/employee.txt' into table mydb.employees;

然后进行查询：

image-20240218110835743

Schema on Read

首先看到数据加载成功，另外注意到最后一个用户的age为NULL，这就引出了Spark的工作模式 - Schema on read:

  • schema on write

    典型使用就是传统数据库。数据不管是在入库、load外部数据、或者将一个查询的输出结果写入数据库、或者是使用UPDATE语句，在数据写入数据库时都需要对schema进行检查控制，如果在加载时发现数据不符合schema，则拒绝加载数据。

  • schema on read

    作用数据加载到查询工具进行分析之前，不管如何数据先存储起来，然后在需要查询分析的时候再为数据设置schema，底层存储不会在数据加载时进行验证，而是在查询数据时进行:

image-20240218105752261

我们在hdfs中可以找到这个txt文件：

image-20240218111216298

查看这个文件，它的最后一条数据还是以abc存进去的：

image-20240218111835394

两种模式对比

业务角度分析

  1. 对于一个成熟的业务，已有模型足够涵盖所有的数据集，变化较少，则可以使用Schema on Write，提前定义好所有数据模型（数仓作用）；
  2. 对于一个新的或者探索性业务，由于业务需求不定，并且变动频繁，因此数据不适合绑定到预定的结构，则可以使用Schema on Read，快速迭代，尽快交付业务需求。

数据质量对比

  1. Schema on Write，会对存储的数据质量进行ETL，确保数据在某个业务场景下明确定义的、精确的和可信的；
  2. Schema on Read，因为数据没有受到严格的ETL和数据清理过程, 也没有经过任何验证, 该数据可能充斥着缺失或无效的数据重复和一大堆其他问题，可能会导致不准确或不完整的查询结果。如果在on read的时候进行ETL，由于同样数据不同schema，则会导致重复工作。

效率对比

  1. Schema on Write倾向于读效率，因为数据存储在合适的地方，并做了类型安全和清理优化工作，通常更高效。但这是经过数据摄入时，繁琐的预处理为代价换来的；
  2. Schema on Read更倾向于写效率，数据摄入不需要做其它处理，简单，快捷。但是就会导致on read时，解析和解释数据效率低下。

功能与系统

  1. Schema on Write更多用于对结构化数据的OLAP与OLTP，对应传统的数据库系统；
  2. Schema on Read基于非结构化数据，需要存储更多的数据，海量的分析需求，快速的需求响应，与大数据系统不谋而和。

总结

  1. schema on read强调灵活自由，schema on write注重稳定和效率；
  2. schema on read与schema on write不是二者取一，而是相辅相成，互相协助；
  3. Schema有其存在的意义，无论是结构化还是非结构数据分析挖掘，Schema都是必须的过程