“胖数据库，瘦中台”：超融合数据库让工程师做更有意义的事

　　超融合数据库将交易型数据库（OLTP）、分析型数据库（OLAP）和大数据/数据湖能力融为一体，并以一种全新的视角展现。如今，包括Teradata、Greenplum、Snowflake在内的主流OLAP数据库都支持事务（ACID），故本文称OLTP为交易型数据库而非事务型数据库。

　　过去十几年，分布式技术和数据库技术都有长足发展，很多产品都在自身原有优势基础之上不同程度的探索能力延伸的边界，并取得了良好的进展。在这种大趋势之下，超融合数据库出现。超融合数据库博采OLTP数据库、OLAP数据库和大数据/数据湖众家之长集于一身，形成一种新的技术形态。

　　而这，或许正改变着相关人士对数据、产品、算法、存储之间关系的看法。

　　数据平台

　　一场大数据时代的进化史

　　数据平台的目的是服务，而最直接的使用者是业务开发人员，开发人员开发出通用的业务系统（譬如CRM、ERP、BI、报表和可视化系统）或者专用的业务系统（譬如某电商的推荐系统、某银行的客户画像系统）供业务人员或用户使用。数据平台最根本的设计目标是支撑业务、提高开发运维效率。

　　自上世纪七八十年代以来，关系数据库一直是数据处理平台的核心。关系数据库很好的划分了业务处理和数据处理的边界：业务逻辑由业务代码实现，数据处理逻辑由数据库实现，两者之间使用标准SQL进行对话。SQL标准不断迭代，从早期的SQL-1992标准到SQL-1999、SQL-2003、SQL-2008、SQL-2011、SQL-2013、SQL-2016、SQL-2019，SQL标准文档逐渐变成了大部头，应用中常用的数据处理逻辑不断的被加入到SQL标准中去，SQL从一种关系语言演进成了数据处理语言（transformation language）。关系数据库解决了数据处理的复杂度问题，开发人员专注在业务逻辑上，效率高、迭代快。

　　2000年后互联网蓬勃发展，也为数据处理带来新的挑战，传统的单节点关系数据库无法满足业务快速发展的需要。起初大型互联网公司例如Google、eBay采用MySQL集群或者Oracle集群来满足快速发展的业务；后来发现这种模式仅仅把MySQL、Oracle当做数据存储使用，而不需要关系数据库的很多特性，基于此洞察出现了一批NoSQL数据库，分别从不同的角度解决某种大数据问题，使开发人员可以应对业务的快速发展，典型的产品有HDFS、Hive、HBase、MongoDB、ElasticSearch等。NoSQL数据库承担了数据处理的部分复杂度，特别是性能方面，同时也把数据处理的部分复杂度留给了开发运维人员。开发人员把这些数据库当做存储用，简单的增删改查（CRUD）由NoSQL数据库实现，复杂点的数据处理逻辑需要由应用代码实现，应用开发效率低。此外产品众多、组合众多，运维复杂。

　　随着业务发展，大量相似的数据处理逻辑和模式在各种应用内反复出现。为了解决这样的问题，很多团队开始抽取相似的数据处理逻辑封装起来供应用开发人员调用。这也是数据中台的雏形。数据中台旨在把复杂度封装起来，把NoSQL留给开发人员的复杂度收回来，让开发人员专注在业务上，提升开发效率。发展到今天，大多数数据中台封装各类软件以满足不同应用需求，拨开其层层封装，核心以开源软件为主。这个时期数据中台比较胖，集成诸多产品实现各种各样的数据处理，包括存储、批处理、流式数据处理、OLTP查询、OLAP查询、ML、数据治理等。数据中台一定程度上回收复杂度，提升开发人员的效率，然而由于数据中台缺乏强大的查询优化和执行引擎，故而很多可以使用现代SQL实现的能力需要用代码实现，这一定程度制约了开发人员的效率。此外运维的复杂度没有降低反而随着集成的产品增加而增加。

　　当前数据架构痛点

　　复杂、昂贵、可变性低

　　现在数据中心部署的数据产品大体可分为四大类：

　　01

　　交易型数据库（OLTP）

　　支撑在线交易业务，典型查询涉及数据行比较少，数据频繁增删改查，数据库追求高并发、低延迟。典型的产品有Oracle、DB2、SQLServer、PostgreSQL、MySQL 等。

　　02

　　分析型数据库（OLAP）

　　支撑在线分析业务，典型查询涉及大量数据行，数据以插入和查询为主，数据清洗后一般不更新或者偶尔更新，数据库追求复杂查询的性能。典型的产品有 Teradata、Greenplum、Snowflake等。这类产品也称为数据仓库。

　　03

　　专用数据库

　　支撑某种特定数据处理业务场景，典型产品有时序数据库、图数据库、GIS数据库、文本检索产品等。

　　04

　　大数据/数据湖（Data Lake）

