天天看点
返回

Hive 文件格式

本文主要转至：http://www.cnblogs.com/skyl/

Hadoop 作为MR 的开源实现，一直以动态运行解析文件格式并获得比MPP数据库快上几倍的装载速度为优势。不过，MPP数据库社区也一直批评Hadoop由于文件格式并非为特定目的而建，因此序列化和反序列化的成本过高。

文本格式的数据也是Hadoop中经常碰到的。如TextFile 、XML和JSON。 文本格式除了会占用更多磁盘资源外，对它的解析开销一般会比二进制格式高几十倍以上，尤其是XML 和JSON，它们的解析开销比Textfile 还要大，因此强烈不建议在生产系统中使用这些格式进行储存。 如果需要输出这些格式，请在客户端做相应的转换操作。 文本格式经常会用于日志收集，数据库导入，Hive默认配置也是使用文本格式，而且常常容易忘了压缩，所以请确保使用了正确的格式。另外文本格式的一个缺点是它不具备类型和模式，比如销售金额、利润这类数值数据或者日期时间类型的数据，如果使用文本格式保存，由于它们本身的字符串类型的长短不一，或者含有负数，导致MR没有办法排序，所以往往需要将它们预处理成含有模式的二进制格式，这又导致了不必要的预处理步骤的开销和储存资源的浪费。

1.TextFile

  • Hive数据表的默认格式，存储方式：行存储。
  • 可使用Gzip,Bzip2等压缩算法压缩,压缩后的文件不支持split
  • 但在反序列化过程中，必须逐个字符判断是不是分隔符和行结束符，因此反序列化开销会比SequenceFile高几十倍。 
--创建数据表：
create table if not exists textfile_table(
site string,
url  string,
pv   bigint,
label string)
row format delimited fields terminated by '\t'
stored as textfile;
--插入数据：
set hive.exec.compress.output=true; --启用压缩格式 
set mapred.output.compress=true;    
set mapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec;  --指定输出的压缩格式为Gzip  
set io.compression.codecs=org.apache.hadoop.io.compress.GzipCodec;      
insert overwrite table textfile_table select * from T_Name;
Hive 文件格式

2.SequenceFile

  • Hadoop API提供的一种二进制文件，以<key,value>的形式序列化到文件中。
  • 存储方式：行存储。
  • 支持三种压缩选择：NONE，RECORD，BLOCK。Record压缩率低，一般建议使用BLOCK压缩。
  • 这种二进制文件内部使用Hadoop 的标准的Writable 接口实现序列化和反序列化。它与Hadoop API中的MapFile 是互相兼容的,这是sequence file的一个优势。
  • Hive 中的SequenceFile 继承自Hadoop API 的SequenceFile，不过它的key为空，使用value 存放实际的值， 这样是为了避免MR 在运行map 阶段的排序过程。如果你用Java API 编写SequenceFile，并让Hive 读取的话，请确保使用value字段存放数据，否则你需要自定义读取这种SequenceFile 的InputFormat class 和OutputFormat class。 
  • SequenceFile是Hadoop本身就可以支持的一种标准文件格式，因为它也是在Hive和其他Hadoop相关的工具中共享文件的可以接受的选择。而对于Hadoop生态系统之外的其它工具而言，其并不适用.
  • SequenceFile可以在块级别和记录级别进行压缩，这对于优化磁盘利用率和I/0来说非常有意义。同时仍然可以支持按照块级别的文件进行分割，以方便并行处理。
值得注意的是，hive读取sequencefile的时候，是把key忽略的，也就是直接读value并且按照指定分隔符分隔字段。但是如果hive的数据来源是从mr生成的，那么写sequencefile的时候，key和value都是有意义的，key不能被忽略，而是应该当成第一个字段。为了解决这种不匹配的情况，有两种办法。一种是要求凡是结果会给hive用的mr job输出value的时候带上key。但是这样的话对于开发是一个负担，读写数据的时候都要注意这个情况。所以更好的方法是第二种，也就是把这个源自于hive的问题交给hive解决，写一个InputFormat包装一下，把value输出加上key即可。 
create table if not exists seqfile_table(
site string,
url  string,
pv   bigint,
label string)
row format delimited fields terminated by '\t'
stored as sequencefile;
--插入数据操作：
set hive.exec.compress.output=true;  --启用输出压缩格式
set mapred.output.compress=true;  
set mapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec;  --指定输出压缩格式为Gzip
set io.compression.codecs=org.apache.hadoop.io.compress.GzipCodec;  
SET mapred.output.compression.type=BLOCK; --指定为Block
insert overwrite table seqfile_table select * from T_Name;
Hive 文件格式

