阿里妹导读：任何应用系统都离不开对数据的处置，数据也是驱动营业创新以及向智能化生长最焦点的器械。数据处置的手艺已经是焦点竞争力。在一个完整的手艺架构中，通常也会由应用系统以及数据系统组成。应用系统负责处置营业逻辑，而数据系统负责处置数据。本篇文章主要面向数据系统的研发工程师和架构师，希望对你有所启发。

前言

传统的数据系统就是所谓的『大数据』手艺，这是一个被缔造出来的名词，代表着新的手艺门槛。近几年得益于产业的生长、营业的创新、数据的爆发式增进以及开源手艺的普遍应用，履历多年的磨炼以及在宽大开发者的共建下，大数据的焦点组件和手艺架构日趋成熟。特别是随着云的生长，让『大数据』手艺的使用门槛进一步降低，越来越多的营业创新会由数据来驱动完成。

『大数据』手艺会逐步向轻量化和智能化偏向生长，最终也会成为一个研发工程师的必备技术之一，而这个历程必须是由云盘算手艺来驱动以及在云平台之上才气完成。应用系统和数据系统也会逐渐融合，数据系统不再隐藏在应用系统之后，而是也会贯穿在整个营业交互逻辑。传统的应用系统，重点在于交互。而现代的应用系统，在与你交互的同时，会慢慢地熟悉你。数据系统的生长驱动了营业系统的生长，从营业化到规模化，再到智能化。

• 营业化：完成最基本的营业交互逻辑。
• 规模化：分布式和大数据手艺的应用，知足营业规模增进的需求以及数据的积累。
• 智能化：人工智能手艺的应用，挖掘数据的价值，驱动营业的创新。

向规模化和智能化的生长，仍然存在一定的手艺门槛。成熟的开源手艺的应用能让一个大数据系统的搭建变得简朴，同时大数据架构也变得很普遍，例如广为人知的Lambda架构，一定程度上降低了手艺的入门门槛。然则对数据系统的后续维护，例如对大数据组件的规模化应用、运维管控和成本优化，需要掌握大数据、分布式手艺及庞大环境下定位问题的能力，仍然具备很高的手艺门槛。

数据系统的焦点组件包罗数据管道、分布式存储和分布式盘算，数据系统架构的搭建会是使用这些组件的组合拼装。每个组件各司其职，组件与组件之间举行上下游的数据交流，而差别模块的选择和组合是架构师面临的最大的挑战。

本篇文章主要面向数据系统的研发工程师和架构师，我们会首先对数据系统焦点组件举行拆解，先容每个组件下对应的开源组件以及云上产物。之后会深入剖析数据系统中结构化数据的存储手艺，先容阿里云Tablestore选择哪种设计理念来更好的知足数据系统中对结构化数据存储的需求。

数据系统架构

焦点组件

上图是一个对照典型的手艺架构，包罗应用系统和数据系统。这个架构与详细营业无关联，主要用于体现一个数据应用系统中会包罗的几大焦点组件，以及组件间的数据流关系。应用系统主要实现了应用的主要营业逻辑，处置营业数据或应用元数据等。数据系统主要对营业数据及其他数据举行汇总和处置，对接BI、推荐或风控等系统。整个系统架构中，会包罗以下对照常见的几大焦点组件：

关系数据库：用于主营业数据存储，提供事务型数据处置，是应用系统的焦点数据存储。

高速缓存：对庞大或操作价值昂贵的效果举行缓存，加速接见。

搜索引擎：提供庞大条件查询和全文检索。

行列：用于将数据处置流程异步化，衔接上下游对数据举行实时交流。异构数据存储之间举行上下游对接的焦点组件，例如数据库系统与缓存系统或搜索系统间的数据对接。也用于数据的实时提取，在线存储到离线存储的实时归档。

非结构化大数据存储：用于海量图片或视频等非结构化数据的存储，同时支持在线查询或离线盘算的数据接见需求。

