大数据培训 Hive 的数据存储与压缩

​

行存储与列存储

• 当今的数据处理大致可分为两大类，联机事务处理 OLTP(on-line transaction processing)联机分析处理 OLAP(On-Line Analytical Processing)=，OLTP 是传统关系型数据库的主要应用来执行一些基本的、日常的事务处理比如数据库记录的增、删、改、查等等而 OLAP 则是分布式数据库的主要应用它对实时性要求不高，但处理的数据量大通常应用于复杂的动态报表系统上

所以一般 OLTP 都是使用行式存储的，因为实时性要求高，而且有大量的更新操作，OLAP 都是使用列式存储的，因为实时性要求不高，主要是要求性能好

行存储的特点

• 查询满足条件的一整行数据的时，只需要找到其中一个值，其余的值都在相邻地方，所以此时行存储查询的速度更快。

• 传统的关系型数据库，如 Oracle、DB2、MySQL、SQL SERVER 等采用行式存储法(Row-based)，在基于行式存储的数据库中， 数据是按照行数据为基础逻辑存储单元进行存储的， 一行中的数据在存储介质中以连续存储形式存在。

• TEXTFILE 和 SEQUENCEFILE 的存储格式都是基于行存储的

• 这种存储格式比较方便进行 INSERT/UPDATE 操作，不足之处就是如果查询只涉及某几个列，它会把整行数据都读取出来，不能跳过不必要的列读取。当然数据比较少，一般没啥问题，如果数据量比较大就比较影响性能，还有就是由于每一行中，列的数据类型不一致，导致不容易获得一个极高的压缩比，也就是空间利用率不高

列存储的特点

• 查询时，只有涉及到的列才会被查询，不会把所有列都查询出来，即可以跳过不必要的列查询，在查询只需要少数几个字段的时候，能大大减少读取的数据量；因为每一列的数据都是存储在一起的，每个字段的数据类型一定是相同的，列式存储可以针对性的设计更好的设计压缩算法，高效的压缩率，不仅节省储存空间也节省计算内存和 CPU

• 不足之处是 INSERT/UPDATE 很麻烦或者不方便，不适合扫描小量的数据

• 列式存储(Column-based)是相对于行式存储来说的，新兴的 Hbase、HPVertica、EMCGreenplum 等分布式数据库均采用列式存储。在基于列式存储的数据库中， 数据是按照列为基础逻辑存储单元进行存储的，一列中的数据在存储介质中以连续存储形式存在。

​列存储的特点：因为每个字段的数据聚集存储，在查询只需要少数几个字段的时候，能大大减少读取的数据量；每个字段的数据类型一定是相同的，列式存储可以针对性的设计更好的设计压缩算法。ORC 和 PARQUET 是基于列式存储的_大数据培训。

举个例子吧不然还是太抽象，假设一个表有 10 亿行数据，按照列式存储的定义，应该先将某个字段的 10 亿条数据存储完之后，再存储其他字段。

常见的数据格式

Hive 支持一下几种存储格式，下面我们会对每种格式的特点进行简单介绍

1. Text File

2. SequenceFile

3. RCFile

4. Avro Files

5. ORC Files

6. Parquet

7. Custom INPUTFORMAT and OUTPUTFORMAT(用户自定义格式)

Hive 默认使用的实 Text File,也就是说当你建表的时候不指定文件的存储格式的时候，它就使用的就是 Text File,Hive 是支持指定默认存储格式的

<property>

<name>hive.default.fileformat</name>

<value>TextFile</value>

<description>

Expects one of [textfile, sequencefile, rcfile, orc, parquet].

Default file format for CREATE TABLE statement. Users can explicitly override it by CREATE TABLE ... STORED AS [FORMAT]

</description>

</property>

TextFile

存储方式：行存储

默认的存储格式，数据不做压缩，磁盘开销大，数据解析开销大。可结合 Gzip、Bzip2 使用(系统自动检查，执行查询时自动解压)，但使用这种方式，压缩后的文件不支持 split，Hive 不会对数据进行切分，从而无法对数据进行并行操作。

并且在反序列化过程中，必须逐个字符判断是不是分隔符和行结束符，因此反序列化开销会比 SequenceFile 高几十倍。

SequenceFile

