数仓之【MaxCompute】

一、简介

Maxcompute：云原生大数据计算服务是一种快速、完全托管的TB/PB级数据仓库解决方案。Maxcompute向用户提供了完善的数据导入方案以及多种经典的分布式计算模型，能够更快速的解决用户海量数据计算问题，有效降低企业成本，并保障数据安全。

MaxCompute是适用于数据分析场景的企业级SaaS（Soft as a Service）模式云数据仓库，以Serverless架构提供快速、全托管的在线数据仓库服务，消除传统数据平台在资源扩展性和弹性方面的限制，最小化用户运维投入，可以经济并且高效的分析处理海量数据。

Maxcompute还深度融合了阿里云如下产品：

DataWorks：基于DataWorks实现一站式的数据同步、业务流程设计、数据开发、管理和运维功能
人工智能平台API：基于机器学习平台的算法组件实现对Maxcompute数据进行模型训练等操作；
实时数仓Hologres：基于Hologres对MaxCompute数据进行外表查询加速，也可导出到Hologres进行交互式分析；
Quick BI：基于Quick BI对MaxCompute数据进行报表制作，实现数据可视化分析。

二、Maxcompute提供的核心功能如下：

全托管的Serverless在线服务：对外以API方式的在线服务，开箱即用；预铺设大规模集群资源，可以按需使用、按量计费；无需平台运维，最小化运维投入；
弹性能力和扩展性：存储和计算独立扩展，支持企业将全部数据资产在一个平台上进行联动分析，消除数据孤岛；支持实时根据业务峰谷变化分配资源；
统一丰富的计算和存储能力：Maxcompute支持多种计算模型和丰富的UDF；采用列压缩存储格式，通常情况下具备5倍压缩能力，可以大幅度节省存储成本；
数据建模、开发、治理能力：借助一站式数据开发与治理平台DataWorks，可实现全域数据汇聚、融合加工和治理。DataWorks支持对Maxcompute项目进行管理以及Web端查询编辑；
集成AI能力：与人工智能平台PAI无缝集成，提供强大的机器学习处理能力；可以使用熟悉的Spark-ML开展智能分析；
深度集成Spark引擎：内建Apache Spark引擎，提供完整的Spark功能；与Maxcompute计算资源、数据和权限体系深度集成；
仓湖一体：集成对数据湖（OSS或Hadoop HDFS）的访问分析，支持通过外部表映射、Spark直接访问方式开展数据湖分析；在一套数据仓库服务和用户接口下，实现数据湖与数据仓库的关联分析；
离线实时一体：与实时数仓Hologres深度融合，支持外部表关联查询，支持存储层直读，查询效率相比其他类型的外部表高5倍以上；Hologres针对MaxCompute支持查询加速，数据无需移动，查询加速10倍以上；Hologres支持对Maxcompute元数据的批量导入，无需手动创建外表；
支持流式写入和近实时分析：支持流式数据实时写入并在数据仓库开展分析；与云上主要流式服务深度集成，轻松接入何种来源的流式数据；支持高性能秒级弹性并发查询，满足近乎实时分析场景需求；
提供持续的SaaS化云上数据保护：为云上企业提供基础设置、数据中心、网络、供电、平台安全能力、用户权限管理、隐私保护等保护三级超20项安全功能，兼具开源大数据与托管数据库的安全能力。

三、产品架构

其中核心模块介绍如下