　　大数据从2005年左右发展起来，起初主要产品是Hadoop，后来发展成为包含众多产品的技术栈。近几年有人提出“数据湖”来描述一种技术和数据处理理念。数据湖的核心理念是“schema on read”，即数据先写入数据湖，然后通过数据治理使之成为可分析的数据。大数据/数据湖相关的典型的产品有HDFS、Hive、Impala、Tez、Kudu、Presto、Drill、Flink、Spark等。

　　而这也由此衍生出另一个问题——这四大类产品之间需要频繁的数据搬运，整个技术栈非常复杂。如下图所示。

　　这种数据架构有诸多问题：

　　01

　　复杂低效

　　产品众多，且运算环境非常复杂，分布式产品则更甚之，整合在一起复杂度进一步叠加；

　　组合多，数据穿行在不同产品组合间，处理逻辑复杂、易出错；

　　产品运维挑战大，易出错，效率低；

　　开发人员学习曲线陡峭且变化快。

　　02

　　昂贵

　　运维支出极高：开源软件产品本身虽不用投入，但是开源软件普遍缺少足够企业级特性或者企业级特性不开源，运维成本极高。据《Business Intelligence Journal》数据，对系统运维的投入超过其对总系统投入的50%；

　　开发运维人员薪资成本极高：复杂软件的运维人员普遍稀缺，因而薪资高举；

　　学习成本极高：用好一套分布式系统就有挑战，何况试图驾驭众多分布式产品；这需要运维人员不断学习相关知识，以应对数据库的复杂及多变性；

　　存储代价极高：同一份数据在不同系统间存储，副本达8个以上，如果考虑每个系统的备份，副本则高达十几份，这并不利于数据优化及使用效率。

　　03

　　阻碍业务快速迭代和创新

　　复杂低效的技术架构消耗开发人员大量的时间进行数据处理而不能集中精力于业务之上；

　　复杂的技术栈对人员技能要求高，形成人才匮乏的局面，应用开发和业务人员无法实现快速迭代，对业务创新形成制约。

　　04

　　用户体验差

　　用户、运维人员、开发人员甚至供应商无法驾驭复杂的技术栈，造成用户使用过程中性能差、故障率高、故障修复时间长等问题。

　　未来数据架构

　　精简、融合、灵活度高

　　古人云“分久必合，合久必分”，数据处理架构演进亦是如此。事实上，关系数据库从上世纪70年代就开始出现，十余年后则开始向商业化之路进行探索并取得成功，之后20多年，关系数据库是商业数据处理应用的核心，也是“one size fits all”的时代。

　　2005年左右，互联网蓬勃发展，出现了一批新数据应用，其典型特点是数据量大（Volume）、数据类型多样化（Variety）、数据产生速度快（Velocity），关系数据库没能快速适应互联网应用对数据处理的新诉求，于是出现了一批新产品，每个产品试图解决一两个特定的问题，譬如HDFS解决高可用廉价存储问题，MapReduce解决批处理并行计算问题，HBase解决宽列数据高效读写问题，MongoDB通过文档模型解决灵活性和读写效率问题，ElasticSearch解决文本检索问题，InfluxDB解决时序数据处理问题，Flink解决流数据处理问题。人们统称这一类产品为“NoSQL”，是“one size does not fit all”的时代。大数据架构师和开发人员根据需求把这些产品组合在一起来解决业务问题。由于产品众多，把这些产品整合在一起挑战大，故而出现了“数据中台”厂商提供这种整合的数据平台服务。数据中台封装各种各样的数据产品，为用户提供通用的、统一的数据存储和处理能力。数据中台通常会打包很多开源软件，是典型的“胖中台”。

　　与此同时，NoSQL也经历了“Non-SQL”、“Not Only SQL”、“No, SQL”等不同的解读，这个词逐渐淡出大众视野，因为大多数NoSQL产品要么没有跟上时代步伐，要么开始支持经典SQL特性，譬如SQL标准、ACID等。之前仅仅解决一两个特定问题的产品开始提供越来越多的能力，产品之间的界限越来越模糊，譬如Kafka提供了KSQL，ElasticSearch也支持SQL，Spark提供了DeltaLake，MongoDB开始支持Schema Validation和分布式事务，Greenplum支持OLTP业务、JSON半结构化数据和库内机器学习（In-database machine learning），PipelineDB在关系数据库内支持流数据处理，MatrixDB在关系数据库中支持时序数据和GIS数据，ElasticSearch支持机器学习等。各种数据产品越发庞杂，新产品形态呼之欲出。

　　超融合数据库在这种形势下应运而生。它博采OLTP数据库、OLAP数据库和大数据/数据湖众家之长集于一身，形成一种新的技术形态。

　　超融合架构的核心是灵活和强大的模块化与插件化。通过模块化和插件化，超融合数据库可以支持不同的场景，譬如可插拔存储器可以使用行存引擎支持OLTP、使用列存引擎支持OLAP、使用LSM存储引擎支持时序数据场景，通过多态存储架构可以同时支持存算一体和存储计算分离，通过自定义类型、自定义函数和自定义聚集支持库内机器学习（in-database machine learning）等。

