构建面向海量信息的大数据管理平台，其本质上是要实现一套可软件定义的数据中心来通过对下层的基础架构进行有效的管理（存储、网络、计算以及相关资源的调度、分配、虚拟化、容器化等）以满足上层的业务与应用需求，并通过软件的灵活性与敏捷性来实现高ROI（Return-on-Investment，投入产出比）。

此前，老孙在《谈云》系列和《解密大数据》的前几讲中，均提到过大数据与云计算之间相辅相成的关系，这一点也充分体现在它们两者的技术栈对应的关系上，下图所示。

图：云计算+大数据体系架构技术栈

大数据存储对应于云计算架构中的存储方式+存储媒介，大数据管理对应于基础设施、计算、云拓扑结构、IaaS以及PaaS层，大数据分析对应于云平台中的应用服务层，而大数据的应用则是云应用程序中的一大类，例如传统企业级应用、Web/HTML5类越来越多面向移动设备的应用、大数据应用等。

在云计算背景下的大数据应用，可以划分为构建于以下云之上的两大类：

·公有云
·企业混合云（兼有私有云、公有云特征）

在垂直技术栈（Vertical Technology Stack）的角度看，两者都自下而上分为：

·网络层
·存储层
·服务器层
·操作系统层
·大数据处理引擎层
·大数据中间件及服务层
·大数据应用层（如可视化、操控中心等）

它们提供的服务与应用无外乎有如下几类：

·传统的数据类服务的延展，如数据仓库、商务智能；
·新型的服务，如大数据存储、大数据流数据分析、无主机计算（ServerlessComputing），机器学习、云间数据迁移等，见下图。

图：大数据技术栈与应用：公有云、混合云

上面提到的大数据服务与应用中，值得一提的是无主机计算。

无主机计算是一种新型的公有（或混合）云服务，最为知名的亚马逊的AWS Lambda，其核心理念是颠覆了DevOps，用NoOps取而代之。NoOps顾名思义就是不需要担心运维的事情，从而极大地解放了程序员，同时企业也不需要负担任何基础架构运维的成本。AWS Lambda的特点就是让使用者不再需要事先部署服务器，而只需要把要执行的代码提交给Lambda后，以AWS庞大基础架构做后台支撑，以毫秒级的精细化计费来完成用户提交的任务的同时收取相当低廉（这一条在共享经济时代最重要！）的费用。

在本质上无主机计算摒弃了传统的以设备（服务器、网络、存储）为中心的计算模式，让用户应用聚焦于业务逻辑本身。通常在实现上采用容器化封装、面向服务的架构（SOA）、事件驱动的应用程序接口（event-driven API）等技术。这些技术最终带来的是更为廉价的计算资源与能力。特别是大数据处理，通常需要更多的基础架构及资源，随着无主机计算的发展，我们有理由相信更多的大数据应用会与之结合。

在大数据（即分布式系统）的管理、分析、处理中有一些基础的理论模型需要了解，最主要的是：

·BASE最终一致性模型
·ACID强一致性模型
·CAP理论

BASE指的是Basically Available（基本可用）、Soft-State（柔性状态）、Eventual Consistency（最终一致性）三个特性，它相对于传统的（单机）关系型数据库时代的ACID模型的Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）、Durability（持久性）四大特性。以数据库交易为例，要实现ACID最关键的部分是数据的一致性，通常的做法是通过locking（加锁）的方式，在一方对某数据读写的时候，其他方只能等待，2PL（Two-Phase Locking，两阶锁）是一种常见的加锁实现方法。这种方法的效率对于高频交易系统显然不太适宜，于是就有了多版本并发控制（MVCC或MCC，Multi-version Concurrency Control）策略，它通过为每个读写方提供了数据库当前状态的快照来提供操作隔离及数据一致性。在分布式交易系统中，如后面要提到的NewSQL类型数据库，实现ACID变得更加困难，一种实现方式是2PC（Two-Phase Commit，二阶提交）来保证分布式交易（事务）操作的原子性及一致性。有趣的是在英文中BASE还有碱的意思，而ACID是酸，看来前辈们在研究理论基础时在起名字上没少下功夫。