SequenceFile 是 Hadoop API 提供的一种二进制文件支持，，存储方式为行存储，其具有使用方便、可分割、可压缩的特点。

压缩数据文件可以节省磁盘空间，但 Hadoop 中有些原生压缩文件的就是不支持分割，所以 Hadoop 猜提供了 SequenceFile 这种格式，支持分割的文件可以并行的有多个 mapper 程序处理大数据文件，大多数文件不支持可分割是因为这些文件只能从头开始读。

SequenceFile 支持三种压缩选择：NONE，RECORD，BLOCK。Record 压缩率低，一般建议使用 BLOCK 压缩，RECORD 是默认选项，通常 BLOCK 会带来较 RECORD 更好的压缩性能。

SequenceFile 的优势是文件和 hadoop api 中的 MapFile 是相互兼容的。

注：建表使用这个格式，导入数据时会直接把数据文件拷贝到 hdfs 上不进行处理。SequenceFile、RCFile、ORC 格式的表不能直接从本地文件导入数据，数据要先导入到 TextFile 格式的表中，然后再从 TextFile 表中用 insert 导入到 SequenceFile、RCFile 表中

RCfile

存储方式：数据按行分块，每块按列存储

Record Columnar 的缩写，是 Hadoop 中第一个列式存储格式。能够很好的压缩和快速的查询性能，但是不支持模式演进。是一种行列存储相结合的存储方式。

首先，其将数据按行分块，保同一行的数据位于同一个块上，避免读一个记录需要读取多个 block。其次，块数据列式存储，有利于数据压缩和快速的列存取，并且能跳过不必要的列读取

ORCfile

存储方式：数据按行分块 每块按照列存储(不是真正意义上的列存储，可以理解为分段列存储，你可以对照我们讲的那个例子来理解)

ORC 的全称是(Optimized Row Columnar)，ORC 文件格式是一种 Hadoop 生态圈中的列式存储格式，它的产生早在 2013 年初，最初产生自 Apache Hive，用于降低 Hadoop 数据存储空间和加速 Hive 查询速度。和 Parquet 类似，它并不是一个单纯的列式存储格式，仍然是首先根据行组分割整个表，在每一个行组内进行按列存储。

ORC 文件是自描述的，它的元数据使用 Protocol Buffers 序列化，并且文件中的数据尽可能的压缩以降低存储空间的消耗，目前也被 Spark SQL、Presto 等查询引擎支持，但是 Impala 对于 ORC 目前没有支持，仍然使用 Parquet 作为主要的列式存储格式。2015 年 ORC 项目被 Apache 项目基金会提升为 Apache 顶级项目。

ORC 文件特点是压缩快 快速列存取,是 rcfile 的改良版本，相比 RC 能够更好的压缩，能够更快的查询，支持各种复杂的数据类型，比如 datetime,decimal,以及复杂的 struct 是以二进制方式存储的，所以是不可以直接读取，ORC 文件也是自解析的，它包含许多的元数据，这些元数据都是同构 ProtoBuffer 进行序列化的。

需要注意的是 ORC 在读写时候需要消耗额外的 CPU 资源来压缩和解压缩，当然这部分的 CPU 消耗是非常少的。

格式

ORC 文件：保存在文件系统上的普通二进制文件，一个 ORC 文件中可以包含多个 stripe，每个 Orc 文件由 1 个或多个 stripe 组成，每个 stripe 一般为 HDFS 的块大小，每一个 stripe 包含多条记录，这些记录按照列进行独立存储，对应到 Parquet 中就是 row group 的概念。每个 Stripe 里有三部分组成，分别是 Index Data，Row Data，Stripe Footer；

stripe：一组行形成一个 stripe，每次读取文件是以行组为单位的，一般为 HDFS 的块大小，保存了每一列的索引和数据。

文件级元数据：包括文件的描述信息 PostScript、文件 meta 信息（包括整个文件的统计信息）、所有 stripe 的信息和文件 schema 信息。

stripe 元数据：保存 stripe 的位置、每一个列的在该 stripe 的统计信息以及所有的 stream 类型和位置。

row group：索引的最小单位，一个 stripe 中包含多个 row group，默认为 10000 个值组成。每次读取文件是以行组为单位的，一般为 HDFS 的块大小，保存了每一列的索引和数据。

