济宁建设局网站首页,crm系统分为哪三类,wordpress文章头图,网页前端做购物网站的实训报告简介#xff1a;阿里云云原生一体化数仓产品技术深度解读。
本文大纲
一、云原生一体化数仓的发布背景
1 市场情况
2 挑战和痛点
二、云原生一体化数仓是什么
三、云原生一体化数仓的技术理念
1 离线实时一体
2 湖仓一体
3 分析服务一体
4 全链路数据治理
一…简介阿里云云原生一体化数仓产品技术深度解读。
本文大纲
一、云原生一体化数仓的发布背景
1 市场情况
2 挑战和痛点
二、云原生一体化数仓是什么
三、云原生一体化数仓的技术理念
1 离线实时一体
2 湖仓一体
3 分析服务一体
4 全链路数据治理
一、云原生一体化数仓的发布背景
1.1市场情况
IDC 2021年的报告显示2021年全球大数据软件市场规模达预计可达5414.2亿人民币相比较2020年的4813.6亿元人民币增长12.5%2021年中国大数据平台软件市场规模预计达125.8亿元人民币。相比2020年增长36.5%。预计未来3年平均复合增长超30%。
阿里云在2021年上半年以明显优势位于中国大数据公有云服务市场第一。 我国的十四五规划中也明确提到要加快数据的高价值转化必须实现以下条件
① 大体量的数据汇聚、全环节的数据采集以及工业基础大数据的建设等。
② 多样性的数据处理包括多种数据类型、多模态以及多行业的数据处理等。
③ 时效性的数据流动包括数据的动态更新、数据共享空间的建立等。
④ 高质量的数据治理将数据的资产和全生命周期很好地管理起来。
⑤ 高价值的数据转化包括通过数据进行政府治理、社会治理、风险控制、工业升级、金融科技的升级等。
大数据在不同的行业中已经有越来越多、越来越成熟的应用。国家规划中也明确提出我们要培育专业化、场景化的大数据解决方案构建多层次的工业互联网平台、建设行业的大数据平台等。
1.2挑战和痛点
现阶段各行业和产业都在利用大数据的能力进行产业升级这也对承载整个数据分析的基础大数据的平台提出了更多和更高的要求。 企业在建设大数据平台时有诸多挑战
● 时效性、准确性、性价比同时有强需求
● 越来越多的非结构化数据难以有效支撑分析决策
● 如何割裂的异构大数据平台之上进行全域的数据分析。
顺应市场的诉求阿里云重磅推出了云原生一体化数仓解决各行业企业构建大数据分析平台的痛点。
二、云原生一体化数仓是什么
云原生一体化数仓是集阿里云大数据产品MaxCompute、DataWorks、Hologres三种产品能力于一体的一站式大数据处理平台。一体化数仓可以解决企业在建设大数据平台中对时效性、准确性、性价比、非结构化数据支撑分析决策、异构大数据平台之上的全域数据分析需求。
通过MaxCompute和Hologres的深度融合提供丰富和灵活的离线实时一体化的能力通过更加开放的对数据湖的支持以及对数据分析多样化统一管理的湖仓一体能力 通过一份数据的基础不断追求对数仓的实时化和在线化的能力结合最后通过DataWorks自顶向下和自底向上的双向建模的能力以及数据治理与企业数据评估模型的新能力来帮助企业更加直观地感受到自身的数据成熟度。开放的DataWorks插件体系也让客户和行业ISV围绕自身的数据去构建更多的场景化数据分析的能力从而真正助力其业务的智能化升级。 其核心是3个一体化和全链路数据治理能力包括离线实时一体化、湖仓一体、分析服务一体化、全链路数据治理。
A. 离线实时一体● 以MaxCompute和Hologres为核心的从N到1极简架构提供离线实时一体化海量云数仓服务
● MaxCompute和Hologres 10X性能高速原生互访深度集成
● MaxCompute发布EB级海量云数仓的快速查询能力。
B. 湖仓一体
● 持续提升易用的湖仓开发体验
● 新增非结构化数据的湖仓管理能力
● 广泛支持开源生态对接。
C. 分析服务一体
● 数仓实时化、敏捷化、在线化、一体化趋势明显
● 一个平台上、一份数据实现灵活探索式分析和高并发在线应用查询同时实现良好的资源隔离和可用性
● 减少数据割裂减少数据移动统一数据服务出口。
D. 全链路数据治理
● 面向业务视角自顶向下进行数仓规范建模
● 问题驱动的可持续数据治理与企业数据治理成效评估
● DataWorks开放平台全新升级。
三、云原生一体化数仓的技术理念
1 离线实时一体
离线计算和实时计算
大数据技术发展早期是面向海量规模的大数据处理而产生的但是随着互联网应用和技术的发展业务在线化和精细化运营的需求越来越强烈比如实时的GMV大屏实时的经营数据分析实时的用户画像和标签系统等所以大数据技术逐渐从离线计算开始往实时化方向演进和发展。
离线数仓和实时数仓在很多场景、设计理念和产品能力上具备不同对的特点。离线数仓面向数据加工场景而实时数仓面向数据分析场景。加工系统为调度服务分析系统为人机交互和在线应用服务处理的数据量加工系统属于大数据进大数据出产出的是加工的结果表而分析系统属于大数据进小数据出产出的是报表、大屏上的KPI在时效性上加工系统通过采用批次加工理念T1方式完成数据加工而分析系统希望数据写入即可用实时可更新在使用上加工系统是离线的作业提交作业有进度中间步骤可重试分析系统是在线系统查询是同步响应查询只有成功和失败两种状态。不同的需求场景决定了不同的技术路线为了扩展性离线系统采用作业异步调度资源计算时分配计算存储完全解耦的设计为了实时的性能实时系统采用RPC同步调用计算资源预分配计算存储运行时绑定等技术。 在从离线到实时化发展的过程中大数据领域出现了很多优秀的系统以应对各种不同的分析和查询场景。比如我们可以将实时的数据归档到像Hive这样的离线数仓里进行数据的离线处理后再将聚合后的小规模数据导出到mysql进行后续的报表查询或者数据访问也有将数据经过flink流计算引擎进行前置的实时处理计算后将结果汇总到HBASE/casandra这样的KV系统进行高并发的点查或者是实时数据直接写入clickhouse/druid这样的mpp系统里进行快速的交互式查询还有通过presto进行多个数据源的联邦查询总之为了实现数据的摄取、处理、分析链路的实时化需要搭建和运维多套系统或者服务最终造成了架构复杂、数据存储割裂、数据不一致、开发成本高等诸多的问题。
从N到1的离线实时一体化海量云数仓
阿里云为了解决这一问题推出了以MaxCompute和Hologres为核心的离线实时一体化海量云数仓架构它用1套架构解决了N种分析场景的需求。过去需要运维N种组件、开发N套系统、对接N种接口、N种安全策略现在只用1个系统就都解决了解决了数据割裂和开发复杂的问题并且让架构变得非常简单。 在数据摄取部分MaxCompute不仅提供传统的批量写入也新近支持了流式写入能力以提高离线数据链路的数据写入效率和数据通道的稳定性而Hologres提供了写入即可见的实时写入和更新能力以保证数据写入和更新的实时性。
在数据计算部分MaxCompute作为一个EB级海量云数仓提供了低成本海量规模的数据存储和计算力。面向高吞吐的设计可以让一个超大规模的计算任务稳定的产出、复杂的UDF功能可支持用户通过灵活的编程进行复杂逻辑的数据处理、海量数仓里的计算任务一般会运行时间较长从分钟到小时甚至到天级别MaxCompute持续进行性能优化目前可将离线查询加速到秒级也就是说具备从秒级到天级别的广谱适用性。
Hologres作为一个实时云数仓通过很多OLAP数仓技术的创新如CPU向量化技术、全链路异步化、以及充分利用ssd写入友好等特性提供了数据实时写入、实时更新、实时分析的云数仓服务支持极致的高并发和亚秒级的低延迟。
MaxCompute和Hologres两个引擎在场景和技术上形成补充相辅相成在他们各自擅长的领域发挥极致的体验。但是他们毕竟是两套系统为了避免数据的割裂我们已经通过深度融合的手段打通了两套系统的元数据和存储可实现在数据不移动的情况下相互访问最终对外提供服务和分析的能力以支持像在线应用、数据大屏、运营看板、即席查询等多种场景的要求。
MaxCompute和Hologres深度融合技术 1. 元数据可见技术
通过元数据可见技术实现不同系统之间的数据可见性进而实现双向的读写能力。MaxCompute的表可以批量导入Hologres的元数据库中支持MaxCompute新增表自动同步到Hologres中。反过来也支持将Hologres的表定义为MaxCompute的外表。通过外表的元数据可见实现了数据不搬迁支持双向的可读可写可感知。元数据自动发现技术更是让外表的创建和更新完全自动化减少了大量手工运维调试的工作。用户不再需要周期性同步表结构不再需要担心数据类型的不对齐。
2. 外表加速技术
理想的状态是离线系统加工好的数据直接可以用于实时系统的交互式分析但由于调度机制、资源分配机制等局限仅仅通过离线系统的技术改进可以实现一定的加速效果但如果要充分发挥交互式分析的计算力通过实时系统的外表加速技术可以更有质量实现离线数据的加速分析。在外表加速加速技术中数据无需搬迁在查询运行时会利用实时系统的计算资源和更高效的RPC调度机制直接访问离线系统中的存储文件。通过实时系统的常驻进程、缓存、预读取、表达式下推等技术实现查询加速广泛使用在BI交互式查询等场景。
3. 高速直读直写
外表的实现有两种思路一种是通过各自引擎的查询接口对接一种是直接访问对方系统的底层存储系统。通过查询接口对接隔离性好接口符合规范对接门槛低但性能不是最优因为调用路径更长访问的组件更多直接访问底层存储引擎侵入性强容易受到系统技术迭代变化引起的不兼容。所以大部分支持联邦查询的系统采用方案一即标准接口的方式比如Presto等。而阿里云MaxCompute和Hologres采用了方案二是因为这两款产品来自于同一个核心研发团队因此有能力解决系统不兼容的问题。两个系统共享基础的存储引擎盘古但保留了各自在存储能力上的创新比如索引设计采用直读直写相对接口方式性能有10倍以上的提升支持了MaxCompute向Hologres 百万级每秒的数据导入场景实现数据刷新回写立即生效。
通过以上三个角度的技术创新实现了实时系统与离线系统的数据打通同时保留了两个系统各自优势的场景能力。
MaxCompute快速查询能力
除了MaxCompute和Hologres的深度融合的一体化架构之外MaxCompute作为海量云数仓也在不断的进行离线加速的努力。如何以低成本的方式对离线海量数仓实现加速平衡客户在性能、延迟和成本上的矛盾是我们要解决的问题。 MaxCompute在原有的架构里扩展支持了内置查询加速引擎可将离线查询加速到秒级。 MaxCompute一直是一个面向吞吐优化的离线数仓即使是一些小查询的计算任务也经常表现出排队时间长执行慢等问题。此次MaxCompute新发布的内置查询加速引擎将针对小数据量的查询任务进行延迟优化。主要采用资源抢占高优先级、多层次的Cache、内存/网络shuffle、向量化执行等技术极大缩减小查询任务e2e链路上的开销。
查询加速引擎支持多种计费模式后付费模式支持自动识别加速无须用户关注即可完成加速这个背后有一套自动作业特征识别算法可针对不同规模和复杂度的查询作业进行离线模式和加速模式的选择让简单查询跑的快复杂查询算的动预付费模式也即将支持查询加速引擎独享资源组的模式可以实现稳定的离线加速效果。
数据通道新增支持了流式写入模式不仅提高了离线数据链路的写入效率和稳定性也可以和查询加速引擎配合实现近实时的数据可见可以有效缩短离线业务的洞察时间。
JDBC接口新增支持多种BI工具如观远BI、网易有数BI、Superset等。
2 湖仓一体
大数据的发展20年形成了数据湖和数据仓库两种形态。 过去20年是大数据技术快速发展的20年。纵观整个计算机科学技术领域对于数据处理的技术主要分为四个阶段数据库阶段、大数据技术探索阶段、大数据技术发展阶段、大数据普惠阶段。数据库阶段主要是在上个世纪70年代至90年代期间这个阶段主要是数据库加单机的黄金时代。数据库系统主要是面向操作面向事务面向在线业务系统的一个数据系统。其实在90年代左右数据仓库概念就已经出现了。数据仓库面向的是历史全量数据分析探查但因为当时的整体数据量并不大所以用一些数据库技术的扩展能够支持当时数据仓库的需求。
2000年左右随着互联网技术的爆发我们迎来了大数据时代。在这个阶段我们用传统数据库的技术是很难满足海量数据处理的需求。大家应该都知道Google的三篇论文分布式存储、调度、计算奠定了整个大数据技术的基础。基本上在同一个时期2006年出现了Hadoop的系统阿里巴巴在2009年发展出了飞天系统包括微软等头部公司都发展出了比较优秀的分布式系统。整个这个阶段整个大数据的技术其实是把数据做起来数据大起来再说。
2010年左右进入了大数据的一个蓬勃发展阶段这个阶段是之前我们希望大数据技术从能用转变为好用。这个阶段出现了一系列以SQL表达为主的一些引擎包括Hadoop体系发展出来Hive、Flink、Presto等一系列引擎。这个时候逐渐形成了以HDFS为统一的存储以ORC、Parquet为开放的文件格式上面有很多开放引擎为主的一个体系这个体系像我们今天讲的数据湖系统。这个阶段Hadoop的本质其实是一个数据湖系统。那数据湖的本质是什么本质是统一的存储能够存储原始的数据能够支持多种计算范式这就是数据湖的本质。
同一时期阿里巴巴在飞天系统的基础上发布了 MaxCompute Google 发布了Big QueryAWS发布了Redshift。这几个系统可以称之为大数据时代下的云数据仓库。那云数据仓库系统跟上述Hadoop体系有什么区别呢云数据仓库并不对外暴露文件系统暴露的是对数据的描述用表的方式用视图的方式暴露出来。存储引擎计算引擎是被屏蔽在系统里面的所以存储引擎计算引擎可以进行深度的优化然而用户是没有办法感知的。这个阶段可以看出来整个大数据技术已经开始细分已经初步的形成了湖的形态和仓的形态。
现在我们所处的这个阶段也就是2015年左右我们进入了大数据普惠阶段。这个阶段我们有观察到两个趋势。第一个趋势大数据技术的发展除了追求规模性能之外。更多的是看数据安全、数据治理、稳定性、低成本等企业级能力。我们也可以看出来阿里巴巴 基于MaxCompute 构建出了非常有阿里特色的数据中台系统。开源体系也发展出了Atlas和Ranger主要围绕血缘、治理、安全等开源项目。第二个趋势随着AI、IOT、云原生技术的发展对于非结构化数据处理的需求越来越强烈。使用云上对象存储作为统一存储的趋势越来越明显。Hadoop的体系也逐渐由HDFS为统一存储发展为云上像S3、OSS这样的云存储做为统一存储的数据湖体系。与此同时出现了很多数据湖构建像AWS Lake Formation以及阿里云发布的DLF这样的产品。数仓方向也在为了适应这样一个趋势我们也在跟数据湖做很密切的联动发展出了外表通过外表的方式可以对数据库里面的数据进行联邦计算。
纵观整个20年的发展随着大数据技术的演进其实是发展出来了仓跟湖的两种体系。
数据湖和数据仓库的定义和区别
我们可以用下图这张表来对比一下数据湖跟数据仓库到底有什么区别。 整体上来说数据湖是一个宽进宽出相对协同比较松耦合的系统。数据仓库是一个严进严出比较严格紧耦合的系统。数据湖是数据先进来然后再开始用所以是属于事后建模。可以存储结构化、半结构化、非结构化数据。数据湖是提供了一套标准的开放接口来支持更多的引擎像插拔式的插到这个体系里面所以它是向所有的引擎开放。但是这里要注意了正是因为它是插拔式的这种方式计算跟存储其实是独立的两套系统。它们彼此之间其实是不能够相互理解的也没有办法做到深度的优化。这样其实导致引擎的优化只能做到适度有限优化。数据湖易于启动但是随着数据规模的增长一系列的治理管理的问题出现后期是比较难以运维的。因为数据湖不做Schema的强一致的数据检查所以数据治理比较低难管理使用。因为数据湖的数据是先进来再使用所以它更适合解决未知的问题比如探查类的分析科学计算数据挖掘等计算处理。
数据仓库在对比维度里基本都是相反的状态数据仓库是一个严格的系统所以需要事前建模数据经过转化清洗进到仓里面存储类型变为结构化或者半结构化。因为数据仓库是一个相对封闭的系统是一个自闭环的系统所以数据仓库向特定引擎开放但是恰恰因为数据仓库是一个自闭环系统它的计算引擎、存储引擎、元数据之间是可以做到非常深度、垂直的优化可以获得一个非常好的性能。数据仓库因为事前建模数据才能进来所以难启动相对来讲启动成本较高。但一旦数据进入数仓之后整个数据的高质量方便做治理这个时候它的整体成本会降低甚至达到一个免运维的状态。数据仓库的Schema会做强一致的检查所以数据质量很高易于使用。所以数据仓库的计算负载天然的适合做离线计算交互式计算以及BI和可视化。
数据湖的灵活性和数据仓库的成长性
整体上来讲数据湖更偏灵活性数据仓库更偏企业级能力。那么这两种特点对于企业到底意味着什么呢我们用下面这张图来表示。 横轴代表企业的业务规模纵轴代表企业构建大数据平台的整体成本。在企业发展的初期业务规模还较小数据从产生到消费还处于一个创新探索的阶段数据湖架构就比较适用不仅易于启动和上手也可以针对临时的数据处理需求快速的添加或部署新的服务而且还有很多开源社区的文章参考。而当企业逐渐成熟起来数据规模变的很庞大参与的人员和部门不断增多对数据治理、精细化的权限控制、以及成本控制等需求就变得越来越关键那么这个时候继续使用数据湖数据处理和管理的开销就会大幅增加。而数据仓库架构就更适用它的高数据质量保证、强管控等能力更适合企业的成长和发展。既然数据湖和数据仓库在企业发展的不同阶段均发挥着关键的作用那么有没有一种技术或者架构可以同时发挥两者的优势呢通过我们对业界的洞察以及阿里云自身的实践我们认为湖和仓正在发生融合湖仓一体新的数据管理架构可以很好的解决这个问题。 数据仓库是一个严格的系统所以数据仓库更适合做事务支持Schema强一致检查和演进天然支持BI更容易做实时性。对于数据湖优势在于数据类型丰富支持多种计算模式有开放的文件系统开放的文件格式是存储计算分离的架构。
所以数据仓库到湖仓一体的演进需要从本身拥有的特性发展出数据湖的特性。其实是要跟HDFS、OSS这样的系统做好联动做好融合所以数据仓库的结构更偏左右结构。对于数据湖到湖仓一体的演进是需要更多的站在HDFS、OSS基础上面来做出强仓的特性。所以数据湖的结构更像一个上下结构。那么DeltaLake和Hudi其实就是在上下结构当中插了一层做了一个湖上面的能够支持强仓的文件类型。
但不管是数据仓库到湖仓一体还是数据湖到湖仓一体最终大家演进的这个方向都是一致的都是湖仓一体。湖仓一体的特性是不变的四种偏仓的特性四种偏湖的特性。
阿里云湖仓一体架构介绍和最新发布 阿里云在2020年的云栖大会上首次提出湖仓一体全新的架构并且在持续的进行架构的升级和技术的优化。上图左侧是阿里云湖仓一体整体架构从下往上看底层是网络层中间层为湖仓引擎层在往上是DataWorks 湖仓数据开发层最上面是业务应用层。我们重点来讲下引擎层阿里云湖仓一体是左右结构左边是阿里云以MaxCompute为代表的自研云数仓产品右边是阿里云 EMR开源数据湖产品中间是通过元数据的统一通过开放格式兼容以达到数据跟任务可以在数据仓库和数据湖之间的任意流动。在2020年云栖大会上发布的是对于Hadoop数据湖的支持。近期我们已经支持阿里云DLF和OSS 的数据湖的湖仓一体。
右边我们highlight了阿里云湖仓一体近期发布的功能点
第一个是更易用的湖仓开发体验DataWorks进行了湖仓一体化的开发和管理的升级支持客户分钟级的自助打通湖和仓屏蔽了很多底层的配置细节让客户实现快速的业务洞察。
第二个是更广泛的生态对接我们可以对接阿里云DLF元数据服务来支持OSS数据湖查询而且也支持Delta lake、Hudi等多种开源文件格式。同时我们也将通过foreign server的方式扩展支持多个外部联邦数据源如未来2个月将支持RDS整库的联邦映射比之前单表映射效率更高。
第三个是更高的性能MaxCompute全新支持智能 Cache配合 内置查询加速引擎可以使数据湖查询性能提升 10 倍以上。
第四个是更丰富的数据类型我们即将支持非结构化数据的湖仓管理能力这个是我们近期正在研发的新功能之前讲的湖仓一体主要是针对湖里的结构化数据这次的发布将针对湖里的非结构化数据我们给客户提供一种非常简单的操作方式可以将湖里的非结构化数据映射成MaxComput数仓中的一种特殊对象然后客户可以像操作表的方式来操作这个对象这个好处是可以将MaxComputeDataWorks强数仓的管理能力投射给非结构化数据来提高非结构化数据的管理甚至治理能力。
阿里云湖仓一体关键技术
不管是从上下结构还是左右结构演进过来的湖仓一体最终都应该是一个简单易用的系统体系。阿里云湖仓一体有四大关键特性这四大关键特性都是在围绕怎么把数据湖跟数据仓库做到更加易用。 1.快速接入
主要有两个层次一个是网络层一个是湖仓一体的开通层。MaxCompute 支持云上云下任何环境下Hadoop体系的打通因为MaxCompute 自有的多租户体系如何跟特定的一个用户环境打通技术方面有很大的挑战我们研发了PrivateAccess网络连通技术来达到这个目标。第二个是DataWorks进行了湖仓一体化的开发和管理的升级支持客户分钟级的自助打通湖和仓屏蔽了很多底层的配置细节让客户实现快速的业务洞察 2. 统一的数据/元数据
其中关键的技术是有一个Database级别的元数据映射就是我们可以把数据湖上面的Database映射成MaxCompute 里面的一个Project。数据湖上面的数据不需要移动就可以让 MaxCompute 像访问操作普通Project一样进行消费。同时做到数据湖和数据仓库的数据/元数据做到实时同步如果数据湖内的一张表数据或者Schema发生变化可以及时的反应在 MaxCompute 数仓这一侧。同时 MaxCompute 具备内置的存储文件格式我们也在持续的跟进开源生态内的文件格式广泛支持开源数据文件格式Delta Lake和Hudi。
3. 提供统一的开发体验
数据湖和数据仓库是两个不同的数据处理系统有各自的数据库对象模式设计去年我们做了很多工作统一了两边的数据库对象模型加上MaxCompute的SQL和Spark语言高度兼容生态作业脚本可以做到两边高度兼容我们在一些客户case上可以做到无缝的进行切换。Dataworks具备多引擎的开发和调度能力我们在此基础上提供了湖仓更加统一的开发和管理功能。并且我们即将支持的非结构化数据的湖仓管理能力进一步的统一了结构化数据和非结构化数据的开发和管理体验。
4. 自动数仓
这是我们一直重点投入的领域。MaxCompute cache技术配合离线查询加速引擎对数据湖查询场景可加速10倍以上同时我们还能够根据业务场景动态调整的策略进行智能化Cache实现数据在湖仓架构里的冷热分层。我们的Cache本身需要存储跟计算做到深度耦合所以数仓做这层Cache可以做到更加的极致。另外我们还尝试在数据湖的数据上进行打标跟识别是从数据建模的角度来判定哪些数据更适合放到仓里面哪些数据更适合放到湖里面。比如一些结构化被反复访问比较高频的表数据更适合放到数据仓库内。如果偏非结构化/半结构化低频的数据更适合放到数据湖内。最终的目的是为了在性能、成本以及业务效果上达到一个最佳的平衡。
3 分析服务一体
分析服务一体化是阿里云一体化数仓中一个重要的能力创新英文叫Hybrid Serving and Analytical ProcessingHSAP是阿里云首先提出的一个架构趋势的理念。分析是通过数据做决策的过程是分析常见的有多维分析、探索式分析、交互式分析、Ad Hoc分析多种说法比如Presto、Greenplum、ClickHouse等系统通常是用在内部经营报表、领导驾驶舱、指标库平台领域擅长处理复杂多变灵活的查询。服务是数据服务通常是TP领域的说法表示支撑在线业务的高性能、高QPS的数据读写需求数据单次请求量不大但对SLA、可用性、延时都有很高的要求与传统TP的核心区别是对事务的要求弱于对吞吐和性能的要求可以采用更灵活的一致性协议比如只需要访问的单调递增性减少了分布式锁的开销常见于HBase、Redis等NoSQL系统通常服务toC在线推荐、在线营销、风控等场景。
两个场景底层数据来源是统一的业务数据库行为日志也是互相支撑在线服务生成的数据需要做二次分析分析的结果数据用于在线服务通过分析服务一体化架构可以简化系统间数据交换提升开发效率为上层应用提供统一的数据服务出口保证了数据口径的一致性。
实时数仓趋势敏捷化、在线化、一体化
什么是一个有效率、有质量、可靠的实时数仓呢基于过去多年的观察和技术实践我们发现了实时数仓领域的三个趋势性特征敏捷化、在线化和一体化。
● 在加工领域加工方法论进行敏捷化升级包含加工脚本的轻量化实时化数据分层的弱化减少层次减少调度从而让数据从生产到消费的链路更加紧凑、简单从而缩短数据可用的等待时间。
● 在服务领域大数据团队直接服务公司的核心在线业务从成本中心转为盈利中心保障在线业务的稳定和高效率通过数据智能提高营销效率提高风控准确度等这让大数据技术从内部分析工具转为在线生产系统需要在系统设计层面支持更高的可靠性、稳定性以及生产级运维能力。
● 在架构领域通过分析服务一体化融合架构减少数据割裂形成统一的数据服务层可以提升开发效率降低运维成本保障了数据口径的一致性和新鲜度。 数据加工敏捷化
传统上搭建一个合理的大数据实时数仓系统是个复杂的工作基本采用Lambda架构有实时加工层、离线加工层甚至还有近实时处理层数据存储根据不同的访问特征分为离线存储和在线存储在线部分还细分为OLAP系统和Key/Value系统分别提供灵活分析和在线高性能点查。在应用侧以API方式访问的多是在线系统以SQL方式访问的多是分析系统不同的系统分别对接不同的存储引擎采用不同的协议使用不同的访问控制策略。
这套架构在业务变化少数据质量高时是有效的但现实要复杂得多业务的变化越来越敏捷数据的质量更是参差不齐数据结构日常频繁调整数据质量需要随时修正重刷这些都是高频且耗时的工作。但目前数据散落在多个不同的系统中数据反复在存储系统间同步让业务的敏捷变得不可能IT同学每天花费大量的时间在数据的排查修正上响应业务变化的周期以周为单位甚至更长。
因此架构上的数据孤岛必然导致数据同步难资源消耗大开发成本高同时招聘人才也更困难。 如果要对复杂的架构进行简化实现数据加工的敏捷化核心是两点一个是简化状态存储减少数据冗余这样数据开发、数据修正只在一份数据上另一个是加工链路的轻量化。
在状态存储上Hologres提供了高吞吐低延时的实时写入与更新的能力写入即可分析不论单条灵活更新还是上亿条批量回刷都可以支持基于Hologres构建数据的统一状态层显著减少数据搬迁。
在数仓加工上采用数仓分层的方法论支持指标的沉淀和复用加工可以分为公共层加工与应用层加工公共层加工采用FlinkHologres Binlog的方式实现ODS-DWD-DWS的全链路事件实时驱动开发支持数据写入即加工。在应用层加工上通过视图封装业务逻辑减少中间表管理通过Hologres的分布式查询能力为业务层提供良好的分析灵活性将灵活性从数据工程师交还给业务分析师实现自助分析、探索式分析。 数据服务在线化
实时数仓的一个核心趋势是数据服务在线化。数据从针对ToB的对内决策场景拓展到支持ToC的在线业务场景支持实时用户画像实时个性化推荐实时风控等通过数据实现在线转化的提效。这对系统的执行效率和稳定性提出了更高的要求从稍微边缘的分析系统进入mission-critical的在线业务系统需要数据平台具备高可用高并发低延时低抖动要支持云原生的弹性能力支持服务热升级热扩容还要具备完善的可观测性和运维能力。 针对这些需求Hologres在存储引擎执行引擎运维能力做了大量的创新能力这包括了存储上在原有行存、列存基础上支持了行列共存结构让同一张表兼具OLAP和KeyValue两种优势场景同时引入了Shard级多副本能力实现了单实例内部通过增加副本数实现QPS线性增长的能力。通过组合行列共存和shard副本能力可以支撑新的非主键点查能力广泛用在订单检索等场景中。
系统不可避免会有运维升级的需求Hologres引入了热升级的能力在升级过程中服务不中断降低系统运维对在线业务的影响通过元数据物理备份以及数据文件lazy open等能力优化了故障恢复时的速度实际业务验证表明有10倍以上的恢复提速分钟级故障自动恢复将故障的影响做到了最小。
同时针对企业级安全场景Hologres提供了数据加密存储数据脱敏访问查询日志自助分析等能力支持完整企业级安全能力。
数据架构分析服务一体化 分析服务一体化是简化数据平台统一数据服务出口的重要趋势它也是存储查询引擎的能力创新在一个架构内支撑了两种典型的数据场景既可以执行复杂的OLAP分析也可以满足在线服务的高QPS、低延时在业务上为用户创建了统一的数据服务出口实现了业务敏捷响应支撑数据自主分析避免了数据孤岛也简化了运维。这对技术架构的挑战很高。因此Hologres在存储上针对不同场景设计了行存和列存分别支撑服务场景和OLAP场景在计算上在数据共享基础上需要有效率支撑细粒度隔离。 Hologres具备基于共享存储的多实例高可用部署模式。在这个方案中用户可以创建多个实例这些实例代表了不同的计算资源但所有的实例共享同一份数据其中一个实例作为主实例支持数据的读写操作其他实例作为子实例是只读的不同实例之间数据内存状态是毫秒级实时同步物理存储上只有一份。在这个方案中数据是统一的权限配置也是统一的但计算负载通过物理资源区分做到了100%隔离。读写请求不会争抢资源支持读写隔离也体现了更好的故障隔离能力。一个主实例目前最多支持挂载4个子实例如果是同一Region部署则共享存储如果是不同Region部署则数据需要复制存储多份实现容灾的能力。这个方案在大促场景下被阿里巴巴内部多个核心业务反复验证的方案可靠性高。通常我们建议一个主实例作为数据写入和加工一个子实例用于内部OLAP经营分析一个子实例用于对外数据服务可以根据不同场景计算力的需求分配不同的计算规格。
通过数据加工层的事件驱动加工与视图敏捷能力通过数据存储层的行列多种存储结构、多实例共享存储架构通过数据计算层的细粒度资源隔离读写分离等分析服务一体化数仓方案为用户提供了满足数据灵活分析与在线服务场景的更精简架构更有效率的开发方法论和更容易治理与性价比的基础组件。
4 全链路数据治理
在企业发展初期或者企业数仓建设初期大家更关注的是如何小步快跑先把数仓整体框架快速搭建起来快速满足业务需求追求更小的成本和更短的交付时间。这个阶段绝大多数企业选择以面向开发视角的自底向上来构建数仓也就是基础的ETL工作。随着企业或企业数仓逐步发展成熟传统企业数字化转型的推进以及数据中台建设渐入深水区原有的“精益生产”方式来构建数仓已经无法满足企业数仓规范化、可持续发展的要求企业数仓建设开始向“敏捷制造”转变更强调标准化、流程化、方法论指导以及组织管理并借助现代化技术和工具来最大限度发挥人的价值。
在这个背景之下阿里云DataWorks在过去多年间一直致力于全链路数据治理产品体系的建设希望能够为企业打造出一套集数据开发和数据治理为一体的一站式平台并与MaxCompute和Hologres一道形成云原生一体化数仓产品解决方案。在数据治理方面阿里云DataWorks在数据质量、数据安全、稳定性保障等基础能力之上近期着力打造了智能数据建模、数据治理中心产品并全新升级了开放平台让用户和伙伴可以实现自定义数据治理插件从而帮助企业实现个性化的数据治理。
智能数据建模
阿里云DataWorks全新推出了智能数据建模产品基于Kimball维度建模理论与阿里巴巴数据中台建设方法论构建能够有效帮助企业实现面向业务视角自顶向下进行数仓规划与规范建模并与DataWorks成熟的自底向上的数据开发ETL能力形成合力帮助企业建设规范化和可持续发展的数仓。 1. 数仓规划
数仓规划是数仓建设的基础阿里云DataWorks智能数据建模的数仓规划工具可以支持从业务抽象到数仓顶层设计包含了数仓分层定义数据域、业务过程、数据维度等。从而有效解决企业数仓结构混乱、权责不清等问题。
2. 数据标准
没有数据标准数据模型就无据可依。阿里云DataWorks的数据标准工具提供了数据字典、标准代码、度量单位、命名词典等定义并支持与数据质量规则无缝打通从而实现快速落标检查。
3. 维度建模
在运用专业的建模工具之前绝大多数企业可能会采用基于文档的形式来设计和记录数据模型刚开始时可以有效解决问题但文档面临着难以持续维护更新的问题久而久之就会与线上系统脱节而线上系统的数据模型就会逐步失控。阿里巴巴早期的数仓建设同样面临着这个问题并通过实践证明光靠组织制度是难以保证数仓模型的强一致性。为此阿里云DataWorks基于Kimball维度建模理论构建了维度建模工具。提供了可视化正向建模和逆向建模。通过逆向建模可有效将已经存在的数仓中的表逆向为数据模型并在此之上进行模型迭代从而帮助企业解决数仓建模冷启动的难题。同时为了提升效率阿里云DataWorks也提供了类SQL的数据建模语言让喜欢写代码的数据工程师可以快速进行数据建模也极大的便利了数据模型的导入导出和备份恢复。
4. 数据指标
同样在有专业数据指标管理工具之前大家可能采用手工写SQL代码来创建和管理数据指标这会带来指标口径不一指标难以复用等难题。阿里云DataWorks全新推出的数据指标工具可提供原子指标和派生指标的定义从而有效确保业务指标口径统一实现指标的高效产出和复用满足企业频繁的看数用数需求。
数据治理中心
阿里云DataWorks在过去多年发展迭代中沉淀了非常多的数据治理能力包含数据质量管理、数据权限管理、敏感数据保护、元数据管理、数据血缘、影响分析、基线保障等等但要把这些工具用好依然依赖于人的经验能力。很多企业在数据治理的过程中也面临数据治理的成效不易评估治理团队业绩不好衡量从而导致数据治理过程往往沦为项目制、运动式不可持续。为解决这样的问题阿里云DataWorks全新推出了数据治理中心产品通过问题驱动的方式帮助企业主动发现待治理问题然后引导用户优化和解决问题再提供数据治理成效的评分模型帮助企业定量评估数据治理的健康度从而实现有效的、可持续运营的数据治理过程。 阿里云DataWorks数据治理中心产品提供了五个维度的待治理问题的发现能力包含研发规范、数据质量、数据安全、计算资源和存储资源。针对这五个维度产品内置了非常丰富的治理项扫描机制能够在事后识别出问题。例如发现暴力扫描的任务、长时间未访问的表等优化之后就可以大大减少计算和存储资源成本。同时产品也内置了检查项拦截机制在事前和事中提前发现和拦截问题。例如可以在任务发布阶段通过发布检查项拦截不符合事先定义的代码规范的任务从而确保企业研发规范的落实。
针对这五个维度阿里云DataWorks结合在阿里巴巴内部的实践设计了一套健康分评估模型可以有效的定量衡量数据治理的成效。企业可以通过数据治理健康分快速识别自身短板然后针对性进行治理并通过健康分实现评比和考核从而达到可持续可运营的数据治理让数据治理过程有的放矢不再无从下手。
同时阿里云DataWorks数据治理中心产品提供不同角色视角的管理视图。通过个人视图让数据工程师可快速识别自己的任务和数据表的问题。通过管理者视图让项目管理员或团队管理员可以查看本项目或本团队的问题以合理规划和推进数据治理工作。团队中的不同成员各居其职实现执行与管理的统一。
DataWorks开放平台
企业的数据治理过程并非标准化的阿里云DataWorks数据治理中心提供的产品能力必然也无法完全满足企业数据治理中的所有需求。因此一套完善的数据治理平台必须要支持插件化机制允许企业自定义数据治理插件。我们的数据治理中心中用于问题发现的治理项和问题拦截的检查项就可视为一个个数据治理插件并且DataWorks允许用户自定义数据治理插件。 为了实现自定义数据治理插件阿里云DataWorks全新升级了开放平台在原有OpenAPI基础之上新增了开放事件Open Event、扩展点Hook和扩展程序Extensions能力。您可以通过Kafka来订阅DataWorks平台中开放的事件消息。DataWorks对核心流程中的事件提供了扩展点机制即Hook当事件发生时系统会自动中断流程同时等待您接收到事件消息并对事件消息进行自定义处理最后通过OpenAPI将您的处理结果回调给DataWorksDataWorks将根据您的自定义处理结果选择执行或者阻断后续流程从而实现您对DataWorks处理流程的自定义控制。您订阅事件、处理事件和回调事件处理结果的程序服务称之为扩展程序即插件。通过这种方式您可以实现各式各样的自定义数据治理插件例如任务发布检查插件、计算费用消耗检查插件等。
当然DataWorks开放平台适用场景远不止实现数据治理插件通过OpenAPI、开放事件、扩展程序机制可以帮助您快速实现各类自有应用系统对接DataWorks方便快捷的进行自定义数据流程管控自定义数据治理和运维操作在自有应用系统中及时响应DataWorks中的业务状态变化。欢迎大家发挥想象力通过DataWorks开放平台实现各类行业化、场景化的数据应用以更好的服务于您或您的客户进行企业数据中台建设。
阿里云DataWorks自2009年开始伴随着阿里巴巴从数仓到数据中台12年的发展之路产品久经考验与打磨沉淀了阿里巴巴大数据建设的最佳实践。从2015年开始在阿里云上对外提供服务迄今已经支撑了众多部委、地方政府、央企、国企、私企和组织等共计数千家客户的数字化转型。 通过本次全新发布的智能数据建模、数据治理中心和开放平台等数据治理相关产品阿里云DataWorks将协同MaxCompute、Hologres组成云原生一体化数仓解决方案进一步帮助企业构建现代化数仓并通过行之有效的数据治理来确保企业数仓能够规范、安全、稳定、可持续地发展同时有效控制IT成本让企业真正将数据变成企业资产让数据为企业创造更大的价值。
原文链接
本文为阿里云原创内容未经允许不得转载。