关于分布式系统，还有一个CAP理论需要关注。CAP（Consistency + Availability + Partition Tolerance）是大数据领域一个著名理论，确切地说是分布式计算机网络领域的一种假说（Conjecture）。最早由加州大学伯克利分校的计算机科学家同时也是后来2002年被Yahoo!收购的著名搜索公司Inktomi的联合创始人兼首席科学家Eric Brewer在1998—2000年期间提出；在2002年由MIT的两位学者论证并随后成为理论（Theorem）。所以这个理论又称为Brewer’s Theorem。

图：Eric Brew，美国工程院院士和ACM Fellow，是著名的分布式系统专家，32岁就拿到加州大学伯克利分校教授（个人网页），提出了分布系统中非常重要的CAP定理。他也是搜索技术先驱Inktomi（李彦宏曾经在这里任职）的联合创始人和首席科学家。（图片来源网络）

这个理论是有哲学高度的，不过两位MIT的学者据说是从比较“狭隘”（Narrower）的视角来论证的，所以该“理论”也受到了学术界与业界的连番挑战 – 最为常见的反对意见是说在分布式系统中CAP中的三点是无法做到同时满足的。然而，总有人会先吃螃蟹。最知名的当属2012年谷歌公司推出的Spanner系统，该系统在全球范围内的跨数据中心间实现了对CAP三大特性的同时满足，后来我们也称类似的系统为NewSQL，在后文中对此类系统展开论述。

图：Spanner是谷歌公司研发的、可扩展的、多版本、全球分布式、同步复制数据库。它支持外部一致性的分布式事务。（图片来源网络）

CAP指出：

一个分布式系统不可能同时保证一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance，又称作可扩展性）这三个要素。

换言之对于一个大型的分布式计算网络存储系统，可用性与可扩展性是首要保证的，那么唯一需要牺牲的只是一致性，对于绝大多数场景而言，只要达到最终一致性即可（非强一致性）。

所谓的最终一致性可以这么理解：强一致性在早期金融网络中要求当你付款给对方时，在对方收到钱后，你的账户要相应同步扣款，否则就会出现不可预知的结果。比如对方收到钱，你的账户却没有扣款（赚到了的感觉）；或者对方没收到，而你的钱被扣掉了（被坑了的感觉），这些都属于系统不能做到实时一致性的体现。

今天的金融系统绝大多数都是规模庞大的分布式系统，要求强一致性只可能会造成系统瓶颈，比如由一个数据库来保证交易的实时一致性，但是这样整个分布式系统的效率会变得低下……，因此弱一致性系统设计应运而生，这也是为什么你在进行银行转账、股票交易等操作时通常会有一些滞后（几秒钟到几分钟或者更长到几天）的交易确认；而对于金融系统来说，对账（Financial Reconciliation）是最重要的，它就是对规定时间内的所有交易来进行确认以保证每一笔交易的两边的进出是均衡的。

CAP理论还有很多容易被人误解的地方，比如到底一个分布式系统应该拥有哪一个、两个属性，抛开理论层面的争执，我们看到今天的大规模分布式系统的设计各有千秋。比如早期谷歌的GFS，就是满足了一致性与可用性却相对牺牲了分区容忍性；阿里巴巴的支付宝的后端为了保证交易的一致性，使用的是EMC的高端存储系统VMAX。阿里集团是“去IOE化”的倡导者。“去IOE”指的是弱化或者拆除IBM、Oracle与EMC公司的产品，这三家分别是计算、数据库与存储领域里面的巨头。（注：IOE经常被代指为在中国市场处于领导甚至垄断地位的国际巨头。）

前面我们提到过NewSQL类数据库中开始出现全面支持CAP三特性（一致性、可用性、分区容忍性）的能力。但是NewSQL是个非常笼统的概念，如果按照NoSQL来细分，还有至少5-6类数据库（或数仓，尽管中文语境下数仓的概念和英文语境下的Data Store是不同的，例如KV Store严格意义上讲不是数仓，也不是数据库，因为它要比前两者在接口、功能、可编程等方面简单得多，但是很多工程师都称Redis为键值数据库 — 这实际上是一种“误称”），例如：