3.RCFile

BG:大多数的Hadoop和Hive存储都是行式存储的，在大多数场景下，这是比较高效的。这种高效归根于如下几点：大多数的表具有的字段个数都不大(一般小于20个)；对文件按块进行压缩对于需要处理重复数据的情况比较高效，同时很多的处理和调试工具(如:more,head,awk)都可以很好的应用于行式存储的数据。

并非所有的工具和数据存储都是采用行式存储的方式的，对于特定类型的数据和应用来说，采用列式存储有时会更好。例如，如果指定的表具有成百上千个字段，而大多数的查询只需要使用到其中的一小部分字段，这是扫描所有的行而过滤掉大部分的数据显然是个浪费。然而，如果数据是按照列而不是行进行存储的话，那么只要对其需要的列进行扫描就可以了，这样可以提高性能。

对于列式存储而言，进行压缩通常会非常高效，特别是在这列的数据具有较低计算的时候(只有很少的排重值时)。同时，一些列式存储并不需要无力存储NULL值的列。

基于这些场景，HIVE中才设计了RCFile.

Hive功能强大的一个方面体现在不同的存储格式间相互转换数据非常的简单。存储信息存放在了表的元数据信息中。当对表执行一个select查询时。以及向其他表中执行insert操作时，Hive就会使用这个表的元数据信息中提供的内容，然后自动执行转换过程。这样使用可以有多种选择，而不需要额外的程序来对不同的存储格式进行转换。

可以在创建表时使用:ColumnarSerDe, RCFileInputFormat 和 RCFileOutputFormat;  /(end bg)

存储方式：数据按行分块，每块按列存储。结合了行存储和列存储的优点：

  • 首先，RCFile 保证同一行的数据位于同一节点，因此元组重构的开销很低
  • 其次，像列存储一样，RCFile 能够利用列维度的数据压缩，并且能跳过不必要的列读取
  • RCFile是Hive推出的一种专门面向列的数据格式。 它遵循“先按列划分，再垂直划分”的设计理念。当查询过程中，针对它并不关心的列时，它会在IO上跳过这些列。需要说明的是，RCFile在map阶段从远端拷贝仍然是拷贝整个数据块，并且拷贝到本地目录后RCFile并不是真正直接跳过不需要的列，并跳到需要读取的列， 而是通过扫描每一个row group的头部定义来实现的，但是在整个HDFS Block 级别的头部并没有定义每个列从哪个row group起始到哪个row group结束。所以在读取所有列的情况下，RCFile的性能反而没有SequenceFile高。

RCFile的一个行组包括三个部分：

  1.  第一部分是行组头部的【同步标识】，主要用于分隔 hdfs 块中的两个连续行组
  2.  第二部分是行组的【元数据头部】，用于存储行组单元的信息，包括行组中的记录数、每个列的字节数、列中每个域的字节数

  3.  第三部分是【表格数据段】，即实际的列存储数据。在该部分中，同一列的所有域顺序存储。

     从图可以看出，首先存储了列 A 的所有域，然后存储列 B 的所有域等。

Hive 文件格式

数据追加：RCFile 不支持任意方式的数据写操作，仅提供一种追加接口，这是因为底层的 HDFS当前仅仅支持数据追加写文件尾部。 

行组大小：行组变大有助于提高数据压缩的效率，但是可能会损害数据的读取性能，因为这样增加了 Lazy 解压性能的消耗。而且行组变大会占用更多的内存，这会影响并发执行的其他MR作业。 考虑到存储空间和查询效率两个方面，Facebook 选择 4MB 作为默认的行组大小，当然也允许用户自行选择参数进行配置。

create table if not exists rcfile_table(
site string,
url  string,
pv   bigint,
label string)
row format delimited fields terminated by '\t'
stored as rcfile;
--插入数据操作：
set hive.exec.compress.output=true;  
set mapred.output.compress=true;  
set mapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec;  
set io.compression.codecs=org.apache.hadoop.io.compress.GzipCodec;  
insert overwrite table rcfile_table select * from T_Name;
Hive 文件格式