结构化大数据存储：在线数据库也可作为结构化数据存储，但这里提到的结构化数据存储模块，更偏在线到离线的衔接，特征是能支持高吞吐数据写入以及大规模数据存储，存储和查询性能可线性扩展。可存储面向在线查询的非关系型数据，或者是用于关系数据库的历史数据归档，知足大规模和线性扩展的需求，也可存储面向离线剖析的实时写入数据。

批量盘算：对非结构化数据和结构化数据举行数据剖析，批量盘算中又分为交互式剖析和离线盘算两类，离线盘算需要知足对大规模数据集举行庞大剖析的能力，交互式剖析需要知足对中等规模数据集实时剖析的能力。

流盘算：对非结构化数据和结构化数据举行流式数据剖析，低延迟产出实时视图。

对于数据存储组件我们再进一步剖析，当前种种数据存储组件的设计是为知足差别场景下数据存储的需求，提供差别的数据模子抽象，以及面向在线和离线的差别的优化偏向。我们来看下下面这张详细对比表：

派生数据系统

在数据系统架构中，我们可以看到会存在多套存储组件。对于这些存储组件中的数据，有些是来自应用的直写，有些是来自其他存储组件的数据复制。例如营业关系数据库的数据通常是来自营业，而高速缓存和搜索引擎的数据，通常是来自营业数据库的数据同步与复制。差别用途的存储组件有差别类型的上下游数据链路，我们可以也许将其归类为主存储和辅存储两类，这两类存储有差别的设计目的，主要特征为：

• 主存储：数据发生自营业或者是盘算，通常为数据首先落地的存储。ACID等事务特征可能是强需求，提供在线应用所需的低延迟营业数据查询。
• 辅存储：数据主要来自主存储的数据同步与复制，辅存储是主存储的某个视图，通常面向数据查询、检索和剖析做优化。

为何会有主存储和辅存储的存在？能不能统一存储统一读写，知足所有场景的需求呢？现在看还没有，存储引擎的实现手艺有多种，选择行存照样列存，选择B+tree照样LSM-tree，存储的是不能变数据、频仍更新数据照样时间分区数据，是为高速随机查询照样高吞吐扫描设计等等。数据库产物现在也是分两类，TP和AP，虽然在往HTAP偏向走，但实现方式仍然是底层存储分为行存和列存。

再来看主辅存储在现实架构中的例子，例如关系数据库中主表和二级索引表也可以看做是主与辅的关系，索引表数据会随着主表数据而转变，强一致同步而且为某些特定条件组合查询而优化。关系数据库与高速缓存和搜索引擎也是主与辅的关系，接纳知足最终一致的数据同步方式，提供高速查询和检索。在线数据库与数仓也是主与辅的关系，在线数据库内数据集中复制到数仓来提供高效的BI剖析。

这种主与辅的存储组件相辅相成的架构设计，我们称之为『派生数据系统』。在这个系统下，最大的手艺挑战是数据若何在主与辅之间举行同步与复制。

上图我们可以看到几个常见的数据复制方式：

• 应用层多写：这是实现最简朴、依赖最少的一种实现方式，通常接纳的方式是在应用代码中先向主存储写数据，后向辅存储写数据。这种方式不是很严谨，通常用在对数据可靠性要求不是很高的场景。由于存在的问题有许多，一是很难保证主与辅之间的数据一致性，无法处置数据写入失效问题；二是数据写入的消耗堆积在应用层，加重应用层的代码庞大度和盘算肩负，不是一种解耦很好的架构；三是扩展性较差，数据同步逻辑固化在代码中，对照难天真添加辅存储。
• 异步行列复制：这是现在被应用对照广的架构，应用层���派生数据的写入通过行列来异步化息争耦。这种架构下可将主存储和辅存储的数据写入都异步化，也可仅将辅存储的数据写入异步化。第一种方式必须接受主存储可异步写入，否则只能接纳第二种方式。而若是接纳第二种方式的话，也会遇到和上一种『应用层多写』方案类似的问题，应用层也是多写，只不外是写主存储与行列，行列来解决多个辅存储的写入和扩展性问题。
• CDC（Change Data Capture）手艺：这种架构下数据写入主存储后会由主存储再向辅存储举行同步，对应用层是最友好的，只需要与主存储打交道。主存储到辅存储的数据同步，则可以再行使异步行列复制手艺来做。不外这种方案对主存储的能力有很高的要求，必须要求主存储能支持CDC手艺。一个典型的例子就是MySQL+Elasticsearch的组合架构，Elasticsearch的数据通过MySQL的binlog来同步，binlog就是MySQL的CDC手艺。