存储引擎：Maxcompute为您提供Maxcompute存储引擎（内部存储）用于存储Maxcompute表、资源等，同时您也可以通过外表的方式直接读取存储在OSS、TableStore、RDS等其他产品中的数据。其中Maxcompute存储引擎主要采用列压缩存储格式，通常情况下可达到5倍压缩比；
计算引擎：Maxcompute提供Maxcompute SQL计算引擎和CUPID计算平台。
- Maxcompute SQL引擎：可直接运行Maxcompute SQL任务。
- CUPID计算平台：可运行Spark任务、Mars任务等第三方引擎的任务。
云服务层：支持创建不同的任务队列，并为每个队列配置不同的资源和优先级，以便对任务执行进行更精细的空值，同时具备强大的调度系统，可以管理并优化计算资源的分配和使用，以提高系统的整体效率。MaxCompute也提供数据安全性的多层保护，包括项目空间隔离、权限空值、数据加密，确保数据的安全和隐私。
统一元数据及安全体系：Maxcompute的离线租户级别元数据信息通过Information Schema提供服务，同时Information Schema也提供Maxcompute的使用历史日志数据查询等服务，可以对作业的运行情况，例如资源消耗、运行时长、数据处理量等指标进行分析，用于优化作业或规划资源容量；Maxcompute还提供了完善的安全管理体系，例如访问空值、数据加密、动态脱敏等为数据安全提供安全性提供保障。
用户接口与开放性：Tunnel：数据传输服务集群，目前包括共享集群和独享集群；API和SDK：Restful API，Java SDK、Python SDK；JDBC；Connector：给第三方产品封装的连接器，目前包括Flink、Spark、Kafka等；开放存储；
数据生态支持：数据湖、数据集成、数据治理、三方引擎的数据开发、数据可视化分析
TopConsole：管理控制台。提供Maxcompute项目管理、Quota管理、租户管理等基础配置管理能力，以及作业运维、资源观测基本运维能力，还有物化视图、成本分析优化等增强运维能力。

Maxcompute产品优势

简单易用：
- 面向数据仓库实现高性能存储、计算
- 预集成多种服务，标准SQL开发简单
- 内建完善的管理和安全能力
- 免运维，按量付费，不适用不是产生计算费用
匹配业务发展的弹性扩展能力
- 存储和计算独立扩展，动态扩缩容，按需弹性扩展，无需提前规划容量，满足突发业务增长
支持多种分析场景
- 支持开放数据生态，以统一平台满足数仓、BI、近实时分析、数据湖分析、机器学习等多种场景
开放的平台
- 支持开放接口和生态，为数据、应用迁移、二次开发提供灵活性
- 支持与AirFlow、Tableau等开源和商业产品灵活组合，构建丰富的数据应用

ACID语义描述

原子性（Atomicity）：一个操作或是全部完成，或是全部不完成，不会结束在中间某个环节
一致性（Consistency）：从操作开始至结束的期间，数据对象的完整性没有被破坏。
隔离性（Isolation）：操作独立于其他并发操作完成。
持久性（Durability）：操作处理结束后，对数据的修改将永久有效，集市出现系统故障，该修改也不会丢失。

四、数仓构建流程

4.1 基本概念

业务板块：比数据域更高维度的业务划分方法，适用于庞大的业务系统；
维度：维度建模有偶Kimball提出。维度建模主张操你个分析决策的需求出发构建模型，为分析需求服务。维度式度量的环境，是我们观察业务的角度，用来反应业务的一类属性。属性的集合构成维度，维度也可以称为实体对象。例如，在分析交易过程时，可以通过卖家、买家、商品和时间等维度描述交易发生的环境；
属性（维度属性）：维度所包含的标识维度的列称为维度属性。维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键；
度量：在维度建模中，将度量称为事实，将环境描述为维度，维度是用于分析事实所需要的多样环境。度量通常为数值型，作为事实逻辑表的事实；
指标：指标分为原子指标和派生指标。原子指标是基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，是具有明确业务含义的名词，体现明确的业务统计口径和计算逻辑，例如支付金额
- 原子指标= 业务过程+度量
- 派生指标=时间周期+修饰词+原子指标，派生指标可以理解为对原子指标业务统计范围的圈定
业务限定：统计的业务范围，筛选出符合业务规则的记录（类似于where后的条件，不包括事件区间）
统计周期：统计的时间范围，例如最近一天，最近30天等（类似于sql中where后的时间条件）
统计粒度：统计分析的对象或视角，定义数据需要汇总的程度，可以理解为聚合运算时的分组条件（类似SQL中的group by的对象）。粒度是维度的一个组合，指明统计范围。例如，某个指标是某个卖家在某个省份的成交额，则粒度就是卖家、地区两个维度的组合。如果需要统计全表的数据，则粒度为全表。指定粒度时，需要充分考虑到业务和维度的关系。统计粒度常为派生指标的修饰词而存在

电商指标体系样例

4.2业务调研

在构建数据仓库之前，首先需要确定构建数据仓库的目标与需求，并进行全面的业务调研。需要了解真实的业务需求，以及确定数据仓库要解决的问题。