4.ORCFile

相比传统数据库的行式存储引擎，列式存储引擎具有更高的压缩比，更少的IO操作，尤其是在数据列很多，但每次操作仅针对若干列进行查询和计算的情景，列式存储引擎的性价比更高。目前在开源实现中，最有名的列式存储引擎莫过于Parquet和ORC，并且他们都是Apache的顶级项目，在数据存储引擎方面发挥着重要的作用。

  • 存储方式：数据按行分块 每块按照列存储
  • 压缩快 快速列存取
  • 效率比rcfile高,是rcfile的改良版本

自定义格式

ORC(OptimizedRow Columnar) 文件格式存储源自于RC（RecordColumnar File）这种存储格式，RC是一种列式存储引擎，对schema演化（修改schema需要重新生成数据）支持较差，而ORC是对RC改进，但它仍对schema演化支持较差，主要是在压缩编码，查询性能方面做了优化。RC/ORC最初是在Hive中得到使用，最后发展势头不错，独立成一个单独的项目。Hive 1.x版本对事务和update操作的支持，便是基于ORC实现的（其他存储格式暂不支持）。ORC发展到今天，已经具备一些非常高级的feature，比如支持update操作，支持ACID，支持struct，array复杂类型。你可以使用复杂类型构建一个类似于parquet的嵌套式数据架构，但当层数非常多时，写起来非常麻烦和复杂，而parquet提供的schema表达方式更容易表示出多级嵌套的数据类型。

Hive中创建表时使用ORC数据存储格式：

create table orc_table (id int,name string) stored as orc;

  • 用户可以通过实现inputformat和 outputformat来自定义输入输出格式。 
hive>  create table myfile_table(str STRING)  
    >  stored as  
    >  inputformat 'org.apache.hadoop.hive.contrib.fileformat.base64.Base64TextInputFormat'  
    >  outputformat 'org.apache.hadoop.hive.contrib.fileformat.base64.Base64TextOutputFormat'; 
OK
Time taken: 0.399 seconds      
hive> load data local inpath '/root/hive/myfile_table'
    > overwrite into table myfile_table;--加载数据      
hive> dfs -text /user/hive/warehouse/myfile_table/myfile_table;--数据文件内容，编码后的格式
aGVsbG8saGl2ZQ==
aGVsbG8sd29ybGQ=
aGVsbG8saGFkb29w      
hive> select * from myfile_table;--使用自定义格式进行解码
OK
hello,hive
hello,world
hello,hadoop
Time taken: 0.117 seconds, Fetched: 3 row(s)

Parquet与ORC对比

Hive 文件格式

5.Parquet列式存储格式 （这部分完全转至:http://www.infoq.com/cn/articles/in-depth-analysis-of-parquet-column-storage-format/）

Parquet是面向分析型业务的列式存储格式，由Twitter和Cloudera合作开发，2015年5月从Apache的孵化器里毕业成为Apache顶级项目，最新的版本是1.8.0。

列式存储和行式存储相比有哪些优势呢？

  1. 可以跳过不符合条件的数据，只读取需要的数据，降低IO数据量。
  2. 压缩编码可以降低磁盘存储空间。由于同一列的数据类型是一样的，可以使用更高效的压缩编码（例如Run Length Encoding和Delta Encoding）进一步节约存储空间。
  3. 只读取需要的列，支持向量运算，能够获取更好的扫描性能。

当时Twitter的日增数据量达到压缩之后的100TB+，存储在HDFS上，工程师会使用多种计算框架（例如MapReduce, Hive, Pig等）对这些数据做分析和挖掘；日志结构是复杂的嵌套数据类型，例如一个典型的日志的schema有87列，嵌套了7层。所以需要设计一种列式存储格式，既能支持关系型数据（简单数据类型），又能支持复杂的嵌套类型的数据，同时能够适配多种数据处理框架。

关系型数据的列式存储，可以将每一列的值直接排列下来，不用引入其他的概念，也不会丢失数据。关系型数据的列式存储比较好理解，而嵌套类型数据的列存储则会遇到一些麻烦。如图1所示，我们把嵌套数据类型的一行叫做一个记录（record)，嵌套数据类型的特点是一个record中的column除了可以是Int, Long, String这样的原语（primitive）类型以外，还可以是List, Map, Set这样的复杂类型。在行式存储中一行的多列是连续的写在一起的，在列式存储中数据按列分开存储，例如可以只读取A.B.C这一列的数据而不去读A.E和A.B.D，那么如何根据读取出来的各个列的数据重构出一行记录呢？