『派生数据系统』是一个对照主要的手艺架构设计理念，其中CDC手艺是更好的驱动数据流动的要害手段。具备CDC手艺的存储组件，才气更好的支持数据派生系统，从而能让整个数据系统架构加倍天真，降低了数据一致性设计的庞大度，从而来面向高速迭代设计。惋惜的是大多数存储组件不具备CDC手艺，例如HBase。而阿里云Tablestore具备异常成熟的CDC手艺，CDC手艺的应用也推动了架构的创新，这个在下面的章节会详细先容。

一个好的产物，在产物内部会接纳派生数据架构来不停扩充产物的能力，能将派生的历程透明化，内部解决数据同步、一致性及资源配比问题。而现实中大多数手艺架构接纳产物组合的派生架构，需要自己去治理数据同步与复制等问题，例如常见的MySQL+Elasticsearch，或HBase+Solr等。这种组合通常被忽视的最大问题是，在解决CDC手艺来实时复制数据后，若何解决数据一致性问题？若何追踪数据同步延迟？若何保证辅存储与主存储具备相同的数据写入能力？

存储组件的选型

架构师在做架构设计时，最大的挑战是若何对盘算组件和存储组件举行选型和组合，同类的盘算引擎的差异化相对不大，通常会优先选择成熟和生态健全的盘算引擎，例如批量盘算引擎Spark和流盘算引擎Flink。而对于存储组件的选型是一件异常有挑战的事，存储组件包罗数据库（又分为SQL和NoSQL两类，NoSQL下又凭据种种数据模子细分为多类）、工��存储、文件存储和高速缓存等差别种别。带来存储选型庞大度的主要原因是架构师需要综合思量数据分层、成本优化以及面向在线和离线的查询优化偏向等种种因素，且当前的手艺生长照样多样化的生长趋势，不存在一个存储产物能知足所有场景下的数据写入、存储、查询和剖析等需求。有一些履历可以分享给人人：

• 数据模子和查询语言仍然是差别数据库最显著的区别，关系模子和文档模子是相对抽象的模子，而类似时序模子、图模子和键值模子等其他非关系模子是相对具象的抽象，若是场景能匹配到具象模子，那选择局限能缩小点。
• 存储组件通常会划分到差别的数据分层，选择面向规模、成本、查询和剖析性能等差别维度的优化偏向，选型时需要思量清晰对这部分数据存储所要求的焦点指标。
• 区分主存储照样辅存储，对数据复制关系要有明确的梳理。（主存储和辅存储是什么在下一节先容）
• 确立天真的数据交流通道，知足快速的数据搬迁和存储组件间的切换能力，构建快速迭代能力比应对未知需求的扩展性更主要。

另外关于数据存储架构，我以为最终的趋势是：

1. 数据一定需要分层
2. 数据最终的归属地一定是OSS
3. 会由一个统一的剖析引擎来统一剖析的入口，并提供统一的查询语言

结构化大数据存储

定位

结构化大数据存储在数据系统中是一个异常要害的组件，它起的一个很大的作用是毗邻『在线』和『离线』。作为数据中台中的结构化数据汇总存储，用于在线数据库中数据的汇总来对接离线数据剖析，也用于离线数据剖析的效果集存储来直接支持在线查询或者是数据派生。凭据这样的定位，我们总结下对结构化大数据存储的几个要害需求。

