写在前面：我是「云祁」，一枚热爱技术、会写诗的大数据开发猿。昵称来源于王安石诗中一句 [ 云之祁祁，或雨于渊 ] ，甚是喜欢。


写博客一方面是对自己学习的一点点总结及记录，另一方面则是希望能够帮助更多对大数据感兴趣的朋友。如果你也对 数据中台、数据建模、数据分析以及Flink/Spark/Hadoop/数仓开发 感兴趣，可以关注我的动态 https://blog.csdn.net/BeiisBei ，让我们一起挖掘数据的价值~


每天都要进步一点点，生命不是要超越别人，而是要超越自己！ (ง •_•)ง

一、前言

最近一直在看《大数据之路：阿里巴巴大数据实践》一书，读完之后感觉受益良多。第一，对于整个大数据的体系有了更多且清晰的认知；第二，对于不同系统的逻辑处理方式给予了引导；第三，毕竟是阿里多年技术的累计产出，而且都是阿里技术大牛写的，干货相当多；最后，如果对于大数据方向想有更深入的了解，推荐大家阅读！

一直以来，我都对大数据真正的价值有思考。后来才发现，大、快、多样性只是表象，大数据的真正价值在于生命性和生态性。

阿里将这类数据称之为“活数据”：活数据是全本记录、实时驱动决策和迭代，它的价值是随着使用场景和方式动态变化的，不可估量。

二、阿里巴巴大数据系统体系架构

首先是一张镇楼图，阿里巴巴的大数据系统的体系架构图，划分为数据采集、数据计算、数据服务及数据应用四层，后面的内容就是围绕这张图展开的，技术含量有多高，大家都懂的，如果读到后面迷失了，可以重新回过头来理解这张图。

数据计算分层：操作数据层、明细数据层、汇总数据层和应用数据层。通过数据仓库不同层次之间的加工过程实现从数据资产向信息资产的转化，并对整个过程进行有效的元数据管理及数据质量处理。

三、数据采集

阿里巴巴的日志采集体系方案包括两大体系：Aplus.JS是Web端日志采集技术方案 ；UserTrack是APP端的日志采集方案。 大多传统公司由于长期经营线下，对于Web，APP等的主动采集能力是偏弱的，一般数据管理部门对于Web或APP端的采集基本是源端推送过来的文件，对于采集没有实际主导权，内容丰富程度大打折扣，同时无论是Web的JS脚本还是APP的SDK,实际上都是有一定的技术门槛，企业APP源端由于受限于合作伙伴的能力，往往采集能力不够，数据质量参差不齐。

互联网源端的日志留存，到底哪些是源端本身的要求，哪些是大数据管理的要求，需要想清楚，大数据管理部门如果想获得更好的数据，是否考虑要往前走一步，毕竟OLAP和OLTP对待数据的角度不一样，人家没必要为你留你所需要的数据。

企业的大数据能否适应互联网的新的形式，打破条线分割，在常规的数据库、文本、消息等采集基础上，新增线上的主动采集工具，是巨大的挑战。当前一些企业提供的企业级大数据采集工具，是缺了这条腿的，以后企业往线上走，这个PaaS能力的确是要具备的。

在采集技术的基础上，阿里巴巴用面向各个场景的埋点规范，来满足通用浏览、点击、特殊交互、APP事件、H5及APP里的H5和Native日志数据打通等多种业务场景。

3.1 浏览器的页面日志采集

3.1.1 页面浏览日志采集

1. 在HTML文档内的适当位置增加一个日子采集节点，但浏览器解析到这个节点时，将自动触发一个特定的HTTP请求到日志采集服务器。
2. 植入采集脚本的动作可以由服务器在相应业务请求时动态执行，也可以在开发页面时由开发人员手动植入。
3. 采集到日志后大多会立刻将日志发送到日志采集服务器，服务器立即返回成功响应，并将日志存储到日志缓存区。
4. 顺序读取日志并处理，转存成标准日志文件，加入到实时消息通道供后端程序读取和进一步处理。

3.1.2 页面交互日志采集

交互日志因为页面类型的不同，无法规定统一的采集内容，故以技术服务的形式采集交互日志。

由业务方注册要采集好交互日志的业务、业务场景和场景下具体的采集点，由系统自动生成采集日志的代码模板。

3.1.3 服务器端数据清洗和预处理

• 识别流量攻击、网络爬虫和虚假流量
• 数据缺项补正
• 剔除无效数据
• 基于数据安全和业务特性的日志隔离分发

3.2 无线客户端的日志采集

无线客户端的日志采集采用采集 SOK 来完成，在阿里巴巴内部，多使用名为 UserTrac 来进行无线客户端的日志采集。

