前言

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

随着互联网技术的日渐发展、数据规模的扩大与复杂的需求场景的产生，传统的大数据架构无法承载。大数据架构在近些年的演进主要体现下以下几方面：

一. 规模化：这里的规模化主要体现在大数据技术的使用规模上和数据规模的增长。大数据技术的使用规模增长代表越来越多的复杂需求产生，而数据规模的增长决定了传统的准大数据技术（如 MySQL）无法解决所有问题。因此，拿存储组件举例来说，通常会划分到不同的数据分层，面向规模、成本、查询和分析性能等不同维度的优化偏向，以满足多样性的需求。

二. 实时化：传统的 T+1 的离线大数据技术无法满足推荐、监控类近实时的需求，整个大数据生态和技术架构在过去十年发生了很大的升级换代。就存储上来说，传统的 HDFS 文件存储、Hive 数仓无法满足低成本，可更新迭代的需求，因此滋生出 Hudi 等数据湖方案。就计算上来说，传统的 MapReduce 批处理的能力无法做到秒级的数据处理，先后出现 Storm 较原始的实时处理和 Spark Streaming 的微批处理，目前由 Flink 基于 Dataflow 模型的实时计算框架在实时计算领域占据绝对主导地位。

二. 云原生化：传统的公司往往会选择自建机房，或者在云上购买机器部署实例这种云托管的形式，但这种架构存在低谷期利用率低，存储计算不分离导致的存储和计算弹性差，以及升级灵活度低等各种问题。云原生大数据架构就是所谓的数据湖，其本质就是充分利用云上的弹性资源来实现一个统一管理、统一存储、弹性计算的大数据架构，变革了传统大数据架构基于物理集群和本地磁盘的计算存储架构。其主要技术特征是存储和计算分离和 Serverless。在云原生大数据架构中，每一层架构都在往服务化的趋势演进，存储服务化、计算服务化、元数据管理服务化等。每个组件都被要求拆分成不同的单元，具备独立扩展的能力，更开放、更灵活、更弹性。

本篇文章将基于云原生大数据架构的场景，详细讨论实时计算中的维表和结果表的架构选型。

大数据架构中的实时计算

实时计算场景

大数据的高速发展已经超过 10 年，大数据也正在从计算规模化向更加实时化的趋势演进。实时计算场景主要有以下几种最常见的场景：

一. 实时数仓：实时数仓主要应用在网站 PV / UV 统计、交易数据统计、商品销量统计等各类交易型数据场景中。在这种场景下，实时计算任务通过订阅业务实时数据源，将信息实时秒级分析，最终呈现在业务大屏中给决策者使用，方便判断企业运营状况和活动促销的情况。

二. 实时推荐：实时推荐主要是基于 AI 技术，根据用户喜好进行个性化推荐。常见于短视频场景、内容资讯场景、电商购物等场景。在这种场景下，通过用户的历史点击情况实时判断用户喜好，从而进行针对性推荐，以达到增加用户粘性的效果。

三. 数据 ETL：实时的 ETL 场景常见于数据同步任务中。比如数据库中不同表的同步、转化，或者是不同数据库的同步，或者是进行数据聚合预处理等操作，最终将结果写入数据仓库或者数据湖进行归档沉淀。这种场景主要是为后续的业务深度分析进行前期准备工作。

