一、底层存储技术

伴随业务的发展壮大，很多公司积累了大量的业务数据和用户数据，数据时代和智能算法时代，为了让数据更好的创造出价值，大数据平台的建设工作也必然是提上日程。

构建大数据平台需要具备很多的条件，如对业务的深入理解、对业务和数据建模抽象、以及支撑业务模型的技术支撑建设。

我们下面主要聚焦大数据平台最核心的存储技术，下面只会介绍几种作者经过调研考察后，重点关注的几种类型存储数据库。

1. HBase (Nosql) 

hbase架构图

---

hbase多版本数据存储技术

优点：很成熟，久经考验，很多大公司都在用
缺点：运维成本高 但是有相关的部门在运维

2. Accumulo (Nosql)

Accumulo的是一个高度可扩展的结构化存储，基于谷歌的BigTable。Accumulo是用Java编写的，并在Hadoop分布式文件系统 （HDFS），这是流行的Apache Hadoop项目的一部分工作。Accumulo支持高效存储和检索的结构化数据，包括查询范围，并提供支持使用Accumulo表作为输入和输出的 MapReduce作业，另外据说美国NASA的棱镜计划，使用的就是Accumulo。

Accumulo数据存储模型

---

优点：

1 读写性能优越于HBase，读写性能是hbase的5倍以上 2  提供了数据的安全访问控制， 财务，薪资等数据

缺点: 用户少，文档和社区少

3. TIDB (NewSql)

TIDB架构图

优点： 读写性能还不错，分布式的存储和计算能力，比较完整的运维工具

缺点: 数据增大后的稳定性需要观察，重点关注region的自动rebalance，split，merge等问题

很多年以前，在ODF开源数据库大会的技术群里，咨询TIDB是否可以配合分布式SQL查询引擎Presto使用，其实TIDB最初设计目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。不过TIDB是否可以达到Presto的查询性能， OLAP实际业务场景的性能如何，作者并没有测试过，感兴趣的自己去做实验吧。

4. ES 文档型存储

无法使用sql执行引擎了，不能通过sql去处理

二、基于CAP理论的思考和选型

上面我们已经介绍了好多种存储DB，究竟选择哪种数据库，是需要有一定的理论支撑的，接下来我们基于CAP理论进行思考和选型的讨论。

首先我们需要先阐明什么是CAP理论，然后讨论我们选型时在一致性与可用性之间的折中与权衡。

CAP理论： 指的是在一个分布式系统中，或者更直接一点，对于分布式数据存储，Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性)，不能同时成立

一致性：是指对于每一次读操作，要么都能够读到最新写入的数据，要么错误。

可用性：是指对于每一次请求，都能够得到一个及时的、非错的响应，但是不保证请求的结果是基于最新写入的数据。

分区容错性: 是指由于节点之间的网络问题，即使一些消息对包或者延迟，整个系统能继续提供服务（提供一致性或者可用性）。

对于分布式系统，网络分区（network partition）这种情况是难以避免的，节点间的数据复制一定存在延迟，如果需要保证一致性（对所有读请求都能够读到最新写入的数据），那么势必在一定时间内是不可用的（不能读取），即牺牲了可用性，反之亦然。

在分布式系统中，计算是相对容易的，真正困难的是状态的维护。那么对于分布式存储或者说数据共享系统，数据的一致性保证也是比较困难的。对于传统的关系型数据库，优先考虑的是一致性而不是可用性，因此提出了事务的ACID特性。而对于许多分布式存储系统，则是更看重可用性而不是一致性，一致性通过BASE（Basically Available, Soft state, Eventual consistency）来保证。

上图展示了ACID与BASE的区别，BASE通过最终一致性来尽量保证服务的可用性，要注意的是ACID BASE只是一个度的问题，并不是对立的两个极端。

下面我们举一个具体的分布式数据库读写的例子来说明CAP中可能出现的问题。

