阿里强大的大数据建设方法论是怎样的？笔者从数据技术篇、数据模型篇以及数据管理篇三部分展开介绍，这些将让你开阔视野，同时也会带给你启发。

最近拜读了阿里数据技术及产品部的著作《大数据之路》，这本书无论是底层的数据技术沉淀、满足各种数据应用场景的产品形态，还是在实践中提炼出来的数据管理理念，都有助于开拓视野，亦可结合实际作为自身数据建设的参考和借鉴。

接下来从数据技术篇、数据模型篇、数据管理篇三个部分展开介绍。

一、数据技术篇

1.1 日志采集

阿里的日志采集方案包含两大体系：基于Web端的日志采集方案Aplus.JS和基于APP端的日志采集方案UserTrack。

以下是页面浏览日志的采集流程：

1. 浏览器点击链接；
2. 浏览器解析请求，并按照标准协议向服务器发出HTTP请求（标准的HTTP请求包括请求行、请求报头、请求正文。请求行会包含请求方法是get还是post、请求资源的URL如taobao.com、HTTP版本协议号等内容，附加信息如cookie会体现在请求报头）；
3. 服务器接收并解析请求，将处理结果以HTTP响应形式发给浏览器（标准的HTTP响应包括状态行、响应报头、响应正文。状态行是3位数字组成的状态码，以标识服务器的处理结果，如200/404，cookie等附加信息在响应报头。响应正文可选但大部分非空，包含HTML文档、图片、脚本等）；
4. 浏览器接收服务器响应，解析并渲染页面。

这是标准的从请求到最终展示页面的全流程。浏览器解析服务器的响应如下：

1. 当解析HTML文档至某个节点，HTML文档中植入的JavaScript脚本采集当前页面参数、浏览行为的上下文信息、运行环境信息；
2. 采集完成后发送给日志服务器，一般以URL参数形式体现在请求行；
3. 日志服务器接受到日志请求后，立即发送请求成功的响应，并把日志内容写入日志缓冲区；
4. 服务器端日志处理程序读取日志并解析，转存为标准的日志文件，并注入实时消息通道供后续程序消费使用。

除了普通的页面浏览日志采集，还有页面交互日志的采集，如采集页面鼠标的移动变化来做精准的用户行为分析。

流程大致如下：

1. 采集代码植入目标页面，与要监测的交互行为做绑定；
2. 产生指定交互行为时，采集代码和正常的业务互动响应代码一起触发执行；
3. 采集完成后发送给采集服务器。

1.2 数据同步

除了日志采集，数据库同步也是数据接入层的重要组成部分。

数据同步的方式有以下三种：

1. 直连同步：通过ODBC或JDBC的方式，直接采取规范统一的标准接口。优点为配置简单，容易实现。但也有缺点，如会降低目标系统的性能。建议采取主备策略，从备库中抽取数据。
2. 数据文件同步：约定好格式，从源系统生成文本文件，通过FTP服务器，传输给目标系统。非常适用于数据源含多个异构的数据库系统，简单实用，此外日志类数据也通常都是文本文件。但上传、下载过程可能会出现丢包或错误。建议上传时同时加上校验文件，标明数据量及文件大小等校验信息。
3. 数据库日志解析同步：源系统的日志文件，按照顺序通过TCP/IP的三次握手机制，传输给目标系统。目标系统通过数据加载模块完成数据导入。可实时或准时同步数据，延迟低，此外对业务系统影响也较小，适用于业务系统到数据仓库的增量同步。但缺点在于投入较大，需要部署中间系统来抽取数据，此外还有数据漂移和遗漏问题。

阿里的数仓同步方式有以下两种：

• 批量数据同步。DataX是能满足多方向高自由度的异构数据交换服务产品。DataX可通过插件形式支持不同数据源，如MySQL、oracle、HDFS、Hbase等。数据在DataX中以中间状态存在，转换成对应的数据格式后，写入目标系统。
• 实时数据同步。TT（time Tunnel）是基于生产者、消费者、Topic消息标识的消息中间件。TT具有支持主动订阅、被动订阅，读取分离、互不影响，支持订阅历史数据的特性。数据交换中心的专门模块会从每台服务器源源不断地读取日志数据，然后将增量数据不断同步到消息队列中，并通知订阅的数据仓库系统获取。

1.3 离线数据平台

整体架构中，数据计算层包含数据存储计算平台（MaxCompute、Stream Compute）、数据整合及管理体系（OneData）。

MaxCompute包含四个部分：

