持续定义 Saas 模式云数据仓库 +实时分析 | 学习笔记

开发者学堂课程【SaaS 模式云数据仓库实战：持续定义 Saas 模式云数据仓库 +实时分析】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/332/detail/3720

持续定义 Saas 模式云数据仓库 +实时分析

内容介绍：

一、云数据仓库概述

二、实时分析场景与价值

三、MaxCompute 云数仓+实时分析

四、实时分析案例

一、云数据仓库概述

1、数据仓库

数据仓库的作用从数据源、数据生产开始，一直到分析应用、数据消费，包括数据仓库、采集同步、加工、存储、建模、治理、查询。

黄色部分是数据仓库建模的部分，ODS、CDM/DW、ADS/DM 这些是建模的业务部分，有一套完善的方法论讲述数据是如何组织的。下面是技术层次包括数据的存储 Storage、数据的处理 ETL、数据的管理。

数仓的概念:

数据仓库的特征在于面向主题、集成性、稳定性和时变性，用于支持管理决策。

数据仓库的意义在于对企业的所有数据进行汇总，为企业各个部门提供统一的， 规范的数据出口。

观点:

数据仓库(模型)本质是人收集和存储数据，认识数据，组织和管理数据，使用数据决策的最佳实践形成的方法论。

模型本身与在哪、用什么技术无关。

但逻辑模型和物理模型在最终方案中又是紧密结合的。

2、云数据仓库

MaxCompute 是云数仓的代表，数仓的基本能力采集同步、加工、存储、建模、治理、查询是不变的，但有些是为了实现数仓的价值必须要做的，首先要有个 IDC 机房，要部署、开通，维护它的日常运维，后续要扩展，还有一些安全性的维护。

这部分过程的总成本，包括核心能力成本、基础成本，还可以算产品成本、数据后续的维护成本、当前的建设成本、长期的未能在这次投资中体现的成本、数仓持续演进的成本。

如果自建数仓，这些成本都需要考虑到，但是现在 MaxCompute 中 SaaS 模式的云数仓解决了底下的一些为了实现云数仓而产生的其他成本。我们可以有多个租户，在逻辑层面上直接开通 project，有开箱即用功能，数仓的功能非常完善，包括上下游的一些功能，还具备业界领先的大规模的高性能，可以直接用户归入无感的容灾备份，还有免运维、极致的安全能力，后续的灵活扩展、低成本，可能后续还会开展数据服务。数仓也是实时变化的，还有快速演进的能力。 

3、云数据仓库支持多场景数仓应用

MaxCompute：SaaS 模式企业级云数据仓库是不同的租户隔离的，在这里实现了整个数仓的所有的功能，包括 ETL、BI、实时分析，后期还有机器学习，甚至还有湖仓一体和统一的结构化的元数据，这些能力适合做实时数仓、交互式查询、流批一体、湖仓一体等等。

应用场景：

·实时数据入仓和分析决策

·业务运营场景-交互式业务指标计算、查询

·各行业搭建数据仓库-流批一体、湖仓一体

·云上弹性扩展大数据计算和存储

产品优势：

·云原生极致弹性：云原生设计，无服务器架构，支持秒级弹性伸缩，快速实现大规模弹性负载需求

·简单易用多功能计算：预置多种计算模型和数据通道能力，开通即用

·企业级平台服务：支持开放生态，提供企业级安全管理能力。与阿里云众多大数据服务无缝集成

·安全：多租户环境下安全控制能力强

·大规模集群性能强、全链路稳定性高，阿里巴巴双11场景验证

推荐组合：

·实时分析场景

-MaxCompute+MC-Hologres+Flink+DataWorks+Quick BI

·机器学习场景-MaxCompute+PAl+DataWorks

4、云数据仓库面向用户的功能和数据流程

上图说明了整个云数仓与外部周边的文化，以及整个数据的流程，包括实时的、非实时的，包括管理功能、治理功能是如何结合的一个数据流程。

二、实时分析场景与价值

1、重提大数据5V