在 ORC 文件中保存了三个层级的统计信息，分别为文件级别、stripe 级别和 row group 级别的，他们都可以用来根据 Search ARGuments（谓词下推条件）判断是否可以跳过某些数据，在统计信息中都包含成员数和是否有 null 值，并且对于不同类型的数据设置一些特定的统计信息。

file level：在 ORC 文件的末尾会记录文件级别的统计信息，会记录整个文件中 columns 的统计信息。这些信息主要用于查询的优化，也可以为一些简单的聚合查询比如 max, min, sum 输出结果。

**stripe level：**ORC 文件会保存每个字段 stripe 级别的统计信息，ORC reader 使用这些统计信息来确定对于一个查询语句来说，需要读入哪些 stripe 中的记录。比如说某个 stripe 的字段 max(a)=10，min(a)=3，那么当 where 条件为 a >10 或者 a <3 时，那么这个 stripe 中的所有记录在查询语句执行时不会被读入

row level： 为了进一步的避免读入不必要的数据，在逻辑上将一个 column 的 index 以一个给定的值(默认为 10000，可由参数配置)分割为多个 index 组。以 10000 条记录为一个组，对数据进行统计。Hive 查询引擎会将 where 条件中的约束传递给 ORC reader，这些 reader 根据组级别的统计信息，过滤掉不必要的数据。如果该值设置的太小，就会保存更多的统计信息，用户需要根据自己数据的特点权衡一个合理的值

数据访问

读取 ORC 文件是从尾部开始的，第一次读取 16KB 的大小，尽可能的将 Postscript 和 Footer 数据都读入内存。文件的最后一个字节保存着 PostScript 的长度，它的长度不会超过 256 字节，PostScript 中保存着整个文件的元数据信息，它包括文件的压缩格式、文件内部每一个压缩块的最大长度(每次分配内存的大小)、Footer 长度，以及一些版本信息。在 Postscript 和 Footer 之间存储着整个文件的统计信息(上图中未画出)，这部分的统计信息包括每一个 stripe 中每一列的信息，主要统计成员数、最大值、最小值、是否有空值等。

接下来读取文件的 Footer 信息，它包含了每一个 stripe 的长度和偏移量，该文件的 schema 信息(将 schema 树按照 schema 中的编号保存在数组中)、整个文件的统计信息以及每一个 row group 的行数。

处理 stripe 时首先从 Footer 中获取每一个 stripe 的其实位置和长度、每一个 stripe 的 Footer 数据(元数据，记录了 index 和 data 的的长度)，整个 striper 被分为 index 和 data 两部分，stripe 内部是按照 row group 进行分块的(每一个 row group 中多少条记录在文件的 Footer 中存储)，row group 内部按列存储。每一个 row group 由多个 stream 保存数据和索引信息。每一个 stream 的数据会根据该列的类型使用特定的压缩算法保存。在 ORC 中存在如下几种 stream 类型：

• PRESENT：每一个成员值在这个 stream 中保持一位(bit)用于标示该值是否为 NULL，通过它可以只记录部位 NULL 的值

• DATA：该列的中属于当前 stripe 的成员值。

• LENGTH：每一个成员的长度，这个是针对 string 类型的列才有的。

• DICTIONARY_DATA：对 string 类型数据编码之后字典的内容。

• SECONDARY：存储 Decimal、timestamp 类型的小数或者纳秒数等。

• ROW_INDEX：保存 stripe 中每一个 row group 的统计信息和每一个 row group 起始位置信息。

在初始化阶段获取全部的元数据之后，可以通过 includes 数组指定需要读取的列编号，它是一个 boolean 数组，如果不指定则读取全部的列，还可以通过传递 SearchArgument 参数指定过滤条件，根据元数据首先读取每一个 stripe 中的 index 信息，然后根据 index 中统计信息以及 SearchArgument 参数确定需要读取的 row group 编号，再根据 includes 数据决定需要从这些 row group 中读取的列，通过这两层的过滤需要读取的数据只是整个 stripe 多个小段的区间，然后 ORC 会尽可能合并多个离散的区间尽可能的减少 I/O 次数。然后再根据 index 中保存的下一个 row group 的位置信息调至该 stripe 中第一个需要读取的 row group 中。

