数据仓库
概念
数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它出于分析性报告和决策支持目的而创建。为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。
一、发展历程
数据仓库的发展大致经历了这样的三个过程：
A、简单报表阶段
这个阶段，系统的主要目标是解决一些日常的工作中业务人员需要的报表，以及生成一些简单的能够帮助领导进行决策所需要的汇总数据。这个阶段的大部分表现形式为数据库和前端报表工具。
B、数据集市阶段
这个阶段，主要是根据某个业务部门的需要，进行一定的数据的采集，整理，按照业务人员的需要，进行多维报表的展现，能够提供对特定业务指导的数据，并且能够提供特定的领导决策数据。
C、数据仓库阶段
这个阶段，主要是按照一定的数据模型，对整个企业的数据进行采集，整理，并且能够按照各个业务部门的需要，提供跨部门的，完全一致的业务报表数据，能够通过数据仓库生成对对业务具有指导性的数据，同时，为领导决策提供全面的数据支持。
通过数据仓库建设的发展阶段，我们能够看出，数据仓库的建设和数据集市的建设的重要区别就在于数据模型的支持。因此，数据模型的建设，对于我们数据仓库的建设，有着决定性的意义。
二、数据仓库与数据库的区别
数据仓库只是BI有机组成的一个部分。BI包括底层的数据仓库和建立在其之上背后的决策报表、数据分析、数据挖掘及深度运算等基于数据的能力。BI是一种方案，包含了数据仓库的构建技术、报表技术、挖掘技术等等。
数据仓库：面向主题的，集成的，时变的，易失的。（核心概念）
数据库：
- 面向应用，根据具体的事件和操作对象，为了达成线上的应用、交易需求进行的设计过程。
- 业务导向、需求驱动，业务人员提出明确的需求（如线上实现10ms的交易需求），清晰的指导方式
- 设计目标：在线事务处理，一个事务是一次完整的数据查询或者修改的操作，是为企业特定需求服务的，并且实现时是有响应时间，数据安全等系统层面考量的。
数据仓库：
- 面向主题，不断的发展更新自己的主题，最终建成一个全有向、完整的分析数据环境。
- 很难获得用户的需求到底是什么，使用人群十分广泛，设计人员了解到仓库里有哪些数据、主题、模型，在此基础再去布局能完成的任务。是一个逐渐迭代的过程。
- 为了做分析决策，建立起企业内全局的数据环境，元数据进入到数据仓库后不会再发生更新，对于数据的响应时间不敏感。设计时更多的考虑数据的组织，如何实现主题划分。
三、数据仓库的主题
数据仓库的主题：
数据仓库的基本数据类型：
四、大数据平台架构
如下图所示：
例：男性、40岁左右、爱抽烟、有车的。BitMap 这种引擎可以快速得到响应的结果。
五、架构分层 重要
如下图所示：
A、数据缓冲层
数据缓冲层也称待转换区，这里是源业务系统数据的快照，两者力度一致，保存细节数据，按天保存。这一层重点要保证数据的快速，准确入库。快速是指尽量减少该过程的时间，准确是指数据入库过程中保证无数据丢失，无乱码，错行等情况，进行简单的数据清洗，涉及敏感的数据会直接进行加密。
功能定义：即 Stage，又称数据中转区，该层通过ETL过程获取源业务系统的数据增量，主要按日存储明细数据。为ODM层提供基础数据。
B、贴源明细层
数据贴源层是用于合并、存储生产系统历史至今数据，表结构及数据类型和源系统保持一致，对不同业务类型表使用不同的存储策略，对有价值的历史状态、历史关系、历史属性进行拉链表处理，比如用户账户信息等。同时对每张表按业务归属用统一缩略语做标识并对其中敏感数据进行加密与脱敏处理，对明确的脏数据规则加以过滤清洗。
功能定义：全称 Original Data Mart，该层负责合并、存储生产系统历史至今数据，按照业务归属组织数据，并进行脱敏及脏数据清洗处理。
- 起到隔离作用，屏蔽源系统数据结构变更、切库迁移等技术性需求
- 为后续主题模型、应用集市和数据探索区提供基础支撑
C、整合明细层
仓库基础层来源于ODM，数据粒度同于ODM，并做了数据清洗及数据脱敏处理与部分预关联工作。原则上，协议、事件相关明细按业务过程整合拉平重要业务节点数据，以宽表落地；用户、产品、流量作为主题做企业级整合。
功能定义：全称 Integrate Data Mart，该层按照主题划分对核心业务数据进行企级整合，在保持原有数据粒度的基础上，完成标准化 (维度、代码 ) 以及数据预关联操作。
D、共性加工层
基于应用集市沉淀的通用类属性、指标而创建面向支持应用系统、数据分析与数据挖掘的公共数据层，主要形式有将重要的京东业务链组合起来的累积快照表和以重要维度为粒度的重要指标汇总表。
功能定义：全称 Summary Data Mart， 该层基于应用集市沉淀的通类属性、指标而创建，面向支持应用系统、数据分析与挖掘的公共层。
E、维度层
维度是对具体分析对象的分析角度，维度要具备丰富的属性，历史信息的可追溯性，对通用的维表要保持一致性。分为公共维度和个性维度。公共维度有数据资产部建设和维护，个性维度各自建设和维护。
F、敏感处理层
G、数据补录层
H、数据集市层
某部门或某些特定用户因特定应用目的而设计创建的数据集，集市分为共享集市和非共享集市；共享集市可对非共享集市提供服务，共享集市间不允许直接共享数据； 非共享集市间不允许直接共享数据，须通过下沉“共性加工层”方式进行数据共享。
每个集市逻辑上分为基础层和应用层。基础层由数据资产部与业务团队共建；应用层由业务团队依据应用目的自建；
各部门业务需求通过各自集市提供服务，原则上不允许直接使用仓库层数据。
功能定义：即 DataMart，这里的 X指代变量，用于某部门或些特定户因应目的而建数据。
六、全量表，增量表，拉链表，流水表，快照表
A、全量表
大部分美团侧的同步方式采用全量表，全量表无分区，每天凌晨流程执行完后，表中数据是截止到前一天的mysql数据。
B、增量表
按天分区，分区字段为dt=YYYYMMDD，每一天的分区会存放mysql在那一天所产生的增量数据（insert，update的数据），注意目前增量表的同步方式不会包含历史数据，即只存放增量数据。对于源系统每天抽取的一部分数据，通常来说抽取的条件，数据的创建日期或者更新日期等于当日。<日志类、交易流水类>
C、快照表
按天分区，分区字段为dt=YYYYMMDD，每一天的数据都是截止到那一天mysql的全量数据。适用于业务系统的汇总，已下单、已付款、已出库，每天的这个状态都会得到记录。
D、拉链表（多为增量拉链，多在ODM层进行，用户的属性表、注册信息等）
维护历史状态，以及最新状态数据的一种表，拉链表根据拉链粒度的不同，实际上相当于快照，只不过做了优化，去除了一部分不变的记录而已,通过拉链表可以很方便的还原出拉链时点的客户记录。（4712 传统。。。）
E、流水表
对于表的每一个修改都会记录，可以用于反映实际记录的变更。
- 拉链表通常是对账户信息的历史变动进行处理保留的结果；拉链表用于统计账户及客户的情况。
- 流水表是每天的交易形成的历史；流水表用于统计业务相关情况。
七、存储策略
- I （增量）：每日一个增量数据分区、适用于日志及交易流水等信息。
- A（全量）：保留最新一份儿全量数据、适用于无变化的维度或者不关注变化的数据存储。
- S（快照）：是“A”的扩展、每日一个全量数据分区、适用于台账表等业务系统的汇总信息等。
- H（拉链）：适用于缓慢变化维如用户账户信息等需要保存轨迹变化类的数据。
八、字段类型
STAGE、ODM、IDM字段类型原则上只允许使用以下3种：bigint、decmail、string。SDM及各集市字段类型可以使用HIVE支持的任何类型。
1、bigint：数量、次数、人数等整数字段。
2、decmail(30,6)：金额、比率等小数字段。一般情况下使用所示精度，入仓调研时的特殊情况视具体而定。
3、string：订单编号、SKU编号、描述类信息等字符字段 注:流量等特殊情况下可以使用MAP等复合类型，但需要事先知会数据仓库组。
高频词根术语表
| 名词中文名 | 名词英文名 | 缩写 |
|---|---|---|
| pin | user_pin | user_pin |
| 交易 | transact/transaction | tx |
| date_format | product | prod |
| 商户、商家 | merchant | mht |
| distanceCalculator | 距离计算 | fst |
| 业务类型 | business_type | biz_type |
| 交易渠道 | order_channel | ordr_chnl |
| 流量 | 过滤特殊字符 | brs |
| 风控 | risk | risk |
| 商户编码 | merchant_code | mht_code |
| 分期 | stage | stg |
| 授信 | credit | crdt |
| 贷款 | loan | loan |
| 余额 | balance | bal |
