本文大纲

一、云原生一体化数仓的发布背景

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；在时效性上，加工系统通过采用批次加工理念，T+1方式完成数据加工，而分析系统希望数据写入即可用，实时可更新；在使用上，加工系统是离线的作业提交，作业有进度，中间步骤可重试，分析系统是在线系统，查询是同步响应，查询只有成功和失败两种状态。不同的需求场景决定了不同的技术路线，为了扩展性，离线系统采用作业异步调度，资源计算时分配，计算存储完全解耦的设计，为了实时的性能，实时系统采用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交互式查询等场景。

更多技术参考：高性能原生加速MaxCompute核心原理

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 Query，AWS发布了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数仓中的一种特殊对象，然后客户可以像操作表的方式来操作这个对象，这个好处是可以将MaxCompute+DataWorks强数仓的管理能力投射给非结构化数据，来提高非结构化数据的管理甚至治理能力。

 

阿里云湖仓一体关键技术

 

不管是从上下结构还是左右结构演进过来的湖仓一体，最终都应该是一个简单易用的系统体系。阿里云湖仓一体有四大关键特性，这四大关键特性都是在围绕怎么把数据湖跟数据仓库做到更加易用。

 

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 Processing，HSAP，是阿里云首先提出的一个架构趋势的理念。分析是通过数据做决策的过程是分析，常见的有多维分析、探索式分析、交互式分析、Ad Hoc分析多种说法，比如Presto、Greenplum、ClickHouse等系统，通常是用在内部经营报表、领导驾驶舱、指标库平台领域，擅长处理复杂多变灵活的查询。服务是数据服务，通常是TP领域的说法，表示支撑在线业务的高性能、高QPS的数据读写需求，数据单次请求量不大，但对SLA、可用性、延时都有很高的要求，与传统TP的核心区别是，对事务的要求弱于对吞吐和性能的要求，可以采用更灵活的一致性协议，比如只需要访问的单调递增性，减少了分布式锁的开销，常见于HBase、Redis等NoSQL系统，通常服务toC在线推荐、在线营销、风控等场景。

两个场景底层数据来源是统一的（业务数据库+行为日志），也是互相支撑，在线服务生成的数据需要做二次分析，分析的结果数据用于在线服务，通过分析服务一体化架构，可以简化系统间数据交换，提升开发效率，为上层应用提供统一的数据服务出口，保证了数据口径的一致性。

 

实时数仓趋势：敏捷化、在线化、一体化

什么是一个有效率、有质量、可靠的实时数仓呢？基于过去多年的观察和技术实践，我们发现了实时数仓领域的三个趋势性特征，敏捷化、在线化和一体化。

●      在加工领域，加工方法论进行敏捷化升级，包含加工脚本的轻量化实时化，数据分层的弱化，减少层次，减少调度，从而让数据从生产到消费的链路更加紧凑、简单，从而缩短数据可用的等待时间。

●      在服务领域，大数据团队直接服务公司的核心在线业务，从成本中心转为盈利中心，保障在线业务的稳定和高效率，通过数据智能提高营销效率，提高风控准确度等，这让大数据技术从内部分析工具转为在线生产系统，需要在系统设计层面支持更高的可靠性、稳定性以及生产级运维能力。

●      在架构领域，通过分析服务一体化融合架构，减少数据割裂，形成统一的数据服务层，可以提升开发效率，降低运维成本，保障了数据口径的一致性和新鲜度。

 

数据加工敏捷化

传统上，搭建一个合理的大数据实时数仓系统是个复杂的工作，基本采用Lambda架构，有实时加工层、离线加工层，甚至还有近实时处理层，数据存储根据不同的访问特征，分为离线存储和在线存储，在线部分还细分为OLAP系统和Key/Value系统，分别提供灵活分析和在线高性能点查。在应用侧，以API方式访问的多是在线系统，以SQL方式访问的多是分析系统，不同的系统分别对接不同的存储引擎，采用不同的协议，使用不同的访问控制策略。

这套架构在业务变化少，数据质量高时是有效的，但现实要复杂得多，业务的变化越来越敏捷，数据的质量更是参差不齐，数据结构日常频繁调整，数据质量需要随时修正重刷，这些都是高频且耗时的工作。但目前数据散落在多个不同的系统中，数据反复在存储系统间同步，让业务的敏捷变得不可能，IT同学每天花费大量的时间在数据的排查修正上，响应业务变化的周期以周为单位，甚至更长。

因此，架构上的数据孤岛，必然导致数据同步难，资源消耗大，开发成本高，同时招聘人才也更困难。

 

如果要对复杂的架构进行简化，实现数据加工的敏捷化，核心是两点，一个是简化状态存储，减少数据冗余，这样数据开发、数据修正只在一份数据上；另一个是加工链路的轻量化。

在状态存储上，Hologres提供了高吞吐低延时的实时写入与更新的能力，写入即可分析，不论单条灵活更新还是上亿条批量回刷，都可以支持，基于Hologres构建数据的统一状态层，显著减少数据搬迁。

在数仓加工上，采用数仓分层的方法论，支持指标的沉淀和复用，加工可以分为公共层加工与应用层加工，公共层加工采用Flink+Hologres 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将您的处理结果回调给DataWorks，DataWorks将根据您的自定义处理结果选择执行或者阻断后续流程，从而实现您对DataWorks处理流程的自定义控制。您订阅事件、处理事件和回调事件处理结果的程序服务称之为扩展程序，即插件。通过这种方式，您可以实现各式各样的自定义数据治理插件，例如任务发布检查插件、计算费用消耗检查插件等。

 

当然DataWorks开放平台适用场景远不止实现数据治理插件，通过OpenAPI、开放事件、扩展程序机制，可以帮助您快速实现各类自有应用系统对接DataWorks，方便快捷的进行自定义数据流程管控，自定义数据治理和运维操作，在自有应用系统中及时响应DataWorks中的业务状态变化。欢迎大家发挥想象力，通过DataWorks开放平台实现各类行业化、场景化的数据应用，以更好的服务于您或您的客户进行企业数据中台建设。

 

阿里云DataWorks自2009年开始伴随着阿里巴巴从数仓到数据中台12年的发展之路，产品久经考验与打磨，沉淀了阿里巴巴大数据建设的最佳实践。从2015年开始在阿里云上对外提供服务，迄今已经支撑了众多部委、地方*、央企、国企、私企和组织等共计数千家客户的数字化转型。 通过本次全新发布的智能数据建模、数据治理中心和开放平台等数据治理相关产品，阿里云DataWorks将协同MaxCompute、Hologres组成云原生一体化数仓解决方案，进一步帮助企业构建现代化数仓，并通过行之有效的数据治理来确保企业数仓能够规范、安全、稳定、可持续地发展，同时有效控制IT成本，让企业真正将数据变成企业资产，让数据为企业创造更大的价值。 

阿里云大数据是为业务敏捷而生的简单、易用、全托管的云原生大数据服务。激活数据生产力，分析产生业务价值。详情访问：https://www.aliyun.com/product/bigdata/apsarabigdata