KV-Store
列数据库、宽表数据库
文档数据库
图数据库
时序数据库等

所谓NewSQL，无非是上面一种或几种数据库的融合，无出其外。而是否还需要SQL化，这个是个见仁见智的问题，简单来说能向后去兼容SQL固然好，但是SQL的弊端在面向实际业务场景时已经是越来越严重了，例如SQL不具备递归能力，任何数据间关联的查询、深度穿透类的计算和查询，SQL的性能问题都会暴露无遗。因此，我们才会看到NoSQL/NewSQL应运而生，蓬勃发展。

下面我们以Ultipa Graph为例分享如何实现CAP-able的图数据库。

Ultipa实时图数据库采用HTAP-cluster架构来搭建分布式集群，其中（如下图所示）多节点间所形成的集群就称之为CAP-Cluster（CAP集群）。在高负载、高并发条件下，整个分布式集群依然以高可用（多实例负载均衡）、一致性（分布式共识）以及数据分区化存储的方式运作。

CAP并不能代表一套分布式系统的全部特征，还有一些重要的指标，例如HTAP能力。HTAP集群的设计理念就是在同一个分布式的集群内（每个集群由多个实例构成），不同的实例可能会完成不同的任务或承担不同类型的工作，例如TP类的实时交易性操作与AP类的偏重于批处理类的操作。在图数据库相关的大数据管理与分析场景中，客户（业务需求方）对于TP与AP融合的需求尤为突出，例如：

实时的数据的增删改查，这类面向元数据的操作都是典型的TP类操作
实时的关联路径查询，这类操作的复杂度远高于元数据操作，但是在很多场景下（风控、推荐、流动性风险识别、反欺诈、反洗钱、实施决策等）依然要求实时性（这种AP操作就是实时化AP）
更为复杂的图数据库上的操作，例如图算法、批量的（甚至全图的）K度邻居查询，这其中有一些操作可以以纯实时的方式实现，但是另外一部分则是需要以T+0甚至更长时间的操作来完成（经典TP类批处理操作）
HTAP集群的特点就是通过集群内部的调度，自行分配对应的计算与存储资源来实现上面所有的操作。从集群内部看来，不同的实例在完成不同类型的操作，但是在集群外部看来，这种操作的分配是动态、透明的。当任意（例如不超过50%个数的实例）实例出现下线情况时，整个系统依然保持着在线服务的状态（所谓CAP之可用性）。

然而，如果任意复杂度的TP或AP操作，能够通过算力、算法的提升而实现：
T+0 --> 纯实时
T+1 --> T+0 (或实时）
T+2 --> T+0 (或实时）

对于客户而言，商业上的意义是不言而喻的，前提是可以在TCO与ROI之间获得一个很好的平衡，例如更高的ROI和更低的TCO则堪称完美。

大数据的管理与分析的本质与云计算的本质并没有本质不同（这句话听起来很拗口？！），记住2点即可：

计算
存储
（optionally) 网络

其中，尤以计算与存储最为重要，无论是计算与存储分离还是存储靠近计算，最终的目标一定是通过算力的提升来获得对海量数据的更快、更好的处理与分析。在这个过程中，我们看到各种框架、各种理念、各种协议、各种算法、各种软硬件产品不断的推陈出新。AI的发展（算力算法与数据），也必然无法摆脱计算与存储，那些飘在应用层的解决方案，最终都会证明价值不大。这也是为什么大数据的管理与分析的核心竞争力，一定是某种数据库或数仓，以及它们之上的具备易用性的工具链条。当然，在这个过程中很多老的架构与系统必死无疑，比如Hadoop，业内有一些激进的同行甚至觉得Spark也不会一直长青。笔者以为，在图数据库领域，那些非原生存储或计算的系统显然也会被淘汰掉，例如用HBase或Hadoop做存储层，用Spark做计算层的解决方案，几乎没有可能满足客户的真实需求。

·文/ 老孙（孙宇熙：云计算、大数据、高性能存储与计算系统架构专家 ）
·END·