由纷争到融合,实时数仓演绎“战国时代”

时间:2022-11-27 01:27:03

群雄并起,诸侯纷争,实时数仓今天的发展现状,像极了“战国时代”。

如果说,战国是齐、楚、燕、韩、赵、魏、秦七国实力比拼;那么,与之类似的实时数仓,是流批一体、湖仓一体、云数仓、HTAP数据库等多种技术路线并存。不同的是,战国是乱世,霸主们为生存而进行了一系列探索与努力,英雄大多以悲剧收场;而实时数仓则恰逢数智化盛世,在追求数据处理速度这条道路上,催生出百家争鸣。

星星之火

所谓 “天下大事合久必分,分久必合”,数据仓库经历30多年的发展后,开始出现分裂,以高吞吐、低延时、全链路实时加工为主要特征的实时数仓,诞生于大数据时代,并以星火燎原之势向互联网、金融、游戏、电商等领域蔓延。

事实上,实时数仓虽然是新提法,但不是一个新需求。PostgreSQL ACE Director、南京基石数据技术有限责任公司CTO 白鳝(徐戟),在接受IT168&ITPUB 实时数仓系列专访时表示:早在20年前,在设计新一代金融交易系统时,就有人想基于客户画像提供个性化服务,包括可以基于历史数据进行分析,了解用户登录系统时的位置、时间、上网方式等,但那个时候受技术条件限制,无法做实时的指标分析。

那么,30年前的技术条件是什么水平呢?欧冶云商股份有限公司首席数据架构师 薛晓刚 ,则以存储为切入点,说明实时数仓的快速发展,是技术和业务双重推动的结果!

2000年左右,当时是1.44寸软盘。那个年代,硬盘驱动器只有1个G,读取速度也比较慢,只有4.5MB/秒。之后,随着存储技术的进步,出现了U盘,1TB级别的磁盘驱动器,再正常不过,但数据传输速度依然满足不了需求,只有 100 MB/s左右,这意味着用户需要花费半个小时以上的时间,才能读取整个驱动器的数据。

此种背景下,谷歌在2003年发表了三篇论文:分别是《GFS》(大型分布式文件系统)、《MapReduce》(大型集群海量数据处理分布式编程模型)、《BigTable》(结构化数据分布式存储系统),标准着大数据时代来临。但从硬件角度看,以hadoop为代表的离线分析,还处于磁头寻道的阶段,通过分布式计算可以“变道超车”,改变之前磁盘IO慢的问题。

如今,随着硬件及其相关技术的发展,我们已经跨越GB级磁盘阶段,单盘SSD已经出现几十个TB级别的产品,IO的瓶颈不再那么明显,处理速度已经提升了万倍,数据处理量可以是TB级别,甚至出现了非易失性内存。

当技术条件足够成熟,企业可以在线处理TB或PB级数据,过去那种离线分析模式很明显已跟不上时代。尤其在数字化转型过程中,企业需要对市场做出快速反应,不管是报表分析(实时数据大盘),还是用户画像(推荐),都会有时间要求。对于后端支撑的数据仓库来说,在线交易完成后,企业可以马上将这些数据进行分析和处理,结合交易快速得出一些判断,进而辅助业务决策,这便是实时数仓最初诞生的 “摇篮”。

寻求新秩序

问题是,实时数仓到底是什么?是一款产品,还是一个解决方案?实时数仓系列专访调研了诸多专家、用户和服务商!

从梳理结果来看,有人说是一款产品,比如:阿里云提供的Hologres;有人说是一套解决方案,比如:星环科技的ArgoDB+ Slipstream,通过“混合架构+统一计算引擎+统一存储管理”形成了一整套方案。与此同时,还有一个方向,看上去不是纯粹的数仓产品或者解决方案,比如:滴普科技的FastData DLink,是通过“标准分层+流计算+批量计算+数据湖”实现了湖仓一体;另外,有很多企业则通过HTAP数据库这种混合架构,满足实时数仓的业务需求,比如:亚信的AntDB数据库、天云数据的Hubble数据库,走的都是HTAP路线。

除了阿里云,还有腾讯云、金山云等这类云数仓,则通过云原生、存算分离、无服务器的形式,实现了数据实时处理目标。包括很多国产数据库,也已经融合了Flink、Spark这样的计算框架,数据过来以后,可以实现行存和列存的自动转换。

最后一个梯队,传统数仓此刻也不会被“立刻革命”,在没有实际 CDC 功能的场景下,传统数仓一般基于 Kafka 里的流式数据生成 ODS、DWD、DWS 的各层数据,以便于查询实时的数据,同时以小时/天粒度修复ETL数据管道,这种近实时以及准实时数仓解决方案,也可以满足部分用户的需求。

