《大数据之路》书籍阅读笔记
日志采集：
浏览器：
浏览日志：
流程：
客户端日志采集
客户端日志发送
服务器端日志收集
服务器端日志解析存档
采集方式：
1. 业务服务器在响应业务请求时动态在HTML 文档内植入日志采集脚本
2. 在开发页面时由开发人员手动植人。
交互日志：
页面交互，与业务高度自定义。
服务端清洗和预处理：
识别流量攻击、网络爬虫和流量作弊（虚假流量）
依托算法识别非正常的流量并归纳出对应的过滤规则
数据缺项补正
为了便利后续的日志应用和保证基本的数据统计口径一致，在大多数情况下，需要对日志中的一些公用且重要的数据项做取值归一、标准化处理或反向补正。
无效数据剔除
日志隔离分发
基于数据安全或者业务特性的考虑，某些日志在进入公共数据环境之前需要做隔离。
无线客户端：
概述：
通过采集SDK进行采集，区别于JavaScript
可以采集到更多的设备相关的数据。
页面事件：
采集要素：
1.设备及用户的基本信息：
2.被访问页面的信息，这里主要是一些业务参数（如商品详情页的商品ID 、所属的店铺等）;
3.访问基本路径（如页面来源、来源的来源等），用于还原用户完整的访问行为。（注意回退行为，可以利用栈的深度来识别）
4.透传的参数
5.通过页面扩展信息接口获取到的额外信息
采集时机：
页面展现
页面退出
控件点击：
采集参数：
基本的设备信息、用户信息
控件所在页面名称、控件名称、控件的业务参数
其他事件：
应用崩溃
前后台切换
应用退出
特殊的情况：
日志聚合：
每个曝光的元素一般都属于一个页面，利用页面的生命周期来实现适当的聚合及确定发送时机。比如曝光的商品列表，可以聚合为一条
只需计数，不需具体内容的场景。
访问路径存在回退行为：
利用页面的生命周期，识别页面的复用，配合校的深度来识别是否是回退行为。
H5 & Native 日志统一
背景：
app的分类，一种是纯Native APP; －种是既有Native ,又有H5 页面嵌入的APP ，即Hybrid APP 。
Native 页面采用采集SDK 进行日志采集， H5 页面一般采用基于浏览器的页面日志采集方式进行采集。
存在问题：
由于采集方式的不同，采集到的内容及采集服务器均分离开。若需要进行完整的数据分析，就需要将两类日志在数据处理时进行关联，而就算不考虑处理成本，在很多情况下， Native 和H5 互跳，即使关联也无法还原用户路径，数据丢失严重。
解决方法：
1.把Native 日志向HS 日志归。
2.把HS 日志归到Native 日志。
优点：
一是采用来集SDK 可以采集到更多的设备相关数据，这在移动端的数据分析中尤为重要；
二是采集SDK 处理日志，会先在本地缓存，而后借机上传，在网络状况不佳时延迟上报，保证数据不丢失。
流程：
1.H5页面通过植入采集脚本，正常采集日志
2.JavaScript通过WebView框架的JSBridge接口，调用移动客户端对应的接口方法，将埋点数据对象当作参数传人。
3.移动端对传入数据进行处理，然后缓存、上传。
优点：
未来如果要实现新的事件类别，比如自定义事件，就不需要改动Web View 层的接口，只需改动JavaScript的部分内容及移动客户端日志采集SDK 中对应的实现即可。
缺点：
必须要浏览器采集JavaScript 、Web View 、客户端采集SDK 的配合。
设备唯一标识：
苹果UDID 禁用， IDFA 、IMEI 、IMSI 做了权限控制， Android 新系统也对设备信息的获取做了权限控制。
app软件难以获取设备唯一标识。
阿里通过UTDID的方式。
日志传输：
上传：
根据间隔、大小、耗时等决定
服务端存储：
nginx access_log存储，切分维度，分流（不同时期需要不同的日志，用于不同的用途）
收集日志：
阿里的消息队列TimeTunel，类似于kafka
挑战：
日志分流与定制处理：
概述：
日志需要分流，以满足不同业务的需求。
那如何分流？核心思想是尽可能早地进行分流，降低日志处理过程中的分支判断消耗
比如将分类任务前置到客户端
采集与计算一体化设计：
早期实践：
以URL 路径，继而以URL（正则）规则集为依托来进行日志分类的。
在网站规模较小时，这一策略还可以基本顺利地运转下去，但随着网站的大型化和开发人员的增加， URL 规则集的维护和使用成本会很快增长到不现实的程度（维护的规则越来越多），同时失控的大规模正则适配（CPU占用越来越多）甚至会将日志计算硬件集群彻底榨干。
阿里实践：
对应于PV日志的解决方案是目前用户可直观感知的SPM 规范（例如，在页面的URL 内可以看见spm参数，利用这个分流）和SPM元数据中心。
通过SPM的注册和简单部署（仅需要在页面文件内声明一个或多个标签），用户即可将任意的页面流量进行聚类，不需要进行任何多余的配置就可以在相应的内部数据产品内查询聚合统计得到的流量、转化漏斗、引导交易等数据，以及页面各元素点击数据的可视化视图。
对应于自定义日志的解决方案则是黄金令箭(Goldlog) / APP 端的点击或其他日志规范及其配置中心。
通过注册一个与所在页面完全独立的令箭实体／控件实体，用户可以一键获得对应的埋点代码，并自动获得实时统计数据和与之对应的可视化视图。
高峰期挑战：
应对措施：
日志分流
服务器端推送配置到客户端，对非重要日志适当限流，错峰后逐步恢复。
配置范围：不同的场景
具体配置：延迟上报、部分采样
数据同步：
分类：
数据从业务系统同步进入数据仓库
数据从数据仓库同步进入数据服务或数据应用
数据：
关系型数据库的结构化数据mysql、oracle、DB2、sql server等
非关系型数据库的非结构化数据，如OceanBase 、HBase 、Mon go DB 等
文件系统的结构化或非结构化数据，如阿里云对象存储oss 、文件存储NAS 等
同步方式：
直连同步、数据文件同步和数据库日志解析同步。
直连同步：
概述：
JDBC
缺点：
对源系统的性能影响较大，当执行大批量数据同步时会降低甚至拖垮业务系统的性能。
如果业务库采取主备策略，则可以从备库抽取数据，避免对业务系统产生性能影响。
但是当数据量较大时，采取此种抽取方式性能较差，不太适合从业务系统到数据仓库系统的同步。
DATAX：
概述：
DataX 采用Framework+Plugin 的开放式框架实现， Framework 处理缓冲、流程控制、并发、上下文加载等高速数据交换的大部分技术问题，并提供简单的接口与插件接人。
插件仅需实现对数据处理系统的访问，编写方便，开发者可以在极短的时间内开发一个插件以快速支持新的数据库或文件系统。
数据文件同步：
概述：
通过约定好的文件编码、大小、格式等，直接从源系统生成数据的文本文件，由专门的文件服务器，如FTP 服务器传输到目标系统后，加载到目标数据库系统中。
可以使用压缩和加密功能，传输到目标系统以后，再对数据进行解压缩和解密
适合场景：
互联网的日志类数据
数据库日志解析同步：
概述：
读取归档日志文件用以收集变化的数据信息，并判断日志中的变更是否属于被收集对象，将其解析到目标数据文件中。这种读操作是在操作系统层面完成的，不需要通过数据库，因此不会给源系统带来性能影响。
通过网络协议，实现源系统和目标系统之间的数据文件传输。
数据文件被传输到目标系统后，可通过数据加载模块完成数据的导入，从而实现数据从源系统到目标系统的同步
适合场景：
延迟可以控制在毫秒级别，并且对业务系统的性能影响也比较小，目前广泛应用于从业务系统到数据仓库系统的增量数据同步应用之中。
TimeTunnel (TT ）：
概述：
一种基于生产者、消费者和Topic 消息标识的消息中间件，将消息数据持久化到HBase 的高可用、分布式数据交互系统。
挑战：
分库分表的处理：
阿里巴巴的TDDL ( Taobao Distributed Data Layer ）就是这样一个分布式数据库的访问引擎，通过建立中间状态的逻辑表来整合统一分库分表的访问。
TDDL 是在持久层框架之下、JDBC 驱动之上的中间件，它与JDBC规范保持一致，有效解决了分库分表的规则引擎问题，实现了SQL 解析、规则计算、表名替换、选择执行单元并合并结果集的功能，同时解决了数据库表的读写分离、高性能主备切换的问题，实现了数据库配置信息的统一管理。
高效同步和批量同步：
存在问题：
1.大量的表需要同步，相似并且重复的操作会降低开发人员的工作热情。
2.数据仓库的数据源种类特别丰富，遇到不同类型的数据源同步就要求开发人员去了解其特殊配置。
3.部分真正的数据需求方，如Java 开发和业务运营，由于存在相关数据同步的专业技能门槛，往往需要将需求提交给数据开发方来完成，额外增加了沟通和流程成本。
解决：
阿里的oneclick产品。实现了数据的一键化和批量化同步，一键完成DDL 和DML 的生成、数据的冒烟测试以及在生产环境中测试等
优点：
对不同数据源的数据同步配置透明化，可以通过库名和表名唯一定位，通过IDB（元数据接口服务）接口获取元数据信息自动生成配置信息。
简化了数据同步的操作步骤，实现了与数据同步相关的建表、配置任务、发布、测试操作一键化处理，并且封装成Web 接口进一步达到批量化的效果。
降低了数据同步的技能门槛，让数据需求方更加方便地获取和使用数据。
增量与全量同步的合并：
方式一：全外连接（ full outer join) ＋数据全量覆盖重新加载（ insert overwrite ）
方式二：每天一个全量分区，保存当天的版本。
同步性能的处理：
存在问题：
有些数据同步任务的总线程数达不到用户设置的首轮同步的线程数时，如果同步控制器将这些同步线程分发到CPU 比较繁忙的机器上，将导致这些同步任务的平均同步速度非常低，数据同步速度非常慢。
用户不清楚该如何设置首轮同步的线程数，基本都会设置成一个固定的值，导致同步任务因得不到合理的CPU 资源而影响同步效率。
不同的数据同步任务的重要程度是不一样的，但是同步控制器平等对待接收到的同步线程，导致重要的同步线程因得不到CPU资源而无法同步。
解决：
通过目标数据库的元数据估算同步任务的总线程数，以及通过系统预先定义的期望同步速度估算首轮同步的线程数，同时通过数据同步任务的业务优先级决定同步线程的优先级，最终提升同步任务的执行效率和稳定性。
数据漂移的处理：
概述：
ODS表的同一个业务日期数据中包含前一天或后一天凌晨附近的数据或者丢失当天的变更数据。
实际上往往由于时间戳字段的准确性问题导致发生数据漂移。
时间戳分类：
数据库表中用来标识数据记录更新时间的时间戳字段（假设这类字段叫modified_ time ）。
数据库日志中用来标识数据记录更新时间的时间戳字段·（假设这类宇段叫log_time ） 。
数据库表中用来记录具体业务过程发生时间的时间戳字段（假设这类字段叫proc_time ） 。
由于网络或者系统压力问题， log_time或者modified_time 会晚于proc_time 。
标识数据记录被抽取到时间的时间戳字段（假设这类字段叫extract time ）。
由于数据抽取是需要时间的， extract_time往往会晚于前三个时间。
解决：
首先根据log_time分别冗余前一天最后15分钟的数据和后一天凌晨开始15分钟的数据，并用modified time过滤非当天数据，确保数据不会因为系统问题而遗漏。
然后根据log_time获取后一天15分钟的数据；针对此数据，按照主键根据log_time做升序排列去重。因为我们需要获取的是最接近当天记录变化的数据（数据库日志将保留所有变化的数据，但是落地到ODS表的是根据主键去重获取最后状态变化的数据）。
最后将前两步的结果数据做全外连接，通过限制业务时间proc_time来获取我们所需要的数据。
离线计算平台：
数据开发平台：
统一计算平台MaxCompute：
概述：
主要服务于海量数据的存储和计算，提供完善的数据导人方案，以及多种经典的分布式计算模型，提供海量数据仓库的解决方案，能够更快速地解决用户的海量数据计算问题，有效降低企业成本，并保障数据安全。
Max Compute 采用抽象的作业处理框架，将不同场景的各种计算任务统一在同一个平台之上，共享安全、存储、数据管理和资源调度，为来自不同用户需求的各种数据处理任务提供统一的编程接口和界面。
它提供数据上传／下载通道、SQL 、Map Reduce 、机器学习算法、图编程模型和流式计算模型多种计算分析服务，并且提供完善的安全解决方案。
架构：
客户端（ MaxCompute Client ）：
提供web、sdk、CLT（command line tool）、IDE工具
接人层（ Max Compute Front End ）：
提供HTTP 服务、Cache 、负载均衡，实现用户认证和服务层面的访问控制。
逻辑层（ MaxCompt阳Server ）
功能：
用户空间和对象的管理、命令的解析与执行逻辑、数据对象的访问控制与授权等功能。
组成：
1.Worker 处理所有的阻STful 请求，包括用户空间（ Project ）管理操作、资源（ Resource ） 管理操作、作业管理等，对于SQLDML 、MR 等需要启动MapReduce 的作业，会生成MaxCompute Instance（类似于Hive 中的Jo b ） ，提交给S cheduler 进一步处理。
2.Scheduler 负责MaxCompute Instance 的调度和拆解，并向计算层的计算集群询问资源占用情况以进行流控。
3.Executor 负责MaxCompute Instance 的执行，向计算层的计算集群提交真正的计算任务。
存储与计算层（ Apsara Core ）
飞天内核（ Apsara Core ），运行在和控制层相互独立的计算集群上，它包括Pangu （分布式文件系统）、F uxi （资源调度系统） 、Nuwa/ZK U、Jamespace 服务） 、Shennong （监控模块）等。
元数据：
存储在阿里云计算的另一个开放服务OTS (Open Table Service ，开放结构化数据服务） 中，元数据内容主要包括用户空间元数据、Table/Partition Schema 、ACL 、Job 元数据、安全体系等。
统一开发平台：
概述：
围绕Max Comp u te 计算平台，从任务开发、调试、测试、发布、监控、报警到运维管理，形成了整套工具和产品。
开发流程：
任务开发及调试、测试、发布、（任务运维、质量监控、运维监控、数据管理）
阿里实践：
开发平台（在云端D2）-> 测试平台（在彼岸）->通过SQLSCAN规则后发布（D2）-> （调度运维（D2）、DQC质量监控、运维监控（摩萨德）、数据管理）
SQLSCAN：
将在任务开发中遇到的各种问题，如用户编写的S QL质量差、性能低、不遵守规范等，总结后形成规则，并通过系统及研发流程保障，事前解决故障隐患，避免事后处理。
有强规则和弱规则两类。触发强规则后，任务的提交会被阻断，必须修复代码后才能再次提交； 而触发弱规则，则只会显示违反规则的提示，用户可以继续提交任务。
DQC：
主要有数据监控和数据清洗两大功能。
监控：
常见的DQC 监控规则有：主键监控、表数据量及波动监控、重要字段的非空监控、重要枚举宇段的离散值监控、指标值波动监控、业务规则监控等。
清洗：
在数据进入ODS 层之后执行。对于需要清洗的表，首先在DQC 配置清洗规则；对于离线任务，每隔固定的时间间隔，数据人仓之后，启动清洗任务，调用DQC 配置的清洗规则，将符合清洗规则的数据清洗掉，并保存至DIRTY表归档。
如果清洗掉的数据量大于预设的阐值，则阻断任务的执行，否则不会阻断。
在彼岸：
概述：
解决上述测试问题而开发的大数据系统的自动化测试平台，将通用的、重复性的操作沉淀在测试平台中，避免被“人肉”，提高测试效率。
数据对比：
支持不同集群、异构数据库的表做数据对比。表级对比规则主要包括数据量和全文对比；字段级对比规则主要包括字段的统计值（如SUM 、A VG 、MAX 、MIN 等）、枚举值、空值、去重数、长度值等。
数据分布：
提取表和字段的一些特征值，并将这些特征值与预期值进行比对。表级数据特征提取主要包括数据量、主键等；字段级数据特征提取主要包括字段枚举值分布、空值分布、统计值（如SUM 、AVG 、MAX 、MIN等）、去重数、长度值等。
数据脱敏：
将敏感数据模糊化。在数据安全的大前提下，实现线上数据脱敏，在保证数据安全的同时又保持数据形态的分布，以便业务联调、数据调研和数据交换。
任务调度系统：
概述：
用户通过D 2 平台提交、发布的任务节点，需要通过调度系统，按照任务的运行顺序调度运行。
整个调度系统共有两个核心模块：调度引擎（ Phoenix Engine ）和执行引擎（ Alisa ）
如果Alisa 中的任务是一个Max Compute任务，计算实际会被提交到Max Compute 集群中， Alisa 中仅仅运行Max Compute 的Client ；
同样，流计算任务等会被提交到对应的目标系统中运行；而S hell 任务、离线数据同步任务、实时同步任务（ TT ）等将直接运行在A lisa 集群上。
调度配置：
问题：
上游修改，导致下游也需要修改
解决：
SQL 解析引擎自动识别此任务的输入表和输出表，输入表自动关联产出此表的任务
监控报警：
设置电话、短信、邮件等不同的告警方式
实时技术：
架构：
数据采集：
概述：
实时采集
数据分类：
数据库
日志
采集周期：
数据大小
时间阈值
数据处理：
流式计算引擎
数据存储：
增量写
数据服务：
实时查询数据
StreamCompute：
概述：
基于storm
数据去重：
精确去重：
分节点处理
模糊去重：
布隆过滤器
基数估计
数据倾斜：
解决倾斜的问题即可
数据存储：
概述：
中间计算结果、最终结果数据、维表数据需要存储下来
hbase：
表名设计：
设计规则：
汇总层标识＋数据域＋主维度＋时间维度
例如： dws_trd_s lr_dtr ，表示汇总层交易数据，根据卖家（ slr ）主维度 +O 点截至当日（ dtr ） 进行统计汇总。
优点：
所有主维度相同的数据都放在一张物理表中，避免表数量过多，难以维护。另外，可以从表名上直观地看到存储的是什么数据内容，方便排查问题。
rowkey 设计：
设计规则：
MD5 ＋主维度＋维度标识＋子维度1 ＋时间维度＋子维度2
例如：卖家ID 的MD5 前四位＋卖家ID+ app ＋ 一级类目ID+ ddd ＋二级类目ID 。
优点：
以M D5 的前四位作为row key 的第一部分，可以把数据散列，让服务器整体负载是均衡的，避免热点问题。
在上面的例子中，卖家ID 属于主维度，在查数据时是必传的。每个统计维度都会生成一个维度标识，以便在rowkey 上做区分。
数据服务：
概述：
实时数据落地到存储系统中后，使用方就可以通过统一的数据服务获取到实时数据。比如下一章将要讲到的OneService
好处：
不需要直连数据库，数据源等信息在数据服务层维护，这样当存储系统迁移时，对下游是透明的。
调用方只需要使用服务层暴露的接口，不需要关心底层取数逻辑的实现。
屏蔽存储系统间的差异，统一的调用日志输出，便于分析和监控下游使用情况。
数据模型：
概述：
实时数据模型是离线数据模型的一个子集，在实时数据处理过程中，很多模型设计就是参考离线数据模型实现的。
ODS层：
采集的原始数据。
存放在数据中间件中，供下游订阅使用。
DWD层：
实时事实明细层
存放在数据中间件中，供下游订阅使用。
DWS层：
订阅明细层的数据后，会在实时任务中计算各个维度的汇总指标。通用。比如卖家的实时成交金额，实时被刷新。
落盘到存储系统上。
ADS层：
个性化维度汇总层。
落盘到存储系统上。
DIM层：
实时维表层的数据基本上都是从离线维表层导出来的，抽取到在线系统中供实时应用调用。这一层对实时应用来说是静态的，所有的ETL处理工作会在离线系统中完成。
也可以实时写入。
多流关联：
概述：
数据到达的时间是不确定的和无序的。
解决：
A 表的某条数据到达，到B 表的全量数据中（内存，同时备份到状态存储）查找，如果能查找到，说明可以关联上，拼接成一条记录直接输出到下游； 但是如果关联不上，则需要放在内存或外部存储中等待，直到B 表的记录也到达。
多流关联的一个关键点就是需要相互等待，只有双方都到达了，才能关联成功。
其他问题：
数据去重，否则下游会有多条记录。
维表使用：
方式一：
join T-2的离线维表
原因：
数据无法及时准备好：
T- 1 的维表数据一般不能在零点马上准备就绪（因为T-1 的数据需要在T 这一天加工生成），因此去关联巨2 维表，相当于在T-1 的一天时间里加工好T-2 的维表数据。
无法准确获取全量的最新数据：
维表也作为一个实时流输入，这就需要使用多流实时关联来实现。
数据的无序性：
如果维表作为实时流输入的话，获取维表数据将存在困难。比如10:00 点的业务数据成功关联维表，得到了相关的维表字段信息，这个时候是否就已经拿到最新的维表数据了呢？
其实这只代表拿到截至10:00 点的最新状态数据（实时应用永远也不知道什么时候才是最新状态，因为不知道维表后面是否会发生变更）。
缺点：
维表数据不是最新的。
使用方式：
1.全量加载
适合数据比较少
2.增量加载
LRU缓存热点数据 + 外部存储
方式二：
多流关联
高峰期挑战：
概述：
高吞吐量、低延时、高保障性、高准确性
任务优化：
1.独占资源和共享资源的策略
在一台机器中，共享资源池可以被多个实时任务抢占，如果一个任务在运行时8 0 % 以上的时间都需要去抢资源，这时候就需要考虑给它分配更多的独占资源，避免抢不到CPU资源导致吞吐量急剧下降。
2.合理选择缓存机制，尽量降低读写库次数
3.计算单元合并，降低拓扑层级
拓扑结构层级越深， 性能越差，因为数据在每个节点间传输时， 大部分是需要经过序列化和反序列化的，而这个过程非常消耗CPU 和时间。
4.内存对象共享，避免字符拷贝
在海量数据处理中，大部分对象都是以字符串形式存在的，在不同线程间合理共享对象，可以大幅降低字符拷贝带来的性能消耗，不过要注意不合理使用带来的内存溢出问题。
5.在高吞吐量和低延时间取平衡
高吞吐量和低延时这两个特性是一对矛盾体，当把多个读写库操作或者ACK 操作合并成一个时，可以大幅降低因为网络请求带来的消耗，不过也会导致延时高一些，在业务上衡量进行取舍。
链路高可用：
通过工具比对多条链路计算的结果数据，当某条链路出现问题时，它一定会比其他链路计算的值小，并且差异会越来越大。
一键切换到备链路，并且通过推送配置的形式让其秒级生效，所有的接口调用会立刻切换到备链路，对直播大屏完全透明，并且用户也感知不到故障的发生。
压测：
产品本身压测：
收集大屏服务端的所有读操作的URL ，通过压测平台进行压测流量回放，按照QPS: 500 次／秒的目标进行压测
前端页面稳定性测试：
将大屏页面在浏览器中打开，并进行8 ～ 24 小时的前端页面稳定性测试。监控大屏前端JS 对客户端浏览器的内存、CPU 等的消耗，检测出前端JS 内存泄漏等问题并修复，提升前端页面的稳定性。
数据服务：
概述：
提供数据访问接口
发展：
1.烟囱式开发
一个需求一个接口
2.openApi
一类需求一个接口
将数据按照其统计粒度进行聚合，同样维度的数据，形成一张逻辑表，采用同样的接口描述。
以会员维度为例： 把所有以会员为中心的数据做成一张逻辑宽表，只要是查询会员粒度的数据，仅需要调用会员接口即可。
3.smartDQ
用sql查询需要的数据
底层封装了跨异构数据源和分布式查询功能。
架构：
(1）数据源
SmartDQ 支持跨数据源查询，底层支持接人多种数据源，比如MySQL 、HBase 、Open Search 等。
(2）物理表
物理表是具体某个数据源中的一张表。每张物理表都需要指明主键由哪些列组成，主键确定后即可得知该表的统计粒度。
多个物理表的元数据会被收集起来，用于物理表与逻辑表的映射。
(3）逻辑表
逻辑表可以理解为数据库中的视图，是一张虚拟表，也可以看作是由若干主键相同的物理表构成的大宽表。SmartDQ 对用户展现的只是逻辑表，从而屏蔽了底层物理表的存储细节。
通过ORM映射到物理表上。
查询的时候，通过查找元数据模型中的逻辑表与物理表的映射关系，将逻辑Query 转变为物理Query 。
(4）主题
逻辑表一般会挂载在某个主题下，以便进行管理与查找。
思想：
对外提供的数据服务接口一定要尽可能抽象，接口的数量要尽可能收敛，最后在保障服务质量的情况下，尽可能减少维护工作量。
4.OneService
除了简单的查询服务需求。其他场景还有这么几类：个性化的垂直业务场景、实时数据推送服务、定时任务服务。
OneService主要是提供多种服务类型来满足用户需求，分别是OneService-SmartDQ 、OneService-Lego、OneService-iPush 、OneService-uTiming。
OneService-Lego：
概述：
面向中度和高度定制化数据查询需求、支持插件机制的服务容器。它本身只提供日志、服务注册、Diamond 配置监听、鉴权、数据源管理等一系列基础设施，具体的数据服务则由服务插件提供。
采用插件化方式开发服务， 一类需求开发一个插件
架构：
采用轻量级的Node.JS 技术核实现，适合处理高并发、低延迟的IO 密集型场景。
底层根据需求特点分别选用Tair 、HBase 、ADS 存储数据。
OneService-iPush：
主要提供Web Socket 和long polling 两种方式，其应用场景主要是商家端实时直播。
架构：
基于高性能异步事件驱动模型的网络通信框架Netty4实现
结合使用Guava 缓存实现本地注册信息的存储，
Filter 与Server 之间的通信采用Thrift 异步调用高效服务实现，
消息基于Disruptor 高性能的异步处理框架（可以认为是最快的消息框架）的消息队列，
在服务器运行中Zookeeper 实时监控服务器状态，
以及通过Diamond 作为统一的控制触发中心。
OneService-uTiming：
主要提供即时任务和定时任务两种模式，其主要应用场景是满足用户运行大数据量任务的需求。
优化：
资源分配：
1.计算逻辑下沉
2.查询资源分配
比如get、list请求分开单独的线程池
3.执行计划优化
查询sql拆分并发
查询索引下推
缓存优化：
元数据缓存：
元数据在比较多的地方使用
模型缓存：
将解析后的模型缓存本地，遇到类似的sql时直接得到解析结果。
做法：
对DSL 进行语法、词法分析，并替换WHERE 中的常量。比如将where user_id = 123 替换为where user_id ＝？。
以替换后的语句做key ，去本地缓存中进行查找。如果命中，则提取出缓存中的模型，直接将SQL 提交给D B 查询。
如果上一步没有命中， 则进行正常的解析处理，并缓存解析后的结果。
注意：
避免内存的溢出
结果缓存：
享元模式，尽可能缓存部分结果。
注意数据的一致性。
具体场景具体分析。
查询能力：
合并查询：
实时和离线的数据源不同，需要做合并。考虑replace语法，优先取离线数据，如果没有再去取实时数据。实现离线数据替换实时数据的功能，不再需要考虑离线数据未产出等问题。
推送服务：
前端轮询请求，对服务器的压力很大。
改为推送消息：
对消息生产者进行监听，做好消息过滤是非常必要的。
消息的推送基于Netty在性能表现上比较优秀
采用协程方式来适配IO 密集型的场景
稳定性：
发布系统：
1.元数据隔离
为了保障系统的稳定性，根据应用环境设计了三套元数据：日常元数据、预发元数据和线上元数据。
用户的变更可以在预发环境中进行充分的验证，验证通过后再发布到线上环境中，避免了因用户误操作而导致线上故障，保障了系统的稳定性。
2.隔离发布
不同用户的发布不会相互影响。
需要考虑资源划分、资源独占（锁）、增量更新等
隔离：
1.机房隔离
2.分组隔离
在总体机器数量不变的情况下，实现资源的最大化利用。
安全限制：
最大返回记录数。数据库的查询强制带上LIMIT 限制，具体的数值以用户配置为准。
必传字段。每张逻辑表都会配置主键，并标识哪些字段是调用者必须传人的。这样最终的SQL 肯定会带上这些字段的限制条件，防止对表做全表扫描。
超时时间。设置合适的超时时间，以使得超时的查询能及时终止并释放资源，保障系统不会被偶发的超时拖垮。
监控：
1.调用日志采集
2.调用监控
性能趋势。总体的QPS 趋势图、RT 趋势图、响应时长区间分布。
分组性能统计、单机QPS 统计，以对当前系统容量做评估。
零调用统计。找出最近N 天无调用的表，进行下线处理，节约成本。
慢SQL 查找。找出响应时间较长的SQL ，及时进行优化。
错误排查。当系统的调用错误数突增时，能从错误日志中及时发现出错原因、出错的数据源等。
限流：
针对调用者以及数据源等关键角色做了QPS 阔值控制。也就是说，如果某个调用者的调用量突增，或者对某个数据源的查询流量突增，超过了预设的QPS 阑值，则后续的请求立即失败返回，不再继续处理。
通过快速失败，将超出系统处理能力的流量直接过滤掉，保障了系统的可用性。
降级：
概述：
将这些数据源、表全部隔离成独立的模块，单个模块的故障不会引起整体不可用。
做法：
通过限流措施，将QPS 置为0 ，则对应的所有访问全部立即失败，防止了故障的扩散。
通过修改元数据，将存在问题的资源置为失效状态，则重新加载元数据后，对应的访问就全部失败了，不会再消耗系统资源。
数据挖掘：
数据挖掘算法平台：
概述：
包含数据处理、特征工程、机器学习算法、文本算法等，可高效地完成海量、亿级维度数据的复杂计算。
MaxCompute MPI：
概述：
MPI 是一种基于消息传递的并行计算框架，由于没有IO 操作，性能优于Map Reduce 。
集成了绝大部分业界主流的机器学习算法（见表7.1 ），从传统的分类、聚类算法，到互联网应用中非常流行的协同过滤、PageRank 算法，再到当前最火热的深度学习算法
数据挖掘中台体系：
概述：
将一些通用的技术集成起来形成中台技术体系，为各业务部门提供统一、高效的技术服务
挖掘数据中台：
数据分类：
特征数据与结果数据
分层：
特征层（ Featural Data Mining Layer, FDM ）
用于存储在模型训练前常用的特征指标，并进行统一的清洗和去噪处理，提升机器学习特征工程环节的效率。
中间层
个体中间层（ Individual Data Mining Layer, IDM ）
个体挖掘指标中间层，面向个体挖掘场景，用于存储通用性强的结果数据，主要包含商品、卖家、买家、行业等维度的个体数据挖掘的相关指标。
关系中间层（ Relational Data Mining Layer, RDM ）
关系挖掘指标中间层，面向关系挖掘场景，用于存储通用性强的结果数据，主要包含商品间的相似关系、竞争关系，店铺间的相似关系、竞争关系等。
应用层（ Application-oriented Data Mining Layer, ADM ）
用来沉淀比较个性偏应用的数据挖掘指标，比如用户偏好的类目、品牌等，这些数据已经过深度的加工处理，满足某一特点业务或产品的使用。
挖掘算法中台：
概述：
从各种各样的挖掘场景中抽象出有代表性的几类场景，并形成相应的方法论和实操模板。
在个体挖掘应用中，消费者画像与业务指标预测是两类非常有代表性的场景；而在关系挖掘应用中，相似关系与竞争关系是两类非常通用的关系挖掘应用
案例：
用户画像：
概述：
可以分为基础属性、购物偏好、社交关系、财富属性等几大类。
购物偏好：
首先需要将女装行业下的商品标题文本提取出来，对其进行分词，得到庞大的女装描绘词库。
需要根据词语权重去除无效的停用词，方法如计算TF-IDF 值。
利用无监督机器学习如LDA 等方法可以计算出一种风格所包含的词汇及这些词汇的重要性。
买家拥有浏览、搜索、点击、收藏、加购物车以及交易等多种行为，针对每种行为赋予不同的行为强度（比如浏览行为强度弱于交易行为），再考虑该商品的风格元素组成，
就能够通过合理的方式获知买家对该风格的偏好程度了。
基础信息：
利用机器学习算法，可以从用户行为中推测其身份，例如男生和女生、老年与青年偏好的商品和行为方式存在区别，根据一定的用户标记，最后能够预测出用户的基础身份信息。
互联网反作弊：
措施：
1.基于业务规则的方法
需要人为判定
2.基于有监督学习的方法
按照有监督分类算法的流程来建模，通过正负样本标记、特征提取、模型训练及预测等过程来识别作弊行为。
最大问题是类不平衡现象，缺点是有些算法结果的可解释性不强，容易造成错判，需要辅以其他指标和方法进行综合判断。
3.基于无监督学习的方法
在此类方法中较常见的是异常检测算法，该方法假设作弊行为极其罕见且在某些特征维度下和正常行为能够明显地区分开来。所以，假设检验、统计分析、聚类分析等手段常被用来做异常检测。
优点是不需要标记正负样本，而且检测到的异常行为还可以沉淀到规则系统中；缺点是特征设计和提取的工作量大，需要在所有可能的风险维度下刻画行为特征。
离线反作弊系统：
离线反作弊系统主要包含规则判断、分类识别、异常检测等模块，通过历史行为和业务规则的沉淀，来判断未来行为的作弊情况。
其优点是准确率较高， 所使用的历史数据越多，判断结果越准确：缺点是时效性较差，无法及时给出判断结果。
实时反作弊系统：
随着在某些场景下对时效性要求的不断提高，人们逐渐发现实时反作弊系统的必要性和重要性。
所以，将离线中的许多规则和算法进行总结，在基本满足准确率和覆盖率的前提下抽取出其中计算速度较快的部分，以此来满足对实时性的要求。但是要求高的实时性可能要以一定的准确率为代价，
而且由于数据需要进行实时采集和计算，所以对数据存储和计算系统的性能要求也非常高。
数据模型：
概述：
数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。
优点：
性能：良好的数据模型能帮助我们快速查询所需要的数据，减少数据的吞吐。
成本： 良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低大数据系统中的存储和计算成本。
效率：良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率。
质量： 良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。
关系数据库系统和数据仓库：
仍然在大规模使用SQL 进行数据的加工和处理，仍然在用Table 存储数据，仍然在使用关系理论描述数据之间的关系，只是在大数据领域，基于其数据存取的特点在关系数据模型的范式上有了不同的选择而已。
OLTP 和OLAP 系统的区别：
OLTP 系统通常面向的主要数据操作是随机读写，主要采用满足3NF 的实体关系模型存储数据，从而在事务处理中解决数据的冗余和一致性问题：
而OLAP 系统面向的主要数据操作是批量读写，事务处理中的一致性不是OLAP 所关注的，其主要关注数据的整合，以及在一次性的复杂大数据查询和处理中的性能，因此它需要采用一些不同的数据建模方法。
ER模型：
概述：
从全企业的高度设计一个3NF 模型，用实体关系（ Entity Relationship, ER ）模型描述企业业务，在范式理论上符合3NF 。
数据仓库中的3NF 与OLTP 系统中的3NF的区别在于，它是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽象。
其具有以下几个特点：
需要全面了解企业业务和数据。
实施周期非常长。
对建模人员的能力要求非常高。
出发点是整合数据，将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性处理，为数据分析决策服务，但是并不能直接用于分析决策。
建模步骤：
高层模型：一个高度抽象的模型，描述主要的主题以及主题间的关系，用于描述企业的业务总体概况。
中层模型：在高层模型的基础上，细化主题的数据项。
物理模型（也叫底层模型）：在中层模型的基础上，考虑物理存储，同时基于性能和平台特点进行物理属性的设计，也可能做一些表的合并、分区的设计等。
维度模型：
概述：
从分析决策的需求出发构建模型，为分析需求服务，因此它重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。
其典型的代表是星形模型，以及在一些特殊场景下使用的雪花模型。
流程：
选择需要进行分析决策的业务过程。
选择粒度。
识别维表。
选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。
选择事实。
Data Vault模型：
概述：
是ER模型的衍生，其设计的出发点也是为了实现数据的整合，但不能直接用于数据分析决策。
它强调建立一个可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合。
同时它基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型，以应对游、系统变更的扩展性。
组成：
Hub ：是企业的核心业务实体，由实体key 、数据仓库序列代理键、装载时间、数据来源组成。
Link ：代表Hub 之间的关系。这里与ER 模型最大的区别是将关系作为一个独立的单元抽象，可以提升模型的扩展性。
它可以直接描述1 : 1 、l :n 和n:n 的关系，而不需要做任何变更。它由Hub的代理键、装载时间、数据来源组成。
Satellite ：是Hub 的详细描述内容， 一个H ub 可以有多个Satellite 。它由Hub 的代理键、装载时间、来源类型、详细的Hub 描述信息组成。
优点：
Data Vault 模型比ER模型更容易设计和产出，它的ETL加工可实现配置化。
Anchor模型：
概述：
对Data Vault 模型做了进一步规范化处理，其核心思想是所有的扩展只是添加而不是修改，因此将模型规范到6NF ，基本变成了k-v 结构化模型。
组成：
Anchors ：类似于Data Vault 的Hub ，代表业务实体，且只有主键。
Attributes ：功能类似于Data Vault 的Satellite ，但是它更加规范化，将其全部k-v 结构化， 一个表只有一个Anchors 的属性描述。
Ties ：就是Anchors 之间的关系，单独用表来描述，类似于Data Vault 的Link ，可以提升整体模型关系的扩展能力。
Knots ：代表那些可能会在多个Anchors 中公用的属性的提炼，比如性别、状态等这种枚举类型且被公用的属性。
缺点：
增加非常多的查询join 操作
阿里的实践：
阶段一：
数据同步到oracle作为ODS层，部分采用一些维度建模的缓慢变化维方式进行历史数据处理
阶段二：
计算平台为MPP 架构体系的Greenplum。
引入ER模型＋维度模型方式，构建出一个四层的模型架构，即ODL （操作数据层） +BDL （ 基础数据层） + IDL （ 接口数据层） +ADL（应用数据层）。
ODL 和源系统保持一致：
BDL 希望引人ER 模型，加强数据的整合，构建一致的基础数据模型；
IDL 基于维度模型方法构建集市层；
ADL 完成应用的个性化和基于展现需求的数据组装。
坑：
在不太成熟、快速变化的业务面前，构建E R 模型的风险非常大，不太适合去构建ER 模型。
阶段三：
以Hadoop 为代表的分布式存储计算平台
维度建模，同时对其进行了一定的升级和扩展，构建了阿里巴巴集团的公共层模型数据架构体系。
操作数据层（ ODS ）、公共维度模型层（ CDM ）和应用数据层（ ADS ）， 其中公共维度模型层包括明细数据层（ DWD ）和汇总数据层（ DWS ）
关于DWD和DWS：
更多地采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性：
同时在汇总数据层， 加强指标的维度退化， 采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。
功能：
组合相关和相似数据：采用明细宽表，复用关联计算，减少数据扫描。
公共指标统一加工：基于OneData 体系构建命名规范、口径一致和算法统一的统计指标，为上层数据产品、应用和服务提供公共指标；建立逻辑汇总宽表。
建立一致性维度：建立一致的数据分析维表，降低数据计算口径、算法不统一的风险。
设计原则：
高内聚和低藕合：
将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型：
将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储。
核心模型与扩展模型分离：
建立核心模型与扩展模型体系，核心模型包括的宇段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要，不能让扩展模型的宇段过度侵人核心模型，以免破坏核心模型的架构简洁性与可维护性。
公共处理逻辑下沉及单一：
越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在。
成本与性能平衡：
适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。
数据可回滚：
处理逻辑不变，在不同时间多次运行数据结果确定不变。
一致性：
具有相同含义的字段在不同表中的命名必须相同，必须使用规范定义中的名称。
命名清晰、可理解：
表命名需清晰、一致，表名需易于消费者理解和使用。
模型建模过程：
维度建模：
第一个阶段是高层设计时期，定义业务过程维度模型的范围，提供每种星形模式的技术和功能描述；
直接产出目标是创建高层维度模型图，它是对业务过程中的维表和事实表的图形描述。确定维表创建初始属性列表，为每个事实表创建提议度量。
第二个阶段是详细模型设计时期，对每个星形模型添加属性和度量信息；
为高层模型填补缺失的信息，解决设计问题，并不断测试模型能否满足业务需求，确保模型的完备性。
确定每个维表的属性和每个事实表的度量，并确定信息来源的位置、定义，确定属性和度量如何填人模型的初步业务规则。
第三个阶段是进行模型的审查、再设计和验证等工作，
本阶段主要召集相关人员进行模型的审查和验证，根据审查结果对详细维度进行再设计。
第四个阶段是产生详细设计文档，提交ETL 设计和开发。
完成模型详细设计文档，提交E TL 开发人员，进入E TL 设计和开发阶段，由ETL 人员完成物理模型的设计和开发。
Inmon 模型：
非常有必要建立一个路线图一一－数据模型，描述数据仓库各部分是如何结合在一起的。
阿里实践：
在建设大数据数据仓库时，要进行充分的业务调研和需求分析。
其次，进行数据总体架构设计，主要是根据数据域对数据进行划分；按照维度建模理论，构建总线矩阵、抽象出业务过程和维度。
再次，对报表需求进行抽象整理出相关指标体系，完成指标规范定义和模型设计
最后，就是代码研发和运维。
数据整合和管理：
概述：
如何建设高效的数据模型和体系，对这些数据进行有序和有结构地分类组织和存储，避免重复建设和数据不一致性，保证数据的规范性， 一直是大数据系统建设不断追求的方向。
阿里的OneData
目标：
建设统一的、规范化的数据接人层（ ODS ）和数据中间层（ DWD和DWS ），通过数据服务和数据产品，完成服务于阿里巴巴的大数据系统建设，即数据公共层建设。
提供标准化的（ Standard ）、共享的（ Shared ）、数据服务（ Service ）能力，降低数据互通成本，释放计算、存储、人力等资源，以消除业务和技术之痛。
规范定义：
概述：
指以维度建模作为理论基础， 构建总线矩阵，划分和定义数据域、业务过程、维度、度量／ 原子指标、修饰类型、修饰词、时间周期、派生指标。
数据域：
指面向业务分析，将业务过程或者维度进行抽象的集合。其中， 业务过程可以概括为一个个不可拆分的行为事件， 在业务过程之下， 可以定义指标； 维度是指量的环境，如买家下单事件，买家是维度。为保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护和更新的， 但不轻易变动。在划分数据域时， 既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域
业务过程：
指企业的业务活动事件，如下单、支付、退款都是业务过程。请注意，业务过程是一个不可拆分的行为事件， 通俗地讲，业务过程就是企业活动中的事件时间周期用来明确数据统计的时间范用或者时间点，如最近30 天、自然周、截至当日等
修饰类型：
是对修饰词的一种抽象划分。修饰类型从属于某个业务域，如日志域的访问终端类型涵盖无线端、PC 端等修饰词
修饰词：
指除了统计维度以外指标的业务场景限定抽象。修饰词隶属于一种修饰类型，如在日志域的访问终端类型下， 有修饰词PC 端、无线端等
度量/原子指标：
原子指标和度量含义相同，基于某一业务事件件行为下的度量，是业务定义中不可子指标再拆分的指标，具有明确业务含义的名词，如支付金额
维度：
维度是度量的环境，用来反映业务的一类属性， 这类属性的集合构成一个维度，也可以称为实体对象。维度属于一个数据域，如地理维度（其中包挤罔家、地区、省以及城市等级别的内容）、时间维度（其中包括年、季、月、周、日等级别的内容）
维度属性：
维度属性隶属于一个维度， 如地理维度里面的国家名称、同家ID 、省份名称等都属于维度属性
派生指标：
派生指标＝一个原子指标＋多个修饰词（可选）＋时间周期。可以理解为对原子指标业务统计范罔的圈定。如原子指标： 支付金额，最近l 天海外买家支付金额则为派生指标（最近l 天为时间周期， 海外为修饰词， 买家作为维度，而不作为修饰词）
命名规范：
指标命名，尽量使用英文简写，其次是英文，当指标英文名太长时，可考虑用汉语拼音首字母命名。
指标设计：
概述：
事务型指标、存量型指标和复合型指标。
按照其特性不同，有些必须新建原子指标，有些可以在其他类型原子指标的基础上增加修饰词形成派生指标。
维度设计：
基本概念：
事实与维度：
维度建模中，将度量称为“事实” ，将环境描述为“维度”，维度是用于分析事实所需要的多样环境。
维度属性：
维度所包含的表示维度的列，称为维度属性。维度的作用一般是查询约束、分类汇总以及排序等。
设计方法：
1.选择维度或新建维度。
2.确定主维表。
3.确定相关维表。
确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。
4.确定维度属性。
第一个阶段是从主维表中选择维度属性或生成新的维度属性；第二个阶段是从相关维表中选择维度属性或生成新的维度属性。
规范：
1.尽可能生成丰富的维度属性。
2.尽可能多地给出包括一些富有意义的文字性描述。
3.区分数值型属性和事实
4.尽量沉淀出通用的维度属性
一方面，可以提高下游使用的方便性，减少复杂度；另一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不一致。
维度的层次结构：
概述：
维度中的一些描述属性以层次方式或一对多的方式相互关联，可以被理解为包含连续主从关系的属性层次。层次的最底层代表维度中描述最低级别的详细信息，最高层代表最高级别的概要信息。
规范化：
当属性层次被实例化为一系列维度，而不是单一的维度时，被称为雪花模式。
大多数联机事务处理系统（ OLTP ）的底层数据结构在设计时采用此种规范化技术，通过规范化处理将重复属性移至其自身所属的表中，删除冗余数据。
反规范化：
将维度的属性层次合并到单个维度中的操作称为反规范化。分析系统的主要目的是用于数据分析和统计，如何更方便用户进行统计分析决定了分析系统的优劣。
比较：
采用雪花模式，用户在统计分析的过程中需要大量的关联操作，使用复杂度高，同时查询性能很差；而采用反规范化处理，则方便、易用且性能好。
一致性维度：
交叉探查：
将不同数据域的商品的事实合并在一起进行数据探查，如计算转化率等
存在问题：
如果不同数据域的计算过程使用的维度不一致，就会导致交叉探查存在问题。当存在重复的维度，但维度属性或维度属性的值不一致时，会导致交叉探查无法进行或交叉探查结果错误。
解决：
共享维表：
比如在阿里巴巴的数据仓库中，商品、卖家、买家、类目等维度有且只有一个。所以基于这些公共维度进行的交叉探查不会存在任何问题。
一致性上卷：
其中一个维度的维度属性是另一个维度的维度属性的子集，且两个维度的公共维度属性结构和内容相同
交叉属性：
两个维度具有部分相同的维度属性。比如在商品维度中具有类目属性，在卖家维度中具有主营类目属性，两个维度具有相同的类目属性，则可以在相同的类目属性上进行不同业务过程的交叉探查。
维度整合：
概述：
数据仓库是面向主题的，面向应用的原始数据导入后需要整合。
具体整合方面：
命名规范的统一。表名、字段名等统一。
字段类型的统一。相同和相似字段的字段类型统一。
公共代码及代码值的统一。公共代码及标志性宇段的数据类型、命名方式等统一。
业务含义相同的表的统一。
采用主从表的设计方式，主表存放都有的字段，从表存放各自的字段。
直接合并
不合并，单独存放。
维表如何整合：
垂直整合：
不同的来源表包含相同的数据集，只是存储的信息不同，通过某个字段能关联起来。
水平整合：
不同的来源表包含不同的数据集，不同子集之间无交叉，也可以存在部分交叉。
关于交叉的部分，可以去重。
维度拆分：
概述：
可能的两个方向：
方案1是将维度的不同分类实例化为不同的维度，同时在主维度中保存公共属性：
方案2 是维护单一维度，包含所有可能的属性。
具体根据原则来定。
原则：
扩展性：当源系统、业务逻辑变化时，能通过较少的成本快速扩展模型，保持核心模型的相对稳定性。软件工程中的高内聚、低稠合的思想是重要的指导方针之一。
效能： 在性能和成本方面取得平衡。通过牺牲一定的存储成本，达到性能和逻辑的优化。
易用性：模型可理解性高、访问复杂度低。用户能够方便地从模型中找到对应的数据表，并能够方便地查询和分析。
如何拆分：
1.维度的不同分类的属性差异情况
定义一个主维度用于存放公共属性；同时定义多个子维度，其中除了包含公共属性外，还包含各自的特殊属性。
2.第二个依据是业务的关联程度。
两个相关性较低的业务，稠合在一起弊大于利，对模型的稳定性和易用性影响较大。
垂直拆分：
概述：
某些维度属性的来源表产出时间较早，而某些维度属性的来源表产出时间较晚；
或者某些维度属性的热度高、使用频繁，而某些维度属性的热度低、较少使用；
或者某些维度属性经常变化，而某些维度属性比较稳定。
阿里实践：
设计主从维度。主维表存放稳定、产出时间早、热度高的属性；从维表存放变化较快、产出时间晚、热度低的属性。
历史归档：
概述：
由于数据量、访问速度的原因，需要定期将历史数据归档至历史维表。
归档策略：
方式一：
同前台归档策略，适用于前台归档策略逻辑较为简单，且变更不频繁的情况。
方式二：
同前台归档策略，但采用数据库变更日志的方式。可以使用增量日志的删除标志，作为前台数据归档的标志。但对前台应用的要求是数据库的物理删除只有在归档时才执行，应用中的删除只是逻辑删除。
方式三：
数据仓库自定义归档策略。原则是尽量比前台应用晚归档、少归档。避免出现数据仓库中已经归档的数据再次更新的情况。
维度变化：
缓慢变化维：
概述：
缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流逝发生缓慢的变化。与数据增长较为快速的事实表相比，维度变化相对缓慢。
处理方式：
重写维度值。
采用此种方式，不保留历史数据，始终取最新数据。
插人新的维度行。
采用此种方式，保留历史数据，维度值变化前的事实和过去的维度值关联，维度值变化后的事实和当前的维度值关联。
缺点：
采用第二种处理方式不能将变化前后记录的事实归一为变化前的维度或者归一为变化后的维度。只能分别对应。
添加维度列：
使用的时候可以选择新旧列。
快照：
每天一份快照
拉链：
基于插人新的维度行。
新增两个时间戳字段(start_dt 和end_dt）
极限存储：
底层的数据还是历史拉链存储，但是上层做一个视图操作或者在Hive 里做一个hook ，通过分析语句的语法树，把对极限存储前的表的查询转换成对极限存储表的查询。
局限性：
对于部分变化频率频繁的宇段需要过滤。
例如，用户表中存在用户积分宇段，这种宇段的值每天都在发生变化，如果不过滤的话，极限存储就相当于每个分区存储一份全量数据（新行），起不到节约存储成本的效果。
解决：
通过将一些属性从维表中移出，放置到全新的维表中，可以解决维度的过度增长导致极限存储效果大打折扣的问题。
其中一种解决方法就是上一节提到的垂直拆分，保持主维度的稳定性；
另一种解决方式是采用微型维度。将一部分不稳定的属性从主维度中移出，并将它们放置到拥有自己代理键的新表中来实现的。
特殊维表：
层次维表：
join：
如果要找到一个父类目下的所有叶子节点，需要用递归SQL，比如oracle的connect by语句。
由于很多数据仓库系统和商业智能工具不支持递归SQL ，且用户使用递归SQL的成本较高。
解决：
层次结构扁平化，遇到空时向下回填，将类目向下虚拟
层次桥接表：
不需要预先知道所属层级，不需要回填，也可解决非均衡层次结构的问题。与扁平化方法相比，该方法适合解决更宽泛的分析问题，灵活性好；但复杂性高，使用成本高。
形式：
父类目ID 子类目ID 类目层级间隔
1 1 0
1 100 2
行为维度：
概述：
很多维表，如卖家主营类目维度、卖家主营品牌维度、用户常用地址维度等。
其中卖家主营类目和主营品牌通过卖家的商品分布和交易分布情况，采用算法计算得到；卖家常用地址通过最近一段时间内物流中卖家的发货地址和买家的收货地址进行统计得到。
类似的维度，都和事实相关，如交易、物流等，称之为“行为维度”，或“事实衍生的维度”。
分类：
另一个维度的过去行为，如买家最近一次访问淘宝的时间、买家最近一次发生淘宝交易的时间等。
快照事实行为维度，如买家从年初截至当前的淘宝交易金额、买家信用分值、卖家信用分值等。
分组事实行为维度，将数值型事实转换为枚举值。如买家从年初截至当前的淘宝交易金额按照金额划分的等级、买家信用分值按照分数划分得到的信用等级等。
复杂逻辑事实行为维度，通过复杂算法加工或多个事实综合加工得到。如前面提到的卖家主营类目，商品热度根据访问、收藏、加人购物车、交易等情况综合计算得到。
存储方式：
一种是将其冗余至现有的维表中，如将卖家信用等级冗余至卖家维表中
另一种是加工成单独的行为维表，如卖家主营类目。
原则：
第一，避免维度过快增长。比如对商品表进行了极限存储，如果将商品热度加入现有的商品维表中，则可能会使每日商品变更占比过高，从而导致极限存储效果较差。
第二，避免耦合度过高。比如卖家主营类目，加工逻辑异常复杂，如果融合进现有的卖家维表中，那么过多的业务稠合会导致卖家维表刷新逻辑复杂、维护性差、产出延迟等。
多值维表：
概述：
维表中的某个属性字段同时有多个值，称之为“多值属性”。它是多值维度的另一种表现形式。
存储方式：
第一种处理方式是保持维度主键不变，将多值属性放在维度的一个属性字段中。
比如property字段存放map
第二种处理方式也是保持维度主键不变，但将多值属性放在维度的多个属性字段中。
扩展性较差
第三种处理方式是维度主键发生变化， 一个维度值存放多条记录。
杂项维度：
概述：
杂项维度是由操作型系统中的指示符或者标志宇段组合而成的，一般不在一致性维度之列。
比如淘宝交易订单的交易类型宇段，包括话费充值、司法拍卖、航旅等类型：支付状态、物流状态等，它们在源系统中直接保存在交易表中。
存储：
建立杂项维度，将这些字段建立到一个维表中，在事实表中只需保存一个外键（实体主键）即可。
事实表：
概述：
描述业务过程的度量
分类：
可加性、半可加性和不可加性
可加性事实是指可以按照与事实表关联的任意维度进行汇总。
半可加性事实只能按照特定维度汇总，不能对所有维度汇总，比如库存可以按照地点和商品进行汇总，而按时间维度把一年中每个月的库存累加起来则毫无意义。
还有一种度量完全不具备可加性，比如比率型事实。对于不可加性事实可分解为可加的组件来实现聚集。
类型：
事务事实表、周期快照事实表和累积快照事实表
事务事实表用来描述业务过程，眼踪空间或时间上某点的度量事件，保存的是最原子的数据，也称为“原子事实表。
周期快照事实表以具有规律性的、可预见的时间间隔记录事实，时间间隔如每天、每月、每年等。
累积快照事实表用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点， 当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改。
设计原则：
原则1：尽可能包含所有与业务过程相关的事实
原则2：只选择与业务过程相关的事实
原则3：分解不可加性事实为可加的组件
比如订单的优惠率，应该分解为订单原价金额与订单优惠金额两个事实存储在事实表中。
原则4：在选择维度和事实之前必须先声明粒度
原则5：在同一个事实表中不能有多种不同粒度的事实
原则6：事实的单位要保持一致
原则7：对事实的null 值要处理
原则8：使用退化维度提高事实表的易用性
维度属性也可以存储到事实表中，这种存储到事实表中的维度列被称为“退化维度”。
设计流程：
第一步：选择业务过程及确定事实表类型。
第二步：声明粒度。
应该尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性。
第三步：确定维
第四步：确定事实。
第五步：冗余维度
考虑更多的是提高下游用户的使用效率，降低数据获取的复杂性，减少关联的表数量。所以通常事实表中会冗余方便下游用户使用的常用维度，以实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等操作。
事务事实表：
单事务事实表
多事务事实表：
将不同的事实放到同一个事实表中，即同一个事实表包含不同的业务过程。多事务事实表在设计时有两种方法进行事实的处理：
不同业务过程的事实使用不同的事实字段进行存放，非当前业务过程则置零表示。
比如是否下单、是否支付、是否完结订单。
不同业务过程的事实使用同一个事实字段进行存放，但增加一个业务过程标签
周期快照事实表：
概述：
当需要一些状态度量时，比如账户余额、买卖家星级、商品库存、卖家累积交易额等，则需要聚集与之相关的事务才能进行识别计算；
聚集长期的事务历史效率比较低，而快照事实表在确定的问隔内对实体的度量进行抽样，这样可以很容易地研究实体的度量值。
比如昨天的成交情况，每次查询如果都重新聚合，需要时间比较多。而快照事实表每天计算一次存储即可。
快照粒度：
业务需要采样的周期
密度与稀疏性：
事务事实表是稀疏的，只有当天发生的业务过程，事实表才会记录该业务过程的事实，如下单、支付等；
而快照事实表是稠密的，无论当天是否有业务过程发生，都会记录一行，比如针对卖家的历史至今的下单和支付金额，无论当天卖家是否有下单支付事实，都会给该卖家记录一行。
稠密性是快照事实表的重要特征
半可加性：
不能根据时间维度获得有意义的汇总结果，但可以取平均。
注意事项：
事务与快照成对设计
互相补充，以满足更多的下游统计分析需求
附加事实：
需要关注上一个采样周期结束时的状态度量，而又不愿意多次使用快照事实表，因此一般在设计周期快照事实表时会附加一些上一个采样周期的状态度量。
累积快照事实表：
设计过程：
第一步：选择业务过程。
第二步：确定粒度。
第三步：确定维度。
第四步：确定事实。
第五步：退化维度。
特点：
数据不断更新
多业务过程日期
用于计算业务过程之间的时间间隔。
实现方式：
1.全量表
每天一份全量，适用于全量数据较少的情况。
2.全量表的变化形式
保留一定间隔的数据，之前的数据存储在归档表中。
3.以业务实体的结束时间分区。
极端情况下，结束时间没有。
解决：
使用相关业务系统的业务实体的结束标志作为此业务系统的结束标志
和前端业务系统确定口径或使用前端归档策略。
无事实的事实表：
概述：
不包含事实或度的事实表称为“无事实的事实表“
分类：
第一种是事件类的，记录事件的发生。在阿里巴巴数据仓库中，最常见的是日志类事实表。
比如用户的浏览日志，某会员某时间点浏览了淘宝首页、某会员某时间点浏览了某卖家的店铺中的某商品详情页等。对于每次点击，其事实为1，但一般不会保存此事实。
第二种是条件、范围或资格类的，记录维度与维度多对多之间的关系。比如客户和销售人员的分配情况、产品的促销范围等。
聚集型事实表：
概述：
通过汇总明细粒度数据来获得改进查询性能的效果
基本原则：
－致性。
避免单一表设计。不要在同一个表中存储不同层次的聚集数据；
聚集粒度可不同。
数据公用性。
不跨数据域。
区分统计周期。
基本步骤：
第一步：确定聚集维度。
第二步：确定一致性上钻。
第三步：确定聚集事实。
带来的问题：
聚集会带来查询性能的提升，但聚集也会增加ETL 维护的难度。当子类目对应的一级类目发生变更时，先前存在的、已经被汇总到聚集表中的数据需要被重新调整。
这一额外工作随着业务复杂性的增加，会导致多数ETL 人员选择简单强力的方法，删除并重新聚集数据。
数据管理：
元数据：
概述：
元数据（ Metadata ）是关于数据的数据。元数据打通了源数据、数据仓库、数据应用，记录了数据从产生到消费的全过程。
元数据主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL 的任务运行状态。
分类：
技术元数据（ Technical Metadata)和业务元数据（ Business Metadata ）。
技术元数据：
概述：
存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据。
分类：
1.分布式计算系统存储元数据，如MaxCompute表、列、分区等信息。记录了表的表名。分区信息、责任人信息、文件大小、表类型，生命周期，以及列的字段名、字段类型、字段备注、是否是分区字段等信息。
2.分布式计算系统运行元数据，如Max Compute 上所有作业运行等信息：类似于Hive 的Job 日志，包括作业类型、实例名称、输入输出、SQL 、运行参数、执行时间、最细粒度的Fuxi Instance(Max Compute 中MR 执行的最小单元）执行信息等。
3.数据开发平台中数据同步、计算任务、任务调度等信息，包括数据同步的输入输出表和字段，以及同步任务本身的节点信息：计算任务主要有输入输出、任务本身的节点信息；任务调度主要有任务的依赖类型、依赖关系等，以及不同类型调度任务的运行日志等。
4.数据质量和运维相关元数据，如任务监控、运维报警、数据质量、故障等信息，包括任务监控运行日志、告警配置及运行日志、故障信息等。
业务元数据：
概述：
从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。
分类：
OneData 元数据，如维度及属性、业务过程、指标等的规范化定义，用于更好地管理和使用数据。
数据应用元数据，如数据报表、数据产品等的配置和运行元数据。
元数据价值：
在数据管理方面为集团数据提供在计算、存储、成本、质量、安全、模型等治理领域上的数据支持。
在计算上可以利用元数据查找超长运行节点，对这些节点进行专项治理，保障基线产出时间。
在数据内容方面为集团数据进行数据域、数据主题、业务属性等的提取和分析提供数据素材。
可以利用元数据构建知识图谱，给数据打标签，清楚地知道现在有哪些数据。在数据应用方面打通产品及应用链路，保障产品数据准确、及时产出。
打通Max Compute 和应用数据，明确数据资产等级，更有效地保障产品数据。
统一元数据体系建设：
概述：
元数据的质量直接影响到数据管理的准确性，如何把元数据建设好将起到至关重要的作用。
目标：
打通数据接入到加工，再到数据消费整个链路，规范元数据体系与模型，提供统一的元数据服务出口，保障元数据产出的稳定性和质量。
措施：
1.梳理清楚元仓底层数据，对元数据做分类，如计算元数据、存储元数据、质量元数据等，减少数据重复建设，保障数据的唯一性。
2.丰富表和字段使用说明，方便使用和理解。
3，根据元仓底层数据构建元仓中间层，依据OneData 规范，建设元数据基础宽表，也就是元数据中间层，打通从数据产生到消费整个链路，不断丰富中间层数据，如MaxCompute 元数据、调度元数据、同步元数据、产品访问元数据、服务元数据等。
4.基于元数据中间层，对外提供标准统一的元数据服务出口，保障元数据产出的质量。
元数据衍生应用：
元数据门户：
概述：
致力打造一站式的数据管理平台、高效的一体化数据市场。
包括“前台”和“后台”，“前台”产品为数据地图，定位消费市场，实现检索数据、理解数据等“找数据”需求；“后台”产品为数据管理，定位于一站式数据管理，实现成本管理、安全管理、质量管理等。
数据地图：
概述：
提供方便快捷的数据搜索服务，拥有功能强大的血缘信息及影响分析，利用表使用说明、评价反馈、表收藏及精品表机制，为用户浮现高质量、高保障的目标数据。
使用：
搜索关键词，查看明细信息、使用规则，通过数据地图的血缘分析可以查看每个数据表的来源、去向，并查看每个表及字段的加工逻辑。
数据管理平台：
围绕数据管理，服务于个人开发者、BU 管理者、系统管理员等用户，提供个人和BU 全局资产管理、成本管理和质量管理等。
针对个人开发者，主要包括计算费用和健康分管理、存储费用和健康分管理，并提供优化建议和优化接口：针对BU 管理者和管理员，主要提供BU 、应用、集群等全局资产消耗概览、分析和预测。
应用链路分析：
概述：
通过元数据血缘来分析产品及应用的链路，通过血缘链路可以清楚地统计到某个产品所用到的数据在计算、存储、质量上存在哪些问题，通过治理优化保障产品数据的稳定性。
通过应用链路分析，产出表级血缘、字段血缘和表的应用血缘。
分析方法：
依赖解析
间接使用、无配置的情况下不适合
日志解析
统一的应用日志打点SDK
作用：
影响分析、重要性分析、下线分析、链路分析、寻根溯源、故障排查等。
数据建模：
概述：
基于现有底层数据已经有下游使用的情况，我们可以通过下游所使用的元数据指导数据参考建模。
元数据驱动的数据仓库模型建设
数据分类：
表的基础元数据，包括下游情况、查询次数、关联次数、聚合次数、产出时间等。
表的关联关系元数据，包括关联表、关联类型、关联字段、关联次数等。
表的字段的基础元数据，包括字段名称、字段注释、查询次数、关联次数、聚合次数、过滤次数等。
使用示例：
基于下游使用中关联次数大于某个阔值的表或查询次数大于某个阐值的表等元数据信息，筛选用于数据模型建设的表。
基于表的字段元数据，如字段中的时间字段、字段在下游使用中的过滤次数等，选择业务过程标识字段。
基于主从表的关联关系、关联次数，确定和主表关联的从表。
基于主从表的字段使用情况，如字段的查询次数、过滤次数、关联次数、聚合次数等，确定哪些字段进入目标模型。
驱动ETL开发：
概述：
数据的下游任务依赖情况、最近被读写的次数、数据是否可再生、每天消耗的存储计算等，这些元数据足以让判断数据是否可以下线；
计算管理：
系统优化：
概述：
Hadoop yarn集群评估资源，一般是根据输入数据量进行静态评估， Map 任务用于处理输入，对于普通的Map 任务，评估一般符合预期：
而对于Reduce 任务，其输入来自于Map 的输出，但一般只能根据Map 任务的输入进行评估，经常和实际需要的资源数相差很大。
HBO：
概述：
(History-Based Optimizer， 基于历史的优化器）
根据任务历史执行情况为任务分配更合理的资源，包括内存、CPU 以及Instance 个数。
原理：
任务执行历史＋集群状态信息＋优化规则→更优的执行配置。
步骤：
前提：最近7 天内任务代码没有发生变更且任务运行4 次。
Instance 分配逻辑：基础资源估算值＋加权资源估算值。
基础资源估算值：
map task：基于输入数据量
reduce task：hive使用Map输入数据量，maxCompute使用最近7 天Reduce 对应Map 的平均输出数据量作为Reduce的输入数据量
加权资源估算值：
通过该Map 在最近一段时间内的平均处理速度与系统设定的期望值做比较，如果平均处理速度小于期望值，则按照同等比例对基础资源数量进行加权，估算出该Map 的加权资源数量。
reduce类似
改进与优化：
HBO 是基于执行历史来设置计划的，对于日常来说，数据量波动不大，工作良好。但是某些任务在特定场合下依旧有数据量暴涨的情况发生，尤其是在大促“双11”和“双12”期间，这个日常生成的HBO计划就不适用了。针对这个问题， HBO也增加了根据数据量动态调整Instance 数的功能，主要依据Map 的数据量增长情况进行调整。
CBO：
概述：
基于代价的优化器。
优化器（ Optimizer ）引人了Volcano 模型 ，该模型是基于代价的优化器（ CBO ），并且引人了重新排序Join (Join Reorder ）和自动MapJoin (Auto MapJoin ）优化规则等，同时基于Volcano 模型的优化器会尽最大的搜索宽度来获取最优计划。
组成模块：
Meta Manager （元数据）、Statistics （统计信息）、Rule Set （优化规则集）、Volcano Planner Core（核心计划器）
特性：
重新排序join
自动MapJoin
任务优化：
概述：
主要讨论数据倾斜
存储和成本管理：
概述：
数据压缩、数据重分布、存储治理项优化、生命周期管理等的角度
数据压缩：
概述：
archive 压缩方法
优点：
可以减少存储。
缺点：
恢复时间更长，可读性更差。
适合场景：
冷备数据与日志数据的压缩存储上。
数据重分布：
概述：
主要采用基于列存储的方式，由于每个表的数据分布不同，插人数据的顺序不一样，会导致压缩效果有很大的差异， 因此通过修改表的数据重分布，避免列热点，将会节省一定的存储空间。
目前我们主要通过修改distribute by 和sort by 字段的方法进行数据重分布。
建议：
一般我们会筛选出重分布效果高于15% 的表进行优化处理。
存储治理顶优化：
概述：
在元数据的基础上，诊断、加工成多个存储治理优化项。
常见治理项：
目前已有的存储治理优化项有未管理表、空表、最近62 天未访问表、数据无更新无任务表、数据无更新有任务表、开发库数据大于lOOGB 且无访问表、长周期表等。
作用：
通过对该优化项的数据诊断， 形成治理项，治理项通过流程的方式进行运转、管理，最终推动各个ETL开发人员进行操作，优化存储管理，并及时回收优化的存储效果。
在这个体系下，形成现状分析、问题诊断、管理优化、效果反馈的存储治理项优化的闭环。通过这个闭环，可以有效地推进数据存储的优化，降低存储管理的成本。
生命周期管理：
概述：
根本目的就是用最少的存储成本来满足最大的业务需求，使数据价值最大化。
策略：
周期性删除策略：
所存储的数据都有一定的有效期，从数据创建开始到过时，可以周期性删除X 天前的数据。
彻底删除策略：
无用表数据或者ETL 过程产生的临时数据，以及不需要保留的数据，可以进行及时删除，包括删除元数据。
永久保留策略：
重要且不可恢复的底层数据和应用数据需要永久保留。比如底层交易的增量数据，出于存储成本与数据价值平衡的考虑，需要永久保留，用于历史数据的恢复与核查。
极限存储策略：
极限存储可以超高压缩重复镜像数据，通过平台化配置手段实现透明访问：缺点是对数据质量要求非常高，配置与维护成本比较高，建议一个分区有超过5G B 的镜像数据（如商品维表、用户维表）就使用极限存储。
冷数据管理策略：
冷数据管理是永久保留策略的扩展。永久保留的数据需要迁移到冷数据中心进行永久保存，同时将Max Compute 中对应的数据删除。一般将重要且不可恢复的、占用存储空间大于1OOTB，且访问频次较低的数据进行冷备，例如3 年以上的日志数据。
增量表merge 全量表策略：
对于某些特定的数据，极限存储在使用性与存储成本方面的优势不是很明显，需要改成增量同步与全量merge 的方式，对于对应的delta增量表的保留策略，目前默认保留93 天。
管理矩阵：
概述：
主要通过对历史数据的等级划分与对表类型的划分生成相应的生命周期管理矩阵。
不同等级下不同表类型，保存的天数不一样。
历史数据等级划分：
PO：非常重要的主题域数据和非常重要的应用数据，具有不可恢复性，如交易、日志、集团KPI 数据、IPO 关联表。
P1：重要的业务数据和重要的应用数据，具有不可恢复性，如重要的业务产品数据。
P2：重要的业务数据和重要的应用数据，具有可恢复性，如交易线ETL 产生的中间过程数据。
P3：不重要的业务数据和不重要的应用数据，具有可恢复性，如某些SNS 产品报表。
表类型划分：
1.事件型流水表（增量表）
事件型流水表（增量表）指数据无重复或者无主键数据，如日志。
2.事件型镜像表（增量表）
事件型镜像表（增量表）指业务过程性数据，有主键，但是对于同样主键的属性会发生缓慢变化，如交易、订单状态与时间会根据业务发生变更。
3.维表
维表包括维度与维度属性数据，如用户表、商品表。
4.Merge 全量表
Merge 全量表包括业务过程性数据或者维表数据。由于数据本身有新增的或者发生状态变更，对于同样主键的数据可能会保留多份，因此可以对这些数据根据主键进行Merge 操作，主键对应的属性只会保留最新状态，历史状态保留在前一天分区中。例如，用户表、交易表等都可以进行Merge 操作。
5.ETL 临时表
ETL 临时表是指ETL 处理过程中产生的临时表数据，一般不建议保留，最多7 天。
6.TT 临时数据
TT 拉取的数据和DbSync 产生的临时数据最终会流转到ODS 层，ODS 层数据作为原始数据保留下来，从而使得TT&DbSync 上游数据成为临时数据。这类数据不建议保留很长时间，生命周期默认设置为93天，可以根据实际情况适当减少保留天数。
7.普通全量表
很多小业务数据或者产品数据， BI 一般是直接全量拉取，这种方式效率快，对存储压力也不是很大，而且表保留很长时间，可以根据历史数据等级确定保留策略。
数据成本计量：
成本组成：
在计量数据表的成本时，除考虑数据表本身的计算成本、存储成本外，还要考虑对上游数据表的扫描带来的扫描成本。我们将数据成本定义为存储成本、计算成本和扫描成本三个部分。
数据使用计费：
概述：
对应三部分成本，使用的收费分别为计算付费、存储付费和扫描付费。
作用：
通过成本计量，可以比较合理地评估出数据加工链路中的成本，从成本的角度反映出在数据加工链路中是否存在加工复杂、链路过长、依赖不合理等问题，间接辅助数据模型优化，提升数据整合效率；
通过数据使用计费，可以规范下游用户的数据使用方法，提升数据使用效率，从而为业务提供优质的数据服务。
数据质量：
概述：
数据质量是数据分析结论有效性和准确性的基础，也是这一切的前提。
评估标准：
完整性、准确性、一致性和及时性。
完整性：
指数据的记录和信息是否完整，是否存在缺失的情况。数据的缺失主要包括记录的缺失和记录中某个字段信息的缺失，两者都会造成统计结果不准确，所以说完整性是数据质量最基础的保障。
准确性：
准确性是指数据中记录的信息和数据是否准确，是否存在异常或者错误的信息。
一致性：
及时性：
在确保数据的完整性、准确性和一致性后，接下来就要保障数据能够及时产出，这样才能体现数据的价值。
方法：
消费场景知晓：
背景：
数据越来越多，到底是否都是重要的，是否都要进行保障， 是否有一些数据已经过期了，是否所有需要都要精确地进行质量保障。
解决：
主要通过数据资产等级和基于元数据的应用链路分析解决消费场景知晓的问题。
根据应用的影响程度，确定资产等级；根据数据链路血缘，将资产等级上推至各数据生产加工的各个环节，确定链路上所涉及数据的资产等级和在各加工环节上根据资产等级的不同所采取的不同处理方式。
资产等级：
分类：
毁灭性质，即数据一旦出错，将会引起重大资产损失，面临重大收益损失，造成重大公关风险。
全局性质，即数据直接或者间接用于集团级业务和效果的评估、重要平台的运维、对外数据产品的透露、影响用户在阿里系网站的行为等。
局部性质，即数据直接或间接用于内部一般数据产品或者运营／产品报告，如果出现问题会给事业部或业务线造成影响，或者造成工作效率损失。
一般性质，即数据主要用于小二的日常数据分析，出现问题几乎不会带来影响或者带来的影响极小。
未知性质，不能明确说出数据的应用场景，则标注为未知。
如何评定：
数据从业务系统中产生的，经过同步工具进入数据仓库系统中，经过数据仓库加工后的产出表用于数据产品。
借助强大的元数据知道整个数据仓库中的哪些表服务于这个数据产品，因此通过给不同的数据产品或者应用划分数据资产等级，再依托元数据的上下游血缘，就可以将整个消费链路打上某一类数据资产的标签。
数据生产加工各个环节卡点校验：
主要包括在线系统和离线系统数据生产加工各个环节的卡点校验。
在线系统生产加工各环节卡点校验：
分类：
根据资产等级的不同，当对应的业务系统变更时，决定是否将变更通知下游；
对于高资产等级的业务， 当出现新业务数据时，是否纳入统计中，需要卡点审批。
在线数据和离线数据的一致性：
措施：
1.发布平台在业务进行重大变更时，通知离线开发人员，使其知晓此次变更的内容。
2.数据库平台进行库表变更时，通知离线开发人员。
3.通过培训，将离线数据的诉求、离线数据的加工过程、数据产品的应用方式告诉在线业务开发人员，使其意识到数据的重要性，了解数据的价值，同时也告知出错后果，使在线开发人员在完成业务目标时，也要注重数据的目标，做到业务端和数据端一致。
离线系统生产加工各环节卡点校验：
主要包括代码开发、测试、发布和历史或错误数据回刷等环节的卡点校验，针对数据资产等级的不同，对校验的要求有所不同。
代码提交时的卡点校验。
SQLSCAN
任务发布上线时的卡点校验。
1.发布上线前的测试主要包括Code Review 和回归测试，对于资产等级较高的任务变更发布，则采取强阻塞的形式，必须通过在彼岸完成回归测试之后才允许发布。
回归测试一方面要保证新逻辑的正确：另一方面要保证不影响非此次变更的逻辑。
2.发布上线后可以在线上做Dry Run 测试或真实环境运行测试，其中Dry Run 测试，不执行代码，仅运行执行计划，避免线上和线下环境不一致导致语法错误；
真实环境的运行测试，则使用真实数据进行测试。
3.节点变更或数据重刷前的变更通知。
一般建议使用通知中心的将变更原因、变更逻辑、变更测试报告和变更时间等自动通知下游，下游对此次变更没有异议后，再按照约定时间执行发布变更，将变更对下游的影响降至最低。
风险点监控：
主要是针对在数据日常运行过程中可能出现的数据质量和时效等问题进行监控，包括在线数据和离线数据的风险点监控两个方面。
在线数据的风险点监控:
概述：
主要是针对在线系统日常运行产出的数据进行业务规则的校验，以保证数据质量，其主要使用实时业务检测平台BCP ( Biz Check Platform ）
BCP：
概述：
针对数据库表的记录进行规则校验。在每一个业务系统中，当完成业务过程进行数据落库时， BCP同时订阅一份相同的数据，在BCP系统中进行逻辑校验，当校验不通过时，以报警的形式披露出来给到规则订阅人，以完成数据的校对。
流程：
首先，用户在BCP 平台进行数据源订阅，以获取需要校验的数据源：
然后，针对所订阅的数据源进行规则的编写，即校验的逻辑，这些规则是至关重要的，也是校验的核心，只要这些规则通过了，即认为这条记录是对的：
最后，配置告警，针对不同的规则配置不同的告警形式。
示例：
订单拍下时间肯定不会大于当天时间，也不会小于淘宝创立时间。
适合场景：
BCP 的配置和运行成本较高， 主要根据数据资产等级进行监控。
离线数据的风险点监控：
概述：
主要是针对离线系统日常运行产出的数据进行数据质量监控和时效性监控，其中数据质量监控主要使用DQC ， 时效性监控主要使用摩萨德。
准确性DQC：
通过运行SQL任务来监控准确性，可以放置在节点之间用于监控。
时效性：
监控任务的出错、延迟。
预警（超时）
质量衡量：
对质量的衡量既有事前的衡量，如DQC覆盖率；又有事后的衡量，主要用于眼进质量问题，确定质量问题原因、责任人、解决情况等，并用于数据质量的复盘，避免类似事件再次发生。
数据质量起夜率：
数据质量事件
首先，用来眼进数据质量问题的处理过程；其次，用来归纳分析数据质量原因z 第三，根据数据质量原因来查缺补漏，既要找到数据出现问题的原因，也要针对类似问题给出后续预防方案。
数据质量故障体系：
概述：
对于严重的数据质量事件，将升级为故障。
流程：
故障定义
故障等级
故障处理
故障review