使用 ORC 文件格式时，用户可以使用 HDFS 的每一个 block 存储 ORC 文件的一个 stripe。对于一个 ORC 文件来说，stripe 的大小一般需要设置得比 HDFS 的 block 小，如果不这样的话，一个 stripe 就会分别在 HDFS 的多个 block 上，当读取这种数据时就会发生远程读数据的行为。如果设置 stripe 的只保存在一个 block 上的话，如果当前 block 上的剩余空间不足以存储下一个 strpie，ORC 的 writer 接下来会将数据打散保存在 block 剩余的空间上，直到这个 block 存满为止。这样，下一个 stripe 又会从下一个 block 开始存储。

由于 ORC 中使用了更加精确的索引信息，使得在读取数据时可以指定从任意一行开始读取，更细粒度的统计信息使得读取 ORC 文件跳过整个 row group，ORC 默认会对任何一块数据和索引信息使用 ZLIB 压缩，因此 ORC 文件占用的存储空间也更小

Parquet

Parquet 能够很好的压缩，有很好的查询性能，支持有限的模式演进。但是写速度通常比较慢。这中文件格式主要是用在 Cloudera Impala 上面的。Parquet 文件是以二进制方式存储的，所以是不可以直接读取的，文件中包括该文件的数据和元数据，因此 Parquet 格式文件是自解析的。

Parquet 的设计方案，整体来看，基本照搬了 Dremel 中对嵌套数据结构的打平和重构算法，通过高效的数据打平和重建算法，实现按列存储（列组），进而对列数据引入更具针对性的编码和压缩方案，来降低存储代价，提升计算性能。想要了解这一算法逻辑的，可以看 Dremel 的论文：Dremel: Interactive Analysis of WebScaleDatasets

测试

准备测试数据

首先我们生成一份测试数据,这是生成数据的测试代码

public class ProduceTestData {

SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-mm-dd HH:MM:ss");

@Test

public void testRandomName() throws IOException {

Faker faker = new Faker(Locale.CHINA);

final Name name = faker.name();

final Address address = faker.address();

Number number = faker.number();

PhoneNumber phoneNumber = faker.phoneNumber();

BufferedWriter out = new BufferedWriter(new FileWriter("/Users/liuwenqiang/access.log"));

int num=0;

while (num<10000000){

int id = number.randomDigitNotZero();

String userName = name.name();

String time = simpleDateFormat.format(new Date(System.currentTimeMillis()));

String city = address.city();

String phonenum = phoneNumber.cellPhone();

StringBuilder stringBuilder = new StringBuilder();

stringBuilder.append(id);

stringBuilder.append("\t");

stringBuilder.append(userName);

stringBuilder.append("\t");

stringBuilder.append(city);

stringBuilder.append("\t");

stringBuilder.append(phonenum);

stringBuilder.append("\t");

stringBuilder.append(time);

out.write(stringBuilder.toString());

out.newLine();

}

out.flush();

out.close();

}

}

下面准备三张表，分别是 log_text、log_orc 和 log_parquet

create table log_text(

id int,

name string,

city string,

phone string,

acctime string)

row format delimited fields terminated by '\t'

stored as textfile;

LOAD DATA LOCAL INPATH '/Users/liuwenqiang/access.log' OVERWRITE INTO TABLE ods.log_text;

create table log_orc(

id int,

name string,

city string,

phone string,

acctime string)

row format delimited fields terminated by '\t'

stored as orc;

insert overwrite table ods.log_orc select * from ods.log_text;

create table log_parquet(

id int,

name string,

city string,

phone string,

acctime string)

row format delimited fields terminated by '\t'

stored as parquet;

insert overwrite table ods.log_parquet select * from ods.log_text;

所有关于 ORCFile 的参数都是在 Hive SQL 语句的 TBLPROPERTIES 字段里面出现

存储空间大小

text

orc

parquet

测试 SQL 执行效率

测试 SQL select city,count(1) as cnt from log_text group by city order by cnt desc;

text

orc

parquet

总结

1. 介绍了行式存储和列式存储的特点，以及适用场景

2. 介绍了 Hive 常见的存储格式，Parquet 和 ORC 都是二进制存储的，都是不可直接读取的，Parquet 和 ORC 都是 Apache 顶级项目，Parquet 不支持 ACID 不支持更新，ORC 支持有限的 ACID 和 更新