现在做网络游戏赚钱吗，最赚钱的八大网络游戏推荐

要害需求

大规模数据存储：结构化大数据存储的定位是集中式的存储，作为在线数据库的汇总（大宽表模式），或者是离线盘算的输入和输出，必须要能支持PB级规模数据存储。

高吞吐写入能力：数据从在线存储到离线存储的转换，通常是通过ETL工具，T+1式的同步或者是实时同步。结构化大数据存储需要能支持多个在线数据库内数据的导入，也要能蒙受大数据盘算引擎的海量效果数据集导出。以是必须能支持高吞吐的数据写入，通常会接纳一个为写入而优化的存储引擎。

厚实的数据查询能力：结构化大数据存储作为派生数据系统下的辅存储，需要为支持高效在线查询做优化。常见的查询优化包罗高速缓存、高并发低延迟的随机查询、庞大的随便字段条件组合查询以及数据检索。这些查询优化的手艺手段就是缓存和索引，其中索引的支持是多元化的，面向差别的查询场景提供差别类型的索引。例如面向牢固组合查询的基于B+tree的二级索引，面向地理位置查询的基于R-tree或BKD-tree的空间索引或者是面向多条件组合查询和全文检索的倒排索引。

存储和盘算成本星散：存储盘算星散是现在一个对照热的架构实现，对于一样平常应用来说对照难体会到这个架构的优势。在云上的大数据系统下，存储盘算星散才气完全发挥优势。存储盘算星散在分布式架构中，最大的优势是能提供更天真的存储和盘算资源治理手段，大大提高了存储和盘算的扩展性。对成本治理来说，只有基于存储盘算星散架构实现的产物，才气做到存储和盘算成本的星散。

存储和盘算成本的星散的优势，在大数据系统下会加倍显著。举一个简朴的例子，结构化大数据存储的存储量会随着数据的积累越来越大，然则数据写入量是相对平稳的。以是存储需要不停的扩大，然则为了支持数据写入或暂且的数据剖析而所需的盘算资源，则相对来说对照牢固，是按需的。

数据派生能力：一个完整的数据系统架构下，需要有多个存储组件并存。而且凭据对查询和剖析能力的差别要求，需要在数据派生系统下对辅存储举行动态扩展。以是对于结构化大数据存储来说，也需要有能扩展辅存储的派生能力，来扩展数据处置能力。而判断一个存储组件是否具备更好的数据派生能力，就看是否具备成熟的CDC手艺。

盘算生态：数据的价值需要靠盘算来挖掘，现在盘算主要划为批量盘算和流盘算。对于结构化大数据存储的要求，一是需要能够对接主流的盘算引擎，例如Spark、Flink等，作为输入或者是输出；二是需要有数据派生的能力，将自身数据转换为面向剖析的列存花样存储至数据湖系统；三是自身提供交互式剖析能力，更快挖掘数据价值。

知足第一个条件是最基本要求，知足第二和第三个条件才是加分项。

开源产物

现在开源界对照着名的结构化大数据存储是HBase和Cassandra，Cassandra是WideColumn模子NoSQL种别下排名Top-1的产物，在国外应用对照普遍。但这里我们重点提下HBase，由于在海内的话相比Cassandra会更盛行一点。

HBase是基于HDFS的存储盘算星散架构的WideColumn模子数据库，拥有异常好的扩展性，能支持大规模数据存储，它的优点为：

• 存储盘算星散架构：底层基于HDFS，星散的架构可带来存储和盘算各自弹性扩展的优势，与盘算引擎例如Spark可共享盘算资源，降低成本。
• LSM存储引擎：为写入优化设计，能提供高吞吐的数据写入。
• 开发者生态成熟，接入主流盘算引擎：作为生长多年的开源产物，在海内也有对照多的应用，开发者社区很成熟，对接几大主流的盘算引擎。

