关于阿里云:DataFunTalk阿里建设一站式实时数仓的经验分享

57次阅读

共计 6238 个字符,预计需要花费 16 分钟才能阅读完成。

简介:本文内容整顿于阿里资深技术专家姜伟华在 DataFunTalk 上的演讲,为大家介绍阿里巴巴基于一站式实时数仓 Hologres 建设实时数仓的教训和解决方案。
导读:大数据计算正从规模化走向实时化,实时大数据建设过程中开始面临很多的痛点和问题。本文内容整顿于阿里资深技术专家姜伟华在 DataFunTalk 上的演讲,为大家介绍阿里巴巴基于一站式实时数仓 Hologres 建设实时数仓的教训和解决方案。

分享的内容从以下三点开展:

实时数仓的演进:一站式实时数仓
Hologres:阿里通过大规模验证的实时数仓
阿里 CCO 部门基于 Hologres 的一站式实时数仓建设过程与教训

点击查看视频回放:https://www.bilibili.com/vide…

作者:姜伟华(果贝)阿里巴巴资深技术专家,实时数仓 Hologres 负责人

实时数仓的演进:一站式实时数仓
1、大数据正从规模化走向实时化
大数据计算正从规模化走向实时化。

随着业务的倒退,不论是实时大屏,还是智能交通、银行金融风控、或者是实时举荐都迫切的须要更实时的数据助力业务增长。

常见的实时数仓有两种场景:

面向 BI 或者内部人员的 OLAP 剖析:次要通过 OLAP 引擎做明细 + 自在剖析
面向 B / C 端的线上服务(Serving):通过 Lambda 架构预计算后写入 KV 零碎,通过 KV 零碎线上服务。
两个场景用了两套架构,导致理论应用时痛点也非常明显,包含:结构复杂保护难、同步数据艰难、数据孤岛、开发成本低等,同时也须要保护很多套零碎,无奈疾速响应业务麻利需要。业务团队上手老本高,必须大数据团队撑持。

image.png

下面是咱们看到的在大数据倒退过程中的广泛现状。上面,咱们也来看看由业务催生的大数据技术发展趋势。

2、实时大数据须要麻利化

image.png

首先第一个趋势就是大数据开发须要麻利化。包含:

应用普惠化
业务能自助开发:业务团队心愿本人可能来做业务开发,而不是把需要提给大数据团队排期开发。
低代码:业务团队相较大数据团队的开发能力更弱,不肯定都会 Java 或 Scala 这样的语言,有的只会 SQL,有的甚至 SQL 都不会,只会各种 BI 工具,所以要实现业务团队低代码开发,只须要可视化配置就能失去想要的数据。
数据治理成为刚需:当把开发能力下沉到业务团队时,须要保障比拟高的数据品质,所以数据治理成为刚需,否则业务团队开发进去的后果与原始数据无奈对齐,会造成十分多的麻烦。

无学习老本
像数据库一样应用大数据:大数据组件上手老本远比数据库要高,业务团队心愿自助开发,升高学习老本,最好能像数据库一样开发。
规范 SQL,容易上手:业务团队心愿开发方式是规范 SQL,这样上手门槛更低。
适配常用工具(如 Tableau):同时,业务团队心愿开发后果能够和常用工具不便对接,缩小开发量和工具学习老本。

开发麻利化
写入即剖析:对业务团队来说,不心愿保护简单的链路体系,最好能写入即剖析,缩小 ETL 档次,缩小预聚合。
存储明细数据,而非预计算后果
灵便剖析,疾速上线:业务变动疾速,而预计算灵便度太差,须要更改指标计算逻辑时,须要做十分多的改变。而业务侧有很强的疾速剖析、疾速上线的诉求。

所有麻利化的需要和趋势,都依赖一款弱小的实时数仓引擎能力实现。

3、实时数仓走向在线化
传统上,数仓是线下零碎,并非用于生产零碎。但随着业务的倒退,线上数据也须要更加灵便,所以越来越多的业务把实时数仓作为在线零碎来应用。所以咱们能够看到,实时数仓开始从传统的外部应用,逐步走到台前,被越来越多的 ToB、ToC 在线业务应用。如下图的阿里淘宝的智能客服和达摩院的小蛮驴无人配送服务,背地都依赖实时数仓技术。

