云上应用系统数据存储架构演进
一 前言
应用为主体：常见的数据架构都是以『应用』为主体，数据主要产生自应用。数据架构围绕业务来设计，通常是先定义业务模型后设计业务流程。由于业务之间区分度很大，每个业务都有截然不同的业务模型，所以数据系统需要具备高度『抽象』的能力，所以通常会选择关系型数据库这类抽象能力强的组件作为核心存储。 数据为主体：这类数据系统通常围绕『特定类型数据』进行构建，比如说围绕云原生监控数据设计的以 Prometheus 为核心的监控数据系统，再比如围绕日志数据分析设计的 ELK 数据系统。这类数据系统的设计过程通常是围绕数据的收集、存储、处理、查询和分析等环节来设计整套数据系统，数据具备统一的『具象』的模型。不同的场景有不同的数据系统，当某个场景具备通用性以及得到一定规模的应用，通常在开源界会诞生一套成熟的、完整的解决方案，比如说云原生 Prometheus、ELK、Hadoop 等。
二 应用系统数据架构
1 传统数据架构（单一系统）
LAMP 架构
如何进行扩展
Scale-up vs Scale-out
Scale-up 即直接提升机器的配置规格，是最直接的扩展手段，计算和存储均可通过 Scale-up 的方式来进行扩展，但扩展空间有限，相对成本较高。Scale-out 即增加更多的机器进来，是相对成本更低、更灵活的手段，但需要相关组件具备能 Scale-out 的能力。
存储和计算分离
存储和计算是两个不同维度的资源，如果强绑定会极大限制扩展性。对数据系统来说，应用节点和存储节点分离就是应用了存储计算分离的设计思想，让应用和存储都能独立扩展。
存储 Scale-out
通常采用数据分片技术，将数据分散到多台机器上。
计算 Scale-out
基于状态路由计算：通常用于状态迁移代价大的数据架构，比如数据库的分库分表。分库分表的扩展需要进行数据复制，所以通常需要提前规划，根据数据所在分片来路由计算。
基于计算复制状态：如果状态能非常灵活的复制或者是共享，那可基于计算来复制状态，是一种更灵活的计算扩展架构。比如说基于共享存储的大数据计算架构，可灵活调度任意计算节点对数据进行处理。
无状态计算：计算不依赖任何状态，可以发生在任意节点上，所以计算节点可非常容易实现 Scale-out，但需要解决计算调度问题。常见 Web 应用中的 LoadBalancer 后置一堆 Web Server 就是一个简单的无状态计算扩展架构。
有状态计算：计算依赖状态，计算的扩展依赖状态的迁移。如果状态不可迁移，那计算的扩展只能采取 Scale-up 的方式。如果状态可迁移，那计算就可实现 Scale-out，此时计算的可扩展性依赖于状态迁移的灵活性。对于可 Scale-out 的计算我们分为两类实现方式，分别是：
可扩展的传统数据架构
存储侧扩展灵活性差，扩展成本较高：计算侧通常是无状态计算节点，扩展相对灵活。但存储侧的扩展需要进行数据复制迁移，扩展周期长且灵活性差。同时 MySQL 的分库分表每次扩展需要双倍资源，成本也较高。
单一存储系统，提供的能力有限：MySQL 作为关系模型数据库，在业务模型抽象上提供极强的抽象能力，所以可以说是一个万能存储。在互联网早期应用负载不高的情况下，MySQL 是最优选择，且已经拥有了成熟的扩展方案。但是随着应用场景和负载不断变化，MySQL 还是难以承载。
存储成本高：简单来说，关系数据库是结构化数据存储单位成本最高的存储系统。
如何解决存储侧扩展问题
2 现代数据架构（多样化系统）
定义问题，分而治之
流量卸载：承载和抵御 MySQL 的部分读写流量，让 MySQL 有更多资源进行事务处理。由于读和写依赖 MySQL 内数据，所以在卸载流量的同时还会复制全部或者部分数据。 数据卸载：MySQL 内部分数据会用于事务处理，而部分数据仅存储和查询。不参与事务处理的数据可卸载，来降低表的存储量，对降成本和减负载都是有极大好处的。
选择合适的存储组件
1）根据场景定义需求
SLA 要求逐步从高到底，在线系统对稳定性要求极高，而后台系统相对来说要求可放低。 从 TP 逐步转向 AP，TP 对访问延迟要求更高，而 AP 对分析能力要求更高。 数据的更新频率逐步降低，逐步归档为不可变数据，所以很多离线系统都是基于数据的不可变性来做存储和计算优化。 存储成本逐步降低，数据规模逐步增大。
2）存储组件的种类和差异
数据模型和查询语言：这两个点仍然是不同数据库最显著的区别。关系模型、文档模型和宽表模型是相对抽象的模型，而类似时序模型和图模型等其他非关系模型是相对具象的模型。抽象模型表达力更强，而具象模型更贴近具体场景。
SQL vs NoSQL：SQL 类更适合事务处理，包含开源或商业关系数据库；NoSQL 类更适合非事务数据处理，基本是以开源为主；场景使用上可以与 SQL 类配合使用，提供流量卸载和存储卸载；另外 NoSQL 类更多是具象模型，贴近场景而生。
数据库 vs 数据仓库：数据仓库更偏离线数据分析，提供更大规模存储，但是在 SLA 和稳定性方面相比数据库略差。
云托管 vs 云原生：云原生的本质是利用云上池化资源来实现更强的弹性，所以简单把一个开源软件托管在云上，并不能称之为云原生。云原生带来的优势是更低使用成本、更低运维成本、更灵活的数据流转以及更弹性的架构。
合理的进行组合
1）派生数据架构
主存储：数据产生自业务或者是计算，通常为数据首先落地的存储。在应用系统数据架构中，MySQL 就是主存储。
辅存储：数据主要来自主存储的数据同步与复制，辅存储是主存储的某个视图，通常面向数据查询、检索和分析做优化。在应用系统数据架构中，承担流量卸载或存储卸载的存储组件，就是辅存储。
应用层多写：这是实现最简单、依赖最少的一种实现方式，通常采取的方式是在应用代码中先向主存储写数据，后向辅存储写数据。这种方式不是很严谨，通常用在对数据可靠性要求不是很高的场景。因为存在的问题有很多，一是很难保证主与辅之间的数据一致性，无法处理数据写入失效问题；二是数据写入的消耗堆积在应用层，加重应用层的代码复杂度和计算负担，不是一种解耦很好的架构；三是扩展性较差，数据同步逻辑固化在代码中，比较难灵活添加辅存储。
异步队列复制：这是目前被应用比较广的架构，应用层将派生数据的写入通过队列来异步化和解耦。这种架构下可将主存储和辅存储的数据写入都异步化，也可仅将辅存储的数据写入异步化。第一种方式必须接受主存储可异步写入，否则只能采取第二种方式。而如果采用第二种方式的话，也会遇到和上一种『应用层多写』方案类似的问题，应用层也是多写，只不过是写主存储与队列，队列来解决多个辅存储的写入和扩展性问题。
CDC（Change Data Capture）技术：这种架构下数据写入主存储后会由主存储再向辅存储进行同步，对应用层是最友好的，只需要与主存储打交道。主存储到辅存储的数据同步，则可以再利用异步队列复制技术来做。不过这种方案对主存储的能力有很高的要求，必须要求主存储能支持 CDC 技术。
现代应用系统数据架构
由多存储组件构成，每个存储组件各司其职： MySQL：承载事务处理，为整个数据架构的主存储，其余组件承担流量卸载和存储卸载的职责。 Redis：作为 MySQL 的查询结果集缓存，帮助 MySQL 来抵御大部分的查询流量，但 Redis 如果失效，则会有击穿 MySQL的风险。 Elasticsearch：倒排索引和搜索引擎技术能提供 MySQL 索引所无法支持的高效模糊查询、全文检索和多字段组合条件过滤的能力，所以主要是承担复杂查询的流量卸载。 HBase：分布式 KV 存储，提供宽表模型。可用于卸载 MySQL 内非事务性数据，可存储 MySQL 内所有表的全量数据，提供低成本的存储卸载。HBase 也是一个在线系统，所以也能提供简单查询的流量卸载。 ClickHouse：MPP 架构的开源数仓，具备非常优异的分析性能，主要职责是分析流量卸载。 基于 MySQL CDC 的派生数据架构，由开源产品 Canal 来做实时数据同步。但这里 ClickHouse 的数据同步并不一定需要是实时增量的，也可采用 T+1 的全量同步方式。 应用系统需要与这些不同组件分别进行交互，且交互接口各不相同。
运维成本极大：运维是一门技术活，需要对组件的原理有比较清楚的了解才能更好的运维，以及进行线上问题的排查和优化。这些开源产品已经将使用成本降的足够低，但是运维成本还是很高，比如 HBase 组件的运维还需要额外运维 Zookeeper、HDFS 等。云托管产品降低了一定的运维成本，但仍无法做到免运维，业务 OPS 仍需要花大量精力在性能调优、容量规划等工作上。另外多组件会比单组件运维成本更高，因为还需要管理组件间的数据流。 多 API 交互复杂：每个组件都提供了不尽相同的 API，应用与不同组件的交互很难抽象和解耦。 成本高：每一个新的组件的引入都需要额外的存储和计算成本，但各组件的偏向不一样，有的更重计算有的更重存储。如果多组件间能共享计算或存储，那能极大的降低成本。而在当前的架构中，每个组件都是相互独立的，需要独享存储和计算资源。
三 云上数据架构实践
DTS（数据传输服务）：原理与 Canal 类似，能对接更多数据库上游和下游，全托管的 MySQL 实时数据同步中间件。
Tair（Redis 企业版）：阿里自研企业级缓存，兼容 Redis 协议，具备更强的性能。
Tablestore（表格存储）：阿里自研 Bigtable，提供兼容 HBase 的宽表引擎，以及能力和性能都优于 Elasticsearch 的索引引擎。纯 Serverless 免运维能最大程度降低运维成本，同时提供 API 和 SQL 的接口降低应用开发成本。
ADB（分析型数据库）：阿里自研实时数仓，具备强大的分析性能，完全兼容 MySQL 协议。
1 表格存储 Tablestore
多模型：提供抽象模型 WideColumn 宽表模型，以及具象模型 Timeline 消息模型以及 Timestream 时序模型。具象模型更适合应用与应用系统，而具象模型是围绕具体场景的数据架构而设计和深度优化。
多元化索引：提供二级索引和多元索引，不同查询加速场景提供不同的索引实现，其中多元索引能提供全文检索、地理位置检索以及灵活的多条件组合查询，功能和性能都优于 Elasticsearch。
存储计算分离架构：提供计算和存储侧的灵活扩展能力，不仅体现在架构上，也体现在产品形态上。用户可以单独为存储付费或为计算付费，提供更灵活的资源组合，获得最低的成本。
Serverless 服务：纯 Serverless 服务，提供完全免运维的服务，全球部署、即开即用。零成本即可接入，最大可扩展至千万 TPS 服务能力以及 PB 级存储。
计算生态：能够与开源计算引擎对接，融合流批一体计算能力。同时自身提供 CDC 能力，让数据能够更灵活的进行流转。
CDC 技术：Tablestore 的 CDC 技术名为 Tunnel Service，支持全量和增量的实时数据订阅，并且能无缝对接 Flink 流计算引擎来实现表内数据的实时流计算。
SQL 支持：提供 SQL 支持，大大降低使用和应用开发门槛。
四 总结
阿里云开发者社区用户调研邀请函
赞 (0)