1. 客户端：Web端，以restful API提供离线数据处理服务；SDK；客户端工具CLT，可以提交命令完成project管理、DDL等操作;IDE，上层可视化ETL及BI工具，可完成数据同步、任务调度及报表生成等操作。
2. 接入层：提供HTTP服务、Cache、负载均衡，实现用户认证和服务层面的访问控制。
3. 逻辑层：又称控制层，是核心部分，实现命令的解析与执行、数据对象的访问控制与授权等功能。其中，Worker处理所有的RESTful请求；Scheduler负责Instance任务的调度和拆解；Excutor负责Instance的执行。
4. 计算层：就是飞天内核Apsara Core，包括分布式文件系统、资源调度系统、监控系统等模块。

围绕Max Compute，阿里内部又基于不同的场景集成了多个子系统，作为统一开发平台：

• 在云端D2，定位一站式数据开发平台，有任务开发、调试、发布、生产任务调度、大数据运维、数据权限管理、数据分析工作台等模块。
• SQLSCAN，代码扫描工具，可通过异常SQL问题沉淀为规则，嵌入到开发流程中，用户提交代码时可触发SQLSCAN检查。校验规则有如下几类：代码规范类校验类，如表命名规范、生命周期设置等；代码质量类校验类，如分母为0提醒、NULL参与计算提醒；代码性能类校验类，如分区裁剪失效、扫描大表提醒、重复计算检测等。
• DQC，数据质量中心。可进行数据监控和数据清洗：监控数据质量问题并报警，如主键监控、表数据量监控、波动监控、非空监控、业务规则监控等；数据同步到ODS层完成后，根据配置的清洗规则对数据进行清洗。
• 在彼岸，自动化测试平台，将通用的、重复性的测试沉淀到测试平台，提高测试效率。支持数据对比、数据分布、数据脱敏等功能。数据对比：支持不同集群、异构数据库的表进行对比，如表级的数据量、字段级的枚举值、空值、去重数、长度值等对比项；数据分布：提取表或字段的特征值，并与预期值进行对比；数据脱敏：将敏感数据模糊化，以便业务联调、数据调研和数据交换。

除了统一开发平台，任务调度系统负责对任务统一调度、管理。它由调度引擎、执行引擎构成。

• 调度引擎：根据任务节点属性及依赖关系进行实例化，生成各类参数的实值，并生成调度树；
• 执行引擎：分配CPU、内存、运行节点等资源，在对应环境中执行节点代码。

任务调度系统具有如下特性：

• 调度配置：输入输出配置与自动识别相结合，提交任务时SQL解析引擎自动识别输入表、输出表，自动关联相关任务，避免配置错误；
• 定时调度/周期调度：定时/周期性地执行任务；
• 补数据任务：进行数据回溯工作；
• 基线管理：按任务1-9制定优先级，分类管理；
• 监控报警：节点出错或超时自动告警，实现日常数据运维自动化。

1.4 数据服务

数据服务架构演进：

• 第一阶段：DWSOA，即一个需求一个接口。实现简单，但扩展性差、复用率低，属于烟囱式开发。
• 第二阶段：OPENAPI，即一类需求一个接口。调研需求，将数据按照既定的统计粒度聚合，可收敛接口数量。
• 第三阶段：SmartDQ，在OPENAPI的基础上继续抽象，用DSL描述取数需求。即封装跨数据源及分布式查询功能，采用标准SQL语法方式，简单查询服务直接开放给业务方。

SmartDQ的元数据模型及处理流程如下：

SmartDQ只是满足了简单查询服务。在Oneservice的统计数据服务层，还有如下三个模块：

• Lego：满足中度、重度的个性化取数业务场景，采取插件方式，并做成微服务docker隔离。
• iPush：实时数据服务。
• uTiming：运行大数据量任务，不直接暴露给用户，而是通过数据超市工具或Lego的个性化取数API来建立任务。

二、数据模型篇

2.1 大数据建模综述

数据模型定义：数据模型就是数据组织或存储的方法，强调从业务、数据存储、数据使用的角度来合理存储数据。

数据模型的意义：

1. 在性能上，提高查询性能，减少IO吞吐；
2. 在成本上，减少冗余，结果复用，降低数据存储和计算成本；效率上，可以提高数据使用效率；
3. 质量上，改善统计口径不一致性。

数据仓库建模方法：

• ER模型。强调数据整合。特点为建模人员要求高，需全面了解业务和数据；实施周期长。如果业务处于不成熟或快速变化阶段，则不适合用ER模型。
• 维度模型。从需求出发，重点关注如何快速响应需求，包括星型模型、雪花模型等。阿里目前在维度模型的基础上进行升级和扩展。
• DataVault模型。ER模型的衍生，强调数据的历史性、可追溯性、原子性，而不进行过度地一致性处理和整合。该模型更易设计和产出（与ER模型相比），ETL加工也可实现配置化。
• Anchor模型。K-V结构化模型，高度可扩展。

2.2 数据整合及管理体系

Onedata是阿里巴巴数据公共层建设的指导方法。它的定位与价值在于：通过数据服务和数据产品，完成数据公共层建设，建立标准化的、共享的数据服务能力，降低数据互通成本，释放数据计算、存储、人力等资源，消除业务与技术之痛。