如上图所示，N1，N2两个节点存储同一份数据V，当前的状态是V0。在节点N1上运行的是安全可靠的写算法A，在节点N2运行的是同样可靠的读算法B，即N1节点负责写操作，N2节点负责读操作。N1节点写入的数据也会自动向N2同步，同步的消息称之为M。如果N1，N2之间出现分区，那么就没法保证消息M在一定的时间内到达N2。

从事务的角度来看这个问题：

α这个事务由操作α1， α2组成，其中α1是写数据，α2是读数据。如果是单点，那么很容易保证α2能读到α1写入的数据。如果是分布式的情况的情况，除非能控制 α2的发生时间，否则无法保证 α2能读到 α1写入的数据，但任何的控制（比如阻塞，数据集中化等）要么破坏了分区容错性，要么损失了可用性。

到底是A（availability）重要还是C（consistency）重要，我们其实应该去根据公司实际的业务场景去考量的， 如果是支付、对账等资金系统，肯定是C（consistency）重要， 如果是微博、知乎等网站，个人认为A（availability）会更加的重要。

从收入目标以及合约规定来讲，系统可用性是首要目标，因而我们常规会使用缓存或者事后校核更新日志来优化系统的可用性。因此，当设计师选择可用性的时候，因为需要在分区结束后恢复被破坏的不变性约。实践中，大部分团体认为（位于单一地点的）数据中心内部是没有分区的，因此在单一数据中心之内可以选择CA；CAP理论出现之前，系统都默认这样的设计思路，包括传统数据库在内。

其实业内针对数据库的高可用也是有很多的解决方案的，比如Mysql集群的PXC解决方案，虽然有网路性能的木桶短板问题，但是写数据强一致，可以有效的避免脏堵，幻读等问题；

如TIDB使用的raft算法，可以使用复制状态机在服务器之间实时可靠地复制数据

TIDB Raft：数据使用行格式存储在多个Raft组中，以服务事务性查询。每个组由一个leader和followers组成。我们为每个组添加了一个learner角色，以异步复制来自leader的数据。这种方法开销低，并保持数据的一致性。复制给learner的数据被转换为基于列的格式。查询优化器被扩展为同时访问基于行和基于列的副本的物理计划。

再比如阿里的X-Paxos高性能分布式强一致Paxos独立基础库，看名称听上去就牛逼哄哄的，事实作者没有接触使用过......

巴拉巴拉讲了这么一堆， 无论是HBase、ES、Accumulo、TIDB、Mysql，抑或是其他的存储数据库，大家都可以基于自己公司的业务从C（consistency）、A（availability）、P（partition tolerance）这三个方面去考虑。

三、 分布式SQL查询引擎

1 SQL引擎数据分析评估

流行度

---

社区活跃度

****

单标查询

---

多表查询

2 SQL引擎特点比对

SQL引擎	特点
Presto	PB 级别的 SQL 引擎，并结合了底层 Hadoop 的扩展性，提供了完全符合 ANSI 标准的 SQL 接口， 和 ACID 一致性，又解决了大数据量和高并发情况下对扩展性的要求，Presto社区活跃度好，Hive的高性能替代品
SparkSQL	性能相对 MapReduce 有很大的提升，但前提是数据量能够在内存容量范围内，否则一旦数据量过大，性能会下降不少，目前对 SQL 的支持完整度也非常有限。比如子查询等支持还不完善。 不过进步很快，值得期待，比如 DataSource，不少人用了。
Hive	非常主流，性能很差，查询太慢，实时报表不太实时
Impala	Hive的高性能替代品 ，内存计算，对机器要求比价高
ClickHouse	适合宽表查询，查询性能极高

作者介绍： 互联网十年交易/支付/搜索等架构和研发经验，擅长架构设计百亿级流量系统和高并发性能调优，目前专注做卫星通信/卫星遥感的研发工作，努力拥抱商业航天的星辰大海。公众号：无量云巅