5V 主要是大数据的大容量、高速率、多样性、数据质量也就是真实性、数据的价值。数据量越大，价值越多，时间越短，价值越大。

随着时间的增长，价值越来越少，因为很多分析的场景，发现问题得越早，越早能决策，产生的效果越大。

(1)容量(Volume)

是指大规模的数据量，并且数据量呈持续增长趋势。目前一般指超过10T 规模的数据量，但未来随着技术的进步，符合大数据标准的数据集大小也会变化。

(2)速率(Velocity)

即数据生成、流动速率快。数据流动速率指指对数据采集、存储以及分析具有价值信息的速度。因此也意味着数据的采集和分析等过程必须迅速及时。

(3)多样性(Variety)

指是大数据包括多种不同格式和不同类型的数据。数据来源包括人与系统交互时与机器自动生成，来源的多样性导致数据类型的多样性。根据数据是否具有一定的模式、结构和关系，数据可分为三种基本类型：结构化数据、非结构化数据、半结构化数据。

(4)真实性 (Veracity)

指数据的质量和保真性。大数据环境下的数据最好具有较高的信噪比。

(5)价值(Value)

即低价值密度。随着数据量的增长，数据中有意义的信息却没有成相应比例增长。而价值同时与数据的真实性和数据处理时间相关，见图。

2、实时分析的两种演化构建方式

最早的数仓一般是离线的，当时是受限于技术能力，现在的实时分析一种是从数仓里演化来的，比如说一个大酒店有餐饮、住宿业务，实时的理解成餐饮业务，是一个大酒店做了一段时间后发展出来的，要利用好原有的客流的流量，要有一些协同，比如是仓库的人员的各种协同。

演化1：以数仓分析为主场景，根据业务实时性需要，有一部分要求很高，所以演化出实时的需求，这种实时的可能会有快速的写入、快速的分析，跟原有的数仓进行交互式，形成了 Lambda 架构，这种演化出来的实时分析，它跟数仓是一体的，或者说是由数仓演化出来的。

另外一种可能一开始就是一个实时分析的场景，很多业务是从监控开始做起的，但是它也要分析、决策，可能一开始就像一个小饭店，只做餐饮这一块业务，只做实时这一块业务，但实时的越做越大，就会有一些积累的历史数类标签，而且需要跟它新满足的业务做一些沉淀，就像餐饮一样，需要更好的外围支持作用，并向综合性发展。

这两种来源是不一样的，因为每个人落到它的使用数仓时，有的人完全沉浸在数仓的流程里来，看到的可能就是 kappa 架构，有的人是从数仓中演化而来面对的就是 Lambda 架构。

演化2：以实时分析为主场景，形成流式架构，又需要能从数仓快速提取数据，和数据源回放，形成 kappa 架构，后续还要考虑实时数据和模型如何入仓。

3、实时分析的两种场景

以数仓分析为主场景，根据业务实时性需求进行实时分析，构建实时通道和实时交互式分析，形成 Lambda 架构

例如 IOT 设备监控分析，从 IOT 上取一些日志或者业务状态、设备信号、人员流动情况，对一些设备做一些配置，如果新换了策略，上来的数据就与原来的不一样，这些前后的变化需要用策略下发，然后对数据源产生影响，数据源生成一套新的数据，实时上报上来，这种从下到上的流程是从整个数仓演变出来的，而且它里面用到的一些数据也是从数仓里拿过来的。这套模型跟数仓也是一样的架构，就是刚才第一种大酒店的模式。

以实时分析为主场景，形成流式架构，又需要能从数仓快速提取数据，和数据源回放，形成 kappa 架构，后续还要考虑实时数据和模型如何入仓

例如欺诈监控，比如说股票购买或者一些金融交易的详单，对这些详单第一时间就要分析一套模型，类似于 CEP，第一时间识别这些模型是否欺诈，做一些报警监控，这套流程是完整的，后续的标签会被其他的方式使用，跟数仓的其他的数据融合形成离线分析。

4、数仓实时分析的能力要求

(1)极速查询响应

·毫秒级响应速度，轻松满足客户海量数据复杂多维分析需求