HBase有其突出的优点，但也有几大不能忽视的缺陷：

查询能力弱：提供高效的单行随机查询以及局限扫描，庞大的组合条件查询必须使用Scan+Filter的方式，稍不注重就是全表扫描，效率极低。HBase的Phoenix提供了二级索引来优化查询，但和MySQL的二级索引一样，只有相符最左匹配的查询条件才气做索引优化，可被优化的查询条件异常有限。

数据派生能力弱：前面章节提到CDC手艺是支持数据派生系统的焦点手艺，HBase不具备CDC手艺。HBase Replication具备CDC的能力，然则仅为HBase内部主备间的数据同步机制。有一些开源组件行使其内置Replication能力来实验扩展HBase的CDC手艺，例如用于和Solr同步的Lily Indexer，然则对照惋惜的是这类组件从理论和机制上剖析就没法做到CDC手艺所要求的数据保序、最终一致性保证等焦点需求。

成本高：前面提到结构化大数据存储的要害需求之一是存储与盘算的成本星散，HBase的成本取决于盘算所需CPU核数成本以及磁盘的存储成本，基于牢固配比物理资源的部署模式下CPU和存储永远会有一个无法降低的最小比例关系。即随着存储空间的增大，CPU核数成本也会响应变大，而不是按现实所需盘算资源来盘算成本。要到达完全的存储与盘算成本星散，只有云上的Serverless服务模式才气做到。

运维庞大：HBase是尺度的Hadoop组件，最焦点依赖是Zookeeper和HDFS，没有专业的运维团队险些无法运维。

热门处置能力差：HBase的表的分区是Range Partition的方式，相比Hash Partition的模式最大的缺陷就是会存在严重的热门问题。HBase提供了大量的最佳实践文档来指引开发者在做表的Rowkey设计的时刻制止热门，例如接纳hash key，或者是salted-table的方式。但这两种方式下能保证数据的涣散平均，然则无法保证数据接见的热度平均。接见热度取决于营业，需要一种能凭据热度来对Region举行Split或Move等负载平衡的自动化机制。

海内的高级玩家大多会基于HBase做二次开发，基本都是在做种种方案来填补HBase查询能力弱的问题，凭据自身营业查询特色研发自己的索引方案，例如自研二级索引方案、对接Solr做全文索引或者是针对区分度小的数据集的bitmap索引方案等等。总的来说，HBase是一个优异的开源产物，有许多优异的设计思绪值得借鉴。

Tablestore

Tablestore是阿里云自研的结构化大数据存储产物，详细产物先容可以参考官网以及权威指南。Tablestore的设计理念很大程度上顾及了数据系统内对结构化大数据存储的需求，而且基于派生数据系统这个设计理念专门设计和实现了一些特色的功效。

| 设计理念

Tablestore的设计理念一方面吸收了优异开源产物的设计思绪，另一方面也是连系现实营业需求演化出了一些特色设计偏向，简朴归纳综合下Tablestore的手艺理念：

• 存储盘算星散架构：接纳存储盘算星散架构，底层基于飞天盘古分布式文件系统，这是实现存储盘算成本星散的基础。
• LSM存储引擎：LSM和B+tree是主流的两个存储引擎实现，其中LSM专为高吞吐数据写入优化，也能更好的支持数据冷热分层。
• Serverless产物形态：基于存储盘算星散架构来实现成本星散的最要害因素是Serverless服务化，只有Serverless服务才气做到存储盘算成本星散。大数据系统下，结构化大数据存储通常会需要定期的大规模数据导入，来自在线数据库或者是来自离线盘算引擎，在此时需要有足够的盘算能力能接纳高吞吐的写入，而平时可能仅需要对照小的盘算能力，盘算资源要足够的弹性。另外在派生数据系统下，主存储和辅存储通常是异构引擎，在读写能力上均有差异，有些场景下需要天真调整主辅存储的配比，此时也需要存储和盘算资源弹性可调。
• 多元化索引，提供厚实的查询能力：LSM引擎特征决议了查询能力的短板，需要索引来优化查询。而差别的查询场景需要差别类型的索引，以是Tablestore提供多元化的索引来知足差别类型场景下的数据查询需求。
• CDC手艺：Tablestore的CDC手艺名为Tunnel Service，支持全量和增量的实时数据订阅，而且能无缝对接Flink流盘算引擎来实现表内数据的实时流盘算。
• 拥抱开源盘算生态：除了对照好的支持阿里云自研盘算引擎如MaxCompute和Data Lake Analytics的盘算对接，也能支持Flink和Spark这两个主流盘算引擎的盘算需求，无需数据搬迁。
• 流批盘算一体：能支持Spark对表内全量数据举行批盘算，也能通过CDC手艺对接Flink来对表内新增数据举行流盘算，真正实现批流盘算连系。

