Tablestore 启发自 Google 的 Bigtable 论文，从2009年开始，在阿里云的飞天团队内，开始萌发。经过10年的锤炼，如今在集团内，云上积累了各式各样的客户和场景。这篇文章我们就来介绍下 Tablestore 大数据场景下的架构和用户场景案例。看看自研的分布式存储平台如何通过贴身理解客户场景，带来大数据架构的简化和升级，并助力业务方最终快速落地他们的需求。

 

大数据系统建设中的痛

数据的产生是多式多样，我们根据需求会选择不同的存储产品来存放这些数据，例如订单数据，用户信息数据我们会选用一款 OLTP 数据库，日志数据会选择 SLS 日志服务，或者自建 ELK 的方案。又有一些数据我们希望做实时的 计算，并且在 ETL 后在进行长期存储，这时会把数据双写到 Kafka，利用 Kafka 流式对接计算引擎的能力实现上面的需求。一些非结构化数据又会使用 HDFS/OSS 来进行长期存储。这些数据从存储到可以给计算引擎分析需要经过很长的链路。例如如果你选用了一款 OLTP 数据库，你希望进行实时计算或者定期批量计算。考虑到避免影响 TP 在线业务，通常我们会把数据实时或者定期投递出来，进入 Kafka/AP 数据库再分别实现实时计算和批计算。投递的过程可能会涉及到很多模块，例如 DTS，Kafka，Spark 批计算，Spark Streaming，AP 数据仓库。搭建一整套大数据架构（例如下图的典型大数据 Lambda 架构），不论是对数据库的研发同学，还是运维同学都带来了较高的门槛。模块多了以后，不论是维护成本还是开发成本都会相应提高。同时各个模块的存储，计算资源可能未必能很好的共享，比如写入峰值到来的时候，可能我们的批计算需求并不大，但是此时批计算的集群资源很难直接让实时写入层共享。反过来也一样，批计算的峰值，Kafka的资源，ETL的资源又未必可以给批计算共享。那有没有办法解决这些问题？降低大数据架构的接入门槛，使用成本，提升开发效率，资源利用率呢？我们下一章来说。

典型的大数据 Lambda 架构

 

云上 Tablestore 的大数据方案

在开始介绍云上大数据架构之前，我们再看下，双十一大促下需要的大数据架构会对存储提出哪些具体的要求呢：

1. 高吞吐，高可用的大数据架构同时满足弹性和低成本

1. 1. 做为大数据架构，分析的数据通常是海量的，吞吐决定了大数据分析的时延，如果不能及时处理数据会导致业务的决策滞后，进而让大数据方案大打折扣。
   2. 高可用同样是一个很重要的指标，往往业务上云就是希望可以告别线下自建系统的不稳定性。
   3. 做为双十一大促的主旋律，业务峰值是不可避免的，一套弹性的架构是帮助我们真正实现业务在大促下依然可以高可用，高吞吐的的利器。

1. 资源成本

1. 1. 抛开成本谈弹性都是没有意义的，既然选择了云上的方案，我们自然希望可以获得较好弹性的同时，控制成本。
   2. Serverless 云原生的产品形态通常可以比较好的在具备弹性的同时控制我们的成本开销。架构无需在业务低峰期预留很多不必要的资源来防御业务峰值的到来。

1. 生态完善

1. 1. 大数据架构中涉及到的概念和需求非常多，这些需求也会对应不同的计算引擎，例如 Spark，Flink，Presto 或者云上的自研组建。存储需要和这些组建，开源产品进行无缝打通，这样可以降低使用的门槛。
   2. 除了计算引擎，数据通道链路的完善也很重要，例如日志类的数据和 OLTP 的数据能方便汇总，数据打宽等。

 

Tablestore 是一款 Serverless 云原生存储引擎，Serverless 相比实例售卖类型的产品，在业务有波峰波谷时天生就有较大的优势，基于 bigTable 的主存储采用行的方式进行存储，可以支撑单表亿级别的QPS。下面列了一些 Tablestore的核心特性：

Tablestore 除了有强大的主存储满足海量业务的实时读写外，基于主存储的分布式日志提供了完整的数据派生能力（详情参考），海量实时写入 Tablestore 的数据，可以实时订阅进行消费。这样就满足了我们的实时计算需求。

