简介: 本文内容整理于阿里资深技术专家姜伟华在DataFunTalk上的演讲,为大家介绍阿里巴巴基于一站式实时数仓Hologres建设实时数仓的经验和解决方案。

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

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

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

 

点击查看视频回放https://www.bilibili.com/video/BV1jY411A73P

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

实时数仓的演进:一站式实时数仓

1、大数据正从规模化走向实时化

大数据计算正从规模化走向实时化。

随着业务的发展,不管是实时大屏,还是智能交通、银行金融风控、或者是实时推荐都迫切的需要更实时的数据助力业务增长。

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

  • 面向BI或者内部人员的OLAP分析:主要通过OLAP引擎做明细+自由分析
  • 面向B/C端的线上服务(Serving):通过Lambda架构预计算后写入KV系统,通过KV系统线上服务。

两个场景用了两套架构,导致实际使用时痛点也非常明显,包括:结构复杂维护难、同步数据困难、数据孤岛、开发成本高等,同时也需要维护很多套系统,无法快速响应业务敏捷需求。业务团队上手成本高,必须大数据团队支撑。

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

2、实时大数据需要敏捷化

首先第一个趋势就是大数据开发需要敏捷化。包括:

  1. 使用普惠化
  • 业务能自助开发:业务团队希望自己能够来做业务开发,而不是把需求提给大数据团队排期开发。
  • 低代码:业务团队相较大数据团队的开发能力更弱,不一定都会Java或Scala这样的语言,有的只会SQL,有的甚至SQL都不会,只会各种BI工具,所以要实现业务团队低代码开发,只需要可视化配置就能得到想要的数据。
  • 数据治理成为刚需:当把开发能力下沉到业务团队时,需要保证比较高的数据质量,所以数据治理成为刚需,否则业务团队开发出来的结果与原始数据无法对齐,会造成非常多的麻烦。
  1. 无学习成本
  • 像数据库一样使用大数据:大数据组件上手成本远比数据库要高,业务团队希望自助开发,降低学习成本,最好能像数据库一样开发。
  • 标准SQL,容易上手:业务团队希望开发方式是标准SQL,这样上手门槛更低。
  • 适配常用工具(如Tableau):同时,业务团队希望开发结果可以和常用工具方便对接,减少开发量和工具学习成本。
  1. 开发敏捷化
  • 写入即分析:对业务团队来说,不希望维护复杂的链路体系,最好能写入即分析,减少ETL层次,减少预聚合。
  • 存储明细数据,而非预计算结果
  • 灵活分析,快速上线:业务变化快速,而预计算灵活度太差,需要更改指标计算逻辑时,需要做非常多的改动。而业务侧有很强的快速分析、快速上线的诉求。

所有敏捷化的需求和趋势,都依赖一款强大的实时数仓引擎才能实现。

3、实时数仓走向在线化

传统上,数仓是线下系统,并非用于生产系统。但随着业务的发展,线上数据也需要更加灵活,所以越来越多的业务把实时数仓作为在线系统来使用。所以我们可以看到,实时数仓开始从传统的内部使用,逐渐走到台前,被越来越多的ToB、ToC在线业务使用。如下图的阿里淘宝的智能客服和达摩院的小蛮驴无人配送服务,背后都依赖实时数仓技术。

4、从阿里看实时数仓新趋势:一站式实时数仓

所以实时数仓的发展趋势,不再是把OLAP分析和线上服务两个场景完全割裂,而是希望通过一站式实时数仓去解决这个问题。业务更希望,无论是实时写入还是离线写入,都能统一写入至一个实时数仓,然后通过这个实时数仓来对外提供线上服务和OLAP分析两种能力。

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

一站式实时数仓的优势非常明显:实时数据和离线数据统一存储、线上服务和线下分析不割裂, 同时因为存有明细数据,所以就能敏捷响应变化,可以快速构建数据服务……

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

Hologres:阿里一站式实时数仓

1、Hologres:经过阿里多个核心场景验证的一站式实时数仓

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

2、Hologres与阿里自研大数据产品矩阵深度兼容

Hologres作为大数据OLAP分析与线上服务的统一出口,一套系统就能提供分析和服务2种能力。依托Hologres,再结合阿里大数据产品矩阵如DataWorks、MaxCompute、Flink、DLF等,能非常完美的支持实时离线一体、分析服务一体、湖仓一体、流批一体等场景。