“事件”为无线客户端日志行为的最小单位。基于常规的分析， UserTrack (UT ）把事件分成了几类，常用的包括页面事件（同前述的页面浏览）和控件点击事件（同前述的页面交互）等。

3.3 日志采集的挑战

3.3.1 日志分流与定制处理

PV日志的请求位置（URL）是随着页面所在业务类型的不同而变化的。不仅考虑日志服务器端的分布计算方案，而且将分类任务前置到客户端。

3.3.2 采集与计算一体化

以URL的正则集来对日志进行分类会随着日志复杂度的增长榨干硬件集群。由用户自己制定需要采集的页面，系统自动对页面采集的来的日志进行计算。

3.3.3 大促保障

日志数据在阿里系乃至整个电商系应该都是体量最大的一类数据，在“双 11”期间，日志必然会暴涨，近万亿的数据量对日志全链路说，无疑是不小的挑战。

从端上埋点采集，到日志服务器收集，经过数据传输，再到日志时解析、实时分析，任何一个环节出现问题，全链路保障就是失败的。考虑到服务器的收集能力（如峰值QPS等）、数据传输能力（ TT 的搬运速度）、实时解析的吞吐量、实时业务分析的处理能力，阿里在各环节都做了不少的工作。

四、数据同步

对于大数据系统来说，包含数据从业务系统同步进入数据仓库和数据从数据仓库同步进入数据服务或数据应用两个方面。

源业务系统的数据类型多种多样，有来源于关系型数据库的结构化数据，如 MySQL Orac le DB2, SQL Server ：也有来源于非关系型数据库的非结构化数据，如 Ocean Base HBase Mongo DB 等，这类数据通常存储在数据库表中：还有来源于文件系统的结构化或非结构化据，如阿里云对象存储 oss 、文件存储 NAS 等，这类数据通常以文件形式进行存储。

数据同步需要针对不同的数据类型及业务场景选择不同的同步方式。总的来说，同步方式可以分为三种：

• 直连同步 数据直抽
• 数据文件同步
• 数据库日志解析同步

4.1 阿里数据仓库的同步方式

• 批量数据同步
  数据类型统一采用字符串类型（中间状态），
  DataX对不同的数据源提供插件，将数据从数据源读出并转换为中间状态存储，
  传输过程全内存操作，不读写磁盘，也没有进程间通信。

• 实时数据同步
  通过解析MySQL的binlog日志来实时获得增量的数据更新，并通过消息订阅模式来实现数据的实时同步，
  日志数据 ——> 日志交换中心 ——> 订阅了该数据的数据仓库，
  针对订阅功能，可以支持主动、被动订阅、订阅端自动负载均衡，数据消费者自己把握消费策略。可以订阅历史数据，随意设置订阅位置，并具有属性过滤功能。

4.2 数据同步问题

• 分库分表处理
  建立了一个中间层的逻辑表来整合分库分表，使得外部访问中间层的时候，与访问单库单表一样简洁。
  阿里巴巴的 TDDL ( Taobao Distributed Data ayer ）就是这样一个分布式数据库的访问引擎，通过建立中间状态的逻辑表来整合统一分库分表的访问，TDDL 是在持久层框架之下、 JDBC 驱动之上的中间件。

• 高效同步和批量同步
  统一管理不同源数据库的元数据信息，强化版的元数据管理平台，要求数据同步配置透明化。通过库名和表名即可通过元数据管理平台唯一定位，再由自动化的数据同步平台完成建表、配置任务、发布、测试的一键化处理。

• 增量与全量同步的合并
  全外连接与insert overwrite代替merge与update；
  采用分区，每天保持一个最新的全量版本，每个版本仅保留较短的时间周期如3天至一周；
  方式为当天的增量数据与前一天的全量数据合并，生成当天的全量数据。

• 数据同步性能
  阿里实践出一套实践出一套基于负载均衡思想的新型数据同步方案，通过目标数据库的元数据估算同步任务的总线程数，以及通过系统预先定义的期望同步速度估算首轮同步的线程数，同时通过数据同步任务的业务优先级决定同步线程的优先级，最终提升同步任务的执行效率和稳定性。

• 数据漂移
  常见于0点时分左右，数据按照日期划分跨天的问题。冗余获取0点左右的数据，根据多种时间字段来排序去重，重新划分和补录数据。

五、离线数据开发

5.1 MaxCompute离线计算引擎

阿里的MaxCompute离线计算引擎弥补了hadoop的很多缺陷，它提供了一个集成管理方案，包括统一的授权，资源管理，数据控制和权限分配等，并提供一个易用的客户端，支撑Web、SDK、CLT、IDE等4种访问模式，集群数量可以到几万台，安全控制能力加强，这些都是当前很多商用hadoop版本难以做到的。

接人层提供 HTTP 服务、 Cache 、负载均衡，实现用户认证和服务层面的访问控制。

逻辑层又称作控制层，是 MaxCompute 的核心部分，实现用户空间和对象的管理、命令的解析与执行逻辑、数据对象的访问控制与授权等功能。

其计算核心就是网传的飞天内核，包括Pangu(盘古分布式文件系统)、Fuxi（伏羲资源调度系统）、Nuwa/ZK (Namespace服务）、Shennong（神农监控模块）等。

5.2 统一开发平台

阿里数据开发平台集成了 个子系统来解决实际生产中的各种痛点。围 Max Comp te 计算平台，从任务开发、调试、测试、发布、监控、 到运维管理，形成了整套工具和产品，既提高了开发效率，又保证了数据质量，并且在确保数据产出时效的同时，能对数据进行有效管理。

5.2.1 在云端（D2）

D2是集成任务开发、调试及发布，生产任务调度及大数据运维数据权限申请及管理等功能的一站式数据开发平台 并能承担数据分析工作台的功能。

5.2.2 SQLSCAN

SQLSCAN将在任务开发中遇到的各类问题，如用户编写的SQL质量差、性能低、不遵守规范等，总结形成规则，并通过系统及研发流程保障，事前解决故障隐患，避免时候故障。

5.2.3 DQC

DQC（数据质量中心）主要关注数据质量，通过配置数据质量校验规则，自动在数据处理任务过程中进行数据质量方面的监控。

其主要有数据监控和数据清洗两大功能，数据监控主要是设置规则并报警，有强规则和弱规则之分，强规则可以阻断任务执行，数据清洗的方式跟我们的大致类似，在引入过程中不进行清洗，入库后，再基于配置的规则进行清洗。

5.2.4 在彼岸

主要将通用的、重复性的操作沉淀在测试平台中，避免人肉，提高测试效率。在彼岸的功能包括数据对比（支持不同集群、异构数据库的表做数据对比，比如数据量、字段统计值SUM、AVG、MAX MIN等）、数据分布、数据脱敏等

从阿里的统一开发平台可以看出来，其不仅提供了从任务开发到运维的整套工具，还特别注重体系的完整性和规则的沉淀，这类平台工具实际很难由第三方公司提供，而传统企业除了自身研发力量不够，往往由于业务需求的压力导致在IT这类基础平台层面的研发投入不足，一味靠资源和人力的投入去解决一些其实无解的问题，同时将报表取数人员和产品开发人员混编在一起，造成疲于应对需求的局面，这是值得深思的。

5.3 任务调度系统

• 调度系统分为调度引擎（ Phoenix Engine ）和执行引擎（Alisa）。
• 状态机分为工作流状态机与任务状态机，工作流包含待提交、已创建、正在执行、成功、失败等各个工作节点；而任务状态则是在工作流之下的一系列状态，例如执行中的等待状态。
• 通过事件驱动，生成调度实例，在两种状态机之间切换执行调度，根据状态的不同也在调度引擎和执行引擎之间切换。

六、实时技术

阿里巴巴基于TimeTunnel来进行实时数据的采集，原理和Kafka等消息中间件类似，采用StreamCompute进行流式处理，跟Storm类似，对于实时统计的问题，它提的些方案值得借鉴。

6.1 流式技术架构

架构分为数据采集、数据处理、数据存储、数据服务四部分。

6.1.1 数据采集

从数据源采集数据均已文件的形式保存，通过监控文件内容的变化，使用数据大小的限制和间隔时间阈值的限制来共同决定采集的频率。
将数据落到数据中间件之后，可由流计算平台来订阅数据。

时效性和吞吐量是数据处理中的两个矛盾体 ，很多时候需要从业务的角度来权衡使用什么样的系统来做数据中转。

6.1.2 数据处理

SQL语义的流式数据分析能力。

• 流式处理的原理：多个数据入口、多个处理逻辑，处理逻辑可分为多个层级逐层执行。
• 数据倾斜：数据量非常大时，分桶执行。
• 去重处理：精确去重使用数据倾斜的方式，模糊去重使用哈希来减少内存占用。
• 事物处理：超时补发、每批数据自带ID、将内存数据备份到外部存储。

在商业智能统计类实时任务中，对于资源消耗有一类是非常高的，那就是去重指标，实时任务为了追求性能，计算逻辑一般在内存完成，在计算去重时，势必要把去重的明细数据保留下来，当去重的明细数据达到上亿时，内存中放不小，怎么办？

精确去重可以通过数据倾斜来进行处理，把一个节点的内存压力分到多个节点，在模糊去重的前提下，可以采用相关的去重算法，把内存使用量降到千分之一甚至万分之一，布隆过滤器就是一种，其简单来讲就是不保存明细数据，只保留明细数据对应哈希值的标记位，当然会出现哈希值碰撞的情况。

6.1.3 数据存储

• 实时系统要求数据存储满足多线程多并发以及毫秒级的低延时。
• 表名设计和rowkey设计遵循数据均衡分布、同一主维度的数据在同一张物理表。

实时任务在运行中会计算很多维度和指标，这些数据如何存呢？由于实时任务大多是多线程处理的，意味着数据存储必须能够较好的支持多并发读写，并且延时需要在毫秒级才能满足实时的性能要求，一般使用HBase、Tair等列式数据存储系统。

当然诸如HBase等系统缺点也比较明显，必须使用rowkey，而rowkey的规则限制了读写的方式，显然没有关系型数据库那么方便，但对于海量数据的实时计算和读写，一般还是适用的，针对HBase阿里提供了表名和rowkey设计的一些实践经验。

比如rowkey可以采取MD5+主维度+维度标识+字维度+时间维度+子维度2，例如卖家ID的MD5的前四位+卖家ID+app+一级类目+ddd+二级类目ID，以MD5的前四位作为rowkey的第一部分，可以把数据散列，让服务器整体负载均衡，避免热点的问题。

6.2 流式数据模型

数据模型设计是贯通数据处理过程的，流式数据处理也 样，需要对数据流建模分层。实时建模跟离线建模非常类似，数据模型整体上分为五层（ ODS DWD DWS ADS DIM ）。

由于实时计算的局限性，每一层中并没有像离线做得那么宽，维度和指标也没有那么多，特别是涉及回溯状态的指标，在实时数据模型几乎没有。

整体来看，实时数据模型是离线数据模型的 个子集，在实时数据处理过程中，很多模型设计就是参考离线数据模型实现的。

• 数据分层
  ODS：直接从业务采集来的原始数据，包含所有业务的变更过程。存储于数据中间件。
  DWD：根据业务过程建模出来的事实明细。存储于数据中间件。
  DWS：各个维度的汇总指标，该维度是各个垂直业务线通用的。落地到存储系统。
  AWS：各个维度的汇总指标，适用于某个业务条线独有的维度。落地到存储系统。
  DIM：实时维表层，由离线的维表导入。离线处理。

其中， ODS层到 DIM 层的 ETL 处理是在离线系统中进行的，处理完成后会同步到实时计算所使用的存储系统。 DIM 层和 DWD 层会放在数据中间件中，供下游订阅使用。而 DWS 层和 ADS 层会落地到在线存储系统中，下游通过接口调用的形式使用。

在每一层中，按照重要性划分为 P0、 P1、P2、P3 等级， P0 属于最高优先级保障。根据不同的优先级给实时任务分配不同的计算和存储资源，力求重要的任务可以得到最好的保障。

另外，字段命名、表命名、指标命名是按照 OneData 规范来定义的，以便更好地维护和管理。

• 多流关联
  多个流关联时，只有能匹配上的数据会被输出到下游，否则存储到外部存储系统中。当有更新进来的时候，从外部存储系统中重新读取数据到内存，从已执行完成的部分继续执行。

6.3 大促挑战＆保障

大促是电商行业的狂欢节，在这期间，各个业务系统面临的峰值都会达到最高点，每年大促的海量数据处理给实时计算的性能和保障提出了很大的挑战。

6.3.1 大促特征

大促和日常比较，在数据量以及要求上有非常大的区别，日常不怎么关注的点，在大促的时候会被放大，并且 天中的峰值特别明显，数据量是其他时间点的几倍甚至数十倍，这对系统的抗压能力要求非常高，不能因为洪流的到来而把系统压垮。

1. 毫秒级延时
2. 洪峰明显
3. 高保障性

由于关注的人非常 ，只要出现数据延迟或者数据质量的问题，业务方的反弹就比较大，并且会第 时间感知到数据异常。因此，在大促般都要求高保障性， 些特殊的情况甚至需要做到强保障。

对于强保障的数据，需要做多链路冗余（从来集、处理到数据服务个数据链路都需要做物理隔离）（见图 5.7 ）。当任何 条链路出现问时，都能够 键切换到备链路，并且需要对业务方透明，让下游感知到有链路上的切换（由于各个链路计算的速度有 定的差异，会导致数据在切换时出现短时间下跌的情况，使用方需要做指标大小的判断，避免指标下跌对用户造成困扰）。

4. 公关特性
大促期间，数据及时对公众披露是一项重要的工作，这时候要求实时计算的数据质量非常高。这里面涉及主键的过滤、去重的精准和口径的统一等一系列问题，只有把每一个环节都做好才能保障和离线的数据一致。

6.3.2 大促保障

1. 如何进行实时任务优化
   (1）独占资源和共享资源的策略
   (2）合理选择缓存机制，尽量降低读写库次数
   (3）计算单元合并，降低拓扑层级
   (4）内存对象共享，避免字符拷贝
   (5）在高吞吐量和低延时间取平衡

2. 如何进行数据链路保障

实时数据的处理链路非常长（数据同步→数据计算→数据存储→数据服务），每一个环节出现问题，都会导致实时数据停止更新。实时计算属于分布式计算的 种，而单个节点故障是常态的，这种情况在直播大屏中表现特别明显，因为数据不再更新，所有的用户都会发现数据出现了问题。因此，为了保障实时数据的可用性，需要对整条计算链路都进行多链路搭建，做到多机房容灾，甚至异地容灾。

6.3.3 如何进行压测

数据压测主要是蓄洪压测，就是把几个小时甚至几天的数据积累下来，并在某个时刻全部放开，模拟“双 11 ”洪峰流量的情况，这里面的数据是真实的。比如通过把实时作业的订阅数据点位调到几个小时或者几天前，这时候每一批读到的数据都是最多的，对实时计算的压力也最大。

产品压测还细分为产品本身压测和前端页面稳定性测试。

七、数据服务

数据服务平台可以叫数据开放平台，数据部门产出海量数据，如何能方便高效地开放出去，是我们一直要解决的难题，在没有数据服务的年代，数据开放的方式简单、粗暴，一般是直接将数据导出给对方。这种方式不仅低效，还带来了安全隐患等诸多问题。

即使如阿里，在数据开放这个方向上的探索和实践，至今也有10个年头了，任何关于数据开放毕其功于一役的做法都将失败，任何一次数据开放的改进都是伴随着对于业务理解的深入而成长起来的。

7.1 数据服务平台

阿里数据服务架构演进过程如图所示。基于性能、扩展性和稳定性等方面的要求，我们不断升级数据服务的架构，依次经历了内部代号为 DWSOA 、OpenAPI 、SmartDQ 和OneService 的四个阶段。

DWSOA：是数据服务的第一个阶段，也就是将业务方对数据的需求通过SOA服务的方式暴露出去，由需求驱动，一个需求开发一个或者几个接口，编写接口文档，开放给业务方调用。

这种架构简单，但接口粒度很粗，灵活性不高，扩展性差，复用率低，随着业务需求的增加，接口的数量大幅增加，维护成本高企，同时，开发效率不高，一个接口从需求开发到上线，按阿里说法至少1天，其实远远不止，如果要变更1-2个字段，也要走一整套流程，这应是大多数公司的常态。

OpenAPI：DWSOA的明显问题是烟囱式开发，很难沉淀共性数据，OpenAPI将数据按照统计粒度进行聚合，同样维度的数据，形成一张逻辑表，采用同样的接口描述，针对某一类的查询，只需要调用一个接口即成，这种形式可以有效收敛接口，笔者公司对外服务很多也是这种形式，比如通过封装几十个位置服务API，统一对外提供灵活查询能力，但其实复杂逻辑的接口还是需要采用一事一议的方式，即第一种方式。

SmartDQ：数据维度是非可控的，随着数据的深度使用，OpenAPI显然会急剧增加，维护映射的压力会很大，阿里于是再抽象一层，用DSL（Domain Specific Language，领域专用语言）来描述取数需求，支撑标准的SQL。至此，所有的简单查询服务减少到另一个接口，这降低了数据服务的维护成本。

传统的方式查问题需要查源码，确认逻辑，而SmartDQ只需要检查SQL的工作量，并可以开放给业务方通过写SQL的方式对外提供服务，SmartDQ封装了跨域数据源和分布式查询功能，通过逻辑表屏蔽了底层的物理表细节，不管是HBASE还是MySQL，是单表还是分库分表，这极大简化了操作的复杂度。

阿里的思路说不上很超前，但它不仅落地了，而且在不停演进，这也许就是企业自主研发的价值，它的产品始终流着同样的血液。

OneService：SQL显然无法解决复杂的业务逻辑，SmartDQ其实只能满足简单的查询服务需求，正如我们的自助取数也仅能满足50-60%的临时取数一样，企业遇到的场景还有以下几类：个性化的垂直业务场景、实时数据推送服务、定时任务服务，OneService主要是提供多种服务类型来满足客户需求，分别是OneService-SmartDQ、OneService-Lego、OneService-iPush、OneService-uTiming。

Lego被设计成一个面向中度和高度定制化数据查询需求，支持插件机制的服务容器，我理解就是提供定制环境和暴露接口，你要怎么做就怎么做。

iPush主要提供 Web Socket long polling 两种方式，其应用场景主要是商家端实时直播。是一个面向TT、MetaQ等不同消息源，通过定制过滤规则，向Web、无线等终端推送消息的中间件平台。

uTiming是基于在云端的任务调度应用，提供批量数据处理服务，支撑用户识别、用户画像、人群圈选三类服务的离线计算以及服务数据预处理、入库，这个感觉是非常个性化的一个应用。

7.2 性能优化

1. 资源分配
   剥离复杂的计算逻辑，将其交由数据共同层处理；
   将Get类型与List类型的查询分为不同的线程池；
   执行计划优化。比如拆分逻辑表的查询到不同的物理表去执行、将List类型的查询改变为Get类型的查询等。

2. 缓存优化
   元数据缓存、逻辑表查询到物理表查询的映射缓存、查询结果缓存。

3. 查询能力
   合并离线数据查询与实时数据查询，在离线数据无法查到结果的时候即时切换到实时查询；
   对于需要轮询的数据，采用推送代替轮询。当监听到数据有更新时，推送更新的数据。

八、数据挖掘

阿里构建了一套架构于阿里云MaxConpute、GPU等计算集群之上，汇聚了阿里大量优质的分布式算法，包括数据处理、特征工程、机器学习算法、文本算法等，可高效完成海量、亿级维度数据的复杂计算，同时提供一套极易操作的可视化编辑页面，大大降低了数据挖掘的门槛，提高了建模效率。

8.1 数据挖掘

其选择的计算框架是MPI，其核心算法都是基于阿里云的MaxCompute的MPI实现的。

MaxCompute MPI 的处理流程如图所示，与分布式计算系统的原理类似，不再赘述。其中伏羲为阿里云飞天系统的分布式调度系统，女娲为阿里云飞天系统的分布式一致性协同服务系统，盘古为阿里云飞天系统的分布式文件存储系统。

基于 MaxCompute MPI ，目前阿里巴巴的算法平台已经集成了绝大部分业界主流的机器学习算法，从传统的分类、聚类算法，到互联网应用中非常流行的协同过滤、 PageRank 算法，再到当前最火热的深度学习算法，这些算法基本可以满足企业级数据挖掘应用的需要。

8.2 数据挖掘中台体系

早在 2015 年，阿里巴巴集团便提出了中台战略，将一些通用的技术集成起来形成中台技术体系，为各业务部门提供统 、高效的技术服务，避免各业务部门在各自业务发展的过程中进行重复的技术建设造成不必要的资源浪费与时间消耗。对于数据挖掘技术而言，中台发展的思路同样适用，并且从长远来看，构建数据挖掘中台技术体系也是绝对有必要的。

阿里将数据中台分为三层：特征层（FDM）、中间层和应用层（ADM）,其中中间层包括个体中间层（IDM）和关系中间层（RDM），如下图所示：

• FDM 层：用于存储在模型训练前常用的特征指标，并进行统一的清洗和去噪处理，提升机器学习特征工程环节的效率。
• IDM 层 ：个体挖掘指标中间层，面向个体挖掘场景，用于存储通用性强的结果数据，主要包含商品、卖家、买家、行业等维度的个体数据挖掘的相关指标。
• RDM 层：关系挖掘指标中间层，面向关系挖掘场景，用于存储通用性强的结果数据，主要包含商品间的相似关系、竞争关系，店铺间的相似关系、竞争关系等。
• ADM 层：用来沉淀比较个性偏应用的数据挖掘指标，比如用偏好的类目、品牌等，这些数据已经过深度的加工处理，满足某一特点业务或产品的使用。

通过挖掘数据中台的建设，能够大幅度节省数据挖掘特征工程的作时间，而中间层与应用层的分层设计则能更有效地管理通用的挖掘计算结果，大量减少重复的基础数据挖掘工作。

九、数据模型

数据建模在这本书占据了三分之一篇幅，可见其重要性。

9.1 典型的数据仓库建模方法论

9.1.1 ER模型

传统关系型数据库的ER模型是基于具体业务实体的，而大数据领域的ER模型是建立于业务主题之上的。更着重描述业务主题之间的关系，将具体业务实体整合到了业务主题之下。业务主题理论上满足3NF的范式要求。描述业务主题之间关系为高层模型，其下的中层模型细化了主题的数据项，中层模型下的物理模型考虑物理存储（分区、合并等）。

9.1.2 维度模型

度模型从业务需求出发，考虑业务事件（比如交易、还款等不可拆分的行为），再将事件细分为多个粒度，基于粒度再设计多种维度，最后选择需要衡量的事实指标。维度模型重点关注需求分析，典型代表是星型模型和雪花模型。

9.1.3 Data Vault 模型

Data Vault Dan Linstedt 发起创建的一种模型，它是 模型的生，其设计的出发点也是为了实现数据的整合，但不能直接用于数据分析决策。它强调建立一个可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合同时它基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型，以应对游、系统变更的扩展性。

9.1.4 Anchor 模型

Anchor Data Vault 模型做了进一步规范化处理， Lars. Ri:innback 的初衷是设计 个高度可扩展的模型，其核心思想是所有的扩展只是添加而不是修改，因此将模型规范到 6NF ，基本变成了 k-v 结构化模型。

9.2 阿里巴巴数据模型实践

第一阶段：完全应用驱动的时代，数据完全以满足报表需求为目的，将数据以与源结构相同的方式同步到Oracle，数据完全以满足报表需求为目的，将数据以与源结构相同的方式同步到 Oracle （称作 ODS 层），数据工程师基于 ODS数据进行统计，基本没有系统化的模型方法体系，完全基于对 Oracle数据库特性的利用进行数据存储和加工，部分采用 一些维度建模的缓慢变化维方式进行历史数据处理。这时候的数据架构只有两层，即
ODS+DSS。

第二阶段：随着阿里业务的快速发展，数据量飞速增长，性能成为一个较大问题，需要通过一些模型技术改变烟囱式的开发模型，消除数据冗余，提升数据一致性，来自传统行业的数据仓库工程师开始尝试架构工程领域比较流行的ER模型+维度模型方式应用到阿里巴巴集团，构建出一个四层的模型架构，即ODL（数据操作层）+BDL（基础数据层）+IDL（接口数据层）+ADL（应用数据层）。ODL与源系统一致，BDL希望引入ER模型，加强数据的整合，构建一致的基础数据模型，IDL基于维度模型方法构建集市层，ADL完成应用的个性化和基于展现需求的数据组装，这个对应当前的ODS，DWD，DWA/DWI及ST层，但阿里在构建ER时碰到了较大的挑战，主要是业务快速发展，人员快速变化、业务知识功底的不够全面，导致ER模型产出困难。

阿里得出了一个结论：在不太成熟、快速变化的业务层面，构建ER模型的风险很大，不太适合去构建ER模型，说的有点道理，比如运营商业务相对比较稳定，国际上也有一些最佳实践，从概念-领域-逻辑-物理的全局把控上还能应对，但面对变化，的确有其限制。

第三个阶段：阿里业务和数据飞速发展，迎来了hadoop为代表的分部署存储计算的快速发展，同时阿里自主研发的分布式计算平台MaxCompute也在进行，因此开始建设自己的第三代模型架构，其选择了以Kimball的维度建模为核心理念的模型方法论，同时进行了一定的升级和扩展，构建了阿里巴巴集团的公共层模型数据架构体系。

阿里模型分为三层：操作数据层（ODS）、公共维度模型层（CDM）和应用数据层（ADS），模型层包括明细数据层（DWD）和汇总数据层（DWS）。

ODS：把操作系统数据几乎无处理的存放到数据仓库系统中。

CDM：又细分为DWD和DWS，分别是明细数据层和汇总数据层，采用维度模型方法作为理论基础，更多采用一些维度退化方法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性，同时在汇总数据层，加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性。

ADS：存放数据产品个性化的统计指标数据，根据CDM与ODS加工生成。

具体见如下模型架构图：

关于模型的分层每个行业都可以基于自己的实际去划分，没有所谓的最佳实践，比如笔者所在的企业，源端维度一致性非常好，DWD主要做标准化工作，屏蔽ODS变化导致的上层改动，关于维度建模的理念更多体现在DWA/DWI层中。

9.3 模型实施

OneData是阿里的模型设计理论，看完这个过程，基本会搞清楚维度建模的各个步骤，强烈建议结合后面的维度和事实表建模进行精读，主要步骤如下：

数据调研：业务调研需要对业务系统的业务进行了解，需求分析则是收集分析师运营人员对数据或者报表的需求，报表需求实际是最现实的建模需求的基础。

实施工作流图镇楼，大佬说这张图就可以值回书价！ ∠( ᐛ 」∠)＿

架构设计：分为数据域划分和构建总线矩阵。数据域划分是指面向业务分析，将业务过程或者维度进行抽象的集合，业务过程可以概括为一个个不可拆分的行为事件，如下单、支付等。构建总线矩阵需要明确每个数据域下游哪些业务过程，业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。

如表 9.5 所示是根据业务过程进行归纳，抽象出的数据域（部分示例）。

在进行充分的业务调研和需求调研后，就要构建总线矩阵了。需要做两件事情 ：明确每个数据域下有哪些业务过程；业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。

如表 9.6 所示是供应链管理业务过程示例。

规范定义：规范定义主要定义指标体系，包括原子指标、修饰词、时间周期和派生指标，关于指标的规范定义阿里有单独的一节描述，大家可以好好学习一下，很多时候细节决定成败。

模型设计：模型设计主要包括维度及属性的规范定义、维表、明细事实表和汇总事实表的模型设计。

总结：OneData 的实施过程是一个高度迭代和动态的过程， 般采用螺旋式实施方法。在总体架构设计完成之后，开始根据数据域进行迭代式模型设计和评审。在架构设计、规范定义和模型设计等模型实施过程中，都会引人评审机制，以确保模型实施过程的正确性。

9.4 维度设计

将度量称为事实，将环境描述为维度。维度的作用一般是条件约束、分类查询与排序。

9.4.1 维度的基本设计原则

1. 从主维表与相关维表中提取维度属性或者生成新的维度属性，属性越丰富越好。
2. 属性是编码类型的，要有文字描述。
3. 将需要复杂逻辑计算的属性提前整理并保存下来。
4. 维表以空间换取简明性和查询性能。
5. 维度一致性。保证能够交叉查询。

不同数据域共享维表。
一致性上卷。某个维度的维度属性是另一个维度的子集。
交叉属性。两个维度有部分属性相同。

9.4.2 维度的整合与拆分

依据高内聚低耦合的原则，保证扩展性、易用性和高效性。

• 水平拆分与整合
  一般根据维度属性类型和维度之间的关联性来进行整合与拆分。要么提取出公共维度属性，分别保存个性化维度属性；要么整合到相同的维表中。
  若类型只有较少的重叠，则采取提取公用维度的做法，否则整合到一张维表中，即使类型重叠较多。但维度属于两个关联性较小的业务条线，也要分开在不同的集市。

• 垂直拆分与整合
  由于维度产出的时间，使用的热度，变化的频率不尽相同，需要使用主从维表来解决。主维表存放稳定、产出时间早、热度高的属性，从表存放变化较快、产出时间晚、热度低的属性。

9.4.3 历史数据归档

有3种归档策略：

1. 数据仓库与前台数据库保持相同的归档算法。但在前台归档算法复杂或者算法经常变化的情况下不适用。
2. 解析前台数据库的日志并归档。当解析到增量日志中的删除标志时归档，但要求前台应用在数仓归档之后才真正删除数据，之前仅做逻辑删除，避免前后台数据状态不一致的情况。（推荐使用）
3. 数据仓库自定义归档策略。但要求比前台应用晚归档、少归档，避免出现前台应用更新已归档数据的情况。

9.4.4 维度变化

维度的变化大多要慢于数据的变化，但根据业务情况不同，有时需要使用某个历史时刻的维度。维度的历史归档策略：

1. 仅保留维度最新的值。无法满足需要使用历史维度的情况。
2. 将新维度作为新的一行数据存储，同时记录维度的生效时间和失效时间。关联查询时要带上时间条件。
3. 将新维度作为新的一列存储，相当于旧值与新值的概念。但变化频繁时不适用。
4. 保存维表快照。根据数仓的数据更新周期，每个周期保存一份快照。根据时间和业务主键进行关联。此方法简单有效，但极浪费存储。
5. 极限存储。使用拉链表的方式存储变化的数据，查询时根据维度的生效时间和结束时间来关联，但与2不同的是做了封装将普通的查询语句转换为带有时间条件的查询语句。而且使用生效时间按月做分区。（推荐）

使用极限存储，仅限于维度变化即不快又不慢的情况，太快会导致维度数据太过庞大，太慢不需要极限存储。而且保存维度历史一般要求维度是枚举值类型，如果类似积分这样的连续值，则可能不适用。

9.4.5 特殊维度

递归层次维度
若维度存在层级关系，通过扁平化存储，将上下层关系以不同的列的方式存储在同一张维表中。
若层级关系是非均衡的，即枝干的深度不一致，有两种处理方式：

1. 回填：将维度向下虚拟，使其与起他枝干的深度一致。
2. 层次桥接表：使用父层级、子层级、父子层级间隔来描述。

行为维度
行为维度是通过对客户行为的计算得到的维度，是否与主维表放在一起取决于维度变化的频率，以及计算逻辑的复杂程度。

多值维度
即事实表的记录与维表记录是1对多的关系，比如申请书与卡片的关系。

1. 降低事实表的粒度。比如申请书降低到以卡片为单位。但经常事实不允许。
2. 保留预留字段。比如申请书中预留多个卡片栏位。
3. 使用关联表。但复杂度高不易维护。

9.5 事实表设计

1. 事实表
   事实表要尽可能多的包含与业务过程相关的度量。
   事实表包含的业务流程可以是一个也可以是多个，多个业务流程需要在更高层面的流程上有关联，并且维度存在一定的相似性。
2. 事实表的粒度
   可以根据维度组合的细节程度，业务含义两方面来表述。
   同一个事实表中的不同事实的粒度须一致。
3. 度量
   一般为整数或浮点数。尽可能是可加的，避免类似百分比这种经过计算度量。
   多事实的事实表的度量是冗余的，当某种事实只使用到部分度量时，将其他度量设置为0。也可以使用同一个度量，但需要额外添加一个类型维度。
4. 退化维度
   保存在事实表中的维度属性。
5. 事物表的类型
   事物事实表，周期快照事实表，累计快照事实表。累计快照事物表更适合处理起止时间明确的短生命周期实体，否则应该使用周期快照事实表。
6. 聚集
   聚集中的维度和度量和原事实表中的维度和度量保持一致。比如原事实表包含了买家与卖家，那么聚集中可以同时包含买家与卖家相关的聚集维度。聚集的维度的粒度保持一致，不能出现按日汇总又出现按月汇总的数据，可以按照不同的列来保存；聚集的粒度可以和原事实的粒度不同，按照实际的需求来确定聚集的粒度。

十、数据管理

数据管理涉及的东西很多，这本书具体提到了元数据、计算管理、存储和成本管理和数据质量，相对内容比较单薄，我挑两点说一下。

一直听说阿里财大气粗，所有数据都永久保留，其实是谬传，人家也是节约过日子的，看下图你就知道了：

应对层出不穷的数据和应用，数据工程师其实很难确认哪些数据是最重要的，需要优先保障，阿里巴巴提出了数据资产等级的方案，旨在解决消费场景知晓的问题，其将数据划分为五个等级，毁灭性质、全局性质、局部性质、一般性质及未知性质，代号从A1到A5。

那么如何个每份资产打上等级标签呢，就是借助强大的元数据能力，了解哪些表服务于哪些数据产品，基于血缘分析可以讲整个消费链路上打上某一类资产的标签，假如将阿里巴巴生意参谋定位等级A2，则所有相关链路的表的等级都是A2，从而启动对应的保障措施,这个跟笔者企业的大数据保障方法类似，从应用重要程度确定表的保障等级。

十一、数据应用

阿里主要介绍了对外的数据产品平台生意参谋和服务于内部的数据产品平台。

生意参谋本质上就是为自己的渠道提供的增值服务，是很成功的一款决策支持产品，体现了一个产品如何从小做起，逐步长成一个庞然大物的过程：

对内数据产品的演进几乎是每一个公司BI系统的发展翻版，但显然它已经长成大树了。从临时取数阶段，到自动化报表阶段（比如BIEE），再到自主研发BI阶段（第三方满足不了自己了），最后到数据产品平台（更加体系化）。

当前阿里的数据产品平台，包括PC和APP版本，共有四个层次，即数据监控、专题分析、应用分析及数据决策。

到这里，基本就读完了，整本书都是经验之谈，读下来闪光频现，小伙伴们有时间可以多读几遍啦( •̀ ω •́ )✧！