随着互联网技能的日渐发展、数据规模的扩大与繁芜的需求场景的产生，传统的大数据架构无法承载。大数据架构在近些年的演进紧张表示下以下几方面：
规模化：这里的规模化紧张表示在大数据技能的利用规模上和数据规模的增长。大数据技能的利用规模增长代表越来越多的繁芜需求产生，而数据规模的增长决定了传统的准大数据技能（如 MySQL）无法办理所有问题。因此，拿存储组件举例来说，常日会划分到不同的数据分层，面向规模、本钱、查询和剖析性能平分歧维度的优化倾向，以知足多样性的需求。实时化：传统的 T+1 的离线大数据技能无法知足推举、监控类近实时的需求，全体大数据生态和技能架构在过去十年发生了很大的升级换代。就存储上来说，传统的 HDFS 文件存储、Hive 数仓无法知足低本钱，可更新迭代的需求，因此滋长出 Hudi 等数据方案。就打算上来说，传统的 MapReduce 批处理的能力无法做到秒级的数据处理，先后涌现 Storm 较原始的实时处理和 Spark Streaming 的微批处理，目前由 Flink 基于 Dataflow 模型的实时打算框架在实时打算领域霸占绝对主导地位。云原生化：传统的公司每每会选择自建机房，或者在云上购买机器支配实例这种云托管的形式，但这种架构存在低谷期利用率低，存储打算不分离导致的存储和打算弹性差，以及升级灵巧度低等各种问题。云原生大数据架构便是所谓的数据湖，实在质便是充分利用云上的弹性资源来实现一个统一管理、统一存储、弹性打算的大数据架构，变革了传统大数据架构基于物理集群和本地磁盘的打算存储架构。其紧张技能特色是存储和打算分离和 Serverless。在云原生大数据架构中，每一层架构都在往做事化的趋势演进，存储做事化、打算做事化、元数据管理做事化等。每个组件都被哀求拆分身分歧的单元，具备独立扩展的能力，更开放、更灵巧、更弹性。本篇文章将基于云原生大数据架构的场景，详细谈论实时打算中的维表和结果表的架构选型。
1 实时打算场景
大数据的高速发展已经超过 10 年，大数据也正在从打算规模化向更加实时化的趋势演进。实时打算场景紧张有以下几种最常见的场景：
实时数仓：实时数仓紧张运用在网站 PV / UV 统计、交易数据统计、商品销量统计等各种交易型数据场景中。在这种场景下，实时打算任务通过订阅业务实时数据源，将信息实时秒级剖析，终极呈现在业务大屏中给决策者利用，方便判断企业运营状况和活动匆匆销的情形。实时推举：实时推举紧张是基于 AI 技能，根据用户喜好进行个性化推举。常见于短视频场景、内容资讯场景、电商购物等场景。在这种场景下，通过用户的历史点击情形实时判断用户喜好，从而进行针对性推举，以达到增加用户粘性的效果。数据 ETL：实时的 ETL 场景常见于数据同步任务中。比如数据库中不同表的同步、转化，或者是不同数据库的同步，或者是进行数据聚合预处理等操作，终极将结果写入数据仓库或者数据湖进行归档沉淀。这种场景紧张是为后续的业务深度剖析进行前期准备事情。实时诊断：这种常见于金融类或者是交易类业务场景。在这些场景中，针对行业的独特性，须要有反作弊监管，根据实时短韶光之内的行为，剖断用户是否为作弊用户，做到及时止损。该场景对时效性哀求极高，通过实时打算任务对非常数据检测，实时创造非常并进行及时止损。2 Flink SQL 实时打算
实时打算须要后台有一套极其强大的大数据打算能力，Apache Flink 作为一款开源大数据实时打算技能应运而生。由于传统的 Hadoop、Spark 等打算引擎，实质上是批打算引擎，通过对有限的数据集进行数据处理，其处理时效性是不能担保的。而 Apache Flink ，从设计之初就以定位为流式打算引擎，它可以实时订阅实时产生的流式数据，对数据进行实时剖析处理并产生结果，让数据在第一韶光发挥代价。
Flink 选择了 SQL 这种声明式措辞作为顶层 API，方便用户利用，也符合云原生大数据架构的趋势：
大数据普惠，规模生产：Flink SQL 能够根据查询语句自动优化，天生最优的物理实行操持，屏蔽大数据打算中的繁芜性，大幅降落用户利用门槛，以达到大数据普惠的效果。流批一体：Flink SQL 具备流批统一的特性，无论是流任务还是批处理任务都给用户供应相同的语义和统一的开拓体验，方便业务离线任务转实时。屏蔽底层存储差异：Flink 通过供应 SQL 统一查询措辞，屏蔽底层数据存储的差异，方便业务在多样性的大数据存储中进行灵巧切换，对云上大数据架构进行更开放、灵巧的调度。上图是 Flink SQL 的一些基本操作。可以看到 SQL 的语法和标准 SQL 非常类似，示例中包括了基本的 SELECT、FILTER 操作，可以利用内置函数（如日期的格式化），也可以在注册函数后利用自定义函数。
Flink SQL 将实时打算拆分成源表，结果表和维表三种，将这三种表的 DDL 语句（比如 CREATE TABLE）注册各种输入、输出的数据源，通过 SQL 的 DML（比如 INSERT INTO）表示实时打算任务的拓扑关系，以达到通过 SQL 完成实时打算任务开拓的效果。
源表：紧张代表系统类的输入，比如 Kafka，MQ（Message Queue），或者 CDC（Change Data Capture，例如将 MySQL binlog 转换成实时流）输入。结果表：紧张代表 Flink 将每条实时处理完的数据写入的目标存储，如 MySQL，HBase 等数据库。维表：紧张代表存储数据维度信息的数据源。在实时打算中，由于数据采集端采集到的数据每每比较有限，在做数据剖析之前，就要先将所需的维度信息补全，而维表便是代表存储数据维度信息的数据源。常见的用户维表有 MySQL，Redis 等。
下图是一个完全的实时打算示例，示例中的 Flink SQL 任务，这个任务的目标是打算每分钟不同商品分类的 GMV (Gross Merchandise Volume，即商品交易总额)。在这个任务中，Flink 实时消费用户订单数据的 Kafka 源表，通过 Redis 维表将商品 id 关联起来获取到商品分类，按照 1 分钟间隔的滚动窗口按商品分类将总计的交易金额打算出来，将末了的结果写入 RDS（Relational Database Service，如 MySQL） 结果表中。
# 源表 - 用户订单数据，代表某个用户（user_id）在 timestamp 时按 price 的价格购买了商品（item_id）CREATE TEMPORARY TABLE user_action_source ( `timestamp` BIGINT, `user_id` BIGINT, `item_id` BIGINT, `price` DOUBLE,SQs) WITH ( 'connector' = 'kafka', 'topic' = '<your_topic>', 'properties.bootstrap.servers' = 'your_kafka_server:9092', 'properties.group.id' = '<your_consumer_group>' 'format' = 'json', 'scan.startup.mode' = 'latest-offset');# 维表 - 物品详情CREATE TEMPORARY TABLE item_detail_dim ( id STRING, catagory STRING, PRIMARY KEY (id) NOT ENFORCED) WITH ( 'connector' = 'redis', 'host' = '<your_redis_host>', 'port' = '<your_redis_port>', 'password' = '<your_redis_password>', 'dbNum' = '<your_db_num>');# 结果表 - 按韶光（分钟）和分类的 GMV 输出CREATE TEMPORARY TABLE gmv_output ( time_minute STRING, catagory STRING, gmv DOUBLE, PRIMARY KEY (time_minute, catagory)) WITH ( type='rds', url='<your_jdbc_mysql_url_with_database>', tableName='<your_table>', userName='<your_mysql_database_username>', password='<your_mysql_database_password>');# 处理过程INSERT INTO gmv_output SELECT TUMBLE_START(s.timestamp, INTERVAL '1' MINUTES) as time_minute, d.catagory, SUM(d.price) as gmvFROM user_action_source s JOIN item_detail_dim FOR SYSTEM_TIME AS OF PROCTIME() as d ON s.item_id = d.idGROUP BY TUMBLE(s.timestamp, INTERVAL '1' MINUTES), d.catagory;
这是一个很常见的实时打算的处理链路。后续章节中，我们将针对实时打算的维表和结果表的关键能力进行展开剖析，并分别进行架构选型的谈论。
三 实时打算维表1 关键需求
在数据仓库的培植中，一样平常都会环绕着星型模型和雪花模型来设计表关系或者构造。实时打算也不例外，一种常见的需求便是为数据流补齐字段。由于数据采集端采集到的数据每每比较有限，在做数据剖析之前，就要先将所需的维度信息补全。比如采集到的交易日志中只记录了商品 id，但是在做业务时须要根据店铺维度或者行业纬度进行聚合，这就须要先将交易日志与商品维表进行关联，补全所需的维度信息。这里所说的维表与数据仓库中的观点类似，是维度属性的凑集，比如商品维度、用户度、地点维度等等。
作为保存用户维度信息的数据存储，须要应对实时打算场景下的海量低延时访问。根据这样的定位，我们总结下对构造化大数据存储的几个关键需求：
1. 高吞吐与低延时的读取能力
首当其冲，在不考虑开源引擎 Flink 自身维表的优化外，维表必须能承担实时打算场景下的海量（上万 QPS）的数据访问，也能在极低（毫秒级别）的延时下返回查询数据。
2. 与打算引擎的高整合能力
在维表自身的能力之外，出于性能、稳定性和本钱的考虑，打算引擎自身每每也会有些流量卸载的能力，在一些情形下无需每次要求都须要去访问下贱维表。例如，Flink 在维表场景下支持 Async IO 和缓存策略等优化特性。一个比较好的维表须要和开源打算引擎有着较高程度的对接，一方面可以提升打算层的性能，一方面也可以有效的卸载部分流量，保障维表不被过多访问击穿，并降落维表的打算本钱。
3. 轻存储下的打算能力的弹性
维表常日是一张共享表，存储维度属性等元数据信息，访问规模每每较大，而存储规模每每不会特殊大。对维表的访问规模极大地依赖实时数据流的数据量。比如，如果实时流的数据规模扩大了数十倍，此时对维表的访问次数会大大提升；又比如，如果新增了多个实时打算任务访问该维表，该维表的查询压力会激增。在这些场景下，存储规模每每不会显著增加。
以是，打算最好是按需的，是弹性的。无论是新增或者下线实时打算任务，或者增加访问流量，都不会影响访问性能。同时，打算和存储是该当分离的，不会纯挚由于访问打算量的激增就增加存储本钱。
2 架构选型
MySQL
大数据和实时打算技能起步之初，互联网早期大量盛行 LAMP （Linux + Apache + MySQL + PHP）架构快速开拓站点。因此，由于业务历史数据已经存在 MySQL 中，在最初的实时打算维表选型中大量利用 MySQL 作为维表。
随着大数据架构的更新，MySQL 云上架构也在不断改进，但在维表的运用处景下仍旧存在以下问题：
存储侧扩展灵巧性差，扩展本钱较高：MySQL 在存储侧的扩展须要进行数据复制迁移，扩展周期长且灵巧性差。同时 MySQL 的分库分表每次扩展须要双倍资源，扩展本钱较高。存储本钱高：关系数据库是构造化数据存储单位本钱最高的存储系统，以是对付大数据场景来说，关系型数据库存储本钱较高。以上这些限定使 MySQL 在大数据维表场景下存在性能瓶颈，本钱也比较高。但总体来说，MySQL 是非常精良的数据库产品，在数据规模不怎么大的场景下，MySQL 绝对是个不错的选择。
Redis
在云上运用架构中，由于 MySQL 难以承载不断增加的业务负载，每每会利用 Redis 作为 MySQL 的查询结果集缓存，帮助 MySQL 来抵御大部分的查询流量。
在这种架构中，MySQL 作为主存储做事器，Redis 作为赞助存储，MySQL 到 Redis 的同步可以通过 binlog 实时同步或者 MySQL UDF + 触发器的办法实现。在这种架构中，Redis 可以用来缓存提高查询性能，同时降落 MySQL 被击穿的风险。
由于在 Redis 中缓存了一份弱同等性的用户数据，Redis 也常常用来作为实时打算的维表。比较于 MySQL 作为维表，Redis 有着独特的上风：
查询性能极高：数据高速缓存在内存中，可以通过高速 Key-Value 形式进行结果数据查询，非常符合维表高性能查询的需求。存储层扩展灵巧性高：Redis 可以非常方便的扩展分片集群，进行横向扩展，支持数据多副本的持久化。Redis 有其突出的优点，但也有一个不可忽略的毛病：虽然 Redis 有着不错的扩展方案，但由于高速缓存的数据存在内存中，本钱较高，如果碰着业务数据的维度属性较大（比如用户维度、商品维度）时，利用 Redis 作为维表存储时本钱极高。
Tablestore
Tablestore是阿里云自研的构造化大数据存储产品，详细产品先容可以参考官网以及威信指南。在大数据维表的场景下，Tablestore 有着独特的上风：
高吞吐访问：Tablestore 采取了存储打算分离架构，可以弹性扩展打算资源，支持高吞吐下的数据查询。低延时查询：Tablestore 按照 LSM 存储引擎实现，支持 Block Cache 加速查询，用户也通过配置丰富的索引，优化业务查询。低本钱存储和弹性打算本钱：在存储本钱上，Tablestore 属于构造化 NoSQL 存储类型，数据存储本钱比起关系型数据库或者高速缓存要低很多；在打算本钱上，Tablestore 采取了存储打算架构，可以按需弹性扩展打算资源。与 Flink 维表优化的高度对接：Tablestore 支持 Flink 维表优化的所有策略，包括 Async IO 和不同缓存策略。方案比拟
上面是前文提到的几个维表方案在各个维度的比拟。接下来，将举几个详细的场景细致比拟下本钱：
1.高存储高打算：维表须要存 100 亿条订单维度的数据，总计存储量须要 1T，只管业务在 Flink 任务端配置了缓存策略，但仍旧有较高的 KV 查询下沉到维表，到维表的 QPS 峰值 10 万，均值 2.5 万。不同维表所需的配置哀求和购买本钱如下：
2.低存储低打算：维表须要存 100 万条地域维度的数据，总计存储量须要 10M，业务端在 Flink 任务中的维表配置了 LRU 缓存策略抵御了绝大部分的流量，到维表的 QPS 峰值 1000 均值 250。不同维表所需的配置哀求和购买本钱如下：
3.高存储低打算：维表须要存 100 亿条订单维度的数据，总计存储量须要 1T，业务端在 Flink 任务中的维表配置了 LRU 缓存策略抵御了绝大部分的流量，到维表的 QPS 峰值 1000 均值 250。不同维表所需的配置哀求和购买本钱如下：
4.低存储高打算：Redis 作为内存数据库，具有超高频的数据 KV 查询能力，仅 4 核 8G 内存的 Redis集群，即可支持 16 万 QPS的并发访问，本钱估量 1600 元 / 月，在低存储高打算场景有着光鲜的本钱上风。
从上面的本钱比拟报告中可见：
1）MySQL 由于缺少存储和打算的弹性，以及关系型数据库固有的缺陷，在不同程度的存储和打算规模下本钱均较高。
2）Redis 作为内存数据库，在低存储（约 128G 以下）高打算场景有着光鲜的本钱上风，但由于内存存储本钱很高、缺少弹性，随着数据规模的提升，本钱呈指数增长。
3）Tablestore 基于云原生架构可以按量对存储和打算进行弹性，在数据存储和访问规模不大时本钱较低。
4）Tablestore 作为 NoSQL 数据库存储本钱很低，在高存储（128G 以上）场景下有着光鲜的本钱上风。
四 实时打算结果表1 需求剖析
结果表作为实时打算完成后数据导入的存储系统，紧张可分为关系数据库、搜索引擎、构造化大数据离线存储、构造化大数据在线存储几种分类，详细差异通过以下表格进行了归纳。
对付这几种数据产品，在各自场景下各有上风，起源的先后也各有不同。为了方便探究，我们将问题域缩小，仅仅考虑实时打算的场景下，一个更好的结果表存储须要承担什么样的角色。
上文提到了实时打算的紧张几个场景中，实时数仓，实时推举，实时监控三个场景须要考虑结果表的选型。我们逐一剖析。
实时数仓：实时数仓紧张运用在网站实时 PV / UV 统计、交易数据统计等实时剖析场景。实时剖析（即OLAP）场景分为预聚合、搜索引擎和 MPP（Massively Parallel Processing，即大规模并行处理）三种 OLAP 模型。对付预聚合模型来说，可以通过 Flink 打算层进行数据聚合写入结果表，也可以全量写入结果表中，通过结果表自身的预聚合能力进行数据存储，在这种形态中极大地依赖结果表数据查询与剖析能力的支撑。对付搜索引擎模型来说，数据将全量写入结果表中，通过搜索引擎的倒排索引和列存特性进行数据剖析，在这种形态中须要结果表有高吞吐的数据写入能力和大规模数据存储能力。MPP 模型是打算引擎，如果访问的是列式存储，可以更好地发挥剖析查询特性。实时 OLAP 存储和打算引擎浩瀚，在一个完全的数据系统架构下，须要有多个存储组件并存。并且根据对查询和剖析能力的不同哀求，须要数据派生派生能力在必要时扩展到其他类型存储。其余，实时数仓中随着业务规模的扩大，存储量会大幅增长，相较来说数据查询等打算规模变革一样平常不会特殊明显，以是结果表须要做到存储和打算整天职离，极大地掌握资源本钱。实时推举：实时推举紧张是根据用户喜好进行个性化推举，在常见的用户商品个性化推举场景下，一种常见的做法是将用户的特色写入构造化大数据存储（如 HBase ）中，而该存储将作为维表另一条用户点击消费行为数据进行关联，提取出用户特色与行为关联输入，作为推举算法的输入。这里的存储既须要作为结果表供应高吞吐的数据写入能力，也须要作为维表供应高吞吐低延时的数据在线查询能力。实时监控：运用的实时监控常见于金融类或者是交易类业务场景，该场景对时效性哀求极高，通过对非常数据检测，可以实时创造非常情形而做出一个止损的行为。在这种场景下无论是通过阈值进行判断还是通过非常检测算法，都须要实时低延时的数据聚合查询能力。2 关键能力
通过以上的需求剖析，我们可以总结出几项实时大数据结果表的关键能力：
1.大规模数据存储
结果表存储的定位是集中式的大规模存储，作为在线数据库的汇总，或者是实时打算（或者是离线）的输入和输出，必须要能支撑 PB 级规模数据存储。
2.丰富的数据查询与聚合剖析能力
结果表须要拥有丰富的数据查询与聚合剖析能力，须要为支撑高效在线查询做优化。常见的查询优化包括高速缓存、高并发低延迟的随机查询、繁芜的任意字段条件组合查询以及数据检索。这些查询优化的技能手段便是缓存和索引，个中索引的支持是多元化的，面向不同的查询场景供应不同类型的索引。例如面向固定组合查询的基于 B+tree 的二级索引，面向地理位置查询的基于 R-tree 或 BKD-tree 的空间索引或者是面向多条件组合查询和全文检索的倒排索引。
3.高吞吐写入能力
实时打算的数据表须要能承受大数据打算引擎的海量结果数据集导出。以是必须能支撑高吞吐的数据写入，常日会采取一个为写入而优化的存储引擎。
4.数据派生能力
一个完全的数据系统架构下，须要有多个存储组件并存。并且根据对查询和剖析能力的不同哀求，须要在数据派生体系下对存储进行动态扩展。以是对付大数据存储来说，也须要有能扩展存储的派生能力，来扩展数据处理能力。而判断一个存储组件是否具备更好的数据派生能力，就看是否具备成熟的 CDC 技能。
5.云原生架构：存储与打算整天职离
在云原生大数据架构中，每一层架构都在往做事化的趋势演进，存储做事化、打算做事化、元数据管理做事化等。每个组件都被哀求拆分身分歧的单元，作为结果表也不例外，须要具备独立扩展的能力，更开放、更灵巧、更弹性。
单就从结果表来说，只有符合云原生架构的组件，即基于存储打算分离架构实现的产品，才能做到存储和打算本钱的分离，以及独立扩展。存储和打算分离的上风，在大数据系统下会更加明显。举一个大略的例子，构造化大数据存储的存储量会随着数据的积累越来越大，但是数据写入量是相对平稳的。以是存储须要不断的扩大，但是为了支撑数据写入或临时的数据剖析而所需的打算资源，则相对来说比较固定，是按需的。
3 架构选型
MySQL
和维表一样，大数据和实时打算技能起步之初，MySQL 是一个万能存储，险些所有需求都可以通过 MySQL 来完成，因此运用规模非常广，结果表也不例外。随着数据规模的不断扩展和需求场景的日渐繁芜，MySQL 有点难以承载，就结果表的场景下紧张存在以下问题：
大数据存储本钱高：这个在之前谈论维表时已经提到，关系数据库单位存储本钱非常高。单一存储系统，供应的查询能力有限：随着数据规模的扩大，MySQL 读写性能的不敷问题逐渐显现了出来。其余，随着剖析类 AP 需求的产生，更适宜 TP 场景的 MySQL 查询能力比较有限。高吞吐数据写入能力较差：作为 TP 类的关系型数据库，并不是特殊善于高吞吐的数据写入。扩展性差，扩展本钱较高：这个在之前谈论维表时已经提到，MySQL 在存储侧的扩展须要进行数据复制迁移，且须要双倍资源，因此扩展灵巧性差，本钱也比较高。以上这些限定使 MySQL 在大数据结果表场景下存在性能瓶颈，本钱也比较高，但作为关系型数据库，不是特殊适宜作为大数据的结果表利用。
HBase
由于关系型数据库的天然瓶颈，基于 BigTable 观点的分布式 NoSQL 构造化数据库应运而生。目前开源界比较有名的构造化大数据存储是 Cassandra 和 HBase，Cassandra 是 WideColumn 模型 NoSQL 种别下排名 Top-1 的产品，在国外运用比较广泛。这篇文章中，我们重点提下在海内运用更多的 HBase。 HBase 是基于 HDFS 的存储打算分离架构的 WideColumn 模型数据库，拥有非常好的扩展性，能支撑大规模数据存储，它的优点为：
大数据规模存储，支持高吞吐写入：基于 LSM 实现的存储引擎，支持大规模数据存储，并为写入优化设计，能供应高吞吐的数据写入。存储打算分离架构：底层基于 HDFS，分离的架构可以按需对存存储和打算分别进行弹性扩展。开拓者生态成熟，与其他开源生态整合较好：作为发展多年的开源产品，在海内也有比较多的运用，开拓者社区很成熟，与其他开源生态如 Hadoop，Spark 整合较好。HBase有其突出的优点，但也有几大不可忽略的毛病：
查询能力弱，险些不支持数据剖析：供应高效的单行随机查询以及范围扫描，繁芜的组合条件查询必须利用 Scan + Filter 的办法，稍不把稳便是全表扫描，效率极低。HBase 的 Phoenix 供应了二级索引来优化查询，但和 MySQL 的二级索引一样，只有符合最左匹配的查询条件才能做索引优化，可被优化的查询条件非常有限。数据派生能力弱：前面章节提到 CDC 技能是支撑数据派生体系的核心技能，HBase 不具备 CDC 技能。非云原生 Serverless 做事模式，本钱高：前面提到构造化大数据存储的关键需求之一是存储与打算的整天职离，HBase 的本钱取决于打算所需 CPU 核数本钱以及磁盘的存储本钱，基于固定配比物理资源的支配模式下 CPU 和存储永久会有一个无法降落的最小比例关系。即随着存储空间的增大，CPU 核数本钱也会相应变大，而不是按实际所需打算资源来打算本钱。因此，只有云原生的 Serverless 做事模式，才要达到完备的存储与打算整天职离。运维繁芜：HBase 是标准的 Hadoop 组件，最核心依赖是 Zookeeper 和 HDFS，没有专业的运维团队险些无法运维。海内的高等玩家大多会基于 HBase 做二次开拓，基本都是在做各种方案来填补 HBase 查询能力弱的问题，根据自身业务查询特色研发自己的索引方案，例如自研二级索引方案、对接 Solr 做全文索引或者是针对区分度小的数据集的 bitmap 索引方案等等。总的来说，HBase 是一个精良的开源产品，有很多精良的设计思路值得借鉴。
HBase + Elasticsearch
为理解决 HBase 查询能力弱的问题，海内很多公司通过 Elasticsearch 来加速数据检索，按照 HBase + Elasticsearch 的方案实现他们的架构。个中，HBase 用于做大数据存储和历史冷数据查询，Elasticsearch 用于数据检索，个中，由于 HBase 不具备 CDC 技能，以是须要业务方运用层双写 HBase 和 Elasticsearch，或者启动数据同步任务将 HBase 同步至 Elasticsearch。
这个方案能通过 Elasticsearch 极大地补足 HBase 查询能力弱的问题，但由于 HBase 和 Elasticsearch 本身的一些能力不敷，会存在以下几个问题：
开拓本钱高，运维更加繁芜：客户要掩护至少两套集群，以及须要完成 HBase 到 Elasticsearch 的数据同步。如果要担保 HBase 和 Elasticsearch 的同等性，须要通过前文提到的运用层多写的办法，这不是解耦的架构扩展起来比较繁芜。其余整体架构比较繁芜，涉及的模块和技能较多，运维本钱也很高。本钱很高：客户须要购买两套集群，以及掩护 HBase 和 Elasticsearch 的数据同步，资源本钱很高。仍没有数据派生能力：这套架构中，只是将数据分别写入 HBase 和 Elasticsearch 中，而 HBase 和 Elasticsearch 均没有 CDC 技能，仍旧无法灵巧的将数据派生到其他系统中。Tablestore
Tablestore 是阿里云自研的构造化大数据存储产品，详细产品先容可以参考官网以及威信指南。Tablestore 的设计理念很大程度上顾及了数据系统内对构造化大数据存储的需求，并且基于派生数据体系这个设计理念专门设计和实现了一些特色的功能。大略概括下 Tablestore 的技能理念：
大规模数据存储，支持高吞吐写入：LSM 和 B+ tree 是主流的两个存储引擎实现，个中 Tablestore 基于 LSM 实现，支持大规模数据存储，专为高吞吐数据写入优化。通过多元化索引，供应丰富的查询能力：LSM 引擎特性决定了查询能力的短板，须要索引来优化查询。而不同的查询场景须要不同类型的索引，以是 Tablestore 供应多元化的索引来知足不同类型场景下的数据查询需求。支持 CDC 技能，供应数据派生能力：Tablestore 的 CDC 技能名为 Tunnel Service，支持全量和增量的实时数据订阅，并且能无缝对接 Flink 流打算引擎来实现表内数据的实时流打算。存储打算分离架构：采取存储打算分离架构，底层基于飞天盘古分布式文件系统，这是实现存储打算整天职离的根本。云原生架构，Serverless 产品形态，免运维：云原生架构的最关键成分是存储打算分离和 Serverless 做事化，只有存储打算分离和 Serverless 做事才能实现一个统一管理、统一存储、弹性打算的云原生架构。由于是 Serverless 产品形态，业务方无需支配和掩护 Tablestore，极大地降落用户的运维本钱。方案比拟
举一个详细的场景，结果表须要存千亿级别的电商订单交易数据，总计存储量须要 1T，用户须要对付这类数据进行查询与灵巧的剖析。日常订单查询与数据检索频率为 1000 次/秒，数据剖析约每分钟查询 10 次旁边。
以下是不同架构达到哀求所需的配置，以及在阿里云上的购买本钱：
五 总结
本篇文章谈了云原生大数据架构下的实时打算维表和结果表场景下的架构设计与选型。个中，阿里云 Tablestore 在这些场景下有一些特色功能，希望能通过本篇文章对我们有一个更深刻的理解。后续，我们会推出从零构建 Flink on Tablestore 系列文章，并针对维表和结果表场景推出最佳实践文章。
作者 | 志羽
原文链接：http://click.aliyun.com/m/1000295975/
本文为阿里云原创内容，未经许可不得转载。
