《大数据之路：阿里巴巴大数据实践》：看阿里人从IT时代走向DT时代的经验之谈(1)

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

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。也可以使用同一个度量，但需要额外添加一个类型维度。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

的相似性。
2. 事实表的粒度
可以根据维度组合的细节程度，业务含义两方面来表述。
同一个事实表中的不同事实的粒度须一致。
3. 度量
一般为整数或浮点数。尽可能是可加的，避免类似百分比这种经过计算度量。
多事实的事实表的度量是冗余的，当某种事实只使用到部分度量时，将其他度量设置为0。也可以使用同一个度量，但需要额外添加一个类型维度。

[外链图片转存中…(img-FUxB7ILK-1715693144082)]
[外链图片转存中…(img-oFywhDES-1715693144082)]
[外链图片转存中…(img-3WvdhDWz-1715693144083)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取