数仓笔记
数仓规范
1 定义
数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。 为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。
元数据是描述数据仓库内数据的结构和建立方法的数据。可将其按用途的不同分为两类，技术元数据和商业元数据。
技术元数据是数据仓库的设计和管理人员用于开发和日常管理数据仓库用的数据。包括：数据源信息；数据转换的描述；数据仓库内对象和数据结构的定义；数据清理和数据更新时用的规则；源数据到目的数据的映射；用户访问权限，数据备份历史记录，数据导入历史记录，信息发布历史记录等。
商业元数据从商业业务的角度描述了数据仓库中的数据。包括：业务主题的描述包含的数据、查询、报表；
元数据为访问数据仓库提供了一个信息目录（informationdirectory），这个目录全面描述了数据仓库中都有什么数据、这些数据怎么得到的、和怎么访问这些数据。是数据仓库运行和维护的中心，数据仓库服务器利用他来存贮和更新数据，用户通过他来了解和访问数据。
数据集市是从数据仓库中独立出来的一部分数据，针对用户特定需求得出的
信息发布系统，把数据仓库中的数据或其他相关的数据发送给不同的地点或用户。基于Web的信息发布系统是对付多用户访问的最有效方法
商业智能（Business Intelligence，简称：BI），又称商业智慧或商务智能，指用现代数据仓库技术、线上分析处理技术、数据挖掘和数据展现技术进行数据分析以实现商业价值。
联机分析处理OLAP是一种软件技术，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。它具有FASMI(Fast Analysis of Shared Multidimensional Information)，即共享多维信息的快速分析的特征。其中F是快速性(Fast)，指系统能在数秒内对用户的多数分析要求做出反应；A是可分析性(Analysis)，指用户无需编程就可以定义新的专门计算，将其作为分析的一部 分，并以用户所希望的方式给出报告；M是多维性(Multi—dimensional)，指提供对数据分析的多维视图和分析；I是信息性(Information)，指能及时获得信息，并且管理大容量信息。
联机事务处理(OLTP)是指利用计算机网络，将分布于不同地理位置的业务处理计算机设备或网络与业务管理中心网络连接，以便于在任何一个网络节点上都可以进行统一、实时的业务处理活动或客户服务。
维度建模是一种将数据结构化的逻辑设计方法，它将客观世界划分为度量和上下文。度量是常常是以数值形式出现，事实周围有上下文包围着，这种上下文被直观地分成独立的逻辑块，称之为维度。它与实体-关系建模有很大的区别，实体-关系建模是面向应用，遵循第三范式，以消除数据冗余为目标的设计技术。维度建模是面向分析，为了提高查询性能可以增加数据冗余，反规范化的设计技术。
事实表是数据仓库结构中的中央表，它包含联系事实与维度表的数字度量值和键。事实数据表包含描述业务（例如产品销售）内特定事件的数据。
维度表是维度属性的集合。是分析问题的一个窗口。是人们观察数据的特定角度，是考虑问题时的一类属性，属性的集合构成一个维。
粒度是指保存数据的细化或综合程度的级别。根据业务处理流程来确定粒度，粒度影响数据仓库中的数据量大小。粒度可以分为两种形式：1.按时间段综合数据的粒度，2.按采样率高低划分的样本数据库
2 操作性系统和DW/BI系统
信息是企业最核心的财产之一。信息总是用于以下两个目的，保存操作记录，和通过分析做出决策。简单来说，操作性系统（operational system）是用来存放数据的地方，DW/BI系统是取出数据的地方。
操作性系统可以比喻为推动企业运作的车轮。操作性系统执行企业的商务流程，反复进行类似的操作，如下订单，注册新用户，监控操作行为的转台，记录客户抱怨等。企业会优化操作性系统使之能够更快的处理事务。操作性系统通常不保存历史状态，而是更新数据以反映当前的状态。
另一方面，DW/BI系统则让企业的车轮转向效益评估。DW/BI系统统计订单数，并和上一周的订单作对比，寻找客户注册的原因和导致客户抱怨的因素。DW/BI系统关注操作过程是否正确。DW/BI系统不会只关注某一个事务，而是通过分析大量事务为问题寻求答案。因此，DW/BI系统会不断被优化以实现海量数据的高性能的查询。对于更复杂的需求，DW/BI系统用户还往往会要求保留历史数据，从而准确的评估企业效益随时间的变化。
3 DW/BI系统的目标
1 DW/BI系统应当使信息更容易获取。DW/BI系统的内容必须易于理解。数据必须对业务人员直观明了，而不仅是对于开发人员。数据结构和标签应当和业务人员的思考逻辑、用词一致。业务人员需要将熟悉数据用无数种方式分拆或是合并。BI工具和应用程序应当能通过简单易用的方式访问数据。BI系统还应当在最短的时间内返回用户查询结果。这可以总结为：简单，快速。
2 DW/BI系统呈现的数据必须一致。DW/BI系统中的数据必须可靠。应当谨慎的组合来自不同源头的数据，清洗，校验质量，并且只有在满足用户使用的情况下释放。一致性也要求跨多个数据源的情况下，DW/BI系统的标签和定义具有相同的含义。如果两个度量具有相同的名字，那么他们就表示完全相同的事物。反过来讲，如果如果两个度量表示不同的事物，他们应当打上不同的标签。
3 DW/BI系统必须能够应对变化。用户需求，业务条件，数据，和技术都面临着随时变化的可能。设计DW/BI数仓时，必须确保其能够稳定的处理必然会发生各种变化，从而避免已有数据和应用的失效。当团队提出新问题，或者有新数据增加到数仓中时，已有的数据和应用不应当发生改变或是被打乱。最后，如果DW/BI中的描述性数据必须被修改，应当合理处理这类变化，使这些变化对用户透明。
4 DW/BI系统所呈现的数据必须具有实时性。为了更好的支持决策的制定，DW/BI系统的使用越来越频繁，原始数据可能需要在小时级，分钟级，甚至秒级的时间段内转变成可执行的信息。当没有充分的时间对数据进行清洗或验证时，DW/BI团队和业务人员应当对数据的交付可能导致的结果有现实的预期。
5 DW/BI系统必须保证信息安全。企业的信息财富都保存在数据仓库中。至少，仓库中保存了你将以什么价格将产品卖给那些客户——如果落在错误的人手中，可能会对公司造成损失。DW/BI系统必须有效的控制企业的涉密信息。
6 DW/BI系统必须为决策持续改进提供权威的、可信赖的基础。数据仓库必须存放正确的数据以支持决策。DW/BI系统最重要的产出，是通过分析证据做出的决策；这些决策对业务产生冲击或是价值，而这些都归因于DW/BI系统。早于DW/BI的原始标签很好的描述了你要设计什么：一个支持决策的系统。
7 DW/BI系统必须以被业务群体所接受作为其成功的标志。DW/BI系统的成功与否不在于你是否采用了最好的产品和平台构建出一个优雅的方案。如果业务群体没有接受DW/BI系统并活跃的使用它，你的工作就是失败的。不同于操作性系统，业务人员除了使用新系统别无选择，DW/BI系统有时是可选的。业务人员只有当一个DW/BI系统能够为可执行信息提供“简单，快速”的来源时，才会接受它。
4 星型模型和OLAP立方体
采用关系型数据库管理系统创建的维度模型被称之为星型模型，因为具有星型结构。采用多维度数据库环境创建的唯独模型称之为联机分析（OLAP）立方体。
部署数据到OLAP立方体时，要考虑以下几个问题：
■ 关系型数据库中持有的星型模型为创建OLAP立方体提供了很好的物理基础，通常被用作更稳定的备份和恢复的基础。
■ 传统上认为OLAP立方体比RDBMS有更好的性能优势，但是随着计算机硬件的发展如内存数据库或RDBMS软件如列式数据库，这一性能上的差别变得不那么重要。
■ OLAP对于不同的服务商而言差异更大，因此最终部署的细节常常取决于所选择的服务商。通常来说，在不同的OLAP工具上移植BI系统要比在不同的关系型数据库上移植BI系统困难。
■ 相比于RDBMS，OLAP立方体能提供更加精细的安全控制，比如限制对具体数据访问的同时开放对汇总数据的访问。
■ OLAP立方体提供了比RDBMS更丰富的分析能力，RDBMS的查询通常受限于SQL。这可能是采用OLAP的主要因素。
■ OLAP立方体支持缓慢渐变维度类型2的变化，但是当使用缓慢渐变维度技术重写数据时，经常需要部分的甚至全部的对数据再次处理。
■ OLAP支持事务和周期性快照事实表，但是受限于上一处提到的重写数据（的不足），不能处理累积快照事实表。
■ OLAP立方体采用优于RDBMS所需方法的自身查询语法，通常支持不规则、深度不定的层次体系，比如组织架构图或材料订单。
■ OLAP可能对维度主键结构施加细节的限制，从而实现类似于关系型数据库的向下钻取层次体系。
■一些OLAP产品不启用维度角色或别名，因此需要分别定义物理维度。
5 用于测评的事实表
在维度模型中，事实表存储了对业务处理事件的结果测量。在一个单独的维度模型中，应当尽可能的存储业务处理的低级测量数据。因为测量数据无疑是数据量最大的数据集，因此这些数据不应当在企业中不同的部门之间做多个副本。应当允许公司不同组织的业务人员从单一中央数据源获取测量数据集。
关于事实表的一些特点：
事实代表一次业务测量，事实表的每一行都对应一个测量事件。
最有用的事实都是数字的、可加的。BI应用很少只是用一条事实记录，而是一次性处理成千上万条记录，最有效的做法就是对这些记录进行累加。
事实常常被描述成连续值，从而在维度属性中找出事实。
理论上说测量的事实有可能是文本的。
所有的事实表有两个或多个外键，通常主键是由外键的子集组成的。
6 用于表述上下文的维度表
维度表描述了与事实相关的“谁，什么，哪里，何时，如何，为何”。
维度属性是查询约束，分组，报告标签的主要来源。
属性应当由实际词汇组成而不是隐晦的缩写。应当尽可能少的在维度表中使用编码，而使用更详细的文本属性。已经通过培训使业务人员记住了操作编码，也要更进一步的减少他们对编码翻译笔记的依赖。应该对操作编码制定标准解码方法，从而可以中编码中获取维度属性，并且为查询，报告和BI应用提供统一的标签。
有些编码或者标识对用户而言具有法律上的重要意义，或者需要重新输入要操作性系统中使用。在这些情况下，除了相应描述信息，编码应当展现成明白无误的维度属性。如果操作编码中包含了信息，比如最后两位代表地区，应当提取出被包含的信息并以单独的维度属性展示给用户，从而使用户可以轻易的进行过滤，分组和报告操作。
7 事实表和维度表组成星型模型示意图
8 Kimball’s DW/BI构架
Operational Source Systems：
操作性系统捕捉业务中的事务。源系统位于数据仓库之外，因为你对操作性系统中的数据及格式有很少甚至没有权限。源系统的首要工作是保证数据处理的性能和可用性。在源数据上进行的操作性查询，一般都是正常事务操作的一部分，严格受限于操作系统，查询范围小、逐条的查询。可以认为源系统上不会实施在DW/BI系统上通常进行的大范围的或其他不常见的查询。源系统几乎不保留历史数据。多数情况下，源系统都有专门的用途，不会与其他操作性系统共享数据。
Extract, Transformation, and Load System：
E 读取，理解元数据并复制数据进入所需的ETL系统，为进一步操作做准备。这一刻起，数据属于数据仓库。
T 数据提取进ETL系统后，有无穷种变化的可能，比如清洗数据（修正错误的拼写，解决域名冲突，处理丢失的元素，解析成标准格式），从多个数据源组合数据，去重等。ETL系统在数据清洗和确认作业中，对数据进行修正和加强。此外，这些活动可以用来构建诊断性的元数据，最终指导业务过程优化从而提高源系统的数据质量。
L 在物理上构建并加载数据到展示区域的目标模型。
展示区域：数据经过组织，排序，并且可以被用户，报告人，其他BI分析应用直接查询。对于展示区域的数据，应当采用星型模型或OLAP立方体，以维度模型展示，存储，引用；应当包含细节的，原子的数据，而不能仅仅存储汇总数据；展示区的数据应当围绕着业务过程测评事件结构化；维度结构必须使用通用的，可靠的维度，依附企业数据仓库总线架构。
1 数仓层级
数仓层级共分为5级，分别为Operation Data Store（ODS） 数据引入层，data warehouse detail（DWD），data warehouse service（DWS），Application Data Store（ADS），dimension table(DIM)；其中前四个属于事实表，且后一层级的数据依赖前一层级。DIM为维度表，为事实表按不同维度提供详细描述信息；DIM数据数仓的辅助数据，有时也不被划分到数仓中。
功能上5个层级分别对应存储业务库原始数据，数据清洗，宽表生成，报表数据以及维度描述。
- ODS层：ODS层属于操作数据层，是直接从业务系统采集过来的最原始的数据，包含了所有业务的变更过程，数据粒度也是最细的。对于ODS层的数据，应当尽可能的保持与业务数据的一致，包括脏数据和敏感信息。必要的话可以进行数据格式的转换，但不应当修改数据内容。
- DWD层：对ODS层数据进行数据清洗，包括去除空值，脏数据，对敏感数据加密，修改存储格式等。从DWD层开始数仓数据将直接面向业务人员，因此必须去除脏数据避免业务人员使用过程中产生困惑，加密敏感数据以保证数据安全。此外，为了提高查询效率，将行存储改为列存储，选择合适的数据压缩格式，也是必要的。
对于清洗的脏数据应当反馈给业务人员，并判断是否有改进操作性系统的必要。 - DWS层：将DWD的数据整合汇总成分析某一个主题域的服务数据，一般是宽表，以便之后关联用户维度信息后进行，从不同角度进行统计分析。
- ADS层：ADS层数据是根据具体的报表需求，提取所需的数据并与维度表进行关联生成的。ADS层数据最终需要导入业务的关系型数据库中。
- DIM层：存储一些诸如省、市、县区域表、渠道列表、商品类目等等表数据，为数据计算提供统一的计算口径，同时也可以各个维度驱动建模。
2 数仓命名规则
为了避免数据库过多，数仓分为ods，dwd，dws，ads，dim五个数据库。数据表按照表来源，表面向域等因素命名。
DIM层的数据是独立于数仓事实表的维度数据，统一存储在dim数据库中，各个表的命名应当与公司采用，定义的维度表相同。如全国行政地区代码表，用于关联行政编码及地名，命名如下dim. administrative_area_code。
ODS层表命名
ODS层数据与输入业务库为一一对应的关系，命名规则如下：
ods.ods_{业务库名}_{业务库原始表名}[_备注]
假设mysql数据库user库中存在user_register_info表，导入ods层时应当命名为
ods. user_user_register_info_用户注册信息表
dwd与ods层表一一对应，命名规则相同
dwd. user_user_register_info_去除手机等敏感信息
DWS层数据为针对某一主题，由不同业务表关联生成的宽表，命名规则如下：
dws_ {主题域标签}_{自定义表名}[备注}
假设为了分析用户活跃度，关联用户注册信息表及登录信息表计算用户留存率，生成的流程率表可以如下命名：
dws.activity retention_rate_用户留存率
3 数据同步
数据同步指业务库到ods的阶段，按同步数据范围可分为增量同步和全量同步，按照时效性可以分为离线跑批同步和实时同步。常用的同步方法有：
1 从业务库（通常为关系型数据库）采用sqoop，spark每次同步T-1的数据到数据仓库。这种方法通常以同步日期作为分区，数据延迟较高。且不适用于数据会修改的业务库表，因为只能保存数据被同步时的状态，而无法两次同步之间数据被修改的状态。
以上方法也可以用于mangodb，hbase等非关系型数据库。
2 实时同步。同时同步按照采集方法的不同，常用的方法有以下两种：
a) Cannal采集mysql binlog，发送kafka，kafka消费数据并写入hdfs。这种方法的优点在于：cannal实施消费binlog，延迟几乎可以忽略不计。可以捕获数据的update操作，并将更新的数据按照update时间写入hdfs，避免了数据中间状态的丢失。
缺点：数据操作复杂度较高，通常额外需要将同一条记录的更新状态按天累加，获取当天记录的最终状态；实时写入存在数据丢失、数据重复等问题，具体解决方法见流计算—数据一致性语义。
b) App直接采集数据并发送kafka，之后可直接写入hdfs或通过spark对数据进行处理后写入hdfs。
c) Flume等其他数据采集工具直接将数据采集到hdfs。
同步过程可以对数据进行清洗加密，经过清洗的数据可以直接写入dwd层而不必存入ods层。但是同步过程不应当对其他数据内容进行任何修改。
4 hive建表规范
分隔符：分隔符限定使用hive默认分隔符\u0001。
文件格式：常用文件存储格式包括：TEXTFILE、Parquet、ORC。其中TEXTFILE为默认格式，导入数据可以直接将文本文件导入hdfs系统上。Parquet、ORC格式的数据要先导入到TextFile格式的表中，然后再从TextFile表中用insert导入到Parquet、RCFile表中。
在生产中，尽量使用TEXTFILE、Parquet、ORC格式，建议ods使用TEXTFILE，原因：1，ods数据有时需要将外部文件系统的文本文件直接上传到相应的文件夹中，或通过mapreduce编程将文件直接写入，采用textFile降低文本处理的难度。
其余层级建议使用orc或parquet格式，orc及parquet格式均为列式存储，查询效率高。
压缩方法： 常用的压缩方法有bzip2, gzip, lzo, snappy等，压缩比：bzip2>gzip>lzo bzip2最节省存储空间，解压速度：lzo>gzip>bzip2> lzo解压速度是最快的。建议使用以下组合：textfile+bzip2，orc/parquet+snappy。注意，gzip和snappy文件不支持split，会降低MapReduce并行度。使用这类压缩方法时，应当避免生成文件过大。
分区表和分通表
为了对表进行合理的管理以及提高查询效率，Hive可以将表组织成“分区”。一个分区实际上就是表下的一个目录，一个表可以在多个维度上进行分区，分区之间的关系就是目录树的关系。
常用的分区表划分方法有按日期或按项目编号，存在多个分区字段时，日期分区放在最后。采用分区表时，应考虑一下几个问题：
1：搜索时where子句常用的搜索字段是否为分区字段一致；2：分区后是否会导致各个分区内文件过小；3：是否需要嵌套分区
建表时分区字段应当在备注上指明分区字段的定义，如p_etl_date表示该分区字段对应采集日期，p_业务库字段 表示按照业务库字段进行分区，如p_create_date=2019-06-30表示该分区存储对应业务表在2019-06-30创建的数据。
分桶是相对分区进行更细粒度的划分。分桶将整个数据内容安装某列属性值得hash值进行区分，如要安装name属性分为3个桶，就是对name属性值的hash值对3取摸，按照取模结果对数据分桶。分通表适用于需要做join的大表，可以有效提高Join效率。分通表在到导入数据时效率较低，只建议在存在大表join操作的情况下使用分通表。
分桶的数量尽量选取2,4，8等数字，有助于采样操作。
5 hive常用的优化方法
5.1 hive简介
Apache Hive是一个基于Hadoop的开源数据仓库。专门用于查询和分析以Hadoop文件形式存储的海量数据。使用Hive可以处理Hadoop上结构化或半结构化的数据。
换句话说，Hive是一个辅助查询和管理存储在分布式存储系统上的数据的工具。必要的，Hive提供了类似于SQL语句的HiveQL(Hive Query Language)。
此外，Hive的一个编译器会把HiveQL语句翻译成MapReduce作业。进而提交给Hadoop平台执行。
Hive不是：
Hive不是一个关系型数据库
Hive不适用于联机事务处理
甚至不支持实时查询和行级更新
Hive架构图
Hive数据模型
Hive数据模型可以分为三种：
Table 表
Parition 区
Bucket 桶
表
A 管理表
当把数据加载到管理表，Hive将数据移动到Hive数仓的目录中。执行删除表操作时，会将表的数据和元数据一起删除。
CREATE TABLE managed_table (dummy STRING);
LOAD DATA INPATH ‘/user/tom/data.txt’ INTO table managed_table;
DROP TABLE managed_table
B 外部表
外部表由用户管理数据的创建和删除。外部数据的位置在表创建时指定。Hive并不会将数据移动到数仓目录，甚至在定义表时不会检查外部位置是否存在。
当删除外部表时，Hive不会检查数据而仅仅是删除元数据。
CREATE EXTERNAL TABLE external_table (dummy STRING)
LOCATION ‘/user/tom/external_table’;
LOAD DATA INPATH ‘/user/tom/data.txt’ INTO TABLE external_table;
分区
Hive根据列和分区的键值，将相同类型的数据划分为一组并分发到分区中。每一张hive表可以具有一个或多个分区键以标识一个特定的分区。使用分区，可以让用户更快的查询数据切片。
HQL查询where条件与分区键一致时，Hive只会加载对应的目录下的数据，避免全表扫描。
i. Hive Static Partitioning
静态分区
将输入数据分别插入一个分区是静态分区
通常当加载文件（大文件）进入Hive表中，静态分区更合适
静态分区加载文件时比动态分区更快
你需要“静态”的给表格增加一个分区，并将文件移动到表的分区中
你可以修改静态分区中的分区
你可以通过文件名获得分区列的值，比如日期是哪一天而不需要读取整个大文件
如果你希望在hive中使用静态分区你应该设置hive.mapred.mode = strict。这是hive-site.xml中的默认设置。
静态方法处于静态模式
You should use where clause to use limit in the static partition.
在静态分区中应该通过使用过where子句使用limit
你可以在Hive管理表和外部表中使用静态分区。
ii. Hive Dynamic Partitioning
动态分区
一次性向分区表各个分区插入数据也就是动态分区
通常，动态分区从非分区表加载数据
如果您有一个存储有大量数据的表，那么就适合使用动态分区
如果你需要按照诺干个列进行分区，但是你不知道列的具体数目这种情况适合使用动态分区
动态分区不需要通过where子句使用limit
我们不能修改动态分区
在hive外部表和管理表上都可以使用动态分区
如果需要是使用动态分区，那么hive的模式应当是non-strict模式。
分桶
在Hive中，表或分区可以根据某一个列的hash值分发到不同的桶中，由此获得的结构可能提供更高效的查询。
Hive中每一个桶对应表目录或分区目录中的一个文件。
对比非分桶表，分桶表提供高效的取样。
分桶表上做Map端join快于非分桶表，因为数据文件被分割成大小接近的部分。
类似于分区表，分桶表能够提供更快的查询速度。
分桶允许对桶中的数据按照某列，或者某些列排序
因为桶join变成了高效的合并排序，使得map端join更加高效。
Hive数据类型
Hive常用的优化设置及原理
- Map输入合并小文件
对应参数：
set mapred.max.split.size=256000000; #每个Map最大输入大小
set mapred.min.split.size.per.node=100000000; #一个节点上split的至少的大小
set mapred.min.split.size.per.rack=100000000; #一个交换机下split的至少的大小
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; #执行Map前进行小文件合并
在开启了org.apache.hadoop.hive.ql.io.CombineHiveInputFormat后，一个data node节点上多个小文件会进行合并，合并文件数由mapred.max.split.size限制的大小决定。
mapred.min.split.size.per.node决定了多个data node上的文件是否需要合并~
mapred.min.split.size.per.rack决定了多个交换机上的文件是否需要合并~
2.输出合并
set hive.merge.mapfiles = true #在Map-only的任务结束时合并小文件
set hive.merge.mapredfiles = true #在Map-Reduce的任务结束时合并小文件
set hive.merge.size.per.task = 25610001000 #合并文件的大小
set hive.merge.smallfiles.avgsize=16000000 #当输出文件的平均大小小于该值时，启动一个独立的map-reduce任务进行文件
3.有数据倾斜的时候进行负载均衡（默认是false）
hive.groupby.skewindata = true
当选项设定为 true，生成的查询计划会有两个MR Job。第一个MR Job中，Map的输出结果会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同的Group By Key有可能被分发到不同的Reduce中，从而达到负载均衡的目的；第二个MR Job再根据预处理的数据结果按照Group By Key分布到Reduce中（这个过程可以保证相同的Group By Key被分布到同一个Reduce中），最后完成最终的聚合操作。
- set hive.optimize.skewjoin=true;
set hive.skewjoin.key=100000;
