看场景、重实操,实时数仓不是“纸上谈兵”

原创
2022/12/07 16:28
阅读数 1.2K

本文转载自阿里云Hologres产品负责人合一在ITPUB的访谈,谈谈他眼中的实时数仓

这两年,企业IT领域掀起实时数仓热潮。然而,只要稍做梳理就会发现,实时数仓格局未定,各种流派群雄逐鹿,还有很多需要进一步探讨的话题方向。

比如:实时数仓是什么?如何从概念上去定义?有人认为,传统数据仓库做了实时化,就是实时数仓;有人认为,云数仓、湖仓一体是实时数仓;还有人认为,HTAP是解决实时数仓需求的一个重要手段!

再比如:实时数仓是一款产品,还是一个解决方案?99%的企业都会认为是一个解决方案,1%的企业会认为是一款产品,这1%就是阿里云!

为了弄清事实真相,帮助用户找到应用选型“快速通道”,本期实时数仓系列访谈,特邀请到阿里云自研大数据平台产品负责人刘一鸣(合一),请他从实时数仓的技术演进、应用场景、架构以及Hologres自身实践角度,一层一层揭开实时数仓的“谜团”!

阿里云自研大数据平台产品负责人刘一鸣(合一)

实时数仓进化

如果,非要给实时数仓下一个定义,一定要符合从1.0到3.0时代的进化特征。

首先,得是一个数仓,具备规模数据的交互式分析能力。实时数仓不只是“实时”,很多系统不支持标准SQL,不能算数仓。所以,属于1.0时代的实时数仓,有一个重要前提,就是支持较为完善的SQL以及优秀的大规模分析能力,因此很多系统采用了分布式、列存、索引、压缩等数仓加速的技术。

其次,面向实时场景做了针对性优化,包括实时写入、实时分析、实时取数等。如果和普通数据库相同,没有针对实时场景做优化,很难达到实时数仓对吞吐和分析的时效性要求。实时数仓需要具备高吞吐写入和更新能力,数据写入即可用,支持灵活的数据更新。比如:很多普通数据库,虽然能写也能查,但当数据规模放大到一定规模,要么牺牲了写入性能保查询,要么牺牲了查询性能优化写入,无法针对实时数据多场景进行优化,这不能算好的实时数仓。

进入2.0时代,实时数仓就要尽可能快地支持在线业务。企业之所以做实时数仓,是希望数据进来之后能够被足够新鲜地消费,能实时写入、实时分析,还要支撑在线服务。在线服务场景需要更高的性能、低抖动、稳定性、并发能力,对在线服务场景进行支持,是实时数仓关键一环。

而3.0时代的实时数仓,可以定义为一站式实时数仓。这个时候的实时数仓,不仅具有高吞吐写入与更新、端到端的全链路实时加工以及低延迟高并发在线服务能力,在保证数据一致的前提下,需要支持多种负载之间完备的隔离和弹性能力,以确保各个业务互不干扰,各自按需使用资源。同时实时数仓的使用通常离不开离线数仓的组合关系,通过离线平台对历史数据的周期性汇聚、抽象和加工,并将结果数据导入实时数仓进行丰富和修正,需要更有效地打通实时与离线两套系统,实现元数据和数据的无缝交换,这也是实时数仓落地时需要具备的能力。这种一站式体现在存储状态的一致性,减少了不同负载之间的数据同步和存储开销,避免了数据服务层的数据孤岛难题。

所以,实时数仓既不是传统数据库的旧瓶装新酒,也不是湖仓一体的多产品组合,它和离线数仓的本质区别是,通过对易变数据结构(包括内存结构、文件存储)和计算资源的细粒度灵活管控,更好地支撑数据的实时写入、实时更新、实时查询 至于,很多公司之所以把实时数仓定义为是一个解决方案,是因为技术相对更加复杂,既要考虑写入和加工能力,又要支持查询和在线分析场景,不得已针对不同技术需求将多种技术栈堆砌在一起,包括采用流式计算、消息中间件来达到端到端的实时加工,采用列式数据库应对分析需求,采用行存系统支撑在线服务系统,并依赖复杂的调度配置,实现数据在中间件、存储系统之间的最终一致性。而将复杂技术落地成为一款易于使用的成熟数仓产品,仍然是少数技术创新者在努力的方向。