四. 实时诊断：这种常见于金融类或者是交易类业务场景。在这些场景中，针对行业的独特性，需要有反作弊监管，根据实时短时间之内的行为，判定用户是否为作弊用户，做到及时止损。该场景对时效性要求极高，通过实时计算任务对异常数据检测，实时发现异常并进行及时止损。

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,
) WITH (
  'connector' = 'kafka',
  'topic' = '
    
    
     ',
  'properties.bootstrap.servers' = 'your_kafka_server:9092',
  'properties.group.id' = '
     
     
      '
  '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' = '
      
      
       ',
  'port' = '
       
       
         ',   'password' = ' 
        
          ',   'dbNum' = ' 
         
           ' ); # 结果表 - 按时间（分钟）和分类的 GMV 输出 CREATE TEMPORARY TABLE gmv_output (    time_minute STRING,    catagory STRING,    gmv DOUBLE,    PRIMARY KEY (time_minute, catagory) ) WITH (    type='rds',    url=' 
          
            ',    tableName=' 
           
             ',    userName=' 
            
              ',    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; 
              
             
            
           
          
         
       
      
      
     
     
    
    

这是一个很常见的实时计算的处理链路。后续章节中，我们将针对实时计算的维表和结果表的关键能力进行展开分析，并分别进行架构选型的讨论。

实时计算维表

关键需求

在数据仓库的建设中，一般都会围绕着星型模型和雪花模型来设计表关系或者结构。实时计算也不例外，一种常见的需求就是为数据流补齐字段。因为数据采集端采集到的数据往往比较有限，在做数据分析之前，就要先将所需的维度信息补全。比如采集到的交易日志中只记录了商品 id，但是在做业务时需要根据店铺维度或者行业纬度进行聚合，这就需要先将交易日志与商品维表进行关联，补全所需的维度信息。这里所说的维表与数据仓库中的概念类似，是维度属性的集合，比如商品维度、用户度、地点维度等等。

作为保存用户维度信息的数据存储，需要应对实时计算场景下的海量低延时访问。根据这样的定位，我们总结下对结构化大数据存储的几个关键需求：

一. 高吞吐与低延时的读取能力      首当其冲，在不考虑开源引擎 Flink 自身维表的优化外，维表必须能承担实时计算场景下的海量（上万 QPS）的数据访问，也能在极低（毫秒级别）的延时下返回查询数据。

二. 与计算引擎的高整合能力

在维表自身的能力之外，出于性能、稳定性和成本的考虑，计算引擎自身往往也会有些流量卸载的能力，在一些情况下无需每次请求都需要去访问下游维表。例如，Flink 在维表场景下支持 Async IO 和缓存策略等优化特性。Flink 相关的优化可以重点参考这篇文章 《Flink SQL 功能解密系列 —— 维表 JOIN 与异步优化》。一个比较好的维表需要和开源计算引擎有着较高程度的对接，一方面可以提升计算层的性能，一方面也可以有效的卸载部分流量，保障维表不被过多访问击穿，并降低维表的计算成本。

三. 轻存储下的计算能力的弹性

维表通常是一张共享表，存储维度属性等元数据信息，访问规模往往较大，而存储规模往往不会特别大。对维表的访问规模极大地依赖实时数据流的数据量。比如，如果实时流的数据规模扩大了数十倍，此时对维表的访问次数会大大提升；又比如，如果新增了多个实时计算任务访问该维表，该维表的查询压力会激增。在这些场景下，存储规模往往不会显著增加。

所以，计算最好是按需的，是弹性的。无论是新增或者下线实时计算任务，或者增加访问流量，都不会影响访问性能。同时，计算和存储是应该分离的，不会单纯因为访问计算量的激增就增加存储成本。

架构选型

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 和不同缓存策略。

方案对比

上面是前文提到的几个维表方案在各个维度的对比。接下来，将举几个具体的场景细致对比下成本：

一. 高存储高计算：维表需要存 100 亿条订单维度的数据，总计存储量需要 1T，尽管业务在 Flink 任务端配置了缓存策略，但仍然有较高的 KV 查询下沉到维表，到维表的 QPS 峰值  10 万，均值 2.5 万。不同维表所需的配置要求和购买成本如下：

二. 低存储低计算：维表需要存 100 万条地域维度的数据，总计存储量需要 10M，业务端在 Flink 任务中的维表配置了 LRU 缓存策略抵御了绝大部分的流量，到维表的 QPS 峰值 1000 均值 250。不同维表所需的配置要求和购买成本如下：

三. 高存储低计算：维表需要存 100 亿条订单维度的数据，总计存储量需要 1T，业务端在 Flink 任务中的维表配置了 LRU 缓存策略抵御了绝大部分的流量，到维表的 QPS 峰值 1000 均值 250。不同维表所需的配置要求和购买成本如下：

四. 低存储高计算：Redis 作为内存数据库，具有超高频的数据 KV 查询能力，仅 4 核 8G 内存的 Redis集群，即可支持 16 万 QPS的并发访问，成本预计 1600 元 / 月，在低存储高计算场景有着鲜明的成本优势。

从上面的成本对比报告中可见：

1）MySQL 由于缺乏存储和计算的弹性，以及关系型数据库固有的缺点，在不同程度的存储和计算规模下成本均较高。

2）Redis 作为内存数据库，在低存储（约 128G 以下）高计算场景有着鲜明的成本优势，但由于内存存储成本很高、缺乏弹性，随着数据规模的提升，成本呈指数增长。

3）Tablestore 基于云原生架构可以按量对存储和计算进行弹性，在数据存储和访问规模不大时成本较低。

4）Tablestore 作为 NoSQL 数据库存储成本很低，在高存储（128G 以上）场景下有着鲜明的成本优势。

实时计算结果表

需求分析

结果表作为实时计算完成后数据导入的存储系统，主要可分为关系数据库、搜索引擎、结构化大数据离线存储、结构化大数据在线存储几种分类，具体差异通过以下表格进行了归纳。

对于这几种数据产品，在各自场景下各有优势，起源的先后也各有不同。为了方便探究，我们将问题域缩小，仅仅考虑实时计算的场景下，一个更好的结果表存储需要承担什么样的角色。

上文提到了实时计算的主要几个场景中，实时数仓，实时推荐，实时监控三个场景需要考虑结果表的选型。我们一一分析。

一. 实时数仓：实时数仓主要应用在网站实时 PV / UV 统计、交易数据统计等实时分析场景。实时分析（即OLAP）场景分为预聚合、搜索引擎和 MPP（Massively Parallel Processing，即大规模并行处理）三种 OLAP 模型。对于预聚合模型来说，可以通过 Flink 计算层进行数据聚合写入结果表，也可以全量写入结果表中，通过结果表自身的预聚合能力进行数据存储，在这种形态中极大地依赖结果表数据查询与分析能力的支撑。对于搜索引擎模型来说，数据将全量写入结果表中，通过搜索引擎的倒排索引和列存特性进行数据分析，在这种形态中需要结果表有高吞吐的数据写入能力和大规模数据存储能力。MPP 模型是计算引擎，如果访问的是列式存储，可以更好地发挥分析查询特性。实时 OLAP 存储和计算引擎众多，在一个完整的数据系统架构下，需要有多个存储组件并存。并且根据对查询和分析能力的不同要求，需要数据派生派生能力在必要时扩展到其他类型存储。另外，实时数仓中随着业务规模的扩大，存储量会大幅增长，相较来说数据查询等计算规模变化一般不会特别明显，所以结果表需要做到存储和计算成本分离，极大地控制资源成本。

二. 实时推荐：实时推荐主要是根据用户喜好进行个性化推荐，在常见的用户商品个性化推荐场景下，一种常见的做法是将用户的特征写入结构化大数据存储（如 HBase ）中，而该存储将作为维表另一条用户点击消费行为数据进行关联，提取出用户特征与行为关联输入，作为推荐算法的输入。这里的存储既需要作为结果表提供高吞吐的数据写入能力，也需要作为维表提供高吞吐低延时的数据在线查询能力。

三. 实时监控：应用的实时监控常见于金融类或者是交易类业务场景，该场景对时效性要求极高，通过对异常数据检测，可以实时发现异常情况而做出一个止损的行为。在这种场景下无论是通过阈值进行判断还是通过异常检测算法，都需要实时低延时的数据聚合查询能力。

关键能力

通过以上的需求分析，我们可以总结出几项实时大数据结果表的关键能力：

一. 大规模数据存储      结果表存储的定位是集中式的大规模存储，作为在线数据库的汇总，或者是实时计算（或者是离线）的输入和输出，必须要能支撑 PB 级规模数据存储。

二. 丰富的数据查询与聚合分析能力

结果表需要拥有丰富的数据查询与聚合分析能力，需要为支撑高效在线查询做优化。常见的查询优化包括高速缓存、高并发低延迟的随机查询、复杂的任意字段条件组合查询以及数据检索。这些查询优化的技术手段就是缓存和索引，其中索引的支持是多元化的，面向不同的查询场景提供不同类型的索引。例如面向固定组合查询的基于 B+tree 的二级索引，面向地理位置查询的基于 R-tree 或 BKD-tree 的空间索引或者是面向多条件组合查询和全文检索的倒排索引。

三. 高吞吐写入能力

实时计算的数据表需要能承受大数据计算引擎的海量结果数据集导出。所以必须能支撑高吞吐的数据写入，通常会采用一个为写入而优化的存储引擎。

四. 数据派生能力

一个完整的数据系统架构下，需要有多个存储组件并存。并且根据对查询和分析能力的不同要求，需要在数据派生体系下对存储进行动态扩展。所以对于大数据存储来说，也需要有能扩展存储的派生能力，来扩展数据处理能力。而判断一个存储组件是否具备更好的数据派生能力，就看是否具备成熟的 CDC 技术。

五. 云原生架构：存储与计算成本分离

在云原生大数据架构中，每一层架构都在往服务化的趋势演进，存储服务化、计算服务化、元数据管理服务化等。每个组件都被要求拆分成不同的单元，作为结果表也不例外，需要具备独立扩展的能力，更开放、更灵活、更弹性。

单就从结果表来说，只有符合云原生架构的组件，即基于存储计算分离架构实现的产品，才能做到存储和计算成本的分离，以及独立扩展。存储和计算分离的优势，在大数据系统下会更加明显。举一个简单的例子，结构化大数据存储的存储量会随着数据的积累越来越大，但是数据写入量是相对平稳的。所以存储需要不断的扩大，但是为了支撑数据写入或临时的数据分析而所需的计算资源，则相对来说比较固定，是按需的。

架构选型

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 系列文章，并针对维表和结果表场景推出最佳实践文章。

希望本次分享对你设计云原生大数据架构有帮助，如果希望继续交流，可以加入我们的开发者技术交流群，可搜索群号『11789671』或『23307953』，亦可直接扫码加入。