1.前言回顾过去二十年的技术发展，整个应用形态和技术架构都发生了很大的升级，任何技术的发展都关系到几个重要的变量。相关的。1.应用形态的变化催生了更多的场景和需求。整个应用形态经历了从企业应用、互联网服务到移动应用等几个不同的发展阶段。从最早的企业应用系统，到通过移动互联网技术覆盖到每个人生活的方方面面，在这个过程中产生了大量的场景和需求。新的场景和需求是推动产品和技术发展的主要因素。2.更复杂的场景和更大规模的挑战推动技术的快速发展。新一代应用面临更复杂的场景和更大规模的挑战，老一代的技术架构无法支撑业务的快速发展，迫切需要推动新技术的研发。这是一个全面的ROI考虑。只有当流量和数据达到一定规模时，技术架构升级才能带来更大的效率和成本效益。3、技术基础设施的完善为技术和产品开发提供了基础。互联网、4G/5G等基础设施的建立和完善是新一代应用诞生和发展的基础。分布式技术、云计算、新一代硬件等技术的成熟是技术架构变革的基础。本文将与大家分享应用系统数据架构的演进和云上架构的最佳实践。在这里，我们首先定义数据系统的分类。数据系统如果按照主体来划分，可以分为以下两类：以应用为主体：常见的数据架构都是以“应用”为基础，数据主要是由应用产生的。数据架构是围绕业务设计的，通常是先定义业务模型，再设计业务流程。由于业务之间差异化很大，每个业务都有完全不同的业务模型，数据系统需要具有高度的“抽象”能力，因此通常选择关系型数据库等抽象能力强的组件作为核心存储。数据为主体：这类数据系统通常是围绕“特定类型的数据”构建的，比如围绕云原生监控数据设计的基于Prometheus的监控数据系统，以及围绕日志数据分析设计的ELK数据系统。这类数据系统的设计过程通常是围绕数据的采集、存储、处理、查询和分析等环节设计一个完整的数据系统，数据具有统一的“具体”模型。不同的场景有不同的数据系统。当某种场景具有普适性并具有一定的应用规模时，开??源世界通常会诞生成熟完善的解决方案，比如云原生的Prometheus、ELK、Hadoop等。本文介绍的数据架构是主要是第一种，即“应用为主体”的数据架构。2.应用系统数据架构应用系统数据架构经历了多次迭代，从传统的单一系统数据架构到由多个组件组成的现代数据架构。现代数据架构包含不同的计算和存储组件，这些组件在处理不同类型的数据和负载时各有优缺点。现代数据架构通过对这些组件的合理选择和组合，让每个组件发挥最大的能力，使整个数据系统能够满足更多样化的场景需求，支持更大的数据规模。1.传统数据架构（单体系统）LAMP架构一个应用系统的基本组成包括：API（提供服务接口）、application（业务处理逻辑）、datastorage（应用数据存储）和operatingenvironment（应用和数据库运行环境）））。互联网早期最流行的LAMP架构是典型的单系统数据架构，其中ApacheServer作为API层，PHP用于开发应用，MySQL作为应用数据存储，所有组件在Linux系统上运行。整个架构采用开源软件搭建，能够提供比商业软件更低的成本，因此在互联网早期能够迅速流行于各种中小型网站，成为最流行的建站技术架构.但是，随着互联网流量越来越大，LAMP架构面临的最大问题就是可扩展性，需要解决应用和存储扩展的问题。如何扩容关于扩容技术的几个基本概念：Scale-upvsScale-outScale-up就是直接增加机器的配置规格，是最直接的扩容手段。计算和存储都可以通过Scale-upExpansion进行，但扩展空间有限，相对成本较高。Scale-out就是增加更多的机器，这是一种相对成本更低、更灵活的方法，但是需要相关的组件具备Scale-out的能力。存储和计算分离存储和计算是两个不同维度的资源，如果强绑定，扩展性会受到很大限制。对于数据系统来说，应用节点和存储节点分离就是应用存储和计算分离的设计思想，让应用和存储可以独立扩展。Scale-out具有更好的灵活性和经济性。计算和存储横向扩展的常见技术方法包括：存储横向扩展通常采用数据分片技术，将数据分散在多台机器上。计算Scale-out基于状态路由计算：通常用于状态迁移成本高的数据结构，如数据库的分库、分表。分库分表的扩容需要数据复制，所以通常需要提前规划，根据数据所在的分片进行路由计算。基于计算的复制状态：如果状态可以非常灵活的复制或共享，那么可以基于计算复制状态，这是一种更灵活的计算扩展架构。例如，基于共享存储的大数据计算架构，可以灵活调度任意计算节点处理数据。无状态计算：计算不依赖于任何状态，可以发生在任何节点上，因此计算节点可以轻松实现横向扩展，但需要解决计算调度问题。常见Web应用中的LoadBalancer由一堆Web服务器做后盾，是一种简单的无状态计算扩展架构。有状态计算：计算依赖于状态，计算的扩展依赖于状态的迁移。如果状态不能迁移，那么计算的扩展就只能是scale-up。如果状态可以迁移，计算就可以实现Scale-out。此时，计算的可扩展性取决于状态迁移的灵活性。对于横向扩展计算，我们将其分为两类实现方式，即：可扩展的传统数据架构LAMP架构应用上述扩展技术演进为如上图所示的可扩展数据架构。应用端通常是无状态计算，可以简单的采用scale-out扩展的方式，前端加载LoadBalancer进行流量调度。在存储方面，采用分库分表的方式扩展存储和计算，采用只读库的方式扩展查询和计算。虽然每一层都具备扩展能力，但系统仍存在一些问题：存储端扩展灵活性差，扩展成本高：计算端通常为无状态计算节点，扩展相对灵活的。但存储侧的扩容需要数据复制和迁移，扩容周期长，灵活性差。同时，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）存储组件的种类和差异首先从宏观层面比较数据库存储组件的差异：数据模型和查询语言：这两点仍然是不同数据库之间最显着的差异。关系模型、文档模型和宽表模型是相对抽象的模型，而其他非关系模型，如时间序列模型和图模型，则是相对具体的模型。抽象模型更具表现力，而具体模型更贴近具体场景。SQLvsNoSQL：SQL更适合事务处理，包括开源或商业关系型数据库；NoSQL更适合非事务性数据处理，主要开源；可与SQL结合使用，提供流量卸载和存储卸载；另外，NoSQL类更多的是具体模型，贴近场景而生。数据库vs数据仓库：数据仓库更多的是离线数据分析，提供更大的存储空间，但是在SLA和稳定性上比数据库略差。云托管vs云原生：云原生的本质是利用云上的池化资源来实现更大的弹性，所以简单的把一个开源软件托管在云上并不能称为云原生。云原生带来的优势是更低的使用成本、更低的运维成本、更灵活的数据流转和更弹性的架构。我们来看看目前主流的开源数据库与对应的云原生数据库产品的对比：在选择存储组件时，要考虑功能和基础需求，选择合适的存储组件。上表仅列出部分场景及其中推荐的产品。这些产品不是唯一的选择，也不一定是最合适的选择。它们根据业务的不同发展阶段和需求而有所不同。存储组件选择困难，架构师在设计数据架构时应提前考虑存储组件的添加或更换。数据架构必须具备这样的灵活性，因为“构建快速迭代能力对未知需求的可扩展性更重要”。在一个复杂的应用系统中，必须有多套存储组件的组合，而不是单一的存储组件来支撑所有场景和流量，因此架构师不得不面临下一个问题：如何合理组合这些存储组件？合理组合1）衍生数据架构在数据系统架构中，我们可以看到会有多套存储组件。这些存储组件中的数据，有的是来自应用程序的直写，有的是来自其他存储组件的数据复制。例如，业务关系型数据库的数据通常来自业务，而缓存和搜索引擎的数据通常来自业务数据库的数据同步和复制。不同用途的存储组件有不同类型的上下游数据链路。我们可以大致分为主存储和二级存储。这两种类型的存储具有不同的设计目标。主要特点有：主存储：数据的产生对于业务或计算，通常是数据最先落地的存储。在应用系统数据架构中，MySQL是主存储。辅助存储：数据主要来自主存储的数据同步和复制。辅助存储是主存储的一种视图，通常针对数据查询、检索和分析进行优化。在应用系统数据架构中，承担流量分流或存储分流的存储组件是二级存储。这种主备存储组件相辅相成的架构设计称为“派生数据系统”。在这个系统下，最大的技术挑战是如何在master和slave之间同步和复制数据。在上图中，我们可以看到几种常见的数据复制方式：应用层多写：这是最简单、依赖最少的实现方式。通常的做法是在应用代码中先向主存写入数据，然后再向从存写入数据。这种方法不是很严谨，通常用于对数据可靠性要求不高的场景。因为存在很多问题，一是难以保证master和slave之间的数据一致性，无法处理数据写入失败；另一种是数据写入的消耗在应用层累积，增加了应用层的代码复杂度和复杂度。计算负担不是一个解耦良好的架构；三是扩展性差，数据同步逻辑固化在代码中，难以灵活添加辅助存储。异步队列复制：这是目前广泛使用的架构。应用层通过队列对派生数据的写入进行异步解耦。在这种架构下，主存和从存的数据写入可以是异步的，也可以只异步写入从存的数据。第一种方式必须接受主存可以异步写入，否则只能采用第二种方式。而如果采用第二种方式，也会遇到类似之前“应用层多写”方案的问题。应用层也是多写的，只不过是写主存和队列，队列是用来解决多从存的。写入和可扩展性问题。CDC（ChangeDataCapture）技术：在这种架构下，数据写入主存储后，会从主存储同步到从存储。对应用层最友好，只需要和主存储打交道。从主存储到二级存储的数据同步可以使用异步队列复制技术来完成。但是该方案对主存储的能力要求很高，主存储必须能够支持CDC技术。“衍生数据系统”是一个比较重要的技术架构设计理念，其中CDC技术是更好驱动数据流动的关键手段。采用CDC技术的存储组件可以更好地支持数据派生体系，从而使整个数据系统架构更加灵活，降低数据一致性设计的复杂度，面向高速迭代设计。MySQL的CDC技术比较成熟，一些中间件和云产品也进化了，比如Canal和阿里云的DTS。因此，在我们现代应用系统的数据架构中，数据的推导主要是基于MySQL的CDC技术。现代应用系统的数据架构上图是一个典型的现代应用系统的数据架构。我们来系统的看一下：1.它由多个存储组件组成，各司其职：MySQL：承载事务处理，为整个数据架构的主要存储，其余组件负责流量卸载和存储卸载。Redis：作为MySQL的查询结果集缓存，帮助MySQL抵御大部分查询流量，但如果Redis失效，则存在把MySQL打垮的风险。Elasticsearch：倒排索引和搜索引擎技术可以提供MySQL索引无法支持的高效模糊查询、全文搜索、多字段组合条件过滤能力，因此主要承担复杂查询的流量分流。HBase：分布式KV存储，提供宽表模型。可用于卸载MySQL中的非事务性数据，存储MySQL中所有表的全量数据，提供低成本的存储卸载。HBase也是一个在线系统，所以它也可以为简单的查询提供流量卸载。ClickHouse：基于MPP架构的开源数据仓库，具有优秀的分析性能，主要职责是分析流量卸载。2、基于MySQLCDC的衍生数据架构，通过开源产品Canal进行实时数据同步。但是这里ClickHouse的数据同步不一定需要实时增量，也可以采用T+1的全量同步方式。3、应用系统需要分别与这些不同的组件进行交互，交互接口不同。这种架构具有一定的灵活性。Canal用于解决异构存储之间的数据同步问题，并且可以通过插件机制灵活添加新的存储组件以满足未来新的需求。每个组件都是经过开源社区多年打磨的成熟产品，同时也有一些中间件来降低应用与这些组件交互的成本。但也存在一些明显的问题：运维成本巨大：运维是一项技术活，需要对组件的原理有清晰的认识，才能更好的进行运维，以及排查和优化在线问题。这些开源产品已经将使用成本降得足够低，但运维成本仍然很高。比如HBase组件的运维需要额外运维Zookeeper、HDFS等，云主机产品降低了一定的运维成本，但仍然不能免于运维。业务运维还是需要在性能调优和容量规划上花费大量精力。另外，多组件的运维成本要比单组件高，因为还需要管理组件间的数据流。API交互复杂：每个组件提供不同的API，应用与不同组件之间的交互难以抽象和解耦。成本高：每个新组件的引入都需要额外的存储和计算成本，但每个组件的偏向不同，有的计算量大，有的存储量大。如果可以在多个组件之间共享计算或存储，则可以大大降低成本。在当前的架构中，每个组件都是相互独立的，需要独占的存储和计算资源。3.云上数据架构实践将现代数据架构迁移到云端，利用云的优势优化整个架构：首先，找到合适的云原生产品来替代开源产品。稳定性和性能强；二是用更少的组件做更多的事情，降低管理和使用成本，同时也降低了应用交互开发的复杂度。以上就是云端完整的数据架构，接下来重点介绍几款替代开源组件的云产品：DTS（DataTransferService）：原理类似Canal，可以连接更多的上下游数据库，以及全托管MySQL实时数据同步中心件。Tair（Redis企业版）：阿里巴巴自研企业级缓存，兼容Redis协议，性能更强。Tablestore（表存储）：阿里巴巴自研Bigtable，提供兼容HBase的宽表引擎，以及能力和性能优于Elasticsearch的索引引擎。纯Serverless免运维，可以最大程度降低运维成本，同时提供API和SQL接口，降低应用开发成本。ADB（AnalyticDatabase）：阿里巴巴自研的实时数据仓库，具有强大的分析性能，完全兼容MySQL协议。接下来重点介绍Tablestore，因为在在线应用系统场景中，Tablestore承载着流量分流和存储分流的重要职责。Tair的使用和定位与Redis如出一辙，而Tablestore相比HBase和Elasticsearch有更大的区别。1.TableStoreTablestoreTablestore是阿里云针对海量结构化、半结构化数据存储而开发的serverless多模型结构化数据存储。广泛应用于社交、物联网、人工智能、元数据和大数据等业务场景。它采用类似于GoogleBigtable的宽表模型，具有天然的分布式架构，可以支持高吞吐量的数据写入和PB级的数据存储。具体产品介绍请参考官网及权威指南。Tablestore提供了兼容HBase的宽表引擎，以及比Elasticsearch能力和性能更好的索引引擎。其核心能力包括：Multi-model：提供抽象模型WideColumn宽表模型，以及具体模型Timeline消息模型和Timestream时序模型。具体模型更适合应用和应用系统，而具体模型是围绕特定场景的数据结构进行设计和深度优化的。多元化索引：提供二级索引和多元索引。不同的查询加速场景提供不同的索引实现。其中，多元素索引可以提供全文检索、地理位置检索、灵活的多条件组合查询。功能和性能优于Elasticsearch。存储计算分离架构：提供计算侧和存储侧的灵活扩展能力，不仅体现在架构上，更体现在产品形态上。用户可以单独为存储或计算付费，提供更灵活的资源组合，获得最低的成本。Serverless服务：纯Serverless服务，提供完全免运维服务，全球部署，开箱即用。零成本接入，最高可扩展千万级TPS服务能力和PB级存储。计算生态：可对接开源计算引擎，集成流批计算能力。同时提供CDC能力，让数据流转更灵活。CDC技术：Tablestore的CDC技术称为TunnelService，支持全量和增量实时数据订阅，可以与Flink流计算引擎无缝对接，实现表中数据的实时流计算。SQL支持：提供SQL支持，大大降低使用和应用开发的门槛。4.总结技术架构的选择没有统一的标准答案，是综合权衡考虑。本文主要介绍应用系统数据架构的变化。相信随着应用场景越来越复杂，提出的需求也越来越多，随着底层基础设施的完善，将会出现更多新技术和新产品，数据架构也会不断演进。但会保留一些经典的设计思想，比如分治法、派生数据架构、如何灵活选择和组合存储和计算组件等。通过下方二维码关注。转载本文请再次联系C你公众号。【本文为专栏作者《阿里巴巴官方技术》原创稿件，转载请联系原作者】点此查看作者更多好文