Lambda 架构中除了实时数据写入，实时计算之前，全量数据需要提供高性能扫描能力，Tablestore 采用行列混合，双引擎的架构，在主存储之外内部通过通道服务实时构建一个列存储，支撑 PB 级别数据的高吞吐扫描。同时在海量的数据场景下，我们相信数据是需要分层存储，所以在构建自身列存的同时，我们会帮助用户构建推送云上数据湖的链路，通过全托管的数据湖投递，降低用户的存储成本。

基于 Tablestore 的 Lambda 架构

 

Tablestore 在专注于打造一款极致性能和成本的存储引擎同时，更加关注完整的计算生态，伴随产品核心功能迭代的过程中，我们和阿里云的几大核心计算引擎做了完善的对接具体包括：

• MaxCompute 的对接，支持 MaxCompute 计算引擎通过外表的方式直读写 Tablestore
• EMR Spark 对接，支持流批源表读，流批结果表写，集团内第一款全 Connector 支持的 kv 存储引擎
• Blink 对接，支持流批源表读，流批结果表写，维表读，集团内第一款全 Connector 支持的 kv 存储引擎
• DLA 对接，支持 SQL 直接读写 Tablestore 的数据
• FC 对接，支持流式增量触发器

 

计算的结果集合需要提供丰富灵活的高并发查询，支撑用户生成实时大屏，报表的场景，Tablestore 通过主存储结合丰富的索引能力以及 MPP 类型计算引擎来实现。

Tablestore Lambda架构结果集合存储和报表展示

 

对 Tablestore 大数据架构感兴趣的同学还可以参考之前的一些架构文章：

1. 结构化大数据分析平台设计
2. 数据中台之结构化大数据存储设计
3. Lambda plus: 云上大数据解决方案
4. 基于大数据的舆情分析系统架构 - 架构篇
5. 通过EMR Spark Streaming实时读取Tablestore数据

 

Tablestore 助力双十一集团业务的落地

介绍完 Tablestore 结构化大数据存储引擎的基础能力后，来看看具体的一些双十一集团业务架构：

实时酒店推荐

场景描述：

商家会实时的更新酒店房型库存和报价，酒店的属性等字段。实时选品过程针对同一个酒店不同供应商的库存和报价进行计算和筛选，最终展示出有库存且按照报价质量排序的列表给平台用户，进行酒店搜索的结果返回

架构优势：

• 在线和分析业务流量隔离
• 基于 Tablestore 对接流计算的便利性实现源表和维表的存储统一
• 全链路延时要求高，商品价格变动后，5秒内可以反馈至搜索库

基于 Tablestore 的酒店选品实时推荐架构

双十一监控作战大屏

场景描述：

海量的机器，业务监控秒级别数据，实时千万级别每秒写入流量，写入 Tablestore 数据实时查询和展示。跨时间的实时聚合，形成分钟级别数据。关键指标的实时聚合和展示，离线批计算提供报表分析能力。

架构优势：

• 核心单表数据规模达 10 PB，可自定义数据生命周期
• 核心单表持续每秒写入进 5000 万个数据点
• 数据实时写入，大大提升数据可见时效性
• 毫秒级实时查询展示趋势图和报表，查询性能不受单表规模约束

基于 Tablestore 时序监控大屏场景

全网爬虫系统

场景描述：

海量爬虫高并发高吞吐数据写入，全量数据存储，数据量达 PB 级，多类数据存储，包含半结构化原始数据、结构化标签数据以及分析结果数据，数据写入后需要即时触发数据实时处理，后续需要对接离线处理。

架构优势：

• 分布式 LSM 引擎数据存储，提供高并发高吞吐写入，PB 级数据存储
• 通过数据更新捕获，实时触发后续对数据的自定义处理逻辑
• 与大数据平台实时数据同步，分析结果写入结果表，供应用层实时查询

基于 Tablestore 的爬虫大数据架构

总结

随着处理数据量，处理实时性的变化，物理硬件处理能力的升级，大数据架构演进是非常迅速的。随着业务数据逐步上云后，大数据处理平台也必然会迁移至云上，相比 TP 类业务，AP 类场景的业务峰值，处理数据带宽可能会更大。我们希望合理的云上大数据架构可以借助存储计算分离，在可控的成本下提供更弹性的数据处理能力，解决各业务在大促到来所遇到的挑战。也让大数据平台的研发人员彻底从基础运维中释放出来，可以全身心的投入满足业务对数据分析平台的需求。如果有兴趣的同学欢迎与我们交流探讨（钉钉交流群：23307953）。