| 特色功效

• 多元化索引

Tablestore提供多种索引类型可选择，包罗全局二级索引和多元索引。全局二级索引类似于传统关系数据库的二级索引，能为知足最左匹配原则的条件查询做优化，提供低成本存储和高效的随机查询和局限扫描。多元索引能提供更厚实的查询功效，包罗随便列的组合条件查询、全文搜索和空间查询，也能支持轻量级数据剖析，提供基本的统计聚合函数，两种索引的对比和选型可参考这篇文章。

• 通道服务

通道服务是Tablestore的CDC手艺，是支持数据派生系统的焦点功效，详细能力可参考这篇文章。能够被行使在异构存储间的数据同步、事宜驱动编程、表增量数据实时订阅以及流盘算场景。现在在云上Tablestore与Blink能无缝对接，也是唯一一个能直接作为Blink的stream source的结构化大数据存储。

大数据处置架构

大数据处置架构是数据系统架构的一部分，其架构生长演进了多年，有一些基本的焦点架构设计思绪产出，例如影响最深远的Lambda架构。Lambda架构对照基础，有一些缺陷，以是在其基础上又逐渐演进出了Kappa、Kappa+等新架构来部分解决Lambda架构中存在的一些问题，详情先容可以看下这篇文章的先容。Tablestore基于CDC手艺来与盘算引擎相连系，基于Lambda架构设计了一个全新的Lambda plus架构。

Lambda plus架构

Lambda架构的焦点头脑是将不能变的数据以追加的方式并行写到批和流处置系统内，随后将相同的盘算逻辑分别在流和批系统中实现，而且在查询阶段合并流和批的盘算视图并展示给用户。基于Tablestore CDC手艺我们将Tablestore与Blink举行了完整对接，可作为Blink的stream source、dim和sink，推出了Lambda plus架构：

1. Lambda plus架构中数据只需要写入Tablestore，Blink流盘算框架通过通道服务API直读表内的实时更新数据，不需要用户双写行列或者自己实现数据同步。
2. 存储上，Lambda plus直接使用Tablestore作为master dataset，Tablestore支持用户在线系统低延迟读写更新，同时也提供了索引功效举行高效数据查询和检索，数据行使率高。
3. 盘算上，Lambda plus行使Blink流批一体盘算引擎，统一流批代码。
4. 展示层，Tablestore提供了多元化索引，用户可自由组合多类索引来知足差别场景下查询的需求。

总结

本篇文章我们谈了数据系统架构下的焦点组件以及关于存储组件的选型，先容了派生数据系统这一设计理念。在派生数据系统下我们能更好的理清存储组件间的数据流关系，也基于此我们对结构化大数据存储这一组件提了几个要害需求。阿里云Tablestore正是基于这一理念设计，并推出了一些特色功效，希望能通过本篇文章对我们有一个更深刻的领会。

在未来，我们会继续承袭这一理念，为Tablestore内的结构化大数据派生更多的便于剖析的能力。会与开源盘算生态做更多整合，接入更多主流盘算引擎。