共计 8469 个字符，预计需要花费 22 分钟才能阅读完成。
简介：回顾过去二十年的技术倒退，整个利用状态和技术架构产生了很大的升级换代，而任何技术的倒退都与几个重要的变量相干。本文将会给大家分享利用零碎数据架构的演进以及云上的架构最佳实际。
作者 | 木洛
起源 | 阿里技术公众号
一 前言
回顾过去二十年的技术倒退，整个利用状态和技术架构产生了很大的升级换代，而任何技术的倒退都与几个重要的变量相干。
一，利用状态的变迁，产生更多的场景和需要。整个利用状态从企业应用、互联网服务再到挪动利用，历经了几个不同阶段的倒退。从最早企业内利用零碎，到通过挪动互联网技术笼罩到每个人生存的方方面面，这个过程中产生了大量的场景和需要。而新的场景和需要，是推动产品和技术倒退的次要因素。
二，更简单的场景，更大规模的挑战，推动技术的疾速倒退。新一代利用面临更简单的场景和更大的规模挑战，老一代技术架构无奈撑持业务的疾速倒退，所以急需推动新的技术的钻研和倒退。这是一个综合的 ROI 的思考，流量和数据到肯定规模能力让技术架构降级带来更大的效率和老本的收益。
三，技术基础设施的欠缺，提供了技术和产品倒退的根底。互联网、4G/5G 等基础设施的建设和欠缺，是新一代利用诞生和倒退的根底。分布式技术、云计算、新一代硬件等技术的成熟，是技术架构改革的根底。
本篇文章会给大家分享利用零碎数据架构的演进以及云上的架构最佳实际，这里先对数据系统的分类做一个定义，数据系统如果依照主体来辨别的话分为以下两类：
利用为主体：常见的数据架构都是以『利用』为主体，数据次要产生自利用。数据架构围绕业务来设计，通常是先定义业务模型后设计业务流程。因为业务之间区分度很大，每个业务都有截然不同的业务模型，所以数据系统须要具备高度『形象』的能力，所以通常会抉择关系型数据库这类形象能力强的组件作为外围存储。
数据为主体：这类数据系统通常围绕『特定类型数据』进行构建，比如说围绕云原生监控数据设计的以 Prometheus 为外围的监控数据系统，再比方围绕日志数据分析设计的 ELK 数据系统。这类数据系统的设计过程通常是围绕数据的收集、存储、解决、查问和剖析等环节来设计整套数据系统，数据具备对立的『具象』的模型。不同的场景有不同的数据系统，当某个场景具备通用性以及失去肯定规模的利用，通常在开源界会诞生一套成熟的、残缺的解决方案，比如说云原生 Prometheus、ELK、Hadoop 等。
本篇文章介绍的数据架构次要是第一类，即以『利用为主体』的数据架构。
二 利用零碎数据架构
利用零碎数据架构历经了屡次迭代，从传统的繁多零碎数据架构，到由多组件形成的古代数据架构。古代数据架构下蕴含不同的计算和存储组件，这些组件在解决不同类型数据以及负载下各有优劣。古代数据架构通过正当抉择和组合这些组件，让各个组件能施展最大的能力，从而让整个数据系统能满足更多样化的场景需要以及能撑持更大的数据规模。
1 传统数据架构（繁多零碎）
LAMP 架构
一个利用零碎的根本形成包含：API（提供服务接口）、利用（业务解决逻辑）、数据存储（利用数据存储）以及运行环境（利用和数据库的运行环境）。互联网晚期最风行的 LAMP 架构就是典型的繁多零碎数据架构，其中应用 Apache Server 作为 API 层、应用 PHP 开发利用，应用 MySQL 作为利用数据存储，所有组件均运行在 Linux 零碎上。
整套架构采纳开源软件构建，相比商业软件能提供更低的老本，所以能疾速在互联网晚期的各大中小站点流行起来，成为最风行的建站技术架构。但随着互联网的流量越来越大，LAMP 架构面临的最大的问题是可扩展性，须要解决利用和存储的扩大问题。
如何进行扩大
对于扩大技术的几个基本概念：
Scale-up vs Scale-out
Scale-up 即间接晋升机器的配置规格，是最间接的扩大伎俩，计算和存储均可通过 Scale-up 的形式来进行扩大，但扩大空间无限，绝对老本较高。Scale-out 即减少更多的机器进来，是绝对老本更低、更灵便的伎俩，但须要相干组件具备能 Scale-out 的能力。
存储和计算拆散
存储和计算是两个不同维度的资源，如果强绑定会极大限度扩展性。对数据系统来说，利用节点和存储节点拆散就是利用了存储计算拆散的设计思维，让利用和存储都能独立扩大。
Scale-out 具备更好的灵活性和经济性，计算和存储进行 Scale-out 的常见技术手段包含：
存储 Scale-out
通常采纳数据分片技术，将数据扩散到多台机器上。
计算 Scale-out
基于状态路由计算：通常用于状态迁徙代价大的数据架构，比方数据库的分库分表。分库分表的扩大须要进行数据复制，所以通常须要提前布局，依据数据所在分片来路由计算。
基于计算复制状态：如果状态能非常灵活的复制或者是共享，那可基于计算来复制状态，是一种更灵便的计算扩大架构。比如说基于共享存储的大数据计算架构，可灵便调度任意计算节点对数据进行解决。
无状态计算：计算不依赖任何状态，能够产生在任意节点上，所以计算节点可非常容易实现 Scale-out，但须要解决计算调度问题。常见 Web 利用中的 LoadBalancer 后置一堆 Web Server 就是一个简略的无状态计算扩大架构。
有状态计算：计算依赖状态，计算的扩大依赖状态的迁徙。如果状态不可迁徙，那计算的扩大只能采取 Scale-up 的形式。如果状态可迁徙，那计算就可实现 Scale-out，此时计算的可扩展性依赖于状态迁徙的灵活性。对于可 Scale-out 的计算咱们分为两类实现形式，别离是：
可扩大的传统数据架构
LAMP 架构利用下面提到的扩大技术，演变成了上图的可扩大的数据架构。利用侧通常是无状态计算，所以能够简略采取 Scale-out 的扩大形式，前置 Load Balancer 来进行流量调度。存储侧采取分库分表的形式来进行存储和计算的扩大，以及只读库的形式来对查问计算进行扩大。尽管各层具备了扩大能力，但该零碎还存在一些问题：
存储侧扩大灵活性差，扩大老本较高：计算侧通常是无状态计算节点，扩大绝对灵便。但存储侧的扩大须要进行数据复制迁徙，扩大周期长且灵活性差。同时 MySQL 的分库分表每次扩大须要双倍资源，老本也较高。
繁多存储系统，提供的能力无限：MySQL 作为关系模型数据库，在业务模型形象上提供极强的形象能力，所以能够说是一个万能存储。在互联网晚期利用负载不高的状况下，MySQL 是最优抉择，且曾经领有了成熟的扩大计划。然而随着利用场景和负载一直变动，MySQL 还是难以承载。
存储老本高：简略来说，关系数据库是结构化数据存储单位成本最高的存储系统。
如何解决存储侧扩大问题
MySQL 不是万能的，但 MySQL 对利用零碎来说是不可替换的，到目前为止都是这样。尽管当初有更多新的云原生关系数据库呈现来取代传统 MySQL 的地位，但实质上都脱不了 MySQL 这个壳，只是更弱小的 MySQL 而已。所以很多解决方案都是围绕 MySQL 作为辅助计划而不是替换计划呈现，比如说 Memcached/Redis 这类缓存零碎，帮忙 MySQL 抵挡大部分查问流量，来解决 MySQL 容易被查问打崩的问题。
这个设计思维是『分而治之』，将本来 MySQL 所承当的职责进行细分，能拆散解决的就拆散解决。古代数据架构就是基于此思路，依然以 MySQL 作为利用交互和业务数据存储的外围，然而应用一些辅助计划解决 MySQL 的问题。
2 古代数据架构（多样化零碎）
定义问题，分而治之
后面提到 MySQL 是利用零碎数据架构的外围存储，且是不可替换的组件。MySQL 间接承载业务数据和大部分业务交互，古代数据架构的演进思路是围绕 MySQL 提供辅助解决方案，采纳『分而治之』的设计思路。所以咱们首先得列举分明在繁多零碎架构中 MySQL 所承当的职责，以及明确哪些点是能够分而治之的。分而治之的具体伎俩包含：
流量卸载：承载和抵挡 MySQL 的局部读写流量，让 MySQL 有更多资源进行事务处理。因为读和写依赖 MySQL 内数据，所以在卸载流量的同时还会复制全副或者局部数据。
数据卸载：MySQL 内局部数据会用于事务处理，而局部数据仅存储和查问。不参加事务处理的数据可卸载，来升高表的存储量，对降老本和减负载都是有极大益处的。
为不便了解对 MySQL 承载的职责的具体含意，咱们对应到一个理论场景来解释对应的职责，咱们以『电商订单』零碎来进行举例。
事务处理个别是须要依据数据库内的统一的状态决定操作的执行，必须要有 ACID 的保障，这部分只能由 MySQL 来承载。MySQL 的大部分查问流量都是可被卸载的，最简略的是创立只读库来卸载查问流量，但某些简单查问操作只读库无奈很高效的执行，必须依赖内部存储来减速，比如说数据搜寻和数据分析。所以这部分流量须要卸载，并且须要复制局部或者全副数据。另外 MySQL 内存储的数据并不会都用于事务处理，很大一部分数据在生成后仅提供查问或非事务型操作，这部分数据的查问流量和存储都是可被卸载的。
咱们把职责给定义分明后，也明确了哪些职责是 MySQL 次要承当的，哪些职责是能够被卸载从而得以无效的『分而治之』的。
在理清了整个解决问题的思路后，接下来才是对架构师最大的挑战：如何抉择适合的组件来卸载流量或者存储？
抉择适合的存储组件
1）依据场景定义需要
精确的定义需要是选对组件的前置条件，切勿仅依据功能性需要来进行匹配，还需思考一些基础性需要，例如存储组件可提供的 SLA、数据可靠性、扩展性、可运维性等等。从下面的表中，咱们可能十分清晰的看到对各组件的功能性需要，那接下来咱们再看看基础性需要如何辨别和抉择。
在做数据系统设计时能够把利用数据尝试落在上图的不同周期内，看下如何对存储组件定义适合的基础性需要。通常利用零碎最先产生的是事务数据，事务数据会逐渐向在线数据、离线数据转换和流动，在线性逐渐升高，从面向前台逐渐转向后盾。再看从事务数据到离线数据，基础性要求的具体变动：
SLA 要求逐渐从高到底，在线系统对稳定性要求极高，而后盾零碎相对来说要求可放低。
从 TP 逐渐转向 AP，TP 对拜访提早要求更高，而 AP 对剖析能力要求更高。
数据的更新频率逐渐升高，逐渐归档为不可变数据，所以很多离线零碎都是基于数据的不可变性来做存储和计算优化。
存储老本逐渐升高，数据规模逐渐增大。
2）存储组件的品种和差别
先从宏观层面比拟下数据库类存储组件的差别：
数据模型和查询语言：这两个点依然是不同数据库最显著的区别。关系模型、文档模型和宽表模型是绝对形象的模型，而相似时序模型和图模型等其余非关系模型是绝对具象的模型。形象模型表达力更强，而具象模型更贴近具体场景。
SQL vs NoSQL：SQL 类更适宜事务处理，蕴含开源或商业关系数据库；NoSQL 类更适宜非事务数据处理，根本是以开源为主；场景应用上能够与 SQL 类配合应用，提供流量卸载和存储卸载；另外 NoSQL 类更多是具象模型，贴近场景而生。
数据库 vs 数据仓库：数据仓库更偏离线数据分析，提供更大规模存储，然而在 SLA 和稳定性方面相比数据库略差。
云托管 vs 云原生：云原生的实质是利用云上池化资源来实现更强的弹性，所以简略把一个开源软件托管在云上，并不能称之为云原生。云原生带来的劣势是更低应用老本、更低运维老本、更灵便的数据流转以及更弹性的架构。
咱们看下以后支流开源数据库以及对应的云原生数据库产品的比照：
在做存储组件选型时，要思考功能性需要和基础性需要，抉择适合的存储组件。以上表格只是列举了局部场景和其中举荐的产品，这些产品不是惟一抉择也不肯定是最适宜的抉择，因业务不同倒退阶段和需要而异。抉择对存储组件是一件很难的事，所以架构师在设计数据架构时，要提前思考到存储组件的新增或替换，数据架构必须具备这样的灵活性，因为『构建疾速迭代能力比应答未知需要的扩展性更重要』。
在一个简单的利用零碎中，必然会存在多套存储组件的组合，而不是繁多的存储组件来撑持所有的场景和流量，所以架构师还得面临下一个难题：如何正当的组合这些存储组件？
正当的进行组合
1）派生数据架构
在数据系统架构中，咱们能够看到会存在多套存储组件。对于这些存储组件中的数据，有些是来自利用的直写，有些是来自其余存储组件的数据复制。例如业务关系数据库的数据通常是来自业务，而高速缓存和搜索引擎的数据，通常是来自业务数据库的数据同步与复制。不同用处的存储组件有不同类型的上下游数据链路，咱们能够大略将其归类为主存储和辅存储两类，这两类存储有不同的设计指标，次要特色为：
主存储：数据产生自业务或者是计算，通常为数据首先落地的存储。在利用零碎数据架构中，MySQL 就是主存储。
辅存储：数据次要来自主存储的数据同步与复制，辅存储是主存储的某个视图，通常面向数据查问、检索和剖析做优化。在利用零碎数据架构中，承当流量卸载或存储卸载的存储组件，就是辅存储。
这种主与辅的存储组件相辅相成的架构设计，咱们称之为『派生数据体系』。在这个体系下，最大的技术挑战是数据如何在主与辅之间进行同步与复制。
上图咱们能够看到几个常见的数据复制形式：
应用层多写：这是实现最简略、依赖起码的一种实现形式，通常采取的形式是在利用代码中先向主存储写数据，后向辅存储写数据。这种形式不是很谨严，通常用在对数据可靠性要求不是很高的场景。因为存在的问题有很多，一是很难保障主与辅之间的数据一致性，无奈解决数据写入生效问题；二是数据写入的耗费沉积在应用层，减轻应用层的代码复杂度和计算累赘，不是一种解耦很好的架构；三是扩展性较差，数据同步逻辑固化在代码中，比拟难灵便增加辅存储。
异步队列复制：这是目前被利用比拟广的架构，应用层将派生数据的写入通过队列来异步化和解耦。这种架构下可将主存储和辅存储的数据写入都异步化，也可仅将辅存储的数据写入异步化。第一种形式必须承受主存储可异步写入，否则只能采取第二种形式。而如果采纳第二种形式的话，也会遇到和上一种『应用层多写』计划相似的问题，应用层也是多写，只不过是写主存储与队列，队列来解决多个辅存储的写入和扩展性问题。
CDC（Change Data Capture）技术：这种架构下数据写入主存储后会由主存储再向辅存储进行同步，对应用层是最敌对的，只须要与主存储打交道。主存储到辅存储的数据同步，则能够再利用异步队列复制技术来做。不过这种计划对主存储的能力有很高的要求，必须要求主存储能反对 CDC 技术。
『派生数据体系』是一个比拟重要的技术架构设计理念，其中 CDC 技术是更好的驱动数据流动的要害伎俩。具备 CDC 技术的存储组件，能力更好的撑持数据派生体系，从而能让整个数据系统架构更加灵便，升高了数据一致性设计的复杂度，从而来面向高速迭代设计。MySQL 的 CDC 技术是比拟成熟的，也演变进去一些中间件和云产品，比方 Canal 以及阿里云的 DTS。所以在咱们的古代利用零碎数据架构中，也次要是基于 MySQL 的 CDC 技术来进行数据派生。
古代利用零碎数据架构
上图就是一个典型的古代利用零碎数据架构，咱们来零碎的看下：
由多存储组件形成，每个存储组件各司其职：
MySQL：承载事务处理，为整个数据架构的主存储，其余组件承当流量卸载和存储卸载的职责。
Redis：作为 MySQL 的查问后果集缓存，帮忙 MySQL 来抵挡大部分的查问流量，但 Redis 如果生效，则会有击穿 MySQL 的危险。
Elasticsearch：倒排索引和搜索引擎技术能提供 MySQL 索引所无奈反对的高效含糊查问、全文检索和多字段组合条件过滤的能力，所以次要是承当简单查问的流量卸载。
HBase：分布式 KV 存储，提供宽表模型。可用于卸载 MySQL 内非事务性数据，可存储 MySQL 内所有表的全量数据，提供低成本的存储卸载。HBase 也是一个在线零碎，所以也能提供简略查问的流量卸载。
ClickHouse：MPP 架构的开源数仓，具备十分优异的剖析性能，主要职责是剖析流量卸载。
基于 MySQL CDC 的派生数据架构，由开源产品 Canal 来做实时数据同步。但这里 ClickHouse 的数据同步并不一定须要是实时增量的，也可采纳 T+1 的全量同步形式。
利用零碎须要与这些不同组件别离进行交互，且交互接口各不相同。
这个架构具备肯定的灵活性，通过 Canal 来解决异构存储间的数据同步问题，通过插件机制可灵便减少新的存储组件来应答将来的新的需要。每个组件都是开源界打磨多年的成熟产品，也有一些中间件来升高利用与这些组件的交互老本。但也存在一些显著的问题：
运维老本极大：运维是一门技术活，须要对组件的原理有比较清楚的理解能力更好的运维，以及进行线上问题的排查和优化。这些开源产品曾经将应用老本降的足够低，然而运维老本还是很高，比方 HBase 组件的运维还须要额定运维 Zookeeper、HDFS 等。云托管产品升高了肯定的运维老本，但仍无奈做到免运维，业务 OPS 仍须要花大量精力在性能调优、容量布局等工作上。另外多组件会比单组件运维老本更高，因为还须要治理组件间的数据流。
多 API 交互简单：每个组件都提供了不尽相同的 API，利用与不同组件的交互很难形象和解耦。
老本高：每一个新的组件的引入都须要额定的存储和计算成本，但各组件的偏差不一样，有的更重计算有的更重存储。如果多组件间能共享计算或存储，那能极大的降低成本。而在以后的架构中，每个组件都是互相独立的，须要独享存储和计算资源。
三 云上数据架构实际
把古代数据架构搬到云上，可利用云的劣势来优化整套架构：一是找到适合的云原生产品替换开源产品，最大益处是升高运维老本，其次能取得更强的稳定性和性能；二是用更少的组件做更多的事，来升高治理和应用老本，也能升高利用交互开发复杂度。
以上就是残缺的云上数据架构，重点讲下替换开源组件的几个云产品：
DTS（数据传输服务）：原理与 Canal 相似，能对接更多数据库上游和上游，全托管的 MySQL 实时数据同步中间件。
Tair（Redis 企业版）：阿里自研企业级缓存，兼容 Redis 协定，具备更强的性能。
Tablestore（表格存储）：阿里自研 Bigtable，提供兼容 HBase 的宽表引擎，以及能力和性能都优于 Elasticsearch 的索引引擎。纯 Serverless 免运维能最大水平升高运维老本，同时提供 API 和 SQL 的接口升高利用开发成本。
ADB（剖析型数据库）：阿里自研实时数仓，具备弱小的剖析性能，齐全兼容 MySQL 协定。
接下来咱们再重点提下 Tablestore，因为在利用零碎在线场景，Tablestore 承载了流量卸载和存储卸载的重要职责。Tair 的应用和定位与 Redis 完全一致，而 Tablestore 相比 HBase 和 Elasticsearch 有更大的差异性。
1 表格存储 Tablestore
表格存储 Tablestore 是阿里云自研的面向海量结构化和半结构化数据存储的 Serverless 多模型结构化数据存储，被宽泛用于社交、物联网、人工智能、元数据和大数据等业务场景。采纳与 Google Bigtable 相似的宽表模型，人造的分布式架构，能撑持高吞吐的数据写入以及 PB 级数据存储，具体产品介绍能够参考官网以及权威指南。
Tablestore 提供兼容 HBase 的宽表引擎，以及能力和性能都优于 Elasticsearch 的索引引擎，它的外围能力包含：
多模型：提供形象模型 WideColumn 宽表模型，以及具象模型 Timeline 音讯模型以及 Timestream 时序模型。具象模型更适宜利用与利用零碎，而具象模型是围绕具体场景的数据架构而设计和深度优化。
多元化索引：提供二级索引和多元索引，不同查问减速场景提供不同的索引实现，其中多元索引能提供全文检索、地理位置检索以及灵便的多条件组合查问，性能和性能都优于 Elasticsearch。
存储计算拆散架构：提供计算和存储侧的灵便扩大能力，不仅体现在架构上，也体现在产品状态上。用户能够独自为存储付费或为计算付费，提供更灵便的资源组合，取得最低的老本。
Serverless 服务：纯 Serverless 服务，提供齐全免运维的服务，寰球部署、即开即用。零老本即可接入，最大可扩大至千万 TPS 服务能力以及 PB 级存储。
计算生态：可能与开源计算引擎对接，交融流批一体计算能力。同时本身提供 CDC 能力，让数据可能更灵便的进行流转。
CDC 技术：Tablestore 的 CDC 技术名为 Tunnel Service，反对全量和增量的实时数据订阅，并且能无缝对接 Flink 流计算引擎来实现表内数据的实时流计算。
SQL 反对：提供 SQL 反对，大大降低应用和利用开发门槛。
四 总结
技术架构的抉择没有对立标准答案，是一个综合的衡量思考。本文次要介绍了利用零碎数据架构的变迁，置信随着利用场景越来越简单、更多需要的提出，随着底层基础设施的欠缺，会有更多新技术和产品呈现，而数据架构也会持续演进。然而一些经典的设计思维会保留，例如分而治之、派生数据架构、如何灵便的抉择和组合存储和计算组件等。
原文链接
本文为阿里云原创内容，未经容许不得转载。