关于云原生:云原生离线实时一体化数仓建设与实践

2次阅读

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

简介:本篇内容分享了云原生离线实时一体化数仓建设与实际。分享人:刘一鸣 Hologres 产品经理

视频链接:https://developer.aliyun.com/…

注释:

本篇内容将通过五个局部来介绍云原生离线实时一体化数仓建设与实际。

一、离线实时一体化数仓建设难点

二、离线实时一体化数仓技术演变

三、阿里巴巴离线实时一体化数仓建设实际

四、离线实时一体化数仓参考架构

五、将来实时数仓外围趋势瞻望

一、离线实时一体化数仓建设难点

随着时代的倒退,数据分析由通过实时大屏洞察业务变动,逐渐转向数据决策和数据在线转化。实时数据的精细化经营,让每个人对数据需要,呈现了指数级增长。另一方面,数据在线举荐,风控系统也重大依赖于实时数据,数据分析的力度和强度有着显著地晋升。

面对蓬勃发展的数据需要,咱们的数据架构也变得越来越简单。无论是订单数据,还是行为数据,它们都通过消息中间件采集,而后通过多条加工链路。一份数据通过离线,实时,在线之后,会产生多份数据集。这套架构让运维老本,开发成本变得很高。

整个架构高老本的背地是因为有多套组件和多套存储。而多套存储带来了多份数据孤岛,导致数据的一致性无奈保障。每个零碎都有本人的运维形式,开发方式和应用形式。从而减少了运维老本和学习老本。

当咱们回顾计算机行业的倒退。在 60 年代,每个程序员在开发零碎时,都须要本人通过离散文件,网络文件或层级文件存储状态。在 80 年代,大家能够通过形容的形式剖析数据。到了大数据时代,数据的存储形式多种多样,同样一份数据在各个引擎里有不同的选型。尽管不同的技术在可扩展性,并行能力,吞吐能力上有所不同。但至今为止,咱们剖析问题的形式并产生没有实质变动。所以我置信随着数据技术的提高,数据存储还会有一个交融的过程。

我认为数仓平台的时效性有两个概念,即实时和准时。其中,只有机器做决策的场景须要实时。比方端到端数据产生和提早,大屏风控,计算提早,事件驱动等等。而人类做决策的工夫,个别以分钟 / 小时 / 天 / 月为准,极度陈腐的数据并不影响人类决策的实质。只有扭转决策后果的零碎,才是优良的实时零碎。比方海量数据的灵便剖析,自助剖析等等。

大家有的时候为了数据的时效性,往往会漠视数据的品质。如果一个数仓平台只谋求时效性,咱们只能看到一个后果值。岂但很难发现数据的品质问题,二修改老本也很高。所以一个优良的实时数仓平台,其数据肯定要可查看,可修改。

image.png

数仓平台实时化的第三个需要就是降低成本。这里次要分为开发成本,运维老本和人力老本。其中,最外围的是开发成本。咱们岂但要让业务与技术解耦,实现数据资产复用,业务自助开发。还要简化链路,缩小依赖和传递。在运维方面,组件岂但要具备很好的弹性能力,还要有托管服务,从而升高运维老本。在人力老本方面,咱们要升高技术门槛和学习老本。

综上所述,一个优良的实时数仓须要具备四个能力。第一,反对实时写入、实时事件计算、实时剖析,并且满足实时和准时的需要、第二,将实时和离线交融。缩小数据冗余和挪动,具备简化数据,修改数据的能力。第三,实现业务与技术解耦。反对自助式剖析和麻利剖析。第四,拥抱规范,拥抱生态,拥抱云原生。升高运维老本、迁徙老本,SQL 优先。

二、离线实时一体化数仓技术演变

接下来,咱们看看离线实时一体化数仓的倒退。如上图所示,阿里巴巴的第一代实时数仓,次要面向特定业务,做烟囱式开发。咱们用典型的 Lambda 架构,履行采集,加工,服务的三步走策略。依据特定业务,进行烟囱化的建设。以工作为单位撑持利用场景,当数据预处理之后,存储到 OLAP 和 KV 引擎。但随着业务场景越来越简单,运维开发成本越来越高。烟囱式的开发方式,曾经不能适应业务变动。