指标命名规范：

派生指标=时间周期+修饰词+原子指标

如近7天APP新增用户数。

指标种类可划分为：事务型指标（如新增注册会员数）、存量型指标（如商品总数）、复合型指标（如比例、变化量、变化率、排名、均值/分位数等统计）。

2.3 维度设计

度量为“事实”，维度为“环境”。维度用于描述事实发生的多样环境，可以用来约束查询、分类汇总以及排序。

维度通常用主键来标识其唯一性。主键有两种：具有业务含义的自然键以及自增列或全局唯一标识的代理键。

数仓的重要特点是要反映历史变化，所以如何处理维度的变化是维度设计的重点工作。对于缓慢变化维，通常有如下三种处理方法：

• 重写纬度值：始终取最新数据，适用于历史数据毫无保留和分析价值的情况。
• 插入新的维度行：维度值变化前/后的事实，分别与历史/当前的纬度值进行关联。
• 添加维度列：互不影响，而且还便于统一归为历史维度值或当前维度值来统计。

阿里采用快照维表的方式记录维度变化：基于计算周期，每天可保留一份全量快照数据。优点在于简单高效，开发和维护成本低；缺点在于存储成本高。所以阿里提出了极限存储的方法。

极限存储采取历史拉链存储的方式，即新增时间字段（start_dt和end_dt），与全量存储相比，优点在于不变的数据不再重复存储。

但历史拉链存储也有缺点，即下游使用理解成本高；时间分区，还有可能超出数据库的分区限制。

所以可以针对性地做两点优化：

1. 透明化（即上层对用户做视图操作，映射关联，用户不感知极限存储表的存在）；
2. 按月做历史拉链表（与按天相比，可大幅降低分区数量）。

2.4 事实表设计

事实用于度量业务过程。常用的事实有三种类型：

• 可加性事实；
• 半可加性事实（如库存可以按地区加和，但不可按时间加和）；
• 不可加性事实（如比率型事实）。

按照生产方法，事实表可分为如下三种：

• 事务事实表：也叫原子事实表，描述业务过程。
• 周期快照事实表：按照规律性、可预见的时间间隔来记录事实。
• 累积快照事实表：保存历史全量数据，每行代表一个实体的整个生命周期。

事实表的几点设计原则：

• 尽可能包含所有与业务过程相关的事实，只选择与业务过程相关的事实；
• 不可加性事实，拆分为可加的组件（如比率型指标拆分为分子和分母）；
• 选择维度和事实之前，先声明粒度，尽可能到原子粒度，以支持无法预期的差异化需求；
• 使用退化维度，提高事实表的易用性。

事实表的设计方法：选择业务过程→声明粒度→确定维度→确定事实。此方法同样适用于收集数据分析需求。

三、数据管理

3.1 元数据

元数据（Metadata），就是数据的数据，记录数据从产生到消费的全过程：数仓中模型的定义、各层级之间的映射关系、监控数据的数据状态、ETL任务运行状态等。

根据用途，元数据可以细分为技术元数据和业务元数据：

• 技术元数据：用于开发和管理数仓使用的数据。其包括但不限于：存储元数据，如表、列、分区等信息；运行元数据，即所有作业运行信息；数据同步、计算任务、任务调度等信息；数据质量和运维相关元数据，如运行日志、监控告警配置等。
• 业务元数据：从业务角度描述了数仓中的数据，便于让用户了解和使用数据。如指标业务含义、指标计算方法等。

统一元数据体系建设目标：打通数据接入、加工、消费整个链路，提供统一规范的元数据服务出口，保障元数据产出的稳定性和质量。

统一元数据体系建设目标过程：

1. 梳理底层数据，对元数据做分类，减少数据重复建设，丰富表和字段使用说明；
2. 建设中间层，提供计算、存储、质量、安全等治理领域的数据支持；
3. 对外提供统一的元数据服务出口。

元数据应用非常广泛：

• 对于数据使用者，可以快速找到所需数据；
• 对于ETL工程师，可指导其进行模型设计、任务优化、任务下线等；
• 对于运维工程师：集群存储、计算和系统优化等运维操作。

阿里的应用主要是以下几方面：

（1）Data Profile

为数据建立血缘图谱，解决研发初期寻找数据、确认口径算法、数据处理的繁杂困境，节约研发成本，更加高效的理解利用数据，通过标签对数据打标、整理、归档。

数据的标签主要分为四类：

• 基础标签：数据的存储情况、访问情况、安全等级；
• 数仓标签：对数据增量还是存量、是否可再生，数据的全生命周期进行标签化处理；
• 业务标签：数据所属的主题域、产品线、业务类型等；
• 潜在标签：说明潜在应用场景，如广告、金融等。