阿里云Hologres,整体技术水平领先业界1-2年,是基于在阿里巴巴内部数据技术的广泛应用与沉淀,一步一步走过来的。阿里有海量数据的复杂应用场景,有历年双11等大促的深度压力测试,有在存储和计算领域深扎多年的技术专家,有上万名数据小二支持业务的灵活需求与快速迭代,这些都是其他公司不具备的得天独厚的条件,推动着阿里在数据技术领域的持续创新。

Hologres支撑的业务的规模、复杂性和对效率的极致追求,实现了通过有些开源技术组合无法达成的数据价值目标。行业内不少企业采用部分开源技术栈,如:用Kafka做中间件,用Hudi做离线存储,用Presto做离线查询加速,用ClickHouse做OLAP查询,用Flink做流式数据加工,用MySQL做缓存,用HBase做在线服务引擎。这些架构也是阿里采用过的第一代实时数仓架构,但当开发效率遇到瓶颈时,当数据链路复杂到成为运维负担时,当数据不一致不得不80%时间在对数排查时,工程师们开始思考是否还有更好的解决方案,是否有一个更加集中化、一体化、能力更全面的数仓选择。而Hologres的出现也就重新定义了实时数仓的形态。

基于此,OLAP查询和在线服务使用Hologres,满足分析的灵活和效率,离线数仓使用MaxCompute,支撑规模性和Serverless扩展性,实时流式计算用Flink,凸显端到端全实时加工,三者的结合让实时和离线计算,分析和服务都能达到一个非常好的平衡,满足业务的多种需求。

阿里云Flink版的出处与Hologres的渊源

有人可能会说,阿里云Hologres+Flink这套组合也用了Flink,和其他解决方案相比,有什么不同呢?

没错,Hologres要想发挥最佳水平,与Flink结合,一定是首选。实时计算需要后台有一套强大的大数据计算能力,而Apache Flink作为一款开源大数据流式计算技术,从设计之初就由流计算开启,相比传统的Hadoop、Spark等计算引擎,更能确保数据处理的低延时,让数据在第一时间发挥价值。

早在2016年,Apache Flink捐献给Apache之后的第三年,阿里已经开始大规模上线使用实时计算产品,用于阿里最核心的搜索推荐以及广告业务场景。2017年,基于Flink的实时计算产品,开始服务于整个阿里巴巴集团,同年双11服务全集团的数据实时化,包括双11的实时大屏。2018年,基于Flink的实时计算平台产品不仅服务于集团内部,同时开始服务于云上中小企业,以公有云的形式对外提供服务。2019年,阿里巴巴收购了Flink的创始公司-Ververica,阿里的Flink实时计算技术团队和德国总部的Flink创始团队,组成全球顶领先的Flink技术团队,共同推进整个Apache Flink开源社区的发展。

用户通过Flink可以把数据实时写入到Hologres,也可以通过Hologres做维表关联。如此一来,离线分析走MaxCompute,数据的点查、联邦分析以及OLAP分析走Hologres。举一个维表加工的例子,Flink每次加工进来之后,每一条事件都要跟维表做关联,比如:事件数据中包含了渠道ID,在分析时需要知道是什么渠道类型,因为要通过加工链路将ID还原为渠道属性,这种关联有时候每秒钟要达到上万、上十万的 QPS。过去,很多业务团队采用HBase来支撑这类点查业务,但HBase没有 Schema,数据写错很难发现,很难修正;现在,Hologres只用过去50% 的资源,支撑了HBase完整的业务。

与开源Flink相比,阿里的实时计算Flink版进行了多处核心功能的优化,在存储、网络和传输等方面都调整到满足业务场景所需要的效果。并且,阿里云Flink版和Hologres做了大量的结合优化工作,不仅支持维表到结果表,也支持通过阿里云Flink的全量读取、Binlog 读取、CDC 读取、全增量一体化等多种方式读取 Hologres 源表数据,尤其是阿里云Flink支持读取Hologres Binlog,就使得Hologres能够达到像Kafka等消息中间件同等的能力,一个 Hologres Table 的数据既可以提供给下游阿里云 Flink 任务消费,还可以对接上游 OLAP/在线服务查询,不仅节省了成本,还简化数仓架构,同时也让数仓中的每一个层次都可以实时构建、实时查询,提升数据的流转效率。在元数据管理方面,阿里云Flink版与Hologres元数据打通,支持Hologres Catalog,实现元数据的自动发现和管理,也大大简化了开发和运维管理工作。

