一、总述
1.1 对大数据的理解
大、快、多样性只是表象，大数据的真正价值在于生命性和生态性。阿里巴巴称之为“活数据”。活数据是全本记录、实时驱动决策和迭代，其价值是随着使用场景和方式动态变化的。简单的把数据定义为正/负资产都太简单。数据也不是会枯竭的能源。数据可以被重复使用，并在使用中升值；数据与数据链接可能会像核反应一样产生价值的聚变。数据使用和数据聚变又产生新的数据。活数据的基础设施就需要来承载、管理和促进这个生态体的最大价值实现（以及相应的成本最小化）。
1.2 阿里巴巴大数据系统体系架构
数据采集、数据计算、数据服务和数据应用。
数据计算分层：操作数据层、明细数据层、汇总数据层和应用数据层。通过数据仓库不同层次之间的加工过程实现从数据资产向信息资产的转化，并对整个过程进行有效的元数据管理及数据质量处理。
二、日志采集
2.1 页面浏览日志采集
在HTML文档内的适当位置增加一个日子采集节点，但浏览器解析到这个节点时，将自动触发一个特定的HTTP请求到日志采集服务器。
植入采集脚本的动作可以由服务器在相应业务请求时动态执行，也可以在开发页面时由开发人员手动植入。
采集到日志后大多会立刻将日志发送到日志采集服务器，服务器立即返回成功响应，并将日志存储到日志缓存区。
顺序读取日志并处理，转存成标准日志文件，加入到实时消息通道供后端程序读取和进一步处理。
2.2 页面交互日志采集
交互日志因为页面类型的不同，无法规定统一的采集内容。故以技术服务的形式采集交互日志。
由业务方注册要采集好糊日志的业务、业务场景和场景下具体的采集点。由系统自动生成采集日志的代码模板。
2.3 服务器端数据清洗和预处理
识别流量攻击、网络爬虫和虚假流量。
数据缺项补正。
剔除无效数据。
基于数据安全和业务特性的日志隔离分发。
2.4 日志采集挑战
日志分流。
PV日志的请求位置（URL）是随着页面所在业务类型的不同而变化的。不仅考虑日志服务器端的分布计算方案，而且将分类任务前置到客户端。采集与计算一体化。
以URL的正则集来对日志进行分类会随着日志复杂度的增长榨干硬件集群。由用户自己制定需要采集的页面，系统自动对页面采集的来的日志进行计算。
三、 数据同步
- 数据直抽。
- 数据文件同步。
生成本地文件和读取数据库表的性能差异在哪里？ - 数据库日志解析同步
3.1 数据同步策略
批量数据同步
数据类型统一采用字符串类型（中间状态）。
DataX对不同的数据源提供插件，将数据从数据源读出并转换为中间状态存储。
传输过程全内存操作，不读写磁盘，也没有进程间通信。实时数据同步
通过解析MySQL的binlog日志来实时获得增量的数据更新，并通过消息订阅模式来实现数据的实时同步。
日志数据——》日志交换中心——》订阅了该数据的数据仓库
针对订阅功能，可以支持主动、被动订阅，订阅端自动负载均衡。数据消费者自己把握消费策略。可以订阅历史数据，随意设置订阅位置。并具有属性过滤功能。
3.2 数据同步问题
分库分表处理
建立了一个中间层的逻辑表来整合分库分表。使得外部访问中间层的时候，与访问单库单表一样简洁。中间层介于应用持久层和JDBC驱动之间。高效同步和批量同步
统一管理不同源数据库的元数据信息，强化版的元数据管理平台，要求数据同步配置透明化。通过库名和表名即可通过元数据管理平台唯一定位，再由自动化的数据同步平台完成建表、配置任务、发布、测试的一键化处理。增量与全量同步的合并
全外连接与insert overwrite代替merge与update。
采用分区，每天保持一个最新的全量版本，每个版本仅保留较短的时间周期如3天至一周。
方式为当天的增量数据与前一天的全量数据合并，生成当天的全量数据。数据同步性能
数据漂移
常见于0点时分左右，数据按照日期划分跨天的问题。冗余获取0点左右的数据，根据多种时间字段来排序去重，重新划分和补录数据。
四、离线数据开发
4.1 统一计算平台
- 承担数据导入、存储、各式计算。
- 从上至下分为客户端、接入层、逻辑层、计算层。
4.2 统一开发平台
- 包括开发调试与发布平台、代码质量控制平台、数据质量监控平台、测试平台。
4.3 任务调度系统
- 调度系统分为调度引擎和执行引擎。
- 状态机分为工作流状态机与任务状态机，工作流包含待提交、已创建、正在执行、成功、失败等各个工作节点；而任务状态则是在工作流之下的一系列状态，例如执行中的等待状态。
- 通过事件驱动，生成调度实例，在两种状态机之间切换执行调度，根据状态的不同也在调度引擎和执行引擎之间切换。
4.4 特点
- 依赖管理。自动识别SQL的输入输出表，自动关联依赖的任务。
- 周期调度。会根据资源和上游依赖的情况，自动调整具体执行时间。
- 手动运行。基于自动发布，可以在开发平台中开发脚本，发布到生产后手工调度。（如何处理数据错误或重复的问题呢？）
五、 实时技术
5.1 流式技术架构
架构分为数据采集、数据处理、数据存储、数据服务四部分。
数据采集
从数据源采集数据均已文件的形式保存，通过监控文件内容的变化，使用数据大小的限制和间隔时间阈值的限制来共同决定采集的频率。
将数据落到数据中间件之后，可由流计算平台来订阅数据。数据处理
SQL语义的流式数据分析能力。
流式处理的原理：多个数据入口、多个处理逻辑，处理逻辑可分为多个层级逐层执行。
数据倾斜：数据量非常大时，分桶执行。
去重处理：精确去重使用数据倾斜的方式，模糊去重使用哈希来减少内存占用。
事物处理：超时补发、每批数据自带ID、将内存数据备份到外部存储。数据存储
实时系统要求数据存储满足多线程多并发以及毫秒级的低延时。
表名设计和rowkey设计遵循数据均衡分布、同一主维度的数据在同一张物理表。
5.2 流式数据模型
数据分层
ODS：直接从业务采集来的原始数据，包含所有业务的变更过程。存储于数据中间件。
DWD：根据业务过程建模出来的事实明细。存储于数据中间件。
DWS：各个维度的汇总指标，该维度是各个垂直业务线通用的。落地到存储系统。
AWS：各个维度的汇总指标，适用于某个业务条线独有的维度。落地到存储系统。
DIM：实时维表层，由离线的维表导入。离线处理。多流关联
多个流关联时，只有能匹配上的数据会被输出到下游，否则存储到外部存储系统中。当有更新进来的时候，从外部存储系统中重新读取数据到内存，从已执行完成的部分继续执行。
多链路冗余、链路开关切换
六、 数据服务
6.1 平台发展
DWSOA
SOA服务
一个需求对应一到多个接口
复用性差、细微改动也要走全套上线流程OpenAPI
为了减少接口数量，将相同维度的数据聚合成一张逻辑宽表，使用相同的接口。
维度不可控，随着维度数量的增长，关系映射的维护变得困难。SmartDQ
为了减少维度，使用ORM框架封装了逻辑表，业务方使用SQL来查询数据，只需要关注逻辑表结构，对真实数据源和数据表不关心。
接口易上难下，即使一个接口也会绑定一批人。所以对外提供的数据服务接口一定要尽可能抽象，接口的数量要尽可能收敛，最后再保障服务质量的情况下，尽可能减少维护工作量。
- OneService
但SQL只能满足简单的查询需求，不能解决复杂的业务逻辑。面对不同的场景，创建了多种服务类型。既有支持简单SQL查询的入口，又有面向负责业务逻辑的定制化插件入口。
6.2 性能优化
1. 资源分配
剥离复杂的计算逻辑，将其交由数据共同层处理。
将Get类型与List类型的查询分为不同的线程池。
执行计划优化。比如拆分逻辑表的查询到不同的物理表去执行、将List类型的查询改变为Get类型的查询等。
2. 缓存优化
元数据缓存、逻辑表查询到物理表查询的映射缓存、查询结果缓存。
3. 查询能力
合并离线数据查询与实时数据查询，在离线数据无法查到结果的时候即时切换到实时查询。
对于需要轮询的数据，采用推送代替轮询。当监听到数据有更新时，推送更新的数据。
七、 大数据建模方法论
7.1 ER模型
传统关系型数据库的ER模型是基于具体业务实体的，而大数据领域的ER模型是建立于业务主题之上的。更着重描述业务主题之间的关系，将具体业务实体整合到了业务主题之下。
业务主题理论上满足3NF的范式要求。描述业务主题之间关系为高层模型，其下的中层模型细化了主题的数据项，中层模型下的物理模型考虑物理存储（分区、合并等）。
7.2 维度模型
维度模型从业务需求出发，考虑业务事件（比如交易、还款等不可拆分的行为），再将事件细分为多个粒度，基于粒度再设计多种维度，最后选择需要衡量的事实指标。
维度模型重点关注需求分析，典型代表是星型模型和雪花模型。
八、 整合及管理体系
分为业务板块、规范定义与模型设计三部分。业务板块即为业务场景，各场景之间的数据基本不重叠。在此之下的规范定义与模型设计基于相同的规则。
8.1 规范定义
- 业务板块下包含多个业务事件，业务事件可分为业务行为与维度。
- 维度包含多个维度属性。属性一般是固有的不变的数据。
- 业务行为可分为原子指标（比如金额、笔数等）与修饰词。修饰词是对业务行为的进一步区分，使用多个修饰词可以唯一确定某个业务细分行为。
- 结合基础指标、修饰词与事件周期，可以派生出多种统计指标。
- 派生指标包括事务型指标、存量型指标、复合型指标3类。
- 派生指标只包含一个原子指标，继承原子指标的数据域，但可以包含多个修饰词。
- 当需要有两个行为派生一个指标时，选择时间靠后的行为作为原子指标，时间靠前的行为作为修饰词。
8.2 模型设计
-
Kimball模型
- 高层模型
- 详细模型
- 模型审查、再设计和验证。是螺旋迭代的过程。
- 提交ETL设计和开发
Inmon模型
-
具体实施
- 数据调研。业务调研、需求调研。
- 架构设计。
根据业务过程归纳、抽象出数据域，每个数据域包含多个不可拆分的业务行为。要求数据域能够涵盖当前所有的业务需求，又能够在有新的业务需求进入时，能无影响的加入到现有数据域中。
搭建总线矩阵。明确数据域下有哪些业务行为，以及业务行为与哪些维度相关。 - 指标体系。
- 模型设计。维表、事实表的模型设计。
- 总结、审查与迭代。
九、 维度设计
将度量称为事实，将环境描述为维度。维度的作用一般是条件约束、分类查询与排序。
9.1 维度的基本设计原则
- 从主维表与相关维表中提取维度属性或者生成新的维度属性，属性越丰富越好。
- 属性是编码类型的，要有文字描述。
- 将需要复杂逻辑计算的属性提前整理并保存下来。
- 维表以空间换取简明性和查询性能。
- 维度一致性。保证能够交叉查询。
- 不同数据域共享维表。
- 一致性上卷。某个维度的维度属性是另一个维度的子集。
- 交叉属性。两个维度有部分属性相同。
9.2 维度的整合与拆分
依据高内聚低耦合的原则，保证扩展性、易用性和高效性。
水平拆分与整合
一般根据维度属性类型和维度之间的关联性来进行整合与拆分。要么提取出公共维度属性，分别保存个性化维度属性；要么整合到相同的维表中。
若类型只有较少的重叠，则采取提取公用维度的做法，否则整合到一张维表中，即使类型重叠较多。但维度属于两个关联性较小的业务条线，也要分开在不同的集市。垂直拆分与整合
由于维度产出的时间，使用的热度，变化的频率不尽相同，需要使用主从维表来解决。主维表存放稳定、产出时间早、热度高的属性，从表存放变化较快、产出时间晚、热度低的属性。
9.3 历史数据归档
有3种归档策略：
- 数据仓库与前台数据库保持相同的归档算法。但在前台归档算法复杂或者算法经常变化的情况下不适用。
- 解析前台数据库的日志并归档。当解析到增量日志中的删除标志时归档，但要求前台应用在数仓归档之后才真正删除数据，之前仅做逻辑删除，避免前后台数据状态不一致的情况。（推荐使用）
- 数据仓库自定义归档策略。但要求比前台应用晚归档、少归档，避免出现前台应用更新已归档数据的情况。
维度的变化大多要慢于数据的变化，但根据业务情况不同，有时需要使用某个历史时刻的维度。维度的历史归档策略：
- 仅保留维度最新的值。无法满足需要使用历史维度的情况。
- 将新维度作为新的一行数据存储，同时记录维度的生效时间和失效时间。关联查询时要带上时间条件。
- 将新维度作为新的一列存储，相当于旧值与新值的概念。但变化频繁时不适用。
- 保存维表快照。根据数仓的数据更新周期，每个周期保存一份快照。根据时间和业务主键进行关联。此方法简单有效，但极浪费存储。
- 极限存储。使用拉链表的方式存储变化的数据，查询时根据维度的生效时间和结束时间来关联，但与2不同的是做了封装将普通的查询语句转换为带有时间条件的查询语句。而且使用生效时间按月做分区。（推荐）
使用极限存储，仅限于维度变化即不快又不慢的情况，太快会导致维度数据太过庞大，太慢不需要极限存储。而且保存维度历史一般要求维度是枚举值类型，如果类似积分这样的连续值，则可能不适用。
9.4 特殊维度
递归层次维度
若维度存在层级关系，通过扁平化存储，将上下层关系以不同的列的方式存储在同一张维表中。
若层级关系是非均衡的，即枝干的深度不一致，有两种处理方式：
- 回填。将维度向下虚拟，使其与起他枝干的深度一致。
- 层次桥接表。使用父层级、子层级、父子层级间隔来描述。
行为维度
行为维度是通过对客户行为的计算得到的维度，是否与主维表放在一起取决于维度变化的频率，以及计算逻辑的复杂程度。
多值维度
即事实表的记录与维表记录是1对多的关系。比如申请书与卡片的关系。
- 降低事实表的粒度。比如申请书降低到以卡片为单位。但经常事实不允许。
- 保留预留字段。比如申请书中预留多个卡片栏位。
- 使用关联表。但复杂度高不易维护。
十、事实表设计
- 事实表
事实表要尽可能多的包含与业务过程相关的度量。
事实表包含的业务流程可以是一个也可以是多个，多个业务流程需要在更高层面的流程上有关联，并且维度存在一定的相似性。 - 事实表的粒度。
可以根据维度组合的细节程度，业务含义两方面来表述。
同一个事实表中的不同事实的粒度须一致。 - 度量。
一般为整数或浮点数。尽可能是可加的，避免类似百分比这种经过计算度量。
多事实的事实表的度量是冗余的，当某种事实只使用到部分度量时，将其他度量设置为0。也可以使用同一个度量，但需要额外添加一个类型维度。 - 退化维度。
保存在事实表中的维度属性。 - 事物表的类型。
事物事实表，周期快照事实表，累计快照事实表。累计快照事物表更适合处理起止时间明确的短生命周期实体，否则应该使用周期快照事实表。 - 聚集
聚集中的维度和度量和原事实表中的维度和度量保持一致。比如原事实表包含了买家与卖家，那么聚集中可以同时包含买家与卖家相关的聚集维度。
聚集的维度的粒度保持一致，不能出现按日汇总又出现按月汇总的数据，可以按照不同的列来保存；聚集的粒度可以和原事实的粒度不同，按照实际的需求来确定聚集的粒度。
十一、元数据
描述数据的数据
11.1 元数据架构
元仓数据，基础的元数据仓库，保存尽可能详尽的表与表字段的元数据。
元数据中间层，与数仓的整合层相呼应，保存了元数据的大宽表，以及数据链路上的各种平台相关的元数据。为上层应用提供服务。
11.2 data profile
描绘元数据血缘关系，为元数据画像（打标签）
基础标签：存储情况、访问情况、安全等级
数仓标签：更新方式，是否可再生，生命周期
业务标签：主题域，产品线，业务类型
潜在标签：应用场景