（2）元数据门户

通过数据地图检索、理解数据，通过数据管理进行计算、存储、安全管理。

（3）血缘关系分析

表级血缘、字段血缘及间接使用的表应用血缘，用于影响分析、重要性分析、下线分析、下线分析、链路分析、故障排查等。

（4）数据建模

可实现经验建模到元数据驱动的升级，提供数据化指导，提高建模效率。使用的元数据有：表的基础元数据，如表的下游情况、查询/关联/聚合次数；表的关联元数据：关联表、关联类型、关联次数、关联字段等；字段的基础元数据，如字段名称、注释、查询/关联/关联/聚合/过滤次数。

（5）驱动ETL开发

可利用OneClick进行日常的数据运维，如任务查询定位、加字段、表删除、表备份、任务下线、任务删除等。如Data Profile判断数据可下线后，OneClick一键点击，触发数据下线的工作流，直接自动删除数据、删除元数据、下线调度任务、下线DQC监控。

3.2 计算管理

计算管理的目的在于降低计算资源消耗，提高任务执行性能，计算优化可分为任务优化和系统优化。

• 系统优化：一般根据数据输入量来进行静态评估。Map任务用于处理输入，任务稳定的情况下，可基于考虑：HBO，基于历史的优化器，根据稳定任务的历史执行，合理分配内存、CPU等资源；CBO，基于代价的优化器，根据收集的统计信息，计算每种执行方式的计算代价，选择最优执行方式。
• 任务优化：以MR/SQL任务为例，可采取map倾斜、reduce倾斜等方式。

3.3 存储和成本管理

从以下几个方面介绍存储优化：

• 数据压缩，可通过数据压缩节省物理空间；
• 数据重分布，避免列热点来节省存储空间，主要通过修改distribute by和sort by字段来进行数据重分布；
• 存储治理项优化：对数据无更新无任务表、无更新有任务表、空表、近2个月无访问表、长周期表等形成治理项；
• 生命周期管理：通过最少的存储成本，使数据价值最大化。制定合理的数据周期性删除策略、永久删除策略、永久保留策略、历史拉链存储策略、冷备策略、增量merge全量策略等。

3.4 数据质量

数据质量是一切分析有效和准备的基础和前提，所以数据质量的保障是数据仓库建设中的重要环节。

数据质量保障原则主要是四个方面：

• 完整性：指数据的记录和信息是否完整，是否有记录的缺失或记录中某些字段的缺失。
• 准确性：数据中记录的信息和数据是否准确，是否有异常或错误的信息。
• 一致性：跨度很大的数仓体系中，多个业务数仓分支中，对于同一份数据，是否保持一致。
• 及时性：保障数据及时产出，才能得以应用，释放数据价值。

阿里的数据质量建设方法包括以下几个方面：

• 消费场景知晓。通过数据资产定级、基于元数据的链路分析，解决消费场景知晓的问题。根据应用影响程度，来确定资产等级，如毁灭性质/全局性质/局部性质/一般性质/未知；根据数据链路血缘，将资产等级上推至数据生产加工的各个环节。
• 数据生产加工各个环节卡点校验。主要针对数据生产加工过程中的卡点监控。在线系统卡点校验，根据资产等级不同，当对应的业务系统变更时，决定是否将变更通知下游；对于高资产等级的业务，当出现新业务数据时，是否纳入统计，需要卡点审批。离线系统卡点校验，代码开发、测试、发布、历史数据或错误数据回溯等环节的卡点校验。
• 风险点监控。主要针对数据运行过程中可能出现的数据质量和时效问题进行监控。对于在线数据，使用实时业务检测平台BCP，针对在线系统日常运行产出的数据进行预置业务规则的校验；对于离线数据，使用DQC进行数据质量监控，使用摩萨德进行时效性监控。

摩萨德可提供强保障监控和自定义告警。强保障监控围绕运维目标即业务监控而设计，业务预警时间收到威胁及报警。如生意参谋的每日离线数据任务，业务产出时间为9点。萨摩德根据当前业务所有任务最近7天的平均运行时长，将预警时间可设置为如果7点数据未产出，可提前发出预警。此外，当任务出错时，可自定义告警配置。

• 质量衡量。事前衡量如DQC覆盖率，事后衡量进行数据事故复盘及数据质量事故报告。离线数据运行通常是在夜里，因此可用“起夜率”来定性衡量。
• 质量配套工具。除了离线数据质量监控系统DQC、实时业务检测平台BCP、时效性监控报警系统萨摩德，还有ETL研发过程中的代码扫描工具SQLSCAN、发布上线过程中的自动化测试系统在彼岸等等，通过这些工具来将制定的数据质量规范落地。

作者：Herman Lee，公众号：产品方法论（ID：HermanLee2018）

本文由 @Herman Lee 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自 Unsplash，基于CC0协议