HSAP分析服务一体化的独特之处

Hologres是两个英文单词的组合,即Holographic+Postgres,Holographic来源于物理学,Postgres代表的是PostgreSQL生态。

从物理学原理看,地球没有被黑洞吸进去,是因为有一个临界点,这个临界点所组成的面,被证明是一个球面,也叫世界面。与此同时,黑洞里所有信息在世界面上都有投影,即3D全息投影技术。Hologres想做的事情是,通过产品化的能力对数据黑洞做全息展示。

合一1.png

为了简化数据存储和统一数据服务,阿里云提出了HSAP架构理论 (Hybrid Serving & Analytical Processing,后续简称HSAP),而Hologres是实践HSAP目标的一个具体实现。Hologres的目标是,做分析服务一体化的实时数仓,典型特征是:存算分离的云原生架构、多负载隔离、端到端实时毫秒级的交互式分析体验、超高QPS的在线服务能力等。从应用场景来看,既可满足实时数仓的需求,也能对离线数据进行查询加速,同时还可实现实时与离线数据的联邦计算,为用户构筑全链路、精细化运营能力。

为什么说分析服务一体化能力特别重要呢?

以广告推荐为例,这是一个非常典型的在线服务场景,如果一个人收藏了一个链接,他就会获得相应的广告推荐,该推荐包含了你过去30 天、60天或者90 天里的行为,还包括你的教育程度、家庭关系,这些是典型的离线特征。对于后端技术平台来说,这些行为不用每天去算,每周算一次就可以。但另一部分特征是实时的,比如你当下点了什么内容,对什么感兴趣,跳转了什么链接,这部分行为就需要通过Flink 这样的流式计算实时处理。只有把实时和离线两部分信息结合起来做推荐,才有全面的360信息,使得推荐更加精准,更加具备上下文相关性。

过去,没有Hologres之前,如果一个大数据系统要支撑广告推荐业务需要写一条很长的链路,反复同步数据,这很难提供灵活敏捷的数据服务,大量数据作业开发成本很高,出现数据不一致等问题。阿里的工程师尝试把问题简化,让数据不动,通过Flink或者MaxCompute加工好的数据,直接提供在线服务,这就需要把Serving场景做强,面向应用程序,或者面向API 消费数据的场景时,要有高QPS、低延迟能力。

而针对Analytics能力,很多企业都会基于OLAP引擎做数据分析。这部分数据一般会有两个出口:一个出口是给机器使用,通过API访问,主要是推荐系统和风控系统;另一个出口是给分析师使用,通过SQL访问,看报表,做对比分析,找到趋势变化。这两个出口的数据需要保持一致性。Hologres作为交互式分析引擎,针对两个场景做了执行优化。在支持在线的高 QPS 服务型查询时,这类查询逻辑相对简单,但并发高,因此采用了Short-Cut技术,通过FixedPlan执行优化,减少在SQL解析优化和调度层的开销,请求直达存储节点,延迟更短;在支持分析师的复杂多维分析时,采用MPP分布式计算框架、列式存储和向量化引擎,有效率大范围过滤数据,保障了亿级数据的秒级数据分析。这样,通过Hologres统一数据服务出口,同时支持在线服务和多维分析两个场景。

Hologres借鉴了主流的数据架构,包括采用类似LSM-tree(Log-Structured Merge Tree)这种高吞吐写入和更新友好的存储架构,利用了CPU指令向量化、异步化的最新技术创新,基于云原生的计算存储分离架构,形成了一款低门槛的生产级产品。Hologres在协议层面上用到了PostgreSQL的这种协议,简化了与业务系统的对接,应用无需重写,也没有厂商引擎绑定,开箱即用,核心的存储引擎、查询引擎是阿里自研的一套系统,持续改进效率、稳定和易用。

Lambda 与Kappa的纷争

其实,最早阿里云没想到要做实时数仓,只是想把实时和离线数据实现一体化。

换言之,阿里云的HSAP架构也是由Lambda架构走过来的。众所周知,Lambda架构有一个优势,既支持流式数仓,又能满足离线数仓的计算要求;但是也有一个弊端,就是流和批分为两套技术栈,运维要维护两套系统架构。后来,Kappa架构出现,有人认为能很好地解决Lambda架构的问题,但事实并非如此。因为企业的数据加工永远会有实时和离线两条链路,这是数据加工作业的属性决定的。实时链路数据总会晚来,或者不来,数据质量并不可靠。所以,只有实时链路,解决不了数据质量问题,还需要离线链路对实时链路的修正和丰富,而依赖消息中间件支撑海量数据的回刷是成本极高及不稳定的架构。也就是说,只要有离线场景,Lambda架构就有存在的合理性。