·千万 QPS 点查

·上千 QPS 简单查询

(2)实时存储

·亿级写入 TPS

·写入即可查询

(3)数仓查询加速

·直接分析

·无数据搬迁

·无冗余存储

·统一权限

(4)应用生态

·开发者生态

·丰富的 API、SDK

·BI 工具无缝对接

·流式处理工具和分布式消息队列无缝对接

(5)联合计算

·统一建模方法

·统一元数据

·统一的管控治理体系

·分层划域架构下的演进和整合

三、MaxCompute 云数仓+实时分析

1、常见的 Lambda 架构的问题

Lambda 架构是离线的批数理和实时的留数理二者的融合，它们可能共用了维度表、共用了一些分析结果的存储，批量的从 ODS、DWD 开始每天定时的周期性的存储、调度、分析，它可能没有那么多事项要求，但是数据量又很大，计算的逻辑一次都算出来形成的业务知识的沉淀和上层可能还会有一些交互式的分享，所以就快速的直接用消息队列里直接跑着我们要的数据，按照我们既定的规则直接把它跑上来、存上去，两个查询的结果要往一起融合的时候，可能要一些 KV 存储，还有一些问题，就是实时跟力量毕竟是两套代码，两套逻辑，语义不同，存储也不同，维护两套是一个高成本，而且语义不同，比如有一个地方算法修改，两个地方都要修改，这种是一致性的问题，另外一个是做一件事，只是因为它的实时性不同，就维护两个系统，那么维护的工作量、资源的消耗，还有标准，这些都是又复杂又难维护的，成本很高，第三是它的开发周期很长、业务不敏捷，改一块的东西可能就需要到处都去改，它也无法响应实时的变化，开发的周期、服务的周期都非常的长，这是 Lambda 架构的问题。

2、开源方案的能力分散

场景案例：搜索推荐精细化运营

这是对 Lambda 架构常用的技术方案，主要是针对实时场景，先是数据的采集，Flink 实时写入需要做交互式分析的比如像点查询的 HBase 里，或者交互分析的 Drill 里，或者是 Presto 里可以做分析的，有一些场景可能还放到 Redis、Mysql 里做一些数据库级别的或者说缓存级别的查询，它可以实现刚才说的营销、实时，就是库存实时报表、实时大屏的实时分析的功能，离线的数据 Flink 可以同时写到归档的离线里，比如 MaxCompute，但是这一个实时的分析场景里用了这么多的工具，就应用来说实现了点查、联邦查询、实时分析、离线加速，基本上把开源里看到的分析工具都用了一遍，这样的设计流程，任何一个单点故障都是非常复杂的。

KVStore:Redis/Mysql/Hbase/Cassandra 存储点查能力

MPP:Impala/Presto/Drill 计算+查询能力

实时数仓:Clickhouse/Druid 存储+计算+查询能力

数仓:Hive/Spark/MaxCompute 存储+批处理

多种能力统一于一个引擎，这个引擎可以实现结果缓存、离线加速、联邦分析、点查询、交互式分析。

3、实时分析简单架构：实时写入和实时查询

这是我们现在所说的 HSAP 混合服务分析处理的架构，它让 MaxCompute 如虎添翼，MaxCompute 是一个大的数操，可以做批处理，有高性能，也可以做一些实时加载的一些能力，但是查询效率相对较差一些，做实时数仓时还是比较大，可以理解成是一个传统数仓。有了 Hologres 后，它可以在一些小规模的实时分析的场景里，直接完成实时数仓的能力，而且还可以对 MaxCompute 进行加速。它可以实现实时跟离线数据的统一存储，以实时分析为中心进行整个的设计，还可以作为 MaxCompute 的加速，作为一个比较完善的融合。

云原生 HSAP 系统：

一份数据同时用于实时分析与在线服务

Hybrid Serving Analytical Processing

4、数仓加速分析：无数据搬迁、数据分析效率高

