分布式存储技术（下）：宽表存储与全文搜索引擎的架构原理、特性、优缺点解析

对于写密集型应用，每天写入量巨大，数据增长量无法预估，且对性能和可靠性要求非常高，普通关系型数据库无法满足其需求。对于全文搜索和数据分析这类对查询性能要求极高的场景也是如此。为了进一步满足上面两类场景的需求，有了宽表存储和搜索引擎技术，本文将对他们的架构、原理、优缺点做介绍。

— 宽表存储 —

宽表存储最早来自 Google 的 Bigtable 论文，最初的定义为：

A Bigtable is a sparse, distributed, persistent multidimensional sorted map. The map is indexed by a row key, column key, and a timestamp; each value in the map is an uninterpreted array of bytes.《Bigtable: A distributed storage system for structured data》

Bigtable 会把数据存储在若干个 Table（表）中，Table 中的每个 Cell（数据单元）的形式如下：Cell 内的数据由字节串（string）构成，使用行、列和时间戳三个维度进行定位。

图片来源于《Bigtable: A distributed storage system for structured data》

Bigtable 在存储数据时会按照 Cell 的 Row Key 对 Table 进行字典排序，并且将一个 Table 按 Row 切分成若干个相邻的 Tablet，并将 Tablet 分配到不同的 Tablet Server 上存储。如此一来，客户端查询较为接近的 Row Key 时 Cell 落在同一个 Tablet 上的概率也会更大，查询的效率也会更高。

Table 中的不同 Cell 可以保存同一份数据的多个版本，以时间戳进行区分。时间戳本质上为 64 位整数，可由 Bigtable 自动设定为数据写入的当前时间（微秒），也可由应用自行设定，但应用需要自行确保 Cell 间不会出现冲突。对于拥有相同 Row Key 和 Column Key 的 Cell，Bigtable 会按照时间戳降序进行排序，如此一来最新的数据便会被首先读取。

由于 Google Bigtable 解决了海量数据场景下并发检索与查询、高速日志写入等核心业务场景需求，工业界受其启发开发了一些项目，如 HBase、Cassandra 等，并统称其为 Wide Column Store（宽表存储，又称表格存储）。宽表存储可以无 schema 限制，表的字段可以自由扩展。一个数据表可以有无穷多的 column，并且每行可以有不同的 column，也允许每行有很多的空值，类似一个稀疏矩阵。一个列族（column family）存储经常被一起查询的相关数据。

当前 DB-Engine 中宽表 NoSQL 数据库的排名如下表，可以看到最受欢迎的主要是 Cassandra、HBase 和 Azure 上的 Cosmos DB。接下来我们将介绍一下 HBase 的情况。

HBase 是一个面向列的分布式 NoSQL 数据库，是 Google Bigtable 框架的开源实现，能够响应随机、实时的数据检索需求。HBase 主要的存储和处理对象是大宽表，存储模式可以兼容本地存储、HDFS 和 Amazon S3 等 Hadoop 支持的文件系统，相比于 RDBMS 有很强的线性扩展能力。HBase 通过采用基于 LSM 树的存储系统以保证稳定的数据写速率，同时利用其日志管理机制以及 HDFS 多副本机制确保数据库容错能力。通常的适用场景为：面向多版本、稀疏的、半结构化和结构化的数据高并发写入/查询的 OLTP 业务。

HBase 的数据模型由不同的逻辑概念构成，包括：表、行、行键、列、列族、单元、时间戳。

• 表（Table）：Table 是 HBase 中数据的组织形式，是列的集合，和传统数据库中表的意义类似，同时也能够涵盖列数据在不同时间戳下的更新记录。

• 列（Column）：是数据库中单独的数据项，每一个 Column 包含数据的一种类型。

• 列族（ColumnFamily）：HBase 中表的数据都是按照 ColumnFamily 分组，ColumnFamily 是一个或多个 HBase 表中相近类型列的聚合。HBase 将同一个 ColumnFamily 的数据放在一个文件中存储，可以起到类似于垂直分区的作用。查询时能减少不必要的扫描，增加查询速度。

• 行（Row）：Row 是 RowKey 和 ColumnFamily 的集合，一个 Row 中可以包括一个或多个 ColumnFamily。

• 行键（RowKey）：HBase 中的行数据以 RowKey 形式进行排序，具有主键的作用，在查询时 HBase 可以通过 RowKey 定位数据，Region 也是通过 RowKey 划分的。