但问题是,Lambda架构一定需要两套系统,这该如何解决?本质上,还是技术的割裂,导致架构不统一。好的Lambda架构,应该是状态层统一的,实时的业务逻辑和离线的业务逻辑尽管加工链路不同,但存储层应该统一,减少数据割裂和不一致,通过实时和离线两套业务逻辑相互补充,离线的业务逻辑对实时数据链路进行修正。

在Lambda架构实践过程中,很多企业实时业务用HBase,离线业务用Hive,这种存储割裂状态,导致数据不一致,口径不一致。正确的架构选择应该是Lambda的改进版,把数据状态统一存储在一个存储系统,这个存储同时支持离线批量导入,也支持实时更新与查询,这也是一种可落地的批流一体实践。

虽然,有些企业在推Kappa,但从实践的角度看,Kappa其实是个伪概念,因为实时业务系统如果取代离线,意味着数据要频繁地修正、更新,而Kappa无法从根本上解决这个问题。目前,推Kappa架构的企业,大部分是消息中间件厂商,或者一些纯粹做实时的团队。他们假设了一种状态,所有的数据都可以通过消息中间件恢复。但现实是,企业不会把所有的状态都通过消息中间件去回放,或者长期存储。所以,通过消息中间件替代数据库的方式,只有消息中间件厂商在力推,不具备广泛落地的参考意义。

在阿里内部,HSAP架构把分析和服务两个场景放在一起,解决了数据不一致问题,减少了数据同步的开销,避免了数据孤岛,数据加工链路保持了实时和离线双链路,实时业务系统解决时效性问题,离线可以为实时业务系统进行修正和丰富,两条链路各解决各自的问题,使得实时和离线由一套系统承载,也就真正实现了流批一体。

下一代实时数仓更重实操

到今天为止,Hologres作为标准产品对外提供服务已经两年多,每年客户数都是三位数增长。在实践中,60%的用户主要使用OLAP场景,20%主要使用Serving场景,还有20%做到了HSAP混合负载的优化架构,通过技术创新为企业降本提效。实时数仓还处于发展过程中,相信随着大数据的不断推动,实时数仓会成为推动业务发展的“有力抓手”。

过去,数据团队更偏内部业务场景,主要的工作就是给管理层出报表,做领导驾驶舱。但在今天,数据团队正从成本中心转为盈利中心,大数据团队要想去影响业务,提升价值感,包括风控、实时画像、实时推荐等手段,是提升业务的主要入口,这也是实时数仓需求快速增长的最根本原因。实时数仓会成为大数据平台里一个重要组成部分,是数据消费端的核心组件。

当然,实时数仓并不是一个新事物,从有数仓开始,用户需求一直存在。但是,因为方案的不成熟,很多都是由开源组件堆在一起,从开发和运维成本上看,技术门槛比较高,导致实时数仓没有实现规模化发展。企业必须招聘来自BAT的人才才能玩得转实时数仓,这个是不正常的,也不是时代发展的趋势,技术一定会普惠化,所有的企业都会用上大数据,但不应该所有的企业都成为技术专家。

真正受市场欢迎的实时数仓产品,简单、易用是前提,能处理海量数据,不用懂很多参数,不用写很多程序,能做到只会写SQL就可以上手。另外,企业希望数据写进来就能用,尽量减少数据加工过程,减少数据链条,实现敏捷化。即使业务方突然提出一个新需求,只要改下SQL就可以了,不用做任何数据重刷,对开发效率提升来说,带来的是根本性的转变。

所以,下一代实时数仓到底如何发展? Hologres已经“打好样”!那就是技术门槛会越来越低,同时计算力会越来越强大,使用方式越来越简单,不仅数据能实时写得进来,还要在原始数据上直接做分析,查询要足够快,并发足够高,取数不用等,需求不求人。希望通过Hologres这样的产品,能够将实时数仓变得更加普惠化、敏捷化,让各行各业的数智化建设迈上新台阶。

展开阅读全文
加载中

作者的其它热门文章

0
0 收藏
分享
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部