3、一站式实时数仓Hologres的演进过程

对Hologres来说,最开始也并不是能完全支持各种场景,其能力是基于业务理解和技术发展趋势不断演进的。

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的数据量在阿里不是最大的,但是业务链路却是最复杂之一。

2、CCO实时数仓的三代发展历程

CCO的实时数仓建设也经历了传统数仓-流批一体数仓-新一代高可用数仓的3代发展过程,且目前第三代还在不断的迭代中。

传统数仓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%的作业在做数据同步,浪费很多资源。

•  实时架构瓶颈。元数据的缺失与引擎的单一功能,无法有效的治理数据和任务。

通过架构3.0的升级,这些问题都得到了很好的解决。

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

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

CCO还有更重要的诉求是希望上游任何一个字段的变化都要去触发整行数据更新,同时能吐出完整的整行数据被Flink去做二次加工。这也是画像类任务的非常常见诉求。

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

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

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中的作用。

场景一:客服资源管理

客服资源管理场景主要是通过数据分析快速的管理客服资源。这个场景并没有非常强的线上属性,更多的是一个内部分析系统。

在这个场景中,离线MaxCompute数据直接通过Hologres查询加速,将外表和实时数据做关联查询得到分析结果;对于实时比较敏感的数据,会通过Flink做轻度汇总,再写入Hologres实时查询。元数据由通过DataWorks数据地图进行查询。这样业务方都可以非常简单高效的自助构建实时监控大屏,比如说某部门人力资源分配情况、接单情况等等。通过BI工具接入Hologres,半小时就可以搭建实时监控大屏出来,非常方便,实现数据敏捷化。

场景二:用户声音洞察

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

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

场景三:智能客服服务

智能客服场景是是淘宝App上的一个to C能力,比如为88VIP的智能客服服务旨在通过智能化的服务降低人工服务成本。

这个场景就是非常典型的在线服务场景,当用户发起服务请求时,智能服务需要快速响应并提供相应的帮助。在该场景中,充分利用了Hologres的在线服务能力,并使用了Hologres内置的达摩院向量检索Proxima能力,支持向量检索,通过对知识库的向量检索来极大提升了知识的检索准确度,减少了架构的复杂度。

总结

通过阿里一站式实时数仓建设经验的分享,我们期望通过实时数仓Hologres能够减少大数据建设中的痛点,行业互通有无,更好的赋能业务增长。

附件:PPT下载

钉钉扫码加入Hologres用户交流群,即可下载本次大会演讲PPT。

了解Hologres:https://www.aliyun.com/product/bigdata/hologram

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

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

DataFunTalk:阿里建设一站式实时数仓的经验分享的更多相关文章

  1. 基于 ByteHouse 构建实时数仓实践

    更多技术交流.求职机会,欢迎关注字节跳动数据平台微信公众号,回复[1]进入官方交流群 随着数据的应用场景越来越丰富,企业对数据价值反馈到业务中的时效性要求也越来越高,很早就有人提出过一个概念: 数据的 ...

  2. 美团点评基于 Flink 的实时数仓建设实践

    https://mp.weixin.qq.com/s?__biz=MjM5NjQ5MTI5OA==&mid=2651749037&idx=1&sn=4a448647b3dae5 ...

  3. Clickhouse实时数仓建设

    1.概述 Clickhouse是一个开源的列式存储数据库,其主要场景用于在线分析处理查询(OLAP),能够使用SQL查询实时生成分析数据报告.今天,笔者就为大家介绍如何使用Clickhouse来构建实 ...

  4. 基于 Flink 的实时数仓生产实践

    数据仓库的建设是“数据智能”必不可少的一环,也是大规模数据应用中必然面临的挑战.在智能商业中,数据的结果代表了用户反馈.获取数据的及时性尤为重要.快速获取数据反馈能够帮助公司更快地做出决策,更好地进行 ...

  5. HBase实战 | 知乎实时数仓架构演进

    https://mp.weixin.qq.com/s/hx-q13QteNvtXRpNsE5Y0A 作者 | 知乎数据工程团队编辑 | VincentAI 前线导读:“数据智能” (Data Inte ...

  6. (转)用Flink取代Spark Streaming!知乎实时数仓架构演进

    转:https://mp.weixin.qq.com/s/e8lsGyl8oVtfg6HhXyIe4A AI 前线导读:“数据智能” (Data Intelligence) 有一个必须且基础的环节,就 ...

  7. 更强大的实时数仓构建能力!分析型数据库PostgreSQL 6.0新特性解读

    阿里云 AnalyticDB for PostgreSQL 为采用MPP架构的分布式集群数据库,完备支持SQL 2003,部分兼容Oracle语法,支持PL/SQL存储过程,触发器,支持标准数据库事务 ...

  8. 大数据之Hudi + Kylin的准实时数仓实现

    问题导读:1.数据库.数据仓库如何理解?2.数据湖有什么用途?解决什么问题?3.数据仓库的加载链路如何实现?4.Hudi新一代数据湖项目有什么优势? 在近期的 Apache Kylin × Apach ...

  9. 基于Flink构建全场景实时数仓

    目录: 一. 实时计算初期 二. 实时数仓建设 三. Lambda架构的实时数仓 四. Kappa架构的实时数仓 五. 流批结合的实时数仓 实时计算初期 虽然实时计算在最近几年才火起来,但是在早期也有 ...

  10. 基于 Kafka 的实时数仓在搜索的实践应用

    一.概述 Apache Kafka 发展至今,已经是一个很成熟的消息队列组件了,也是大数据生态圈中不可或缺的一员.Apache Kafka 社区非常的活跃,通过社区成员不断的贡献代码和迭代项目,使得 ...