image.png

image.png

4、从阿里看实时数仓新趋势:一站式实时数仓
所以实时数仓的发展趋势,不再是把 OLAP 剖析和线上服务两个场景齐全割裂,而是心愿通过一站式实时数仓去解决这个问题。业务更心愿,无论是实时写入还是离线写入,都能对立写入至一个实时数仓,而后通过这个实时数仓来对外提供线上服务和 OLAP 剖析两种能力。

基于此,阿里提出了一个新的理念:剖析服务一体化(Hybrid Serving/Analytics Processing, HSAP),冀望通过一个产品解决就能 OLAP 剖析和线上服务两个问题。HSAP 是比拟技术化的概念,与之对应的业务概念就是“一站式实时数仓”。

image.png

一站式实时数仓的劣势非常明显:实时数据和离线数据对立存储、线上服务和线下剖析不割裂,同时因为存有明细数据,所以就能麻利响应变动,能够疾速构建数据服务……

而阿里云产品 Hologres,则是 HSAP 理念下的最佳产物,通过了阿里多个外围场景的生产验证。上面咱们将会对其进行进一步介绍。

Hologres:阿里一站式实时数仓
1、Hologres:通过阿里多个外围场景验证的一站式实时数仓
基于一站式实时数仓 HSAP 的理念,阿里外部齐全自研了 Hologres。Hologres 从诞生至今已有 5 年多的工夫,经验了阿里外部多个外围场景的生产验证,包含淘系数字化大屏、电商剖析、阿里妈妈广告投放、智能客服、物流的菜鸟、达摩院、飞猪、饿了么等。并且也稳固撑持了历年的阿里大促场景,如双 11、618 等。在 2021 年的双 11 中,写入峰值达 11 亿 +/ 秒,单个业务点查峰值达到上亿条 / 秒。OLAP 剖析场景,单业务峰值达到 2000+QPS,同时反对了 PB 级数据存储。

image.png

2、Hologres 与阿里自研大数据产品矩阵深度兼容
Hologres 作为大数据 OLAP 剖析与线上服务的对立进口,一套零碎就能提供剖析和服务 2 种能力。依靠 Hologres,再联合阿里大数据产品矩阵如 DataWorks、MaxCompute、Flink、DLF 等,能十分完满的反对实时离线一体、剖析服务一体、湖仓一体、流批一体等场景。

image.png

3、一站式实时数仓 Hologres 的演进过程
对 Hologres 来说,最开始也并不是能齐全反对各种场景,其能力是基于业务了解和技术发展趋势一直演进的。

image.png

2020 年,Hologres 反对通过一套技术栈,通过行存和列存两种存储格局来别离提供线上服务和 OLAP 剖析两种能力。相比传统形式,最大的劣势就是对立技术栈、对立模型、对立 SQL。同时也比拟不便做数据治理。然而数据须要行存列存各写一份,存在割裂,应用上还是有些不不便。

2021 年,Hologres 反对了行列共存的表,做到了 One-Data,Multi Workload。即一份数据供线上服务和 OLAP 剖析两个 Workload 应用。其中的行存用来给线上服务用,列存用来给 OLAP 用,行存和列存的数据是强统一的不须要存储多份,缩小冗余和反复导数。同时在企业级能力上提供高可用部署,反对读写拆散,无效的隔离剖析和服务两种场景,保障了线上服务的稳定性。这些能力也在 2021 年阿里双 11 生产级验证。

但咱们认为这还不是一站式实时数仓的齐全态。

2021 年解决的问题是一份数据多个利用场景,而在之后要解决的问题是如何更加的简化数据加工链路,能在一个平台上把数据加工过程用 SQL 表达出来。比方实时物化视图。目前相干性能正在开发中。这样在横向(多种利用场景)和纵向(数据加工链路)两个维度上都实现了“一站式”。

阿里 CCO 一站式实时数仓建设教训
Hologres 反对了阿里团体内十分多的外围业务场景,比方阿里妈妈、淘宝、菜鸟等。上面咱们将会以阿里 CCO 为例,介绍其实时数仓建设过程中的教训和思考,以帮忙大家在建设实时数仓这条路线上走得更加便捷。