于是咱们有了第二代实时数仓,面向指标复用,进行数仓开发。咱们引入了 OLAP 引擎,将小数据量明细存储在 MPP 数据库,反对 OLAP Query。而后在 DWD 层,依照主题将数据源整合,构建可复用的 DWS 层,缩小建设的烟囱化。与此同时,不同的工作和引擎中,仍积淀了烟囱化的业务逻辑。因为不同业务的 SLA 不同,KV 引擎和 OLAP 依据 SLA,拆分了多个实例,导致数据运维老本和开发成本减少。与此同时,KV Schema Free 的元数据管理也尤为艰难。

为了解决上述问题,咱们研发了第三代实时数仓,即面向对立数据服务的一站式开发。在第三代实时数仓中,咱们将公共明细层和汇总层,利用明细层和汇总层,集中存储,对立治理。其次,咱们将 OLAP、KeyValue 对立为 SQL 接口。而后,简化实时链路和加工链路,让数据可修改,缩小内部零碎的依赖。通过一站式开发,咱们岂但实现了数据的秒级响应,让全链路状态可见,而且整个架构的组件更少,依赖更少。无效升高了运维老本和人工成本。

三、阿里巴巴离线实时一体化数仓建设实际

接下来,咱们讲一讲阿里巴巴离线实时一体化数仓建设的实际。2020 年阿里巴巴双十一大屏,峰值解决音讯 40 亿条 / 秒,全天解决 150 万亿条,GMV 3 秒以内,全天提早 1~2 秒。这些数据次要来自两个渠道。第一,结构化的订单数据。第二,用户点击时,产生的点击流数据。数据收集汇总之后,一部分数据进入实时加工链路,进入 Flink。另一部分数据以归档的形式,进入离线数仓。离线零碎以 MaxCompute 为主,在线零碎以 Hologres 为主。

因为 MaxComput 是一项大数据计算服务。它能提供灵便疾速、齐全托管、高性能、低成本、平安的 PB 级数据仓库解决方案。所以当数据集成之后,数据进入 Date Works 平台,通过 MaxComput,对数据进行深度剖析,报表剖析。MaxComput 岂但简略易用,领有极致的弹性能力,而且领有企业级的平安能力,充沛保障企业的数据安全。

上图是阿里云的重要组件 DateWorks。DateWorks 由很多组件组成,其中包含数据治理,数据开发,数据调度,元数据管理等模块。DateWorks 集成了阿里云不同的引擎,提供了优良的元数据管理能力和企业及治理能力。

我通常将存储分为三类。第一类 Transaction 在线的事务零碎。适宜模型简略的剖析场景,以 TP 模型解决 AP 的问题。第二类 Analytics 零碎,这个零碎的往往采纳分布式,列存,索引。通各种压缩技巧,把海量数据分析做到极致。第三类是 Serving 零碎,这类零碎能毫秒级的响应,每秒反对上万的 qps,以只读为主,更新简略。

HSAP 以数仓模型解决了数据服务的问题。HSAP 次要利用在数据报告,数据看版,在线利用。可能对立数据存储,对立进行数据服务。除此之外,HSAP 反对离线数据的批量导入,实时数据的实时更新。

上图是一站式实时数仓的演进。无论是交互式剖析,联邦查问,还是在线的高性能点查都能够缩小数据的传递和依赖。数据离线加工的局部,咱们持续应用 MaxCompute。数据实时加工的局部应用 Flink。防止数据割裂,赋能数据服务,简化运维治理。

阿里云的 Hologres 为剖析服务一体化,设计的实时数仓。在云原生方面,与 MaxCompute 底层买通,通明减速,实时离线一体。在流批一体的存储方面,高吞吐数据写入,反对更新,写入即可见。在性能方面,随着 CPU 的多核化,咱们对向量化、全异步等执行引擎优化,充分利用计算资源。

咱们在阿里客户体验零碎 CCO 的实时数仓革新中,对交易、征询、退款等数据整合,解决了危险经营、智能排班、售前转询、现场调度等需要。做到了架构简化牢靠,无数据孤岛,反对联邦查问,全流程秒级提早。岂但缩小了数据同步,防止了数据提早和数据库抖动。而且满足了双 11 流量 10 倍的增长需要。