• 时间戳（Timestamp）：Timestamp 是给定值的版本标识，和值同时写入 HBase 数据库。Timestamp 可以是任何类型的时间格式，对于每个 RowKey 来说可以有多个时间版本的记录更新。

片来源于《HBase: The Definitive Guide》

在 HBase 中，表按照 RowKey 被切分为多个 Regions 存储。每个 Region 是 HBase 数据管理的基本单位，Region 通过 RowKey 切分，具有类似水平范围分区的作用，数据得以分布于集群的各个节点，不同节点上的 Region 共同组合成表的整体逻辑视图，通过扩展 Region 可以提升容量。

片来源于《HBase: The Definitive Guide》Regions 由 HRegionServer 维护，HRegionServer 受到 HMaster 统一管理。HMaster 可以自动调整 HRegionServer 中的 Region 数量，这样就实现了存储数据的无限扩展。

图片来源于《HBase: The Definitive Guide》HBase 的技术架构如上图，主要的组件或服务包括：

• Client：Client 是整个 HBase 集群的访问入口，负责与 HMaster 通信，以进行集群管理类操作，或者与 HRegionServer 通信进行数据读写类操作。

• ZooKeeper：集群中每个节点的状态信息都会注册在 ZooKeeper，HMaster 通过 ZooKeeper 感知每个 HRegionServer 的健康状态。另外 HBase 允许启动多个 HMaster，ZooKeeper 可保证集群中只有一个 HMaser 在运行。

• HMaster：负责管理对数据表的 CRUD 操作，管理 HRegionServer 的负载均衡，负责新 Region 的分配；在 HRegionServer 故障停机时负责失效 HRegionServer 上的 Region 迁移。

• HRegionServer：一个节点对应一个 HRegionServer。负责接收 HMaster 分配的 Region,负责与 Client 通信并处理其管理的所有 Region 相关读/写请求。