3. 我们简单对比了一下 Text、ORCfile 和 Parquet 的存储占用和查询性能，因为我们的查询比较简单加上数据本身不是很大，所以查询性能差异不是很大，但是占用空间存储的差异还是很大的

Hive 压缩

对于数据密集型任务，I/O 操作和网络数据传输需要花费相当长的时间才能完成。通过在 Hive 中启用压缩功能，我们可以提高 Hive 查询的性能，并节省 HDFS 集群上的存储空间。

HiveQL 语句最终都将转换成为 hadoop 中的 MapReduce job,而 MapReduce job 可以有对处理的数据进行压缩。

首先说明 mapreduce 哪些过程可以设置压缩：需要分析处理的数据在进入 map 前可以压缩，然后解压处理，map 处理完成后的输出可以压缩，这样可以减少网络 I/O(reduce 通常和 map 不在同一节点上)，reduce 拷贝压缩的数据后进行解压，处理完成后可以压缩存储在 hdfs 上，以减少磁盘占用量。

Hive 中间数据压缩

提交后，一个复杂的 Hive 查询通常会转换为一系列多阶段 MapReduce 作业，这些作业将通过 Hive 引擎进行链接以完成整个查询。因此，这里的 ‘中间输出’ 是指前一个 MapReduce 作业的输出，将会作为下一个 MapReduce 作业的输入数据。

可以通过使用 Hive Shell 中的 set 命令或者修改 hive-site.xml 配置文件来修改 hive.exec.compress.intermediate 属性，这样我们就可以在 Hive Intermediate 输出上启用压缩。

hive.exec.compress.intermediate：默认为 false，设置 true 为激活中间数据压缩功能，就是 MapReduce 的 shuffle 阶段对 mapper 产生中间压缩。可以使用 set 命令在 hive shell 中设置这些属性

set hive.exec.compress.intermediate=true

set mapred.map.output.compression.codec= org.apache.hadoop.io.compress.SnappyCodec

或者

set hive.exec.compress.intermediate=true

set mapred.map.output.compression.codec=com.hadoop.compression.lzo.LzoCodec

也可以在配置文件中进行配置

<property>

<name>hive.exec.compress.intermediate</name>

<value>true</value>

<description>

This controls whether intermediate files produced by Hive between multiple map-reduce jobs are compressed.

The compression codec and other options are determined from Hadoop config variables mapred.output.compress*

</description>

</property>

<property>

<name>hive.intermediate.compression.codec</name>

<value>org.apache.hadoop.io.compress.SnappyCodec</value>

<description/>

</property>

最终输出结果压缩

hive.exec.compress.output：用户可以对最终生成的 Hive 表的数据通常也需要压缩。该参数控制这一功能的激活与禁用，设置为 true 来声明将结果文件进行压缩。

mapred.output.compression.codec：将 hive.exec.compress.output 参数设置成 true 后，然后选择一个合适的编解码器，如选择 SnappyCodec。设置如下（两种压缩的编写方式是一样的）：

set hive.exec.compress.output=true

set mapred.output.compression.codec=org.apache.hadoop.io.compress.SnappyCodec

或者

set mapred.output.compress=true

set mapred.output.compression.codec=org.apache.hadoop.io.compress.LzopCodec

同样可以通过配置文件配置

<property>

<name>hive.exec.compress.output</name>

<value>true</value>

<description>

This controls whether the final outputs of a query (to a local/HDFS file or a Hive table) is compressed.

The compression codec and other options are determined from Hadoop config variables mapred.output.compress*

</description>

</property>

常见的压缩格式

Hive 支持的压缩格式有 bzip2、gzip、deflate、snappy、lzo 等。Hive 依赖 Hadoop 的压缩方法，所以 Hadoop 版本越高支持的压缩方法越多，可以在 $HADOOP_HOME/conf/core-site.xml 中进行配置：

<property>

<name>io.compression.codecs</name>

<value>org.apache.hadoop.io.compress.GzipCodec,org.apache.hadoop.io.compress.DefaultCodec,com.hadoop.compression.lzo.LzoCodec,com.hadoop.compression.lzo.LzopCodec,org.apache.hadoop.io.compress.BZip2Codec

</value>