上图反映的是,阿里客户体验零碎 CCO 过来三年,实时加工工作的倒退。间断三年,老本 100% 的增长,导致运维压力大,老本耗费大。通过钻研 CCO 的技术架构,咱们发现实时工作有烟囱化的遗留问题。首先,KV 引擎与 OLAP 引擎不通,没有对立的存储。其次,公共层工作链路过长,不同实例间的数据同步,作业产生了收缩,导致保护老本越来越高。

为了解决以上问题,咱们用了 Hologres 技术机构,与 Flink 和 DataWorks 数据地图集成。实现了高性能写入,让元数据集成 DataWorks 数据地图。构建了高牢靠的场景 HA,实现了行列混存和资源隔离。

通过 DataHub+Flink+Hologres+MaxCompute 的技术架构,CCO 的整体硬件资源老本降落 30%,实时写入反对行存千万 / 秒,列存几十万 / 秒写入要求。在 2020 双 11 当天,查问 latency 均匀 142ms,99.99% 的查问在 200ms 以内。除此之外,还可能撑持 200+ 实时数据大屏搭建,为近 300+ 小二提供稳固的数据查问服务。

四、离线实时一体化数仓参考架构

云原生的实时数仓次要分为加工层的和存储层。加工层以 Flink 加工为主。存储层有 Hologres 零碎。数据的解决形式只有有三种。第一,即席查问形式;第二,准实时形式;第三,增量形式。通过这三种形式,满足了绝大多数场景的解决需要。

实时数仓的数据分析,次要利用在可视化大屏、Web 利用 API、BI 报表零碎、实时数据接口服务等等。首先,将业务零碎的结构化数据,采集到实时数据缓存平台。初步分类之后,增量数据进 DataHub;明细全量数据进 Hologres。而后进行数据集成,Flink 加工增量数据,实时更新明细数据。

而后离线工作加工后果表,由 MaxCompute 导入,在 CDM/ADS 层表为理论物理表,工作由 DataWorks 对立调度。最初,前端实时申请,数据实时性依赖,全副由 DataWorks 调度周期配置。

增量数据的实时统计,只有通过增量流,增量流 join 动态维,增量流 join 增量流,这 3 种场景,就能统计出数据。而后通过 Flink 计算、datahub 进行数据存储。而 ADS 层的利用数据存储在 Hologres。逻辑简略,实时性强。

该怎么抉择 MaxCompute 和 Hologres?这两个技术的技术原理是齐全不同。MaxCompute 有典型的做数据加工场景,计算过程是异步的,资源按需分配。扩展性简直不受限制,接口标准是 MC SQL。Hologres 的所有工作都是同步的,简单查问尽量避免跨多节点数据 shuffle,基于 Pangu,利用 SSD 做缓存减速,老本绝对高。接口标准是 PostgreSQL。

数仓开发应逐渐实现缩小档次,一直复用的指标。缩小数据档次,麻利适应需要变动,弱化 ADS、面向 DWS、DWD 的利用开发。MaxCompute 与 Hologres 底层互通,互读互写,无需内部同步工具,数据传递效率比其他软件高 10 倍以上。

数据开发不是欲速不达,肯定要分阶段进行。大家肯定要在不同阶段,应用不同的加工形式。第一阶段,肯定以获取数据为主。短平快地撑持,了解业务和数据。

第二阶段,要满足在线疾速业务上线。丰盛公共层明细数据,确定产品框架。
到第三阶段的成熟层时,才开始布局不同的组织架构。整个零碎趋于稳定,需要成体系。与业务密切合作常态化。公共汇总层开始积淀。

五、将来实时数仓外围趋势瞻望

我感觉在将来,实时数仓的外围趋势是一站式的数据平台,麻利化的数据开发,在线化的数据服务。

一站式的实时数仓,一个零碎能同时解决,OLAP 剖析与线上服务两个问题。肯定要满足业务麻利响应,数据自助剖析,防止数据孤岛,赋能数据服务,简化运维治理。

数据服务仅是外部零碎,而且要成为内部的在线零碎。岂但能撑持数据决策,而且要提效在线转化。最终实现数据平台的高可用,高并发。数据的低延时 / 低抖动,安全可靠。

最初,数据开发麻利化。在将来,心愿通过技术创新,通过空云原生的弹性能力,缩小人类的瓶颈。以公共层对外提供服务,将查问灵便度从数仓工程师转移到业务分析师,让卓越计算力解决人力瓶颈。

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

正文完
 0