随机推荐

  1. Python isinstance() 函数含义及用法解析

    描述 isinstance() 函数来判断一个对象是否是一个已知的类型,类似 type(). isinstance() 与 type() 区别: type() 不会认为子类是一种父类类型,不考虑继承关 ...

  2. ypipe, zmq的核心部件,无锁读写的管道。

    必须指出,无锁读写只限于单个读跟单个写之间,读与读,还有写与写之间必须确保同步.所以ypipe不必读写锁rwlock或者读写之间的锁,但需要读锁跟写锁两个锁,在读端之间或在写端之间仍然是临界资源.本质 ...

  3. 记录--微信小程序获取用户信息的最新方法记录

    这里给大家分享我在网上总结出来的一些知识,希望对大家有所帮助 微信小程序获取用户信息的几种方式 以下三种方式都无法获取到用户的openID 1. 开放组件获取用户信息<open-data> ...

  4. config.cache 使用

    官方地址:https://docs.pytest.org/en/8.0.x/reference/reference.html#config-cache在 pytest 中,cache 是一个非常有用的 ...

  5. vue中elementui组件el-dialog拖拽(已处理边界情况)

    全局注册 Vue.directive("elDialogDrag", (el) => { const header = el.querySelector(".el- ...

  6. FPT:又是借鉴Transformer,这次多方向融合特征金字塔 | ECCV 2020

    论文提出用于特征金字塔的高效特征交互方法FPT,包含3种精心设计的特征增强操作,分别用于借鉴层内特征进行增强.借鉴高层特征进行增强以及借鉴低层特征进行增强,FPT的输出维度与输入一致,能够自由嵌入到各 ...

  7. Lab1:Xv6 and Unix utilities

    Sleep功能 通过接受时间参数,调用system_call 指令 sleep实现该功能 #include "kernel/types.h" #include "kern ...

  8. Unity 2022.3.20f1新功能,异步实例化预制体Object.InstantiateAsync

    今天查看Unity 2022.3.20f1更新日志,发现新增了个异步实例化的功能,这个功能解决了Unity历史上实例化预制体卡顿的痛点,简直不要太爽. 具体的API文档请点击跳转. 做了个简单的实例化 ...

  9. #搜索,计算几何#JZOJ 4016 圈地为王

    题目 在\(n\)行\(m\)列的网格中,你要圈一些地. 你从左上角出发,最后返回左上角,路径内部的区域视为被你圈住. 你不可以进入网格内部, 只能在边上行走. 你的路径不能在左上角以外自交, 但是边 ...

  10. JDK12的新特性:CompactNumberFormat

    目录 简介 CompactNumberFormat详解 自定义CompactNumberFormat 解析CompactNumber 总结 JDK12的新特性:CompactNumberFormat ...