存算分离，现在已经成为云原生数据库的标配， 开始大规模流行。存算分离后， 进一步使计算单元和存储单元解耦，每个单元可以实现单独的动态扩缩容，并且可以通过冗余配置，实现对单点故障的容忍度， 可以说是近年来数据库市场上的一大进步。
作者 | 祁国辉
责编 | 韩 楠
纵观历史， 随着IT技术的发展， 到底是存算一体还是存算分离， 其实反复过很多次，让我们来简单回顾一下，数据库历史上几次大的架构变更。希望可以帮助大家按照技术发展脉络，来加深对技术原理和用户收益的理解。
第一次存算分离
最早版本的数据库，即网状数据库管理系统（DBMS），由通用电气公司1961年开发成功，其IDS（Integrated DataStore，集成数据存储）是世界上第一个网状DBMS，也是第一个DBMS。但是它只能运行于通用电气的主机上，且数据库只有一个文件，所有的表必须通过手工编码生成、存储和计算是紧密耦合在一起的。
这一点从它的名字就可以看出来，集成数据存储（IntegratedData Store，IDS）。
而之后的很长时间，数据库都是属于高端应用，和各种大型机、中型机紧密绑定在一起，典型的IBM大型机（(MainFrame），老牌IT人都熟悉的System/360， 通过编程访问内部的各种数据库， 后来大家熟悉的DB2， 也是最早运行在这个平台上， 借助当时超强的计算能力， 在全球各种大型金融机构， 大型科研实验室和大型企业独领风骚， 占据了领导地位。
IBM当时在计算机领域无愧它“蓝色巨人”的称号， 除了响当当的产品之外， 还有大量的精英在其中对最新科技进行研究， 对数据库影响最大的几位大神都在IBM供职， 包括提出关系型数据库模型的Codd博士， 在此基础上发扬光大的 C.J.Date和Jim Gray。可以说DB2 在整个数据库历史上扮演了一个很重要的承上启下的作用。
当然也不得不提另外一位传奇人物， 就是Oracle的创始人之一，Larry Ellison， 自1977年创立SDL， 1982年更名为Oracle， 然后迅速借助小型机的快速发展，迅速占领了商用数据库的第一把交椅， 直至今日， DB Engine上Oracle仍占据榜首， 数十年未动摇。
因为小型机的快速发展，计算机市场出现群雄争霸的局面， 而在Unix 系统开始大行其道之后， 市面上能够提供unix主机的企业越来越多， 除了IBM， 还有HP、Compaq、富士通、Sun。而几乎所有的Unix主机都会连接独立的存储服务器，来实现第一次的存储和计算的分离。
在这次的存算分离当中， 最重要的支撑技术主要包括成熟的网络组网技术，以及成熟的存储网络技术，当然Oracle自己的杀手级技术缓存融合，也起到很大的作用。
那么看一下用户得到的好处在哪里？
• 增强了系统的伸缩性， 用户可以独立增加数据库服务器来提升处理能力，增加存储服务器来扩大数据库容量。
• 增强了系统的容错性，在这种分离架构下，可以通过冗余配置来防止任何一个环节出现单点故障， 增强了数据库系统的持续服务能力。
内存融合技术 则是在两个计算节点间 共享对方节点的内存数据， 来减少磁盘读取带来的IO， 从而提高性能。
缓存融合技术允许不同RAC节点间 通过高速内网共享各节点数据库实例内部缓存的数据块，缓存的数据块直接从一个节点的共享内存传递到其他节点的共享内存。这样对于最新的数据块， 就可以直接访问其他节点的缓存， 而不必等待缓存写入磁盘之后再从磁盘读取， 从而使得多个节点之间可以高效率地协同工作。
为了降低存取远端内存时的主机消耗， Oracle 还使用了专用的基于RDMA技术的RDS协议， 可以直接绕开CPU， 直接实现远程内存的直接读取，进一步提升访问效率。
海量数据催生的存算一体
时间进入本世纪， 随着用户数据的快速膨胀， 用户对海量数据的分析需求越来越明显， 各行各业都在搭建自己的数据仓库和商业智能系统， 这时用户面临的最大挑战第一是成本， 第二是性能。
因为传统Unix主机和高端存储价格高居不下， 所以想要搭建一个用于决策支持的数据仓库系统， 在硬件和软件license上就是一笔不小的投资。另外可能耗费巨资搭建的系统， 在做海量数据统计汇总的时候，比老黄牛还慢， 厂家分析过之后， 诊断结果：磁盘转速不够， 网络传输不够，CPU处理能力不够。总而言之， 系统需要扩容。
究其根本原因， 还是在IO， 因为计算单元处理数据， 但是它不存储数据， 所有的数据要从存储中取， 而存储在取数据的时候， 都是一个数据块一个数据块来取， 根本没法判断这个块中哪些数据是计算单元需要的。在传统行存储的场景， 一个决策查询可能只需要几个字段， 但是必须把所有数据都拿到计算单元， 由计算单元处理/判断之后再丢弃。
浪费了大量的IO， 另外由于计算单元内存不够， 再大表连接的时候， 出现大量的临时数据， 这些临时数据还需要在存储中临时存放， 需要的时候再拿出来， 这就又造成了大量的资源浪费。
所以这个时候就自然催生出新的架构， 普遍的原理是OLTP系统中每次操作都是小数据量， 这种场景是移动数据到计算；而OLAP系统中，每次都会涉及大量数据处理， 所以要减少网络传输， 这时候应该是移动计算到数据。这个描述有点抽象， 但是大概意思就是海量数据首先在本地进行初步加工， 减少数据量之后，再去参与后继计算，这样IO和算力都得到节省， 自然性能就上去了。
这个时候的玩家， 包括来自大厂的TD 和DB2， 也包括后来居上的开源MPP产品GreenPlum，还有国内的老牌数据库厂商南大通用Gbase， 以GP为例， 示例如下：
此阶段技术核心关注在减少网络间传输的IO， 一方面通过列式存储， 来支持分析系统中按列统计的习惯， 每次查询只需要取需要的列就可以， 减少无谓的IO， 同时利用各种索引技术， 加快数据定位和存取的效率。另外通过闪存技术的高速发展， 利用高速闪存还可以进一步提升系统的性能。
而之后盛行的Hadoop架构， 也是属于利用本地磁盘通过搭建分布式文件系统，来实现海量数据的处理。开源的Hadoop架构发展迅猛， 不断有新的技术加入，大大催生了数据仓库领域的技术发展。衍生出很多非常亮眼的技术， 比如Hive、Impala、Presto、Spark等等。
不过MPP虽然让更多的人能够以较低的成本搭建海量数据仓库， 随着应用的深入，也暴露出几个问题：
• 计算存储紧耦合， 提升了计算效能， 但是在系统容量扩容的时候， 需要对所有节点上的数据进行重新分布， 而这个时间相对较长， 有可能会影响业务， 所以在一些业务比较繁忙的客户场景中， 一般智能用新建集群的方式来进行容量扩容。
• 因为开启了大规模并行， 所有的任务都会启动并行计算，启动后计算任务会分布到集群中的每个节点， 那么集群并发能力的上限， 并不取决于集群大小， 而是取决于集群中配置最低的那一台机器， 这台机器能支持多少任务并行， 就代表整个集群能支持多少并行。
• 配置弹性不足， 因为上述原因， 为了能够支撑企业业务高峰期的业务， 必须把整个集群配置到能符合业务高峰期的规模， 而在平时， 机器闲置率就很高， 导致投资浪费。
云时代带来的新一代存算分离
随着公有云的快速发展， 按需付费的概念逐步深入人心，对大规模数据的分析也要求能做到按需供给，那么传统MPP这种存算一体的紧耦合架构，就没法满足用户的需求了。另外， 网络技术和存储技术也飞速发展， 这时就自然带来新一代的云原生数据库的存算分离架构， 把数据库技术向前推进了一大步。
以业界最有名的Snowflake公司为例，创立Snowflake之前，Benoit Dageville和Thierry Cruanes在甲骨文做了十多年数据工程师，后来他们决定在云上创建数仓，联合另外一位创始人Marcin Żukowski， 共同创建了Snowflake。
为了更好地利用云上的资源，他们首先把存储和计算再次分离，把数据以大量分区的方式存储在共享的对象存储中，存储中的数据按列保存，而中间的计算层， 也通过无状态的虚拟数据仓库来动态拉起和销毁， 来实现用户不同workload的灵活调度和计费。目前已经成为云原生数仓的标准范本。
下面简单看一看Snowflake的技术架构：
Snowflake内核组件从底向上可以分为三个层次：
- 数据存储层。Snowflake的数据存储是构建在Amazon S3对象存储上，主要用来存储表数据和查询结果。
- 计算层-虚拟仓库。虚拟仓库构建在Amazon EC2虚拟机组成的弹性集群之上，负责执行用户的查询请求。
- 调度云服务层。云服务组件包括并发访问控制、基础设施管理、优化器、事务管理、安全管理、元数据管理，其中元数据包含schema信息、表信息、权限认证信息、秘钥、统计信息。
在这个架构下， 不同的workload可以随时通过创建不同的虚拟仓库来实现计算的灵活调配， 而每次计算的时候， 计算层通过网络直接从存储层获得数据，然后在虚拟数据仓库中进行计算， 负载比较中的workload可以创建较大的虚拟仓库， 而普通查询可以创建较小的虚拟仓库，用户还可以通过调整虚拟仓库中单节点CPU和节点个数来平衡计算复杂性和并发性。
虚拟仓库之间，通过占用不同的硬件节点或者计算层中的资源调度来实现隔离。因为整个虚拟仓库的无状态， 所以用户可以随时创建和销毁虚拟仓库， 当然也意味着计算层的可以通过增加EC2的台数，来实现计算层的横向扩展。
同时， 由于存储层也已经完成了与计算层的解耦， 所以存储层也可以随时按需进行横向扩展， 而无需停机做数据分布。
◆ 技术优化手段
我们都知道， 存算分离架构，提高了系统的灵活性， 可以实现计算能力和存储能力的动态扩缩容，无需按照业务峰值来搭建系统， 但是也带来了大量数据需要在存储层和计算层之间传输的问题。
- 网络加速
好在，这么多年的存储，网络技术飞速发展， 能很好地满足这些需求， 同时新一代云数仓也从不同的地方做出优化，来提升效率。一般而言， 有两个方向：
第一就是通过各种软件的优化，减少网络传输；
第二，就是加大网络吞吐能力，实现网络提速。
目前的高速低延迟网络，比如ROCE等数据传输技术， 数据中心内部的高速互联网路等技术， 可以大大加快存储层到计算层的数据传输效率。
- 本地缓存
和Oracle的思路类似， 计算存储分离架构中， 还有一个环节就是数据缓存，如果每次数据访问都必须访问磁盘， 那么系统性能就会大打折扣， 所以在snowflake的虚拟仓库层， 也是会利用cache来进行数据的缓存。
- 存储优化
另外，在目前大多数的云上数仓解决方案中， 都会更加强化Metadata的作用， 对于一些基本的sum、Max、min等操作， 可以直接从metadata中返回结果， 不需要产生磁盘IO。此外在存储格式上， 类似ORC、Parquet等存储模式，利用列存和SIMD技术， 实现一次IO，返回更多有效数据；同时启用多种索引技术， 使得查询定位更加快捷。
思考与未来展望
展望将来， 云原生分布式数据库的高速发展，必然带来计算、存储的分离，“存算分离”是当前网络技术发展和社会经济进步的时代产物，是最适合当前时代发展需求的一种架构。拥抱云原生，按需付费的云数仓模式会持续走强，而在中国，也会走出公有云、私有云共同繁荣的未来。
▼
作者介绍
祁国辉
前 Oracle 云平台事业部电信行业技术总监
现就职于杭州石原子科技有限公司
【作者介绍】网名"atiger"，前 Oracle 云平台事业部电信行业技术总监。拥有超过25年数据库和数据仓库HK经验。曾创办著名数据仓库网站：www.dwway.com (数据仓库之路）。
StoneDB 2.0 云原生分布式实时 HTAP 架构详细设计以 RFC 形式持续进行，欢迎大家关注我们最新进展，更欢迎给我们开源协作的模式和方法提出改进意见，一起通过开源的方式共建 StoneDB ~
https://github.com/stoneatom/stonedb/issues/436
StoneDB 开源仓库
https://github.com/stoneatom/stonedb
END
标签：存储,计算,数据库,技术,VS,StoneDB,数据,存算 From： https://blog.51cto.com/u_15722181/5968724