Hive 文件格式

图1 行式存储和列式存储

Google的Dremel系统解决了这个问题，核心思想是使用“record shredding and assembly algorithm”来表示复杂的嵌套数据类型，同时辅以按列的高效压缩和编码技术，实现降低存储空间，提高IO效率，降低上层应用延迟。Parquet就是基于Dremel的数据模型和算法实现的。

Parquet适配多种计算框架

Parquet是语言无关的，而且不与任何一种数据处理框架绑定在一起，适配多种语言和组件，能够与Parquet配合的组件有：

查询引擎: Hive, Impala, Pig, Presto, Drill, Tajo, HAWQ, IBM Big SQL

计算框架: MapReduce, Spark, Cascading, Crunch, Scalding, Kite

数据模型: Avro, Thrift, Protocol Buffers, POJOs

那么Parquet是如何与这些组件协作的呢？这个可以通过图2来说明。数据从内存到Parquet文件或者反过来的过程主要由以下三个部分组成：

1, 存储格式(storage format)

parquet-format项目定义了Parquet内部的数据类型、存储格式等。

2, 对象模型转换器(object model converters)

这部分功能由parquet-mr项目来实现，主要完成外部对象模型与Parquet内部数据类型的映射。

3, 对象模型(object models)

对象模型可以简单理解为内存中的数据表示，Avro, Thrift, Protocol Buffers, Hive SerDe, Pig Tuple, Spark SQL InternalRow等这些都是对象模型。Parquet也提供了一个example object model 帮助大家理解。

例如parquet-mr项目里的parquet-pig项目就是负责把内存中的Pig Tuple序列化并按列存储成Parquet格式，以及反过来把Parquet文件的数据反序列化成Pig Tuple。

这里需要注意的是Avro, Thrift, Protocol Buffers都有他们自己的存储格式，但是Parquet并没有使用他们，而是使用了自己在parquet-format项目里定义的存储格式。所以如果你的应用使用了Avro等对象模型，这些数据序列化到磁盘还是使用的parquet-mr定义的转换器把他们转换成Parquet自己的存储格式。

Hive 文件格式

图2 Parquet项目的结构

Parquet数据模型

理解Parquet首先要理解这个列存储格式的数据模型。我们以一个下面这样的schema和数据为例来说明这个问题。

message AddressBook {
 required string owner;
 repeated string ownerPhoneNumbers;
 repeated group contacts {
   required string name;
   optional string phoneNumber;
 }
}

这个schema中每条记录表示一个人的AddressBook。有且只有一个owner，owner可以有0个或者多个ownerPhoneNumbers，owner可以有0个或者多个contacts。每个contact有且只有一个name，这个contact的phoneNumber可有可无。这个schema可以用图3的树结构来表示。

每个schema的结构是这样的：根叫做message，message包含多个fields。每个field包含三个属性：repetition, type, name。repetition可以是以下三种：required（出现1次），optional（出现0次或者1次），repeated（出现0次或者多次）。type可以是一个group或者一个primitive类型。

Parquet格式的数据类型没有复杂的Map, List, Set等，而是使用repeated fields 和 groups来表示。例如List和Set可以被表示成一个repeated field，Map可以表示成一个包含有key-value 对的repeated field，而且key是required的。

Hive 文件格式
Hive 文件格式

图3 AddressBook的树结构表示

Parquet文件的存储格式

那么如何把内存中每个AddressBook对象按照列式存储格式存储下来呢？

在Parquet格式的存储中，一个schema的树结构有几个叶子节点，实际的存储中就会有多少column。例如上面这个schema的数据存储实际上有四个column，如图4所示。

Hive 文件格式

图4 AddressBook实际存储的列