1、CCO 利用场景介绍
阿里巴巴 CCO 全称 Chief Customer Office,次要负责阿里全链路的客户体验。其次要的场景有:

客服现场调度:人工调配客服坐席,疾速响应线上问题
购物链路预警:在淘系的购物链路中(曝光、点击、加购、下单、物流、售后)发现潜在问题并对客服做出预警,这样客服就能疾速响应客户的相干问题并及时处理,防止信息滞后。
AI 智能服务:通过 AI 智能客服承接淘系的在线客服答疑问题,,防止耗费过多的人力老本。

目前 CCO 业务背地的实时数仓,承载着上千个 Flink 实时工作,耗费几万 CU,写入峰值 4000 万 + 条 / 秒,产生 2000 万 + 条 / 秒 Binlog,有超过上千张的行存表和 4000 张 + 的列存表。尽管 CCO 的数据量在阿里不是最大的,然而业务链路却是最简单之一。

image.png

2、CCO 实时数仓的三代倒退历程
CCO 的实时数仓建设也经验了传统数仓 - 流批一体数仓 - 新一代高可用数仓的 3 代倒退过程,且目前第三代还在一直的迭代中。

image.png

传统数仓 1.0:在 2016 至 2017 年,通过 Flink 实时数据加工,把预计算后果写到 HBase 或 MySQL 等 KV 存储中,而后对外提供查问。强调的是重加工和预计算,并且整个链路都是端到端,作业和作业之间不共享数据,就是端到端的烟囱开发。

流批一体数仓 2.0:然而业务倒退太快,到 2018 年烟囱开发式的数仓无奈更好的承载业务需要。于是用 Flink 构建了实时数仓的分层(DWD/DWS/ADS),通过音讯队列 Datahub 来承载。这样,不同的 Flink 作业之间就能够共享 DWD 和 DWS 层的实时数据。计算结果依据业务需要写入 OLAP 和 KV 两个引擎。其中 OLAP 引擎承载的是对内的明细查问剖析; KV 引擎对外提供点查服务。

这个架构也是目前市面上比拟风行的架构,同时也有了数仓分层,能更好的为业务服务。然而在理论业务利用中,也很快遇到了问题。

于是来到了新一代高可用数仓 3.0 的建设:2020 年 CCO 开始和 Hologres 一起构建实时数仓 3.0。实时数据通过 Flink 实时写入 Hologres,离线数据在 MaxCompute 加工后也写入 Hologres,在 Hologres 中对立存储了实时和离线数据。再通过 Hologres 承载 OLAP 剖析和线上服务两个能力。如果须要二次加工,间接通过 Flink 订阅 Hologres Binlog。

3.0 实时数仓架构相比于 2.0 架构,次要有以下几个劣势:

流批一体和实时离线一体。
与 Flink 有十分好的配合,缩小了反复开发。
可用性和隔离型高。
与阿里外部的元数据管理体系有很好地连接。

3、技术架构降级的挑战和解法
上面咱们来具体分析 CCO 实时数仓升级换代过程中遇见的挑战和解法。

实时数仓 2.0 尽管做到了流批一体,然而实质上还是一个 Lambda 架构,在理论应用中有很多问题:

首先看业务表象:

工作增速快,老本高:2.0 时代也是淘系疾速暴发的时候,业务增长特地快,导致作业增速快,而开发成本十分高,运维压力十分大。
实时数据产研效率低。每到大促,实时研发就会成为瓶颈,工作和表无对立元数据管理,灾备通过双联路实现,开发和压测老本都十分高。

再来看问题背地的起因:

实时工作烟囱化。实时工作尽管做了很多中间层,然而整个烟囱化还是非常明显,KV 引擎和 OLAP 引擎并不通,造成数据孤岛。数据须要多份冗余存储,造成很多数据同步工作,统计下来大略有 30% 的作业在做数据同步,节约很多资源。
• 实时架构瓶颈。元数据的缺失与引擎的繁多性能,无奈无效的治理数据和工作。

image.png

通过架构 3.0 的降级,这些问题都失去了很好的解决。

以 CCO 典型的用户画像场景为例来补充阐明实时数仓 3.0 如何解决相干痛点。

