数据中台之大数据结构化存储技术

任何应用系统都离不开对数据的处理，数据也是驱动业务创新以及向智能化发展最核心的东西。这也是为何目前大多数企业都在构建数据中台的原因，数据处理的技术已经是核心竞争力。在一个完备的技术架构中，通常也会由应用系统以及数据系统构成。应用系统负责处理业务逻辑，而数据系统负责处理数据。

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

数据系统的核心组件包含数据管道、分布式存储和分布式计算，数据系统架构的搭建会是使用这些组件的组合拼装。每个组件各司其职，组件与组件之间进行上下游的数据交换，而不同模块的选择和组合是架构师面临的最大的挑战。

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

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

结构化大数据存储的定位是集中式的存储，作为在线数据库的汇总（大宽表模式），或者是离线计算的输入和输出，必须要能支撑PB级规模数据存储。数据从在线存储到离线存储的转换，通常是通过ETL工具，T+1式的同步或者是实时同步。结构化大数据存储需要能支撑多个在线数据库内数据的导入，也要能承受大数据计算引擎的海量结果数据集导出。所以必须能支撑高吞吐的数据写入，通常会采用一个为写入而优化的存储引擎。

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

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

满足第一个条件是最基本要求，满足第二和第三个条件才是加分项。目前开源界比较知名的结构化大数据存储是HBase和Cassandra，Cassandra是WideColumn模型NoSQL类别下排名Top-1的产品，在国外应用比较广泛。但这里我们重点提下HBase，因为在国内的话相比Cassandra会更流行一点。

存储计算分离架构：底层基于HDFS，分离的架构可带来存储和计算各自弹性扩展的优势，与计算引擎例如Spark可共享计算资源，降低成本。LSM存储引擎：为写入优化设计，能提供高吞吐的数据写入。开发者生态成熟，接入主流计算引擎：作为发展多年的开源产品，在国内也有比较多的应用，开发者社区很成熟，对接几大主流的计算引擎。HBase有其突出的优点，但也有几大不可忽视的缺陷：

通道服务是Tablestore的CDC技术，是支撑数据派生体系的核心功能。能够被利用在异构存储间的数据同步、事件驱动编程、表增量数据实时订阅以及流计算场景。目前在云上Tablestore与Blink能无缝对接，也是唯一一个能直接作为Blink的streamsource的结构化大数据存储。

大数据处理架构是数据系统架构的一部分，其架构发展演进了多年，有一些基本的核心架构设计思路产出，例如影响最深远的Lambda架构。Lambda架构比较基础，有一些缺陷，所以在其基础上又逐渐演进出了Kappa、Kappa+等新架构来部分解决Lambda架构中存在的一些问题，详情介绍可以看下这篇文章的介绍。Tablestore基于CDC技术来与计算引擎相结合，基于Lambda架构设计了一个全新的Lambda plus架构。