过去一个月里,堪称国产数据库又一高光时刻。
这边厢PingCAP刚刚发布面向企业级核心场景、具备完整 HTAP 能力的分布式数据库TiDB 5.0 版本;那边厢OceanBase也紧跟着推出3.0版本,主攻方向亦是HTAP分布式数据库,在GitHub Oceanbase标注自己为“ The leading Scalable HTAP Database” , 并且又玩了一把TPC-H打榜第一的套路(后续:其成绩很快被超过)。
可能有人会质疑TPC-C和TPC-H的测试价值,毕竟这是两个历史悠久的测试标准,参考价值成疑。OceanBase如果能在TPC-DS上取得好成绩会更有说服力。不过OceanBase自带阿里&蚂蚁光环,属于招黑体质,一举一动都容易引来争议,但敢于在国际舞台亮剑,何尝不是国产数据库的荣耀,所以也无须过于苛刻。
闲言少叙,PingCAP和OceanBase把HTAP这个词彻底带火了。5月28日宣布开源计划的阿里云PolarDB也谈及HTAP,连Oracle上周都发了一篇HTAP的文章。PingCAP近年来一直都是HTAP信徒,大力宣传无可厚非;而OceanBase从传统意义上讲,大家普遍认为它聚焦在OLTP数据库领域,为何这次也大张旗鼓的喊出HTAP口号?
个中玄机,还得从HTAP的历史说起。
HTAP:鱼和熊掌可兼得
HTAP(Hybrid Transaction and Analytical Processing,混合事务和分析处理)就是能够将在线事务处理(On-Line Transactional Processing,简称OLTP) 和在线数据分析 (On-Line Analytical Processing,简称OLAP) 请求在同一个数据库系统中完成。
正所谓天下大势,分久必合合久必分。此话放在数据库领域一样适用。HTAP的确不是一个很新的概念,纵观数据库五十余年的发展历程,OLTP和OLAP两种需求在其中经历了漫长的融合-分离-再融合的过程。
2005年,Gartner正式提出了HTAP这一概念,并且迅速引起了一些企业的关注,被视为是未来数据发展的重要趋势之一。转眼到了2014年,Gartner又对HTAP数据库给出了明确的定义:即需要同时支持OLTP和OLAP场景,基于创新的计算存储框架,在同一份数据上保证事务的同时支持实时分析,省去费时的ETL过程。
彼时,正是大数据兴起之际,人们对于数据及其价值有着重新的认识与认知;另一方面,多核处理器、闪存等硬件技术的高速发展,也让人们逐渐意识到数据库设计是时候重新设计了,在同一数据库处理OLTP和OLAP请求的可行性大幅提升。
所以,作为国产数据库的两大代表,PingCAP和OceanBase齐刷刷瞄准HTAP,的确是摸准了时代的脉搏。但今天的HTAP已经与过去大不相同,数据资源、数据消费习惯以及数据架构的颠覆性变化,既赋予了HTAP新时代的内涵,也让HTAP承担起更重大的责任。
HTAP因数而变
为什么HTAP会变得如此炎手可热?
原因始终绕不开一个“数”字。如果仔细研究Gartner关于HTAP的定义,我们会发现“同时支持OLTP和OLAP、创新计算存储框架、去掉ETL”这几大关键词都跟“数据”密切相关,其背后是数据资源、数据消费习惯以及数据架构颠覆性的改变。
首先,数据产生方式、规模、速度与过去大不同。以行为和机器产生的非结构化/半结构化数据正在成为数据增长的主力军,这些数据无论是数据规模、密集度、产生速度都远超交易型的结构化数据;这也直接驱动着HTAP场景在未来会更加丰富化。
其次,实时性的数据消费正在成为新常态,数据消费的人群规模、场景丰富程度迅速增加,无论是最终消费者,还是企业员工都有数据消费需求,驱动着OLTP场景与OLAP场景互相渗透,彼此之间的界限变得模糊。
例如,一个快消品的调研员,会通过手持终端设备随时随地了解产品销售情况和预测销售趋势,进而根据数据做出相应决策;一个基金经理往往需要随时根据客户资产净值、交易频次变化、金融产品销售情况等一系列数据服务,来有针对性进行营销决策……而这些决定常常需要几分钟甚至几秒钟内完成,实时性需求成为新一代HTAP的刚需。
过去,OLTP场景仅仅负责产生数据,数据往往需要搬运到数据仓库或者机器学习平台进行数据消费,数据消费人群也仅仅是数据仓库管理员、决策层等少数人群;现在,在数据驱动型场景大幅增加的加持下,人人都是随时随地的数据消费者,极大推动OLTP场景与OLAP场景的融合。
第三,数据驱动型场景的井喷式出现,让计算与数据两个角色出现变化,过去一直都是以计算为核心,而数据驱动型场景则是以数据为核心,核心角色的转变意味着数据架构将发生彻底改变。
所以这就涉及到一个核心问题:即在OLTP场景和OLAP场景加速融合的趋势下,在架构层到底是Move Data还是Move Code。过去,OLTP场景产生数据之后,往往需要通过ETL将数据导入到数据仓库,然后在数据仓库中建模、ODS、建立报表,如果涉及到需要应用到机器学习,还需要将数据导入到机器学习平台,数据移动次数已经足够频繁。现在,OLTP场景和OLAP场景加速融合,BI呈现和AI操作服务实时化,数据互相移动将更加频繁,这无疑对于数据架构带来极大挑战。
关于数据移动,AWS有一个经典的描述:AWS认为随着数据量的不断增加,数据的往来移动操作变得越来越困难,称之为“数据重力”现象。要想解决“数据重力”现象,AWS的做法类似Move Data,针对每个场景有专用数据库,并且集成Athena、Glue等工具集,让ETL等移动操作更加集成化、自动化和高效化。这种模式比较适合大型互联网企业,拥有比较强大的技术团队。
另一种则是Move Code,通过HTAP这种融合的数据平台,在一份数据上同时支撑业务系统运行并实现OLAP 场景,缩短数据移动路径,让数据不再搬家,就地实现OLTP场景和OLAP场景的融合。这个更符合大多数企业,尤其是企业数字化转型的需求。
本质上,HTAP的做法更具变革性,打破了OLTP场景和OLAP场景之间过去传统的分界线,大幅提升大数据体系下数据实时处理和分析计算能力;另一方面,通过分布式架构,也彻底解决了过去困扰传统数据库、数据仓库多年的性能、扩展性,实时性等难题。
但HTAP虽好,但实现起来却没有那么简单。这里不能不提PingCAP,其在HTAP上的战略布局显然更快人一步,随着TiDB 5.0的发布,也标志着国产数据库厂商在HTAP领域占领先机。
都是HTAP,哪些趋势不能忽视
事实上,不光是PingCAP和OceanBase在搞HTAP,Oracle、GreenPlum这些传统数据库时代的大咖也在聚焦HTAP。
都是HTAP,哪些才是真正代表着HTAP的趋势呢?
其一,产品架构上需要对未来做好准备,HTAP本质上已经开始逐渐演变成一体化数据服务平台,其多元化场景决定了绝非是OLTP和OLAP简单叠加,如果通过OLTP架构外扩实现OLAP,显然只能算权宜之计,不能代表面向未来的架构。用户在分布式数据库和大数据技术的融合也产生了广泛意义的HTAP的需求,长远来看,HTAP会成为数字化时代一种普遍性的需求。
以PingCAP为例,其TiDB 4.0就是一款为HTAP而设计的分布式数据库,到了5.0版本,在TiFlash引入MPP模式与多项企业级特性的增加,使得TiDB 5.0发展为“一栈式数据服务平台”。
其二,开源生态决定基础,数据库作为重要的基础软件,HTAP数据库未来需要在成百上千的场景中打磨,过去那种封闭模式不管是技术迭代还是用户增长都是举步维艰,走向开放开源的生态之路已经是大势所趋。比如,TiDB5.0发布会“TiDB+FIink”的混合架构突破了狭义HTAP的范围,开启了“分布式数据+大数据技术栈”的HTAP生态模式。
未来,将开源战略作为核心战略、构建高度活跃的开源社区将会是HTAP数据库的长远目标。
其三,拥抱云是未来,需要支持云原生架构,充分利用云原生技术轻量化、松耦合、灵活度高等优势,另外还实现跨云与多云部署。
同样,TiDB 5.0在这方面也做出了榜样,基于云原生架构的TiDB 5.0能够充分发挥云资源的能力,PingCAP在海外市场推出了TiDB Cloud服务,坚定拥抱云路线。国内也有很多客户在云原生架构中采用TiDB构建云原生技术栈。
HTAP将是新蓝海
既然HTAP如此火热,那么它会取代以Oracle为代表的关系型数据库或者传统数据仓库么?
在笔者看来,HTAP虽然不是一个很新的概念,却是一个新的蓝海市场,它代表着数据驱动型场景井喷之后,用户在数据处理、消费整个需求的迭代升级,HTAP的兴起意味着一个新的数据库蓝海市场正在逐步形成。
因此,单纯的谈论HTAP点对点的取代关系型数据库或者传统数据仓库其实并无太大意义,HTAP也不应该成为国产化替代的一个“借口”,它更像一条新的数据库赛道,给予了像PingCAP、OceanBase这些后起之秀更多市场机会,让它们看到了抓住新需求的机遇,以及打破数据库市场垄断局面的希望。
从更大的范围来看,新一代HTAP,正在成为分布式数据库与大数据栈融合的明珠,我们甚至可以预见,未来的HTAP不再是数据库的一个技术术语,而是成为一种以融合简化方式构建数据栈的一种方式。
总体来看,HTAP现在很火,市场既有像PingCAP这样具有前瞻性的新锐数据库创新企业,也有OceanBase这种自带光环的明星数据库公司,还有Oracle这样的大鳄,未来竞争必然会愈发激烈。对于中国数据库厂商而言,路很长、未来很远,砥砺前行,且行且珍惜。