典型的画像类场景做法是将多个数据源的数据构建成一个实时大宽表,并实时更新。CCO 也不例外,基于主题构建实时大宽表时,把不同起源的数据放在大宽表的不同字段,数据来源于多个上游零碎,并且任何字段的更新都能在大宽表中体现进去。传统计划是 Flink 多流 Join,但 Flink 多流 Join 的问题在于,上游如果只是一两个流还比拟简便,但如果上游是很多个流,那 Flink 多流 Join 就十分麻烦。这个痛点在很多公司在做画像类产品的时候都很常见。

CCO 还有更重要的诉求是心愿上游任何一个字段的变动都要去触发整行数据更新,同时能吐出残缺的整行数据被 Flink 去做二次加工。这也是画像类工作的十分常见诉求。

image.png

在实时架构 3.0 中,实时大宽表利用了 Hologres 的主键更新能力,多个上游流作业各自更新同一主键的不同字段,完满解决画像类大宽表数据更新的问题。

同时,CCO 和 Hologres 一起共建了 Hologres Binlog。这样,画像大宽表的任一字段更新都会透出 Hologres Binlog,Flink 再基于 Binlog 做二次加工构建 DWS 层。

image.png

2021 年,在实时数仓 3.0 中,Hologres 与 CCO 共建“一份数据、多种负载”的高可用能力,并在 2021 年双 11 中生产级落地:

标注 1:行存提供高性能的写入、多正本、Flink 读取 Binlog 二次加工的能力。
标注 2:列存提供内外服务,通过共享存储高可用部署,多个实例共享一份存储然而计算资源齐全隔离,数据只须要存储一份就能实现剖析服务隔离、读写拆散、高可用等
标注 3:灾备计划。在 2.0 实时数仓中,灾备计划是双链路。而 3.0 架构中数据实时写入 2 后会主动实时同步到 3 去。简略高效的实现灾备

4、CCO 典型利用场景实际
上面咱们将联合 CCO 的 3 个典型业务场景介绍 Hologres 在实时数仓 3.0 中的作用。

场景一:客服资源管理
客服资源管理场景次要是通过数据分析疾速的治理客服资源。这个场景并没有十分强的线上属性,更多的是一个外部剖析零碎。

image.png

在这个场景中,离线 MaxCompute 数据间接通过 Hologres 查问减速,将表面和实时数据做关联查问失去剖析后果;对于实时比拟敏感的数据,会通过 Flink 做轻度汇总,再写入 Hologres 实时查问。元数据由通过 DataWorks 数据地图进行查问。这样业务方都能够非常简单高效的自助构建实时监控大屏,比如说某部门人力资源分配状况、接单状况等等。通过 BI 工具接入 Hologres,半小时就能够搭建实时监控大屏进去,十分不便,实现数据麻利化。

场景二:用户声音洞察
用户声音洞察场景次要是用于实时聆用户的诉求,并及时为用户解决问题。

image.png

零碎会实时采集用户在淘系购物体验的全链路数据,实时写入 Hologres,并通过 Binlog 订阅二次计算,提供 QPS 实时剖析的能力,反对超过 20 个 BU 的用户声音洞察。

场景三:智能客服服务
智能客服场景是是淘宝 App 上的一个 to C 能力,比方为 88VIP 的智能客服服务旨在通过智能化的服务升高人工服务老本。

image.png

这个场景就是十分典型的在线服务场景,当用户发动服务申请时,智能服务须要疾速响应并提供相应的帮忙。在该场景中,充分利用了 Hologres 的在线服务能力,并应用了 Hologres 内置的达摩院向量检索 Proxima 能力,反对向量检索,通过对知识库的向量检索来极大晋升了常识的检索准确度,缩小了架构的复杂度。

总结
通过阿里一站式实时数仓建设教训的分享,咱们冀望通过实时数仓 Hologres 可能缩小大数据建设中的痛点,行业互通有无,更好的赋能业务增长。

附件:PPT 下载

钉钉扫码退出 Hologres 用户交换群,即可下载本次大会演讲 PPT。

理解 Hologres:https://www.aliyun.com/produc…

原文链接:http://click.aliyun.com/m/100…

本文为阿里云原创内容,未经容许不得转载。

正文完
 0