• HStore：HStore 在 HBase 中负责数据存储功能，有 1 个 MemStore 和 0 个或更多的 StoreFiles。数据先写入内存 MemStore，刷写成 StoreFile(File 的封装），最后持久化到 HDFS，当查询某一列的时候只需要调出 HFDS 相应的 block 即可。

• HLog：日志管理与回回放，每个进入 MemStore 的操作都会记录在 HLog。

HBase 采用 LSM 作为底层存储结构。LSM 相对于 RDBMS 常采用的 B+树有更好的写速率。由于磁盘随机 IO 的速率比顺序 IO 的速率慢指数级，所以数据库的存储设计都尽量避免磁盘随机 IO。虽然 B+树会将同一个节点尽量存储在一个分页上，但是这样只在相对较小数据量的情况有效，大量随机写时节点会趋于分裂，磁盘随机读写概率提升。为了保证写速率，LSM 先写在内存，然后再顺序批量落入磁盘。顺序写设计使 LSM 相对于 B+树有更好的海量数据写性能，但是读取的时候需要写合并内存数据和磁盘的历史数据，因此读性能有一定牺牲。但同时，LSM 也可以通过将小集合并成大集合（合并），以及 Bloom Filter 等方式提高一定的读速。

图片来源于《HBase: The Definitive Guide》

HBase 与存储相关的结构包括 MemStore、HFile、WAL。MemStore 是一个能够将数据的随机写转化为顺序写的内存存储结构，数据在写入时会先写入 MemStore，直到内存存储容量无法继续存储数据时，再将数据存储转移在磁盘上。HFile 便是 HBase 数据最终写到磁盘上的文件数据结构，即 StoreFile 的底层保存格式。在 HBase 中一个 StoreFile 对应着一个 HFile，通常情况下 HFile 存储在 HDFS 之上的，因此能够保证数据完整性并提供分布式存储。WAL（Write-Ahead Log）负责提供高并发、持久化的日志存储和回放服务。HBase 发生的所有业务操作都会存储在 WAL 中，以提供灾难恢复。例如 MemStore 内存数据写入 HFlie 持久化时如果机器断电，可以通过 WAL 回放，而数据不会丢失。

— 全文搜索引擎 —

关系数据库以行记录的方式存储有固定格式数据，与之不同的是，搜索引擎会将数据以文档的形式存储，在物理上会是层次化结构或者树形结构。这个做法的好处是非常容易增加半结构化或者结构化数据的处理能力。目前搜索引擎比较有代表性的数据库有开源 Elasticsearch，国内星环科技有自研的搜索产品 Scope。在 DB Engine 的排名中，Elasticsearch 常年排名在前十以内，相较于 SQL 数据库，ES 提供了可扩展、近实时性的分布式搜索功能，支持将文本数据分割为多个部分交由集群节点进行存储和备份以提高检索速度并保证数据的完整性，支持自动化的负载均衡和应急处理以确保整个集群处于高可用状态。ES 适用于各种对文档等非结构化数据有处理需求的业务，如智能分词、全文检索、相关度排名等。

ES 定义了一套专有的存储和管理数据的要素和概念，最主要的为 Field、Document、Type 和 Index。Field 是 Elasticsearch 中最小的数据单位,与关系型数据库中的列相似，是一组具有相同数据类型的数据值的集合。Document 类似于关系型数据中行的概念，一个 Document 包含每一个 Field 中与之相应的数据值。Type 类似数据库中的表级别概念，而 Index 是 Elasticsearch 中最大的数据单位，与 SQL 的索引不同，ES 中 index 对应 SQL 中 schema 的概念。

在物理模型上，Elasticsearch 主要的概念包括 Cluster（集群）、Node（节点）和 Shard（分片）。其中节点指的是一个 Elasticsearch 的实例或者说 Java 进程，如果硬件资源比较充足，是可以在一个节点上运行多个实例的。Shard 是 ES 集群进行数据处理的最小单元，是 Lucene 索引的一个实例，每个 Index 由一个或多个节点上的 Shard 共同组成。Shard 分为 Primary Shard 和 Replica Shard，每一个 Document 都会存储在一个 Primary Shard 中，如果 Primary Shard 或所在节点发生故障时，Replica Shard 可以转为主 Shard 以保证数据的高可用；而在检索数据时，查询命令可以在备份 Shard 中进行以减轻主 Shard 的压力，进而提高了查询性能。

当向 Elasticsearch 写入数据时，Elasticsearch 根据文档标识符 ID 将文档分配到多个分片上，当查询数据时，Elasticsearch 会查询所有的分片并汇总结果。为了避免查询时部分分片查询失败影响结果的准确性，Elasticsearch 引入了路由功能。当数据写入时，通过路由将数据写入指定分片。当查询数据时，通过相同的路由指明在哪个分片将数据查出来。

凭借着底层 Lucene 倒排索引技术，Elasticsearch 在查询和搜索文本、日志类数据方面表现非常突出，几乎超过所有关系型数据库和其他基于 Lucene 改造的产品(如 Solr)，因此被广泛应用在日志分析、情报分析、知识检索等领域中，尤其是基于 Elastic Stack 构建的多个行业解决方案。但是 2020 年 Elastic 改变了其 license 模式，限制云厂商直接托管销售 Elasticsearch，业内尝试通过一些其他方式（如基于 Elasticsearch 5.7 版本开发的 OpenSearch）来绕过相关的 license 限制。

不过 ES 也有几个非常明显的架构不足之处，限制了其进一步拓展应用场景，包括：

• 不支持事务功能仅能支持数据的最终一致性，因此不能用于关键数据的存储和使用

• 分析能力偏弱如复杂的聚合能力偏弱

• 各个分片之间的高可用采用主从复制，可能存在数据脑裂问题

• 单个 Node 的处理数据容量还有待提升

• ES 的安全模块是商业化插件，大量的 ES 集群缺少合适的安全防护

正是有以上的架构不足之处，也给业内其他搜索引擎一些改进的方向，尤其是 ES 的安全性问题，目前在国内已经导致数起重大的数据安全泄露事件。星环科技在 2017 年开始研发 ES 的国产替代品，并于 2019 年发布了基于 Lucene 开发的分布式搜索引擎 Scope，采用了全新基于 Paxos 协议的高可用架构、支持跨数据中心的部署模式、内置原生安全功能、支持单个服务器多个 Node 实例等方式，极大地提升了搜索引擎的稳定性、可靠性和性能，在国内已经落地多个大型生产集群，单个集群服务器数量超过 500 节点。

— 小结—

本文介绍了宽表存储和搜索引擎技术的架构、原理、优缺点（现在各项技术发展比较快，可能存在技术描述跟最新技术发展情况不太一致的情况）。那么有了基础的数据存储管理，下一步是通过整合计算，获得所需结果，面对大数据量，如何实现高吞吐、低延迟、高扩展、支持容错，是分布式计算技术的关键，下一篇起，我们将介绍以 MapReduce 和 Spark 为代表的分布式计算技术。

【参考文献】【1】Chang F, Dean J, Ghemawat S, et al. Bigtable: A distributed storage system for structured data[J]. ACM Transactions on Computer Systems (TOCS), 2008, 26(2): 1-26.【2】Lars George，HBase: The Definitive Guid, 2011.