长文解析:带你解读阿里的大数据建设方法论

0 评论 5770 浏览 31 收藏 27 分钟

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

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

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

一、数据技术篇

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协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!