Parquet文件在磁盘上的分布情况如图5所示。所有的数据被水平切分成Row group，一个Row group包含这个Row group对应的区间内的所有列的column chunk。一个column chunk负责存储某一列的数据，这些数据是这一列的Repetition levels, Definition levels和values（详见后文）。一个column chunk是由Page组成的，Page是压缩和编码的单元，对数据模型来说是透明的。一个Parquet文件最后是Footer，存储了文件的元数据信息和统计信息。Row group是数据读写时候的缓存单元，所以推荐设置较大的Row group从而带来较大的并行度，当然也需要较大的内存空间作为代价。一般情况下推荐配置一个Row group大小1G，一个HDFS块大小1G，一个HDFS文件只含有一个块。

Hive 文件格式

图5 Parquet文件格式在磁盘的分布

拿我们的这个schema为例，在任何一个Row group内，会顺序存储四个column chunk。这四个column都是string类型。这个时候Parquet就需要把内存中的AddressBook对象映射到四个string类型的column中。如果读取磁盘上的4个column要能够恢复出AddressBook对象。这就用到了我们前面提到的 “record shredding and assembly algorithm”。

Striping/Assembly算法

对于嵌套数据类型，我们除了存储数据的value之外还需要两个变量Repetition Level(R), Definition Level(D) 才能存储其完整的信息用于序列化和反序列化嵌套数据类型。Repetition Level和 Definition Level可以说是为了支持嵌套类型而设计的，但是它同样适用于简单数据类型。在Parquet中我们只需定义和存储schema的叶子节点所在列的Repetition Level和Definition Level。

Definition Level

嵌套数据类型的特点是有些field可以是空的，也就是没有定义。如果一个field是定义的，那么它的所有的父节点都是被定义的。从根节点开始遍历，当某一个field的路径上的节点开始是空的时候我们记录下当前的深度作为这个field的Definition Level。如果一个field的Definition Level等于这个field的最大Definition Level就说明这个field是有数据的。对于required类型的field必须是有定义的，所以这个Definition Level是不需要的。在关系型数据中，optional类型的field被编码成0表示空和1表示非空（或者反之）。

Repetition Level

记录该field的值是在哪一个深度上重复的。只有repeated类型的field需要Repetition Level，optional 和 required类型的不需要。Repetition Level = 0 表示开始一个新的record。在关系型数据中，repetion level总是0。

下面用AddressBook的例子来说明Striping和assembly的过程。

对于每个column的最大的Repetion Level和 Definition Level如图6所示。

Hive 文件格式

图6 AddressBook的Max Definition Level和Max Repetition Level

下面这样两条record：

AddressBook {
 owner: "Julien Le Dem",
 ownerPhoneNumbers: "555 123 4567",
 ownerPhoneNumbers: "555 666 1337",
 contacts: {
   name: "Dmitriy Ryaboy",
   phoneNumber: "555 987 6543",
 },
 contacts: {
   name: "Chris Aniszczyk"
 }
}
AddressBook {
 owner: "A. Nonymous"
}

以contacts.phoneNumber这一列为例，"555 987 6543"这个contacts.phoneNumber的Definition Level是最大Definition Level=2。而如果一个contact没有phoneNumber，那么它的Definition Level就是1。如果连contact都没有，那么它的Definition Level就是0。

下面我们拿掉其他三个column只看contacts.phoneNumber这个column，把上面的两条record简化成下面的样子：

AddressBook {
 contacts: {
   phoneNumber: "555 987 6543"
 }
 contacts: {
 }
}
AddressBook {
}

这两条记录的序列化过程如图7所示：

Hive 文件格式
Hive 文件格式

图7 一条记录的序列化过程

如果我们要把这个column写到磁盘上，磁盘上会写入这样的数据（图8）：

Hive 文件格式

图8 一条记录的磁盘存储

注意：NULL实际上不会被存储，如果一个column value的Definition Level小于该column最大Definition Level的话，那么就表示这是一个空值。

下面是从磁盘上读取数据并反序列化成AddressBook对象的过程：

1，读取第一个三元组R=0, D=2, Value=”555 987 6543”

R=0 表示是一个新的record，要根据schema创建一个新的nested record直到Definition Level=2。

D=2 说明Definition Level=Max Definition Level，那么这个Value就是contacts.phoneNumber这一列的值，赋值操作contacts.phoneNumber=”555 987 6543”。

2，读取第二个三元组 R=1, D=1

R=1 表示不是一个新的record，是上一个record中一个新的contacts。

D=1 表示contacts定义了，但是contacts的下一个级别也就是phoneNumber没有被定义，所以创建一个空的contacts。