业界有一种说法是,企业IT领域纷繁复杂,概念多到可以超过时尚行业。从实时数仓概念火爆,到真正在企业场景落地,每个人都有自己的看法,短期内无法达成统一。但任何事物的出现,都不是一蹴而就,如果单纯从数仓发展来看,我们可以概括出几个重要阶段。第一,数仓阶段;第二,大数据阶段;第三,大数据和MPP数据库并存的阶段;第四,以 Snowflake为代表的云数仓,近似于实时数仓这样一个概念;第五,Databricks重新定义了湖仓一体的概念,即围绕数仓的能力,打造出全新的实时数仓的状态;第六,流批一体阶段,用户可以基于一套架构解决流和批的场景问题,进而满足复杂业务需求。

整体来看,虽然各家技术路线不同,短期内无法实现统一,但最终目标一致,那就是让企业的数据分析变得更快、更易用。一般来说,实时数仓的数据展示能力都不是T+1天的更新频率,而是T+1秒,其中秒级响应,也不一定就是1秒,3-5秒用户也可以接受。我们还发现,大多数实时数仓都是以解决方案的形式呈现,通过很多自研或者开源技术,打通数据的采集、计算、加工处理等不同环节,进而满足时效性要求。

合纵连横

当实时数仓遍地开花,各条技术路线之间是怎样一种关系呢?虽然这一时期的外在表现是“大分裂”,但绝对不是各自为政,而是相互融合!

随着实时计算技术不断发展,Storm、Flink等实时流计算引擎逐渐发展起来,实时计算框架由原来的流批分离的Lambda架构,发展到流批一体的Kappa架构,且新的架构也在不断涌现。在大数据资深人士 数据一哥 看来,虽然离线大数据架构已不能满足实时需求,逐渐被新一代数据架构取代,但不意味着离线需求也跟着消失,这也是由Flink的火热带出的流批一体架构出现的根本原因。

以快手为例,企业最初也是Lambda架构,拥有成熟的离线计算方案,但缺点是不能满足实时需求,所以另外引入了一条实时链路,这样导致企业需要提供两套计算引擎,一个提供Streaming能力,一个提供Batch能力,不同引擎提供的API不同,需要两套业务开发逻辑,很难保证一致性的计算结果。为了解决Lambda的问题,企业最初通过Bean引入统一的API,但无法解决复杂的流批一体场景。之后,企业引入了Spark,通过批来模拟流,以达到实时计算目标,但无法满足极致的实时计算需求。之后,Flink成为流计算引擎的事实标准,快手进行了大胆尝试,率先在机器学习和数据集成场景引入Flink Streaming,最终实现了计算和存储引擎的统一,通过流批融合提供一致性体验。

同样,湖仓一体、HTAP都是混合架构下的典型模式,包括MPP数据库和云数仓,其实也在相互融合,满足特定场景需求。目前,HTAP已经是很多国产数据库的标配,很多人甚至认为HTAP是解决实时数仓问题的有效手段。至于,是不是真的做到了,我们还需要拭目以待。另外,湖仓一体、云与AI的结合,都是实时数仓走向开放式架构的典型特征,最终谁能具备更快的数据加工能力,在短时间内满足用户的数据消费需求,谁就能赢得市场。

需要重点强调是,诸多技术路线,各有优势,也会有缺点。但既然是实时数仓,首先在线交易就要达成实时,否则和离线相比没有太多优势。其次,要具备统一的存储能力,如果存储问题不解决,最终也会影响数据分析结果。其三,实时数仓考验的是强大的运算处理能力,如何将数据更好地进行运算和处理,是实时数仓落地过程中必须要面对的问题。

由纷争到融合,实时数仓演绎“战国时代”

最后,针对不同技术路线,不同用户是如何一步步落地的,我们需要结合具体的业务场景进行尝试和探索,为了寻找更多“灯塔”类用户,寻找行业优秀解决方案,IT168&ITPUB搭建了实时数仓选型指南专区(实时数仓选型指南-ITpub), 最终我们梳理出近十家客户的实践案例,和近二十家服务提供商的解决方案,并且未来还会持续更新,希望能为企业和用户搭建良性互动和沟通平台,以推动实时数仓走向更高阶段。

通过实时数仓变法图强, 2023精彩还在继续,《实时数仓选型指南》将以电子书的形式,推送给更多行业用户,具体内容敬请期待!