Hologres 还可以对 MaxCompute 查询的能力做补充，MaxCompute 原来也有一些查询的能力，但是不像 Hologres 可以实现点查询、交互式分析、OLAP 分析各种分析的能力，而且 Hologres 和 MaxCompute 数据都存储在 Pangu 分布式存储的系统上，有的是 Hologres 的内表，有的是 MaxCompute 的内表，作为外表的方式被 Hologres 引用。后续打算将它们的存储、权限做统一，包括应用层次做一下统一。现在可以实现无数据搬移的数据高效分析的数仓加速的能力。

Hologres 可以对数据库的 MaxCompute 各层做查询加速，做 OLAP 增强，因为查询跟处理毕竟还是两个场景，我更建议比如数仓的 DWS 层，或者是分析的 ADS 层这些偏应用的交互式分析加速查询的场景里来用。

5、开源方案实时数仓：实时成本高、开发周期长、业务支持不灵活

·kappa 架构，基于流式架构(数据走一遍，所以的都算出来，非常快)，需要回放和关联数仓，后续还要考虑实时数据和模型如何入仓。

·Kappa 架构的原理就是在 Lambda 的基础上进行了优化，将实时和流部分进行了合并，将数据通道以消息队列进行替代。因此对于 Kappa 架构来说，依旧以流处理为主，但是数据却在数据湖层面进行了存储，当需要进行离线分析或者再次计算的时候，则将数据湖的数据再次经过消息队列重播一次。

·Kappa 架构看起来简洁，但实施难度相对较高，尤其是对于数据回放部分，什么时候放、放多大、数据量大时怎么放、有多个数据源时怎么放，这些都是要考虑的问题。而且 Kappa 架构很多时候都要依赖于 Kafka 分布消息队列，前端还有点查、交互式查询、OLAP 分析这些查询能力，也是一个相对比较复杂的架构。

6、实时、离线、分析、服务一体化方案

有 Hologres，Flink 就可以直接存入到 MC-Hologres，然后直接可以做实时分析，它可以支持一些从 ODS 到 DWD 的超大事实表的存储、计算，还可以支持从 DWD 到 DWS 这种应用级别，其间可以有一些超大的维表的查询能力。

在大规模上，它的实时写入、实时分析的能力，在业内是比较强的，我们可以把数据按冷、热、温三个使用频度来处理。冷，包括 OSS、MaxCompute 离线数仓的这些数据；温，是 Hologres 对 MaxCompute 的查询加速，它可以把 DWS 和 ADS 这些偏应用、偏业务的数据放到 Hologres 里，有一种非常快速的交互式查询能力；热，就是实时写入、实时分析的这套流的参与能力。

Hologres 和 MaxCompute 在存储、数据交互、模型构建上是统一的，因为它就是 MaxCompute 里的一部分，Hologres 和 MaxCompute 的融合是可以被大家预期的，做到了实时离线联合分析，冷热温三类数据的全洞察。

四、实时分析案例

1、常用场景：实时、离线、分析、服务一体化方案

方案说明：适用于电商、游戏、社交等互联网行业数据化运营，如智能推荐、日志采集分析、用户画像、数据治理、业务大屏、搜索等场景。

方案优势：阿里巴巴最佳实践的大数据平台，1)技术领先性;2)降本提效;3)高附加值业务收益;

涉及产品:日志服务 SLS、数据传输 DTS、DataHub、实时计算 Flink，交互式分析、云数仓 MaxCompute、数据治理 DataWorks、Quick BI 报表、DataV 大屏、ES 搜索、机器学习 PAI。

在实时里用日志服务、DataHub、Kafka 消息队列，用 Flink 来处理，到 Hologres 里，然后做前台的 OLAP 分析。点查就是查询的用以固定的一个条件，可以做一些优化。交互式查询是一些没有定义好查询条件，可能有多列，或者是不同条件，都可以做查询，做一个查询之后，觉得结果可能不符合分析，换一个条件再查。OLAP 分析狭义来说就是有一套底下的 OLAP 模型，就是多维的模型，有维度表、实施表，然后可以在维度表上面上卷下钻，做旋转切片，拖拽 BI 报表，这是三种应用。Hologres 是可以一套方案完美的结合这三种能力，实时的 Flink 可以写入到 Hologres 里来，还有实时预警的这种场景，也可以直接推到前端，这也是一种应用场景。还有 Hologres 的这种场景更多一些，它可以跟 MaxCompute 之间做一些实时的模型和数据的归档、查询，这种刚才说的是实时的。