　　超融合数据库是技术发展的自然走向。2011年，451Research提出的NewSQL为OLTP和大数据的融合 ；2015年，Gartner提出的HTAP为OLTP和OLAP的融合；2020年，Databricks提出的Lakehouse为数据仓库和数据湖的融合；数据库发展逐渐从两两融合走向超融合；而预计不远的2022年，超融合数据库技术将实现产品化和商业化。

　　超融合数据库通过融合多种技术于一体，可以很好的解决上面提到的四类问题：

　　01

　　架构简洁

　　大大简化技术栈，降低系统复杂度，降低运维复杂度，提升开发效率，让开发人员专注在业务逻辑上，把数据处理工作的主体交给数据库，实现数据处理和业务逻辑的松散耦合。

　　02

　　性价比高

　　无需采购和运维众多产品，大幅降低产品开销和运维开销，避免数据过量冗余存储。

　　03

　　业务迭代和创新

　　精简的技术栈使得应用开发人员集中精力在业务逻辑上而不是数据处理上，业务迭代更快，为业务创新赋能。

　　04

　　提升用户体验

　　精简的技术栈易于驾驭，故障率低，最终用户体验好。

　　超融合是一种技术架构，也是一种理念或者说数据处理范式。对于绝大多数客户，数据量为百TB级别，完全可以使用一套数据库集群来处理 OLTP、OLAP和大数据分析业务。这种架构开发省力、运维省心、老板省钱，下图一目了然的展示了超融合数据库架构的优势。

　　如果数据量很大，譬如10PB级别，一套数据库集群来处理全部业务是不现实的，此时可以使用多套超融合数据库来实现，不同的数据库集群偏向处理某种业务或者某类业务，集群之间可以高效互联互通。

　　目前，超融合数据库不会替代专注优化极端场景的的数据库，例如双11、春晚微信红包等数据处理需求系统。但随着超融合数据库的成熟与更新，绝大多数数据处理场景可以以超融合数据库为核心，实现数据处理，“胖数据库、瘦中台”时代到来了。

　　超融合数据库

　　解放开发和运维人员的数据处理

　　本文提到的“胖”、“瘦”比喻如何在整个系统内划分功能边界，不带有褒贬色彩；其次胖与瘦是相对的。胖与瘦的本质是复杂度切分，是把什么样的复杂度留给谁，或者说谁选择解决什么样的复杂度。

　　在“one size fits all”时代，数据处理的复杂度由关系数据库承担，开发效率高，运维简单；在大数据时代，数据处理的复杂度分散在数据库和应用中，应用开发效率变低，运维变复杂；数据中台（或者数据处理平台）出现后试图把分散在应用中的复杂度收回来由数据中台承担，但是目前还没有出现很好解决这一问题的产品和解决方案。

　　超融合数据库的出现，把数据处理平台体系内需要整合多个产品才能解决的问题集成到一个产品内，最大合理限度的把复杂度留给数据库，解放开发和运维人员。过去五十多年，数据库经历了层状数据库、网状数据库、关系数据库、对象数据库、XML数据库、KV数据库、文档数据库、列族数据库、时序数据库、图数据库、内存数据库、并行数据库和分布式数据库等不同技术和产品的洗礼，很多优秀技术沉淀下来。发展到今天，模块化、可插拔的数据库基础技术已经比较成熟，在这样的技术能力之上，通过插拔存储器、执行器、优化器等方法在超融合数据库中支持不同的数据类型，包括结构化数据、时序数据、GIS数据、JSON数据、Text等，支持不同的业务场景，包括交易业务、分析业务和流数据处理业务，把数据处理逻辑再次打包到数据库中，通过现代SQL与应用进行对话，让开发运维人员聚焦到业务逻辑而不是数据处理逻辑上，这显然是数据时代的又一次变革性跨越，让开发运维省心省力。

　　01

　　开发省力

　　超融合数据库替代多个不同的数据库，并提供现代SQL能力，开发人员不需要从不同数据库中读取数据到内存再进行计算合并聚集关联等，而是直接使用现代SQL能力进行数据处理，一条SQL语句抵数千行代码，大大提升效率，降低错误率。

　　02

　　运维省心

　　运维管理一套数据库而不是多套数据库，无需在不同数据库之间搬运数据，安装配置、监控告警、安全保护、备份恢复、扩容、升级等工作量大幅降低。

　　复杂度最大合理限度留给数据库而解放开发和运维人员，数据库边界不断拓展，逐渐变“胖”，超融合数据库到来！

　　关 于 我 们

　　yMatrix是全球超融合时序数据库开创者，专为物联网、车联网、工业互联网和智慧城市提供一站式数据平台。

　　MatrixDB为首款PB级超融合时空数据库，基于自主研发的多项专利技术，MatrixDB可以同时完美支持传统的关系型数据和物联网海量时空数据的快速采集、高效存储、实时分析以及深度学习（ML+AI），开创了现代实时数据仓库方向，为万物互联的智能时代提供坚实、简洁的智能数据核心基础设施。MatrixDB为公司自主研发的国产数据库，公司拥有该产品的全部知识产权。