关于hive:云原生大数据架构中实时计算维表和结果表的选型实践

简介：随着互联网技术的日渐倒退、数据规模的扩充与简单的需要场景的产生，传统的大数据架构无奈承载。

作者 | 志羽
起源 | 阿里技术公众号

一 前言

传统的大数据技术起源于 Google 三架马车 GFS、MapReduce、Bigtable，以及其衍生的开源分布式文件系统 HDFS，分布式计算引擎 MapReduce，以及分布式数据库 HBase。最后的大数据技术与需要往往集中在超大规模数据存储、数据处理、在线查问等。在这个阶段，很多公司会抉择自建机房部署 Hadoop 的形式，大数据技术与需要集中在离线计算与大规模存储上，常见的体现形式有 T+1 报表，大规模数据在线查问等。

随着互联网技术的日渐倒退、数据规模的扩充与简单的需要场景的产生，传统的大数据架构无奈承载。大数据架构在近些年的演进次要体现下以下几方面：

规模化：这里的规模化次要体现在大数据技术的应用规模上和数据规模的增长。大数据技术的应用规模增长代表越来越多的简单需要产生，而数据规模的增长决定了传统的准大数据技术（如 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 gmv
FROM
  user_action_source s
  JOIN item_detail_dim FOR SYSTEM_TIME AS OF PROCTIME() as d
    ON s.item_id = d.id
GROUP 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 系列文章，并针对维表和后果表场景推出最佳实际文章。

原文链接
本文为阿里云原创内容，未经容许不得转载。