在往年的第七届中国开源年会上，StoneDB 团队在大数据分论坛发表了《HTAP 的下一步？SoTP 初探》主题演讲，在本次演讲中，咱们首次正式对外阐释了“SoTP 数据库”的技术理念，本系列是演讲实录 + 小编补充版，权当抛砖引玉，供大家批评指正。因为内容比拟多，本文为第一章节，次要讲讲咱们提 SoTP 的背景：From Big to Small and Wide Data。
一、HTAP 的起源、流派和迷思
HTAP 起源
咱们首先从起源讲起，不过因为是公开演讲，思考到一些听众是小白，所以这里次要是从一个比拟宏观的关系型数据库行业倒退历史视角来看的，对于 HTAP 更具体的技术和商业的起源背景，能够看看 StoneDB 首席架构师李浩老师写的这篇文章：HTAP 的背景。
家喻户晓，图灵奖（Turing Award）算是计算机领域里最高的一个奖项，截至今日，因为在数据库畛域有杰出贡献而取得图灵奖的只有四位，别离是：
- 查尔斯·巴赫曼（CharlesW. Bachman），1973 年获奖，设计并开发了网状数据库管理系统 IDS，推动了数据库规范的制订，包含网状数据库模型、数据定义和数据操纵语言的标准阐明（艰深来讲，是他第一次提出了数据库这么个货色，能够说是咱们的祖师爷）；
- 埃德加·弗兰克·科德（Edgar Frank Codd），1981 年获奖，提出了关系数据库模型（关系型数据库经久不衰，目前仍然占据市场最多的份额）；
- 詹姆斯·古瑞（James Gray），1998 年获奖，次要是在大型数据库和事务处理技术上的冲破（重点钻研如何保障数据的完整性、安全性、并行性，以及故障复原，曾负责 VLDB 期刊的主编）；
- 迈克尔·斯通布雷克（Michael Stonebraker），2014 年获奖，古代数据库系统的概念和实际方面的基础性奉献（领导了影响力微小的奠基性数据库 Ingres 的开发，也是最早提倡倒退列存数据库的大佬之一）。
除了这四位数据库界公认的大佬外，也有其余大牛，比方：
- 1988 年，为解决数据集成问题，IBM 的 2 位研究员 Barry Devlin 和 Paul Murphy，创造性地提出了数据仓库（Data Warehouse）的概念；
- 1992 年，比尔·恩门（Bill Inmon）给出了数据仓库的定义。数据仓库是一个面向主题的、集成的、绝对稳固的、反映历史变动的数据汇合，用于反对治理中的决策制定；
- 1993 年，E.F.Codd 提出 OLAP，以及 OLAP 12 条准则。
- ……
能看到，早些年的数据库界名人们，并没有太多中国人士，和操作系统一样，中国在这类根底软件上的起步和投入都不算太早，这也是数据库畛域目前成为我国 35 个“卡脖子”技术之一的起因吧。
我这里要指出的是——置信那些在数据库界深耕数十年的敌人们应该早就感触到了——好像，自从上述这些大佬奠定了关系型数据库倒退的总基调后，后续的几十年里，就再没看到什么轰动一时的翻新了，或者说，影响力能达到以上这些人士的数据库专家学者也没那么多了。那段时间，关系型数据库的热点话题如同从百家争鸣陷入了一个绝对寂静的期间，当然，前面也断断续续有一些新的技术热点，不过，能像下面这些大佬一样间接奠定一个学科或者实践的，就比拟少了。
万籁“俱寂”时，一家出名 IT 钻研与参谋咨询机构的发声，给关系型数据库这个平静的池塘丢了颗巨石：2014 年，Gartner 正式提出了 HTAP 这个概念。
Gartner’s definition in 2014: utilizes in-memory computing technologies to enable concurrent analytical and transaction processing on the same in-memory data store.
Gartner’s new definition in 2018: supports weaving analytical and transaction processing techniques together as needed to accomplish the business task.
能够看到，Gartner 重点强调了应用 内存技术 实现 HTAP 的可行性，并示意 HTAP 将为微小的业务翻新发明机会，增量市场空间微小。
一石卷起千层浪，陷入半寂静的关系型数据库技术，如同迎来了春天。那个时候，商业智能（BI）曾经开始宽泛渗入到泛滥企业的营销业务体系里了，解决数据的业务剖析部门对实时处理和运维最简化的需要越来越重要，HTAP 计划的提出天然迅速地引起了行业的强势关注，因为这玩意儿光是听起来就省心省力，引诱很大。
咱们正在做的 StoneDB，就是对标 Oracle MySQL HeatWave 的一款开源版实时一体化 HTAP 数据库。
HTAP 流派
上图是清华大学李国良传授团队梳理的 HTAP 数据库的倒退工夫线。咱们这里再举几个大家耳熟能详的企业：像数据库巨头 Oracle 去年就推出了 MySQL HeatWave，没错，Oracle 官网曾经明确示意了，做 HeatWave 的目标就是为了反对 HTAP，在最近的 Oracle CloudWorld 大会上还官宣了 MySQL HeatWave Lakehouse；Google 在 HTAP 上也动作频频，除了搞 F1 Lightning 以外，在往年 5 月 12 日的 Google I/O 2022 开发者大会还发表了云原生 HTAP 数据库 AlloyDB for PostgreSQL；紧接着，所有云数仓都想打的出名厂商 SnowFlake 也在 6 月 14 日的用户大会 Snowflake Summit 2022 上官宣正式推出 HTAP 存储引擎 Unistore；数据库独角兽 SingleStore（前身为 MemSQL）也早就在 HTAP 畛域上频频发声，顶会论文都发了。国内上的这些大厂和独角兽都在搞 HTAP，国内的更不用说了，阿里、百度、腾讯、华为、字节和泛滥新兴守业公司（包含咱们 StoneDB），以及老牌数据库厂商都开始宣传本人的一些产品能够实现或者主攻 HTAP。Gartner 之前在报告里预测说，到 2024 年，HTAP 数据库会被宽泛用到各行各业中，当初看来，真的是有这种势头了。
不言而喻，HTAP 这俩马车的车轮曾经压在了数据库行业的历史轨迹上，正在滚滚向前，势不可挡。然而，随着越来越多的厂商正式退出赛道，对于 HTAP 架构的技术实现，天然产生了一些分化。
咱们之前在文章《深度干货！一篇 Paper 带您读懂 HTAP》中有做介绍，这篇报告里提到，至多有四种不同的架构形式能够实现 HTAP。
目前 HTAP 大抵有四种实现形式：
- 计划 1（一套零碎一套存储）：在一个零碎里用一种数据格式满足两种业务需要；
- 计划 2（一套零碎两套存储）：一个零碎里同时存在行存储和列存储，行存储上的更新会定期导入到列存储里转换成列存储格局；
- 计划 3（两套零碎两套存储）：零碎里同时存在 OLTP 与 OLAP 两套引擎，别离写入和读取行存储和列存储；
- 计划 4（多套零碎松耦合）：不同的异构零碎之间，通过独立的插件服务对数据进行准实时同步，对外出现 HTAP 能力。
上面这张表图是咱们对这四种架构计划的一个简略的综合盘点。
HTAP 迷思
随着一些 HTAP 产品性能可能实现落地了，在 HTAP 架构的抉择上引起了不少争议（咱们讲叫技术口水战），这很失常，大家都想说 HTAP 是本人做得比拟好嘛。比方 StoneDB 这边就比较支持齐全一体化的混合负载架构（咱们称之为真正的 HTAP 面临的挑战）；也有的团队比拟想搞那种两套零碎叠加的架构；还有更猛的，间接说要基于 GPU/CPU 搞 HTAP，就是 RateupDB，据说是寰球惟一一个基于 GPU/CPU 和并行的 HTAP 数据库，还发了一篇 VLDB，不过如同当初匿影藏形了，创始人目前应该是投身一家势头较猛的云数仓守业公司去了。
由此可见，HTAP 尽管引起了一阵狂欢，然而，对 HTAP 数据库架构抉择目前业界还是没有一套特地称得上成熟的计划，大家也都是在打磨产品中。有的走的略微早了一些；有的还在孵化打磨；有的曾经倒在半路上了，然而一个不可否认的事实是，大家都开始说本人能或者行将能反对 HTAP 了，就和数据库畛域另外一个爆火的“云原生”关键字一样，这真堪称是“二四八月乱穿衣”了，这也算是当初 HTAP 畛域上存在的迷思吧。
新的趋势：From Big to Small and Wide data
所以，在这个时候，作为率先提出要做 MySQL 开源 HTAP 数据库的 StoneDB，想要略微沉着一下。
不是说咱们不做 HTAP 了，而是有了一个新的思路。这个思路，也同样来自于咱们的老朋友、好搭档，大家都巴不得上他们报告的权威机构——Gartner。
Gartner 在去年公布的《Gartner 2021 十大数据和剖析趋势》报告里，特地提到了一个重要的趋势：。From Big to Small and Wide data
据 Gartner 预测，到 2025 年 70% 的组织会把重点从“大”数据转向“小”数据和“宽”数据，为剖析提供更多的场景，使人工智能（AI）缩小对数据量的需要（原文是 making artificial intelligence (AI) less data hungry）。
当然，这个趋势的调研论断是有背景的，那就是从天而降的新冠疫情。面对新冠，很多数据简直是一夜式爆发式变动增长，导致了基于大量历史数据的机器学习和人工智能模型变得不那么牢靠，随着智能决策变得更加简单和严格，数据和剖析领导者应抉择可能更加无效利用现有数据的剖析技术。
如何更加无效利用数据分析？那就是咱们讲的用“小”而“宽”的数据取代“大”数据来解决问题。小数据——顾名思义，指的是可能应用所需数据量较少，但仍能提供实用洞见的数据模型。宽数据——能够了解为多模数据，即应用宽数据分析各种小而多样化的非结构化和结构化数据源并施展它们的协同成果，从而加强情景态势感知（contextual awareness，情境感知）和决策。
上面就来具体解说一下 Small Data 和 Wide Data 的定义。
Small data 概念
小数据的办法是指应用绝对较少的数据，但仍能提供有见解的剖析技术。其中包含了有针对性地应用数据要求比拟低的模型，比方一些工夫序列剖析的技术，而不是用一刀切的形式去应用数据量要求较高的深度学习技术。
艰深地来讲，应用 AI 或者 ML 技术，往往须要大量的数据源作为剖析的训练模型，但并不是数据量越多越好，特地是那些过期的历史数据，对剖析毫无意义，如果能够及时地找到一些比拟精准的小数据进行剖析，往往能取得更有价值的成果。总之，小数据侧重于利用剖析技术，在小量的、独自的数据集中寻找有用的信息。
Wide data 概念
宽数据容许分析师检查和组合各种大小、非结构化和结构化数据。具体来说，宽而宽泛的数据就是将各种起源的不同数据源捆绑在一起，以进行有意义的剖析。
基于宽数据的数据分析技术围绕着结构化和非结构化数据的剖析和协同，而不论数据集是否间接相干。宽数据最大的特色是能够提取或辨认异构数据集之间的分割。
Small and Wide data 联合的作用
Gartner 出名钻研副总裁 Rita Sallam 示意：“应用‘小’而‘宽’的数据可能提供弱小的剖析和 AI，同时升高企业机构对大型数据集的依赖性。企业机构能够应用‘宽’数据取得更丰盛、更残缺的态势感知或 360 度视图，这将使企业机构可能应用剖析技术做出更好的决策。”
Gartner 高级钻研总监孙鑫示意：“随着企业逐步意识到大数据作为剖析和人工智能要害推动者的局限性，被称为小数据和宽数据的办法正在缓缓涌现，小数据的办法抛开了对于大型单体数据的依赖，实现了对于小型、大型、结构化、非结构化的数据源的剖析和协同。”
同时，据 Gartner 预测，到 2025 年，超过 85% 的技术供应商，将在人工智能解决方案当中退出让数据变得更丰盛的办法和模型训练技术，以进步模型的弹性和敏捷性，而在 2020 年，这样做的供应商只有不到 5%。 由此可见，小数据和宽数据的市场增量微小。
Small and Wide data 外围场景
说了这么多“小”数据和“宽”数据，这两个到一块儿到底能落地到什么利用场景上？
从一个具体的场景为例，当初电商以及社交媒体都在做一个实时举荐的业务场景，而实时举荐的规范流程是首先通过大数据系统对客户的购买历史进行剖析，要关注客户购买产品的生命周期，客户与企业之间的交互历史；同时要去通过各种渠道去理解，目前客户正在什么环境，听到了什么？正在浏览什么信息？联合各种数据进行剖析，最初产生 Top10 的产品举荐，而后通过 App 或者其余伎俩推送给客户。
在这个过程中，须要收集的数据十分宏大，包含各种结构化数据，例如历史订单，客户个人信息等，另外客户的上网日志，网页浏览历史，客户的地位信息，口头轨迹，这些数据的体量都十分大，而一旦波及到千万乃至上亿的用户，同时上万种产品的场景下，这个数据量就是天文数字，而期待所有这些数据都收集残缺并进行 AI 建模预测，则很可能是 1-2 天之后的事件了。
所以，为了尽可能快地对客户当前状况进行反馈，并推出相应的举荐计划，必须把数据链条缩短：首先通过在生产零碎端，贴合用户的购买历史和行为，对整个场景进行束缚，从海量数据分析，变成小数据量的剖析，把举荐产品从几万，放大到几十的范畴，这个时候，就是从大数据到“小”数据的过程。而后在此基础之上，通过补足其余渠道的信息，包含图像、声音、浏览日志等等，对几十的范畴进行进一步的精准化定位。这个时候，则体现了“宽”数据的价值。
预计小数据和宽数据技术将产生踊跃的后果，即：
- 批发需求预测（Retail demand forecasting）
- 实时行为智能（Real time behavioral intelligence）
- 超个性化和整体客户体验的改善（Hyper personalization and improvement of the overall customer experience）
- 人生平安
- 欺诈检测
- 自适应主动零碎（比方 自适应 AI）等等
尽管“小”数据和“宽”数据技术的确切后果还没有呈现，但这个概念必定是将来可期的，因为这些技术可能在过来或历史趋势不再相干的畛域提供行之有效的洞察剖析能力。
对于从“大”数据到“小”数据的过程，一个趋势就是，数据分析不用肯定从数仓开始，而是从前端业务零碎，联合肯定的场景，首先发动快捷的数据分析，解决场景定位，计划范畴初筛等数据的初步解决，让后继的剖析尽可能地聚焦在指定的畛域，一方面缩小计算量，同时减速后继决策的速度。
所以业务零碎在承当业务交易的时候，必须减少肯定的数据分析和筛选的能力，这个和传统的业务零碎是纯正 OLTP 零碎的定义不一样，未来业务零碎的能力将会从 OLTP 向 HTAP 逐渐变迁。
这一块还有很多货色能够讲，后续咱们持续探讨，明天就先点一下。作为在数据分析畛域耕耘多年的数据库团队，咱们对这个观点是十分认可的。因为，常常做数据分析的人都晓得，随着应用数据的场景越来越多，数据撑持经营的场景也越来越多，很多状况下，数据驱动经营须要的是近期的热数据，而不是长时间的数据。而这个“热数据”，再更准确一些讲，就应该是“热”的“小”而“宽”数据。
这恰好和 StoneDB 提倡的基于 MySQL 的 HTAP 数据库要可能反对实时与中小数据量场景不约而同（失常 10T 左右，最高不超过 100T，当然了，要是扩大成 LakeHouse，反对的数据量会更多）。也和 SingleStore 讲的观点很相似：没有 HTAP，机器学习和人工智能都是不切实际的。
基于此，咱们提出一个 idea，即 StoneDB 这种强调对热数据实时剖析的 HTAP 数据库，也能够叫做 SoTP 数据库。
SoTP 初探
SoTP，即 Serving over TP。
Serving 是什么？SoTP 的定义和驱动又是什么？这个留给咱们下一篇文章持续解读，欢送关注 StoneDB 公众号。
StoneDB 2.0 云原生分布式实时 HTAP 架构具体设计以 RFC 模式继续进行，欢送大家关注咱们最新进展，更欢送给咱们开源合作的模式和办法提出改良意见，一起通过开源的形式共建 StoneDB ~
https://github.com/stoneatom/…
- StoneDB 代码已齐全在 Github 开源：
https://github.com/stoneatom/…
- StoneDB 官网：
https://stonedb.io/