前言

在上一篇文章中讲到数据源接入的两类方式：推（push）或者拉（pull），不管是采用哪种方式将数据源接入到数据处理系统中，大概率都会先将数据落地（存储），尤其是对于一些基于较大数据量的计算分析场景。

那么数据落地一般怎么落地呢？数据保存到什么样的存储介质中最为合适呢？纵观如此多的持久化存储技术，一般来说可以总结为3大类：1，文件系统；2，消息队列；3，数据库(DB)。

以上3大类涵盖了所有数据持久化存储需要的介质，那么究竟如何选择，就成了摆在架构师或者技术负责人面前的一道思考题。

任何一种存储介质都有其适用的场景，各有优劣，究竟如何选择，是比较考验选择者技术水平的。

下面以我的经验来对这个3种不同的存储介质进行展开说明。

一

1. 文件系统

这种存储介质是最简单也是最容易想到的，这里的文件系统又可以分为单机版的文件系统和分布式文件系统，具体说明如下图所示。

不管是哪种文件系统，对于数据来说都是持久化到磁盘，可以作为数据源的一个永久备份。

2. 消息队列

相较于文件系统，数据在消息队列上是没法永久性保存的（消息队列上的数据都有一个保存周期，过期就会删除），鉴于这个数据过期特性，消息队列则无法保存全量的数据源数据，对于消息队列的特点说明如下图所示：

消息队列是目前大数据处理领域炙手可热的技术组件，几乎每一个大型数据处理系统都有它的影子，尤其是kafka，已经成为消息队列的顶级明星。

3. 数据库

数据库作为数据落地的技术选型之一，其使用场景相较于上面两个应该是最少的了，数据库存在的本质是基于业务需求的数据结构存储，其核心需求之一就是为了基于业务需求的快速查询。对数据库的特点说明如图所示：

而之所以在这个位置用的少，原因在于：

1，相较于文件系统跟消息队列，数据写入最慢(因为要考虑索引、主键等因素)；

2，数据在写数据库前一般都需要做一定的预处理，而这部分工作一般会留给后续的数据处理来做；

3，在数据落地阶段，一般只保存原始数据，而非经过加工后的数据。

但是也并不排除一定不在这个阶段使用数据库，因为业务需求千奇百怪，谁又能保证呢。

接下来分析下每个技术选型各自适合的场景。

二

1. 什么时候用文件系统

文件系统最大的特点就是可以保存数据源的全量数据，但是呢，因为数据全部都保存在磁盘上且没有做任何数据读取的优化，因此其数据读取会非常的消耗磁盘IO，所以非常的缓慢，其读取流程如下图所示：

数据读取程序从磁盘中读取数据的大概过程，一共分为2步，其中第一步是最慢的，因为没有任何读取优化机制，且这部分在磁盘上属于随机读取，是效率最低的。那么哪些场景下会选择用文件系统呢：

1. 1, 因为读取效率低下，适合数据处理延迟较高的场景，比如数据仓库的离线分析(如HDFS、S3)和基于大数据量的批处理场景；

2. 2, 需要对数据源进行全量备份的场景，方便后续对数据重新计算；

3. 业务上没有时效要求，只想用最简单的方式将数据落地，不想给自己带来额外技术负担的场景。

2. 什么时候用消息队列

相比于文件系统，虽然消息队列的数据依然是保存在磁盘中的，但是它的数据读取效率却高出非常多，原因在于消息队列用了非常多的读写优化手段，以下就以使用率最高的kafka为例进行说明：

• 1, 分区设计模式：一份数据集可分散在多台机器上，程序可以分布式多机器并发读写，提供读写效率；

• 2, 利用Linux缓存页技术：为了避免直接读写磁盘效率低的特点，在数据读写磁盘前先读取或先写入系统的page cache，然后再择机flush到磁盘，大大提高数据的读取效率；

• 3, 顺序读写：无论是数据写入还是读取，消息队列都可以做到最低时间复杂度O(1)的操作，追加式写入以及顺序式读取都是效率最高的方式；

• 4, 零拷贝技术：一般普通外部进程通过网络接口读取数据会通过多个数据拷贝步骤才能到达网卡最终传输到用户进程中，但是采用零拷贝技术之后的消息队列，则可以省去中间一些不必要的数据拷贝流程，具体如下图所示：

• 采用selector多线程模式：满足多用户异步请求需求，能够允许多用户同时请求读写而不阻塞。

那么一般在什么场景下会使用消息队列呢？

1. 1, 实时性要求高：要求数据从产生到分析出结果必须在很短时间范围内完成，比如1分钟以内甚至10秒钟之内；

2. 2, 数据源具有源源不断的特点：数据源并不是以一个固定周期产生，而是遵循量小频率高的特点接入；

3. 3, 同一份数据需要被多次消费：系统存在多个业务处理模块需要读取同一份数据源，但是允许读取进度不一样，且读取进度(offset)可根据业务需要随时调整；

4. 4, 数据源流量既有高峰又有低谷：数据源并不总是以固定频率产生数据，比如像类似12306网站，高峰期时会存在特别大的流量，而低谷期流量则会非常少。利用消息队列，数据计算模块可以用一个比较固定的速度来消费数据，高峰期数据消费可能存在延迟，但是低谷期又可以追赶之前落下的数据。

3. 什么时候用数据库

数据库方案应该是3个方案中相对用的较少的一个，数据库具有如下几个特点：

• 1，数据库都是设计用来面向业务查询的，其数据结构特点都是面向业务，而非数据计算模块；

• 2，数据库的设计一般都有着比较复杂的处理逻辑和数据结构，其IO上限要远小于文件系统和消息队列，不太适合作为后续数据计算的数据源；

• 3，不管是用SQL数据库还是nosql数据库，因为存在索引的特点，势必导致数据写入比单纯的文件系统和消息队列慢很多，且花费的存储空间更大（因为还要保存索引数据）；

• 4，数据库本身是一个非常复杂的系统，其使用成本和运维成本均高于文件系统和消息队列，在能够满足业务需求情况下，技术选型越简单维护则越好。

因此，数据库作为数据源落地的次选方案，一般可能只会在以下几种情形才使用：

1. 1，数据源本身比较符合业务需要，不需要经过系统的ETL处理就可以直接对数据进行CRUD操作；

2. 2，技术团队只对数据库技术熟悉，对文件系统和消息队列完全不了解，为了快速推进项目只好用数据库方案。

当然，数据库中也有例外情况，那就是我们常用的hive，它经常在实际项目中被我们用做离线数据存储(数据落地)的首选方案，但我一直认为hive不能算是一个真正意义上的数据库，或者至少它不够【纯粹】。

（PS：本章内容因为我之前在知乎写过，部分配图找不到原版了，因此有几张图片是直接从知乎文章扒下来的）