确定需求

充分的业务调研和需求分析是数据仓库建设的基石，直接决定数仓能否建设成功。在数据仓库建设项目启动前，需要请相关的业务人员介绍具体的业务，以便明确各个团队的分析员和运营人员的需求，沉淀出相关文档。

可以通过调查表和访谈的形式详细了解以下信息：

用户的组织架构和分工界面。
1. 例如，用户可能分为数据分析、运维和维护部门人员，各个部门对数据仓库的需求不同，需要对不同分别进行调研
用户的整体业务架构，各个业务板块之间的联系和信息流动的流程。需要梳理出整体的业务数据架构。
各个已有的业务板块的主要功能及获取的数据

本教程中以A公司的电商业务为例，梳理出业务数据框架如下如所示。A公司的电商业务板块分为招商、供应链、营销和服务四个模块，每个板块的需求和数据应用都不同。在构建数仓之前，首先需要明确构建数据仓库的业务板块和需要具体满足的业务需求。

此外，还需要进一步了解各业务板块中已有的数据功能模块。数据功能模块通常和业务板块紧耦合，对应一个或多个表，可以作为构建数据仓库的数据源。下边展现的是一个营销业务板块的数据功能模块。

数据功能模块	A公司电商营销管理
商品管理	Y
用户管理	Y
购买流程	Y
交易订单	Y
用户反馈	Y

说明：Y代表包含该数据功能模块，N代表不包括

假设用户是电商营销部门的营销数据分析师。数据需求为最近一条某品来（例如，厨具）商品在歌声的销售总额、该类目Top10销售商品名称和各省客户购买力分布（人均消费额）等，用于营销分析。最终的业务需求是通过营销分析完成该类目的精准营销，提升销售总额。通过业务调研，我们将着力分析营销业务板块的交易订单数据功能模块。

需求分析

在未考虑数据分析师和业务运营人员的数据需求的情况下，淡出依据业务调研结果构建的数据仓库可用性差。完成业务调研后，需要进一步收集数据的使用者的需求，进而对需求进行深度的思考和分析，需求分析的途径有两种：

根据与分析师和业务运营人员的沟通获知需求
对报表系统中现有的报表进行研究分析

在需求分析阶段，需要沉淀出业务分析或者报表中的指标，以及指标的定义和粒度。粒度可以作为维度的输入。建议思考下列问题，对后续的数据建模将有巨大的帮助：

业务数据是根据什么（维度、粒度）汇总的，衡量标准是什么？例如，成交量是维度，订单数是成交量的度量；
明细数据层和汇总数据层该如何设计？公共维度层如何设计？是否有公共的指标？
数据是否需要冗余或沉淀到汇总数据层中？

举例：数据分析师需要了解A公司电商业务中厨具类目的成交金额。当获知这个需求后，需要分析：根据什么（维度）汇总、汇总什么（度量）以及汇总的范围多大（粒度）。例如，类目是维度，金额是度量，范围是全表。此外，还需要思考明细数据和汇总数据应该如何设计、是否有公共层的报表及数据是否需要沉淀到汇总表中等因素。

需求调研的分析产出通常是记录原子与派生指标的文档。

4.3 分析业务过程

业务过程可以概括为一个个不可拆分的行为事件。用户的业务系统中，通过埋点或日常积累，通过已经获取了足够的业务数据。为理清数据之间的逻辑关系和流向，首先需要理解用户的业务过程，了解过程中涉及到的数据系统。

可以采用过程分析法，将整个业务过程涉及的每个环节一一列清楚，包括技术、数据、系统环境等。在分析企业的工作职责范围（部门）后，您也可以借助工具通过你想工程抽取业务系统的真实模型。可以参考业务规划设计文档以及业务运行（开发、设计、变更等）相关文档，全面分析数据仓库涉及的源系统及业务管理系统：

每个业务会生成哪些数据，存在于什么数据库中
对业务过程进行分解，了解过程中的每一个环节会产生哪些数据，数据的内容是什么
数据在什么情况下会更新，更新的逻辑是什么

业务过程可以是单个的业务事件，例如交易的支付、退款等；也可以是某个事件的状态，例如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程。具体取决于分析的是某些事件过去发生情况、当前状态还是事件流转效率。