3，读取第三个三元组 R=0, D=0

R=0 表示一个新的record，根据schema创建一个新的nested record直到Definition Level=0，也就是创建一个AddressBook根节点。

可以看出在Parquet列式存储中，对于一个schema的所有叶子节点会被当成column存储，而且叶子节点一定是primitive类型的数据。对于这样一个primitive类型的数据会衍生出三个sub columns (R, D, Value)，也就是从逻辑上看除了数据本身以外会存储大量的Definition Level和Repetition Level。那么这些Definition Level和Repetition Level是否会带来额外的存储开销呢？实际上这部分额外的存储开销是可以忽略的。因为对于一个schema来说level都是有上限的，而且非repeated类型的field不需要Repetition Level，required类型的field不需要Definition Level，也可以缩短这个上限。例如对于Twitter的7层嵌套的schema来说，只需要3个bits就可以表示这两个Level了。

对于存储关系型的record，record中的元素都是非空的（NOT NULL in SQL）。Repetion Level和Definition Level都是0，所以这两个sub column就完全不需要存储了。所以在存储非嵌套类型的时候，Parquet格式也是一样高效的。

上面演示了一个column的写入和重构，那么在不同column之间是怎么跳转的呢，这里用到了有限状态机的知识，详细介绍可以参考Dremel。

数据压缩算法

列式存储给数据压缩也提供了更大的发挥空间，除了我们常见的snappy, gzip等压缩方法以外，由于列式存储同一列的数据类型是一致的，所以可以使用更多的压缩算法。

压缩算法 使用场景
Run Length Encoding 重复数据
Delta Encoding 有序数据集，例如timestamp，自动生成的ID，以及监控的各种metrics
Dictionary Encoding 小规模的数据集合，例如IP地址
Prefix Encoding Delta Encoding for strings

性能

Parquet列式存储带来的性能上的提高在业内已经得到了充分的认可，特别是当你们的表非常宽（column非常多）的时候，Parquet无论在资源利用率还是性能上都优势明显。具体的性能指标详见参考文档。

Spark已经将Parquet设为默认的文件存储格式，Cloudera投入了很多工程师到Impala+Parquet相关开发中，Hive/Pig都原生支持Parquet。Parquet现在为Twitter至少节省了1/3的存储空间，同时节省了大量的表扫描和反序列化的时间。这两方面直接反应就是节约成本和提高性能。

如果说HDFS是大数据时代文件系统的事实标准的话，Parquet就是大数据时代存储格式的事实标准。

Apache Parquet 最初的设计动机是存储嵌套式数据，比如Protocolbuffer，thrift，json等，将这类数据存储成列式格式，以方便对其高效压缩和编码，且使用更少的IO操作取出需要的数据，这也是Parquet相比于ORC的优势，它能够透明地将Protobuf和thrift类型的数据进行列式存储，在Protobuf和thrift被广泛使用的今天，与parquet进行集成，是一件非容易和自然的事情。 除了上述优势外，相比于ORC, Parquet没有太多其他可圈可点的地方，比如它不支持update操作（数据写成后不可修改），不支持ACID等。

6. Avro

Avro是一种用于支持数据密集型的二进制文件格式。它的文件格式更为紧凑，若要读取大量数据时，Avro能够提供更好的序列化和反序列化性能。并且Avro数据文件天生是带Schema定义的，所以它不需要开发者在API 级别实现自己的Writable对象。最近多个Hadoop 子项目都支持Avro数据格式，如Pig 、Hive、Flume、Sqoop和Hcatalog。

7.示例自定义输入格式：DualInputFormat；

总结：

数据仓库的特点：一次写入、多次读取，因此，整体来看，ORCFile相比其他格式具有较明显的优势。

  • TextFile 默认格式，加载速度最快，可以采用Gzip、bzip2等进行压缩，压缩后的文件无法split，即并行处理
  • SequenceFile 压缩率最低，查询速度一般，三种压缩格式NONE，RECORD，BLOCK
  • RCfile 压缩率最高，查询速度最快，数据加载最慢。

版权声明：本文为CSDN博主「weixin_34014277」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/weixin_34014277/article/details/92378615

数据库 json 大数据
上一篇: 常见的文件格式
下一篇: 数据库时间格式转换

继续阅读