</property>

<property>

<property>

<name>io.compression.codec.lzo.class</name>

<value>com.hadoop.compression.lzo.LzoCodec</value>

</property>

需要注意的是在我们在 hive 配置开启压缩之前，我们需要配置让 Hadoop 支持，因为 hive 开启压缩只是指明了使用哪一种压缩算法，具体的配置还是需要在 Hadoop 中配置

常见的压缩格式有：

其中压缩比 bzip2 > zlib > gzip > deflate > snappy > lzo > lz4，在不同的测试场景中，会有差异，这仅仅是一个大概的排名情况。bzip2、zlib、gzip、deflate 可以保证最小的压缩，但在运算中过于消耗时间。

从压缩性能上来看：lz4 > lzo > snappy > deflate > gzip > bzip2，其中 lz4、lzo、snappy 压缩和解压缩速度快，压缩比低。

所以一般在生产环境中，经常会采用 lz4、lzo、snappy 压缩，以保证运算效率。

对于使用 Gzip or Bzip2 压缩的文件我们是可以直接导入到 text 存储类型的表中的，hive 会自动帮我们完成数据的解压

CREATE TABLE raw (line STRING)

ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n';

LOAD DATA LOCAL INPATH '/tmp/weblogs/20090603-access.log.gz' INTO TABLE raw;

Native Libraries

Hadoop 由 Java 语言开发，所以压缩算法大多由 Java 实现；但有些压缩算法并不适合 Java 进行实现，会提供本地库 Native Libraries 补充支持。Native Libraries 除了自带 bzip2, lz4, snappy, zlib 压缩方法外，还可以自定义安装需要的功能库（snappy、lzo 等）进行扩展。而且使用本地库 Native Libraries 提供的压缩方式，性能上会有 50%左右的提升。

使用命令可以查看 native libraries 的加载情况：

hadoop checknative -a

完成对 Hive 表的压缩，有两种方式：配置 MapReduce 压缩、开启 Hive 表压缩功能。因为 Hive 会将 SQL 作业转换为 MapReduce 任务，所以直接对 MapReduce 进行压缩配置，可以达到压缩目的；当然为了方便起见，Hive 中的特定表支持压缩属性，自动完成压缩的功能。

Hive 中的可用压缩编解码器

要在 Hive 中启用压缩，首先我们需要找出 Hadoop 集群上可用的压缩编解码器，我们可以使用下面的 set 命令列出可用的压缩编解码器。

hive> set io.compression.codecs;

io.compression.codecs=

org.apache.hadoop.io.compress.GzipCodec,

org.apache.hadoop.io.compress.DefaultCodec,

org.apache.hadoop.io.compress.BZip2Codec,

org.apache.hadoop.io.compress.SnappyCodec,

com.hadoop.compression.lzo.LzoCodec,

com.hadoop.compression.lzo.LzopCodec

演示

首先我们创建一个未经压缩的表 tmp_no_compress

CREATE TABLE tmp_no_compress ROW FORMAT DELIMITED LINES TERMINATED BY '\n'

AS SELECT * FROM log_text;

我们看一下不设置压缩属性的输出

在 Hive Shell 中设置压缩属性：

set hive.exec.compress.output=true;

set mapreduce.output.fileoutputformat.compress=true;

set mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.GzipCodec;

set mapreduce.output.fileoutputformat.compress.type=BLOCK;

根据现有表 tmp_order_id 创建一个压缩后的表 tmp_order_id_compress:

CREATE TABLE tmp_compress ROW FORMAT DELIMITED LINES TERMINATED BY '\n'

AS SELECT * FROM log_text;

我们在看一下设置压缩属性后输出:

总结

1. 数据压缩可以发生在哪些阶段 1 输入数据可以压缩后的数据 2 中间的数据可以压缩 3 输出的数据可以压缩

2. hive 仅仅是配置了开启压缩和使用哪种压缩方式，真正的配置是在 hadoop 中配置的，而数据的压缩是在 MapReduce 中发生的

3. 对于数据密集型任务，I/O 操作和网络数据传输需要花费相当长的时间才能完成。通过在 Hive 中启用压缩功能，我们可以提高 Hive 查询的性能，并节省 HDFS 集群上的存储空间。

文章来源于大鱼的数据人生

​