选择粒度：在业务过程事件分析中，需要预判所有分析需要的细分的程度和范围，从而决定选择的粒度。识别维表、选择好粒度之后，需要基于此粒度设计维表，包括维度属性等，用于分析时进行分组和筛选。最后，需要确定衡量的指标。

本教程中，经过业务过程调研，了解到用户电商营销业务的交易订单模块的业务流程如下：

这是一个非常典型的电商交易业务流程图。在该业务流程中，有创建订单、买家付款、卖家发货、确认收货四个核心业务步骤。由于确认收货代表交易成功，我们重点分析确认收货（交易成功）步骤即可。

在明确用户的业务过程之后，可以他根据需要对进行分析决策的业务划分数据域。

4.4 划分数据域

数据域是面向主题（数据综合、归类并进行分析利用）的应用。数据仓库模型设计除了横向的分层外，通常也需要根据业务情况纵向划分数据域。数据域是联系较为紧密的数据主题的集合，是业务对象高度概括的概念，目的是便于管理和应用数据。

通常，需要阅读各源系统的设计文档、数据字段和数据模型，研究你想导出的物理数据模型。进而，可以进行跨源的主题域合并，跨源梳理出整个企业的数据域。

数据域是指面向业务分析，将业务过程或者维度进行首相的集合。为了保障整个体系的生命力，数据域需要抽象提炼，并长期维护更新。在划分数据域时，既能涵盖当前所有的业务需求，又能让新业务在进入时可以被包含进已有的数据域或者扩展新的数据域。数据域的划分工作可以在业务调研之后进行，需要分析各个业务模块中有哪些业务活动。

数据域可以按照用户企业的部门划分，也可以按照业务过程或者业务板块中的功能模块进行划分。例如A公司的电商营销业务板块可以划分为如下数据域，数据域中的每一个部分都是实际业务过程经过归纳抽象之后得出的。

数据域	业务过程
会员店铺域	注册、登录、装修、开店、关店
商品域	发布、上架、下架、重发
日志域	曝光、浏览、单击
交易域	下单、支付、发货、确认收货
服务域	商品收藏、拜访、培训、优惠券领用
采购域	商品采购、供应链管理

4.5 定义维度与构建总线矩阵

明确每个数据域下有哪些业务过程后，需要开始定义维度，并且基于维度构建总线矩阵。

定义维度

在划分数据域、构建总线矩阵时，需要结合对业务过程的分析定义维度。以A电商公司的营销业务板块为例，在交易数据域中，我们重点考察确认收货（交易成功）的业务过程。

在确认收货的业务过程中，主要有商品和收货地点（假设收货和购买时同一个地点）两个维度所依赖的业务角度。从商品维度我们可以定义出以下维度的属性：

商品ID（主键）
商品名称
商品交易价格
商品新旧程度：1全新 2闲置 3 二手
商品类目ID
商品类目名称
品类ID
品类名称
买家ID
商品状态：0 正常 1 删除 2 下架 3 从未上架
商品所在的城市
商品所在的省份

从地域维度，我们可以定义出以下维度的属性：

城市code
城市名称
省份code
省份名称

作为维度建模的核心，在企业级数据仓库中必须保证维度的一致性和唯一性。以A公司的商品维度为例，有且只允许有一种维度定义。例如，省份code这个维度，对于任何业务过程所传达的信息都是一致的。

构建总线矩阵

明确每个数据域下有哪些业务过程后，即可构建总线矩阵。需要明确业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。如下图所示A公司电商板块交易功能的总线矩阵，我们定义了购买省份、购买城市、类目名称、类目id、品牌名称、品牌id、商品名称、商品ID、成交金额等维度。

数据域/过程		一致性维度
数据域/过程		购买省份	购买城市	类目ID	类目名称	品牌ID	品牌名称	商品ID	商品名称	成交金额
交易	下单	Y	Y	Y	Y	Y	Y	Y	Y	N
	支付	Y	Y	Y	Y	Y	Y	Y	Y	N
	发货	Y	Y	Y	Y	Y	Y	Y	Y	N
	确认收货	Y	Y	Y	Y	Y	Y	Y	Y	Y