数据库领域同样如此。过去五十余年，数据库经历OLTP和OLAP两种需求漫长的融合-分离-再融合的过程。究其原因，数据库的发展始终与用户场景需求变迁紧密相关。如今，随着云计算和大数据的兴起，业务场景正在经历前所未有的变革，数据库领域也掀起了一股HTAP浪潮。
Gartner在多次报告中强调，HTAP是数据库领域最重要的发展趋势之一，也是用户数字化转型中重要的数据平台。业界甚至认为，HTAP的兴起代表着数据库大融合时代的开启。
那么，为什么数据库大厂和云服务巨头们均纷纷押宝HTAP？开源+多云为何是HTAP普及的助推剂？面对新一代HTAP数据的崛起，多年积累形成的MySQL生态终于找到最佳归宿？
放在几年前，HTAP可能还会被认为是数据库领域的小众产品，是否成气候还有待观察。
而随着数据资源、数据消费习惯和数据驱动型场景发生巨大变化，用户需求与传统数据库之间的供需矛盾日渐突出，使得HTAP这种具备“同时支持OLTP和OLAP、创新计算存储框架、去ETL”等特征的新时代数据库成为不可阻挡的趋势。
如今，几乎所有数据库大厂和云服务巨头都在布局HTAP。例如，OceanBase去年推出的 3.0版本中就正式宣布向HTAP数据库进军；今年5月，Google Cloud发布HTAP云端数据库AlloyDB，为PG用户提供了HTAP数据库服务；再加上Oracle MySQL Heatwave，甚至连SnowFlake也发布Unistore来“蹭”HTAP的热点。
如果细数近一年以来的HTAP新品，会发现几乎全部都建立在云端之上。新一代HTAP+云正在成为数据库市场重要的潮流。例如，PingCAP近日发布的TiDB 6.0，也是与云端紧密联系的新一代HTAP数据库。
事实上，PingCAP是HTAP数据库领域非常重要的一个引领者。早在TiDB 3.0起，PingCAP就正式转向HTAP，从OLTP主引擎+OLAP辅助能力，到OLTP引擎+外接分析引擎，再到OLTP引擎+融合分析引擎，PingCAP在HTAP领域稳打稳扎，一个版本上一个台阶。
如今，随着TiDB 6.0的发布，针对HTAP进行了更多成熟性改进，TPC-C 性能也较 5.0 版本提升达到 76.32%，TiDB 6.0还增强了多个企业级特性，以更好适合云时代用户对于HTAP数据库的需求。
固然，有人质疑当前HTAP是新瓶装旧酒，并无太多新意。但业界普遍形成共识：新一代HTAP与过去完全不同，开源+云孕育而出，很多都有AI加持，而且是为数据敏捷而生，拥有过去前所未有的创新活力与迭代速度，并逐渐形成数据库技术变革的新潮流。
PingCAP CTO 黄东旭也直言：“TiDB近年来的快速进化与迭代，得益于开源和云的助力。”
HTAP之所受到用户青睐，某种程度是因为用户对于数据敏捷性的极度渴求。
“在数字化时代，客户最为在乎的是如何快速走向市场。这需要数据敏捷性，而HTAP恰恰是数据敏捷的核心能力。”黄东旭如是说。
最近几年，“海量、实时、在线”的需求越来越广泛，大量采用 MySQL 和 PostgreSQL 开源数据库的新一代企业需要提升对于热数据的实时在线分析能力，这类需求遍布几乎所有的互联网企业以及从事线上业务的数字化转型企业。对于新鲜数据的实时分析能力直接决定了这些业务的生死存亡，传统的 OLTP+OLAP+ETL 的数据架构已经严重阻碍了消费者体验，这种诉求催生了 HTAP 的技术变革。
而真正帮助HTAP与用户需求完成对接的则是开源+云。众所周知，开源近年来在数据库领域的流行和影响力与日俱增，DB-Engines数据显示，全球383款数据库中开源数据库占据51.7%，六款开源数据库进入到前十，开源正在成为像HTAP这种新时代数据库的创新源泉。
以PingCAP的TiDB为例，其产品研发体系建立在开源体系和开源社区的基础上，实现了一年一个大版本、一个月一个小版本的迭代速度。黄东旭透露道：“开源是TiDB的第一个增长引擎，通过开源体系，开发者、贡献者、布道者和用户能够很好串联起来，形成飞轮效应，让产品能够走向加速迭代和创新的正向循环。”
据悉，TiDB每年会有超过 40% 的代码更新，而这些代码有很大一部分由外部贡献者所共享。TiDB开源项目一直在全球和中国开源项目活跃度中名列前茅。
如果说开源改变了HTAP产品的开发模式和迭代速度，那么云则能够为HTAP产品提供用户最为直接的需求反馈。众所周知，云数据库一改以往传统数据库部署、运维、扩展等难题，以云服务的方式让数据库使用更加简单；更加关键的是，随着云计算的普及，云上用户群体持续增加，来自云上用户群体的需求反馈无时无刻都在发生，对于数据库产品的进化与迭代至关重要。
“真正的产品迭代是如何缩短用户问题/需求的反馈时间。云无疑为数据库等基础软件提供了这样的价值，让产品可以更好地迭代。”黄东旭如是说。以TiDB为例，自去年五月全托管的数据库即服务（DBaaS）产品 TiDB Cloud 公测版发布以来，已经陆续登陆亚马逊云 科技 、谷歌云等全球知名云服务商的Marketplace，并在今年5月份正式全球商用；今年 6 月与阿里云合作上线阿里云云市场，成为为数不多的跨全球三朵云的数据库服务。
在众多数据库产品之中，MySQL凭借着开源、免费、适合互联网场景等优势，常年位居全球最受欢迎数据库的前三。根据Slintel网站的统计数据，在全球关系型数据库市场中，MySQL市场份额最高，达到43.04%。
过去二十年里，开源MySQL数据库对于各行各业影响至深，捕获了来自互联网、金融、零售、交通等多个行业用户的心，堪称“万人迷”。例如，在中国就有超过9成的金融机构都应用了MySQL数据库。
但任何数据库潮流都是“需求变化+技术变革+架构创新”融合的产物，MySQL是如此，HTAP亦不例外。如今，场景的数据规模、业务并发量、处理速度要求跟以往相比早已不是一个数量级。此时，MySQL数据库的局限性愈发突出，扩展性很难满足用户需求，想继续获得增长的企业不得不使用分库分表方案，但这又会造成数据架构的复杂性。
新一代HTAP数据库无需分库分表，且具备实时海量规模的OLTP和实时数据分析能力，还拥有极为出色的扩展性，与很多业务场景的海量交易实时数据展现、平稳运行的需求高度契合，HTAP凭借技术架构优势崛起已成必然。
“用户需求侧最大的变化就是很多用户需要借助热数据实现运营级别的实时分析，获得实时洞察以支持决策，这极大推动了新一代HTAP数据库的需求。”PingCAP副总裁刘松补充道。
虽然MySQL已经增加列存引擎Heatwave来获得HTAP能力，但主要解决规模化查询的问题，系统本身架构并未产生革命性变化，扩展能力、OLTP吞吐量依然有着很大局限。“智能新能源 汽车 跟传统燃油车在外表看几乎没区别。数据库也类似，像TiDB这种新一代HTAP数据库，从架构设计、应对场景和使用体验等角度，都与传统数据库有着极大的区别。”刘松形象比喻道。
事实上，与过去SAP HANA这种小众、昂贵的HTAP不同，新一代HTAP拥有极强的兼容性，像Google Cloud、PingCAP这些数据库厂商都借助新一代HTAP架构为采用 MySQL或者PG开源数据库的企业拓展 OLTP和OLAP的能力范围。
例如，Google Cloud发布的HTAP云端数据库AlloyDB，为单机版PG生态用户提供了最好选择，TiDB则成为MySQL生态的最佳归宿。PingCAP大量用户中有很多TiDB与MySQL混合部署的成功案例；得益于 TiDB 的开放性，TiDB 也可通过和其他数据服务产品“混搭”形成新的数据服务解决方案， 如通过同样是开源的大数据计算引擎 Flink 混搭形成实时数仓解决方案，扩展 HTAP 数据库的能力边界。
黄东旭则直言，HTAP数据库除了产品、技术之外，尤为需要关心用户体验，“HTAP应该让用户觉得好用，屏蔽掉数据库的复杂性。”据悉，PingCAP是2022 Gartner Peer Insights“Voice of the Customer” 云数据库领域唯一入选的中国数据库公司，客户总体评分达到 4.7 分（满分 5 分），在所有入选企业中位列第一。在参与Gartner Peer Insights评分的PingCAP用户中，像互联网、金融等重点行业用户均高度认可HTAP现代数据库理念。
总体来看，今年是HTAP的大年，各大厂商纷纷在市场中上新。随着新一代HTAP数据库产品的增多，整个市场对于HTAP数据库理念和产品的接受与采用将会提速。而随着新一代HTAP数据库持续完善，让广大MySQL生态用户群真正看到了大数据时代一条绝佳的迁移路径。
WPS成功上市代表了信息化企业软件国产化的趋势。在雷涛看来，WPS不是简单复制后替代Windows office，而是找到了下一代产品需求。
以往无论是运营商还是银行核心系统，大架构都垄断在西方的 IOE（IBM、Oracle、EMC）这三座大山里。直到2008年阿里提出去“IOE”运动，开始助推信息化软件国产化浪潮。
天云数据就是其中最早一批入场者。2010年为了建立中国完整的云计算产业链，中国宽带之父田溯宁投资建设云基地，天云数据便由此孵化，初备雏形。
2015年，雷涛带领创始团队们正式成立天云数据，率先切入金融领域。天云提供了国内领先的国产HTAP数据库Hubble，完成了“去IOE”中最困难的部分，替代金融A类核心系统惯用的西方IOE架构，在银行的联机事务中解决A类核心系统减负问题。此外，为了降低AI使用门槛，天云数据还推出AI PaaS平台MaximAI，逐步将数据价值逐渐扩展到能源、医药、军事等其它行业。
目前天云数据有70多家行业内大企业客户，单笔合同200-500万，纯软件年营收过亿。
融资方面，天云数据2018年曾获得曦域资本、华映资本B轮1亿人民币投资。
作为行业老兵，雷涛在北美跨国公司有20多年的技术管理经验， 2005年便入席SNIA存储工业协会中国区技术委员会联合主席，CCF中国计算机学会大数据专委会委员。
2011年在云基地时期，雷涛和创始团队通过BDP大数据平台负责了众多运营商业务，如联通的数据魔方、移动总部、南方基地等，2015年天云数据正式独立后，雷涛为了避免同业竞争，选择先聚焦在金融领域。
“天云数据的目标是替代 Oracle 和 SAS ”。云基地时期的积累让天云数据一开始就有高起点，首单就接下了光大银行的核心系统——OLTP线交易系统。比如银行能在全国所有营业厅实时实现OOTD交易，实时查询存钱取钱数额，整个环节涉及的技术都是天云数据早期对Oracle的一些替代。
但之后在多次的项目 *** 作过程中雷涛发现，在几百万条交易规格的强一致性下，数据的移动性、计算框架的变化、联机事务同时要做大规模并行计算，这对计算场景的通用性、即时性和全量数据要求极高，传统 Oracle架构根本无法适应。
“在Oracle架构之上，还需要升级满足新需求”。
于是天云数据自主研发HTAP国产分布式数据库Hubble。与传统 IT 架构处理失误需要联机分析和分开处理不同，HTAP 数据库能够在一份数据上同时支撑业务系统运行并做 OLAP 场景，避免在线与离线数据库之间大量的数据交互，为系统减负。
HTAP国产分布式数据库Hubble替代了Oracle一体机,核心表2000余张80T左右、400亿条交易数据、提供56只服务应用交易、满足500个用户并发、500ms交易服务响应、每天在线交易量超200万、占整个银行核心交易量的10%，让银行面向柜面系统可提供7*8小时A类实时核心交易，面向手机网银系统可提供7*24小时A类实时核心交易。
从集中式Oracle切换到分布式HTAP，也解决了数据库扩展性的问题。比如天云数据让光大银行解决了 历史 数据查询问题，以往 历史 查询只能查到2年前，但在分布式技术上线后，可以查询15年前所有交易数据，同时让银行柜面系统以及手机APP可以无数人同时查询。
而在BI逐步转向AI的过程中，复杂的商业流程经算法重构。过去要把数据拿到SAS平台先分析，一层一层地把数据提出来搭建。但现在通过分布式技术，流程趋于扁平化，可以实现毫秒级的服务响应。
天云数据一开始就撬动的是行业头部资源。目前天云数据有光大银行、兴业银行、中信银行、中泰证券、中国石油、国家统计局等70余家行业内大企业客户，分布在金融、能源、医药、政府军事等领域，单笔合同级别超百万
针对每个垂直行业，天云数据都会成立一个子公司来专注赛道。目前天云数据有160人，技术人员超六成。
在雷涛看来，如果一年600个项目，全是5万、15万等碎片化的订单，公司总是重复满足初级客户的简单需求，技术很难沉淀和深入。“在当下成长阶段，打造产品需要在用户想要什么和你想做什么中找到平衡”。
对于雷涛而言，专注头部大B发展有两大发展潜力。一方面，大B拥有机器学习的普遍能力和实验室，更容易接受新产品。另一方面，天云数据交付产品和交付服务的同时也在转移大B客户的数据价值。
“AI本身是一个知识生产过程，它能把大型企业规则、流程的经验价值快速地抽样出来进行复制，赋能行业内其它客户甚至类似的其它行业。”
但在头部客户更定制化、个性化的情况下，天云数据是否失去了很强的复制能力？
雷涛解释到，虽然每个企业要求不尽相同，但都在不大的池子里找数据库。企业从海量数据中对数据进行迁徙、清洗、去重，可以去找合适的AI方法让它产生业务的价值，此过程具有通用性。
谈到核心壁垒，雷涛认为天云数据壁垒就是数据的复制价值。
壁垒的构建可分为两个阶段。第一个阶段是前沿 科技 本身的壁垒，比的是效率和产品核心价值，谁能够扎得深和更好的交付，谁就能拔得头筹。而作为国内最早研发大数据和人工智能的团队，天云数据有一定的技术先发优势。
第二个阶段是推理端的服务。数据资源的价值需要通过机器学习进行提炼，形成知识，进而封装成推理服务服务于行业。比如某保险公司20年长周期发生的重疾赔付定价上学习出来的特征和内容能够快速地移植到保险行业，而头部大企业客户给天云数据带来很优质的训练数据库。
未来AI将引爆万亿级大市场，但目前渗透率不到1%，这给各企业留有众多机会和想象空间。但无论哪种圈地方式，最终比的是速度、服务的稳定性以及产品化的能力。
HTAP（Hybrid Transaction and Analytical Process，混合事务和分析处理）自 2014 年明确提出以后成为了很多数据库厂商努力的方向。其实 HATP 并不新鲜，早年 RDB 刚兴起时本来就是用一个数据库同时做事务和分析，但随着数据规模不断变大再直接基于业务库做分析就会影响业务，这时数据仓库出现了，将业务数据导入数据仓库来专门应对分析需求，同时与业务库隔离，这样不仅可以更好地服务分析场景，又不会对业务系统产生影响，这是“合久必分”的阶段。但是由于数据仓库将 历史 数据与实时数据分开了，有时经常还会采用异构数据库（或大数据平台），如果要分析实时全量数据（T+0）就非常困难了，而 T+0 又是很多及时性业务必须的，这就造成了“数据仓库之殇”。为了解决这个问题，能不能把 AP 和 TP 在一个数据库内同时满足呢？于是 HTAP 再次登场了，这又到了“分久必合”的阶段。
但我们知道，AP 和 TP 两个场景有显著不同，前者涉及的数据量很大，并且计算逻辑复杂，但并发量往往不大，没有数据一致性要求，甚至经常为了使用方便可以不满足范式；后者恰恰相反，数据量不大且数据处理逻辑简单，但并发量很大，有数据强一致性要求。从功能上讲，TP 数据库本来就能执行 SQL，也本来就具有一定的 AP 功能。当初之所以要把 TP 和 AP 分开，就是因为巨大数据量时，继续采用偏向 TP 的技术就不能高效地处理 AP 的需求（比如 AP 要求高性能需要使用列存，但 TP 为了写入更新便利需要使用行存），TP 和 AP 的这些巨大差异就决定了这两个场景不能采用一个技术体系来同时满足，而这件事到现在并没有实质性地改变。
即使如此，还是有一些厂商尝试在同一引擎中同时满足 TP 和 AP 的需求，实现上有几种方式。一种是采用多副本的方式，其中某一个副本（可能使用列存）专门用来满足 AP 的需求；一种是采用行列混合存储，行存和列存各一份，二者之间自动转换；还有一种方式可以不区分行列存储，通过单一存储引擎支撑 TP 和 AP 场景，常见的是某些内存数据库。这类 HTAP 数据库在实现上会优先满足 TP 的需要，在此基础上再发展 AP 的功能，因此在满足 AP 需求时相对一般专用的 AP 产品往往会有很大差距。
另一种 HTAP 数据库的做法是在底层仍然将两个场景分离，以“模块化”的方式来设计存储，业务数据产生后就会被复制两份（不考虑副本的情况），一份仍然使用行存用于交易，一份复制使用列存用于分析。相应的存储和计算再借助原本在 TP 和 AP 领域已经成熟的技术进行封装和优化，同时设计统一的对外访问接口，底层的差异对应用层完全透明，这样就形成了可用的 HTAP 产品。
无论采用哪种方式设计 HTAP 数据库，在应用时都会碰到一个问题，如果原来的业务数据库不是（大概率）采用 HTAP 数据库就要涉及数据库迁移，这将面临巨大的风险和成本。不仅要考量数据类型差异导致的数据结构迁移过程中需要进行改造和处理，还会涉及视图、存储过程以及复杂 SQL 的改造等，还有在迁移工程中遇到的种种问题要解决，可谓坑多且深。由此带来的业务影响可能会带来极大价值损耗。
此外，现代业务系统不仅涉及 RDB，还有 MongoDB、InfluxDB 等 NoSQL，以及各种自己封装的业务数据源，种类很多五花八门。这些数据源要迁移到新数据库就没那么简单了，像 MongoDB 数据转存到 RDB 会发现实现很困难。MongoDB 中的很多数据类型和集合之间的关系在 RDB 中并不存在，比如嵌入式的数据结构、数组和哈希等集合类型、多对多关系的实现。这些问题并不是简单通过数据迁移就能解决的，需要在迁移之前先对部分数据结构进行重构，这需要事先投入相当多的人工和时间成本去梳理业务并设计目标数据组织方式。即使最后花费很大代价把业务数据源迁移到 HTAP 上，原来那些多样性数据源自身的优势却又丧失了，得失之间有时甚至很难权衡是否值得。
我们知道，数据计算性能和数据组织密不可分，在 AP 类场景中通常要使用列存来发挥计算优势，但只有列存是远远不够的，有些复杂计算需要针对计算特点专门设计数据存储形式（比如有序存储、数据类型转换、预计算等）。而这些对性能要求高的复杂计算在 AP 类场景中并不少见，但无论采用何种方式的 HTAP，简单“自动化”地行存转列存并不能实现相对“个性化”的效果，性能往往无法达标。这个道理也很简单，天下没有什么都好的事儿，你想融合就必须容忍在某一或某些方面的不足。
迁移风险大、成本高、有损失、性能还可能不达标，考虑到这些问题，我们不禁会问：HTAP 数据库这个技术路线对吗？
说到这里我们再回头看一下 HTAP 的目的，为什么要用 HTAP？
其实就是为了进行全量数据实时查询统计，也就是 T+0！
如果数据仓库等相关技术能搞定这个问题，那自然也就不需要 HTAP 了。不过很遗憾，数据仓库仍然延用了关系数据库的封闭体系，数据要先入库才能计算，而且入库又有较强约束。这些导致数据仓库无法很好实现跨数据源尤其是异构和非关系型数据源的混合计算，很难实现 T+0 的目标。
但集算器 SPL 可以。
集算器 SPL（Structured Process Language），一个专门面向结构化数据计算的 开源 计算引擎和程序语言。除了提供了丰富的计算类库使其拥有不依赖数据库的独立计算能力外，SPL 可以对接多种数据源并完成多源混合计算，从而轻松完成跨数据源的 T+0 查询。
SPL 通过与现有系统融合的方式实现 HTAP，这样原有系统的改动很小，TP 部分几乎不动，甚至原有的 AP 数据源也可以继续工作，逐步使用 SPL 接管 AP 业务。SPL 部分或全部接管 AP 业务后， 历史 冷数据使用 SPL 高性能文件存储，原来针对业务库到数据仓库的 ETL 过程可以直接移植到 SPL 上。冷数据量大且不再变化使用 SPL 高性能文件存储可以获得更高地计算性能；热数据量小仍然存放在原有 TP 数据源中，SPL 直接读取计算，由于热数据量并不大，直接基于 TP 数据源查询也不会对其造成太大影响，访问时间也不会太长。再利用 SPL 的冷热数据混合计算能力，就可以获得针对全量数据的 T+0 实时查询。我们只要定期将变冷的数据固化到 SPL 的高性能存储中，原数据源只需要保持少量近期新产生的热数据即可。这样不仅实现了 HTAP，而且还是高性能的 HTAP，且对应用架构冲击很小。
现代信息系统中建设数据仓库等专门服务分析场景已然十分常见，加之数据源种类繁多，将这些数据都迁移到一处代价太大了，对于这点前文我们已经分析过。如果能在现有架构的基础上增加跨数据源的实时混合计算能力，就相当于插上了 HTAP 的翅膀，在不改变现有架构的情况下快速实现 HTAP 的需求，而这正是 SPL 的强项。
SPL 支持多种数据源，RDB、NoSQL 以及 RESTful 等都可以直接使用，还可以解析 JSON/XML 等类型数据，可以对接 Elasticsearch、Kafka 等数据源，此外传统 / 新兴数据仓库、大数据平台等也可以直接取数计算。
在对接的同时可以针对任意多种数据源进行混合计算，这样实时数据从生产库中读与取自 历史 库 / 数据仓库 / 大数据平台的冷数据混合计算就可以实现 T+0 全量实时数据查询。这样原有应用架构几乎不用变动（尤其是生产库）就可以获得 HTAP（架构层面）期望的效果，成本极低。
使用 SPL 在现有架构上输出 HTAP 能力还有一个好处是可以充分保留原有数据源的优势。NoSQL 仍然可以继续使用而不必强行将结构拉成 RDB 的形式，自己封装的数据访问与交互接口也不必费心去迁就新数据库，原来的优势与个性化仍然保持，风险很低的同时价值几乎没有损耗。
在分析侧也一样，基于 SPL 也可以继续使用原本建设好的分析平台。但如前所述，分析场景面临的数据量大且计算逻辑复杂，尤其需要高性能。SPL 还提供了高性能计算机制，可以全面接管原来分析侧（AP）的业务实现高性能数据计算。
我们知道，高性能计算涉及两方面，一个是数据组织方式即数据存储，另一个是算法，这二者密不可分，很多高性能算法需要将数据组织成相应格式（如有序）才能发挥作用。SPL 提供了自有的高性能存储机制，直接采用文件系统。将数据存储特定格式的文件中，不仅可以获得更高的 IO 存取效率以及文件系统灵活的管理能力，还可以充分利用自有格式的列存、有序、压缩、并行分段等数据存储优势，从而高效地发挥高性能算法效力。
而在算法方面，SPL 提供了十分丰富的高性能算法库。遍历复用、有序归并、外键预关联、标签位维度、并行计算等，都已经封装好，可以直接使用，配合 SPL 的存储机制就能获得高性能。而且这其中有很多算法都是 SPL 独创的，在业内也是首次提出。
如果简单地将 TP 中的行存转换成 SPL 中的列存，工作量也非常低。但为了获得高性能，常常还需要精心设计存储方式，这时，将会有一定量的 ETL 动作，但这个工作与原来从业务系统 ETL 数据到数据仓库基本是一样的，并不会更复杂，而且这个工作对于高性能是少不了的。和一般 HTAP 数据库很难实施经过有效设计的存储相比，SPL 将冷热数据分离后可以从容不迫地像以前 TP/AP 分离时那样实施更高效的存储组织，这样更能将 TP 和 AP 双边的性能发挥到极致。相对大幅的性能提升，数据组织的工作往往是值得的。
在实战中，使用 SPL 存储和算法提升数倍数十倍性能的案例很多。比如在某保险公司车险保单跑批的案例（ 开源 SPL 优化保险公司跑批优从 2 小时到 17 分钟 ）中，使用 SPL 将计算时间从 2 小时缩短到 17 分钟。这里使用 SPL 接管存储后再利用 SPL 特有的遍历复用技术（在对大数据的一次遍历过程中实现多种运算）有效地减少外了存访问量，同时将涉及对一个大表进行三次关联和汇总的运算只需要遍历一次（SQL 要将大表遍历三次），并在关联运算上采用了不同的算法，因此获得了巨大的性能提升。
还有在 开源 SPL 将银行手机账户查询的预先关联变成实时关联 的案例中，使用 SPL 将原本只能预关联的手机账户查询变成实时关联，同时服务器数量从 6 台降为 1 台。这里充分利用了 SPL 的有序存储机制，一次性读取整个账户数据时可以有效减少硬盘时间（物理存储连续），再借助区分维表和事实表的外键实时关联技术使用单机就能完成实时关联查询，性能提升明显，硬件需求也降低了许多。
基于 SPL 的 HTAP，并不止于 T+0 和高性能。
数据计算（主要指 OLAP 场景）一向有两个难点，跑得慢（性能）和写得简单（开发效率）。前者我们说过了，后者使用 SPL 还可以获得很大改善。
现在我们处理数据还主要基于 SQL（其他高级语言太麻烦），但 SQL 仍然有很多不好描述的运算，这个原因主要是 SQL 的理论限制，这里我们不多说，感兴趣的小伙伴可以阅读这篇文章： 写着简单跑得又快的数据库语言 SPL
鉴于 SQL 在复杂计算方面的描述能力（开发效率）太差，SPL 并没有沿用 SQL 体系，而是基于新的理论重新设计了一套敏捷计算语法，基于这个语法再实施计算尤其复杂计算会更有优势，写法也更简单。
我们可以通过电商系统中常见的漏斗运算来感受一下 SPL 的简洁性。
SQL（oracle）实现：
SPL 实现：
oracle 的 SQL 写出来要三十多行，理解起来有相当的难度。而且这段代码和漏斗的步骤数量相关，每增加一步数就要再增加一段子查询。这种 SQL，写出来就已经不易，性能优化更是无从谈起。
相比之下，SPL 就简单得多，处理任意步骤数都是这段代码。
好了，说到这里各位看官应该了解了，SPL 并不是一个 HTAP 数据库，而是提供了一种新思路来满足 HTAP 的需要。HTAP 数据库很热，厂商的宣传口号很容易让我们陷入只能使用一种数据库来解决 HTAP 问题的藩篱而不自知。但只要我们再多想一点就会发现，HTAP 是一种合理的业务需求，满足它或许并不需要一种新数据库，而是能够解决问题的新技术和架构，而 SPL 提供了这种可能。
SPL下载地址：http://c.raqsoft.com.cn/article/1595816810031
SPL开源地址：https://github.com/SPLWare/esProc
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）