还有批量的，通过数据集成对传统的 DTL 分层的处理，构建ODS、DW 层的模型，包括实时的也可以批量的方式往 MaxCompute 来写入，整个前端都是由 DataWorks 来做数据开发、治理、服务的能力，这是所有产品的一个组合，这些实时的能力跟批量传统数仓的海量出仓的能力，是前端的 BA 应用派的 AI 分析或者是搜索 DataV 大屏的这种整体的架构。

2、PB 级用户行为交互式分析案例

友盟+是国内最大的移动应用统计服务商，其统计分析产品U-App&U-Mini&U-Web 为开发者提供基本报表统计及自定义用户行为分析服务。

业务痛点：

·业务数据量大，年新增行为数据10PB 级

·个性化、自定义地交互式用户行为分析强需求

·基于 MaxCompute 提供异步离线的 adhoc 分析和优化、以及自研引擎开发尝试均无法满足业务需求

有了 MC-Hologres 能力，首先有全部数据的行为数据，对它进行排序、预处理、用户分群构建一层 ODS，将上层分析的数据放到 Hologres 里，提前预计好存储和索引，用 Hologres 的引擎直接对接业务分析的引擎，它低下的平台是基于 MaxCompute 和 Hologres 实时的批量能力，对接业务引擎，最后生成统计数据。它现在可以实现30s 交互式的体验，而且 PB 级数据可以秒级查询，与 MaxCompute 深度集成，能够利用 range cluster 索引加速，实时离线联邦查询，同时也可以实现冷热数据混合查询，有利于成本性能平衡。

可以实现 MaxCompute 带来的资源弹性伸缩的稳定性，可兼顾扩展性、稳定性、性能、成本，在 PB 级里 Hologres 的表现是最好的。

3、互联网内容资讯客户实时推荐案例          

小影是一款原创视频、全能剪辑的短视频社区 APP，面向大众提供短视频创作工具，包括视频剪辑、教程玩法、视频拍摄，谷歌应用商城收入榜前五，全球累计用户突破8.9亿。

SaaS 模式云数据仓库(一套存储引擎、三种计算力量)

MaxCompute +Realtime Compute + MC-Hologres

离线计算       实时计算        交互式分析

(1)用户标签数据开发

客户通过 MaxCompute 针对每天 APP 产生的客户基础属性数据、行为日志数据、内容数据等进行计算，每天离线更新用户标签的数据，支持营销业务的使用。

(2)用户画像实时洞察

客户基于 MC 离线计算好的用户标签，通过 MC-Hologres 进行多标签、多维度的实时分析，了解用户属性标签与内容标签之间的关联性，洞察交叉销售机会，并通过人群圈选，进行 APP 消息 PUSH。

(3)实时视频推荐

客户通过 Flink+MaxCompute+MC-Hologres+PAI 搭建个性化实时推荐系统，基于用户特征和实时行为特征，实时推荐个性化的短视频内容。有一些中小级的客户，可能不一定对数据规模有那么高的要求，但是对架构要尽量的简单，实时性要尽量的强，那么我们就可以把一些需要用的，就像一些标签数据，用 MaxCompute 简单计算，然后整个实施的场景对接 Hologres 做一个输出，Hologres 场景也可以落回到了 MaxCompute 里来，像我们刚开始说的饭店的模式一样，它是以实时推荐的场景引起的，但是它用的 MaxCompute 的能力，也让它具备了数仓的能力，后续的业务积淀、业务实时的模型沉淀的能力，刚才就是属于我已经有一个数仓了，从上面要做一些分析，对性能做一些极致的优化，查询加速，可能后续演化出一些用户场景的业务行为的一些监控。