数据仓库的基础知识

数据仓库

背景

1、数仓是什么，其实就是存储数据，体现历史变化的一个数据仓库。因为互联网时代到来，基于数据量的大小，分为了传统数仓和现代数仓。

2、传统数仓，使用传统的关系型数据库进行数据存储，因为关系型数据库本身可以使用SQL以及函数等做数据分析。所以把数据存储和数据分析功能集合为一体，加上一个可视化界面，就能从数据存储，数据分析，数据展示完整方案。

3、到了互联网时代，由于上网用户剧增，特别是移动互联网时代，海量的网络设备，导致了海量的数据产生，企业需要也希望从这些海量数据中挖掘有效信息，如行为日志数据，业务数据，爬虫数据等等中提炼出有价值信息。但传统的关系型数据库由于本身技术限制，无法很好承担这么大数据量存储和分析的任务，现代大数据技术应运而生。而数仓就是做这些海量数据存储的地方。

经典数仓分层架构

ADS：应用服务层

DWS：数仓汇总层

DWD：数仓明细层

ODS：操作数据（最原始的数据）层 ——— 贴源层

DIM层：存储维表

ODS层：对应着外部数据源ETL到数仓体系之后的表！

DWD层：数仓明细层；一般是对ODS层的表按主题进行加工和划分；本层中表记录的还是明细数据；

DWS层：数仓汇总层；

ADS层：应用层，主要是一些结果报表！

分层的意义：数据管理更明晰！运算复用度更高！需求开发更快捷！便于解耦底层业务（数据）变化！

数据运营层（ODS）

Operation Data Store 数据准备区，也称为贴源层。数据仓库源头系统的数据表通常会原封不动的存储一份，这称为ODS层，是后续数据仓库加工数据的来源。

ODS层数据的来源方式：

业务库
- 经常会使用sqoop来抽取，例如每天定时抽取一次。
- 实时方面，可以考虑用canal监听mysql的binlog，实时接入即可。
埋点日志
- 日志一般以文件的形式保存，可以选择用flume定时同步
- 可以用spark streaming或者Flink来实时接入
- kafka也OK
消息队列：即来自ActiveMQ、Kafka的数据等。

主要作用：直接映射操作数据（原始数据），数据备份；
建模方法：与原始数据结构保持完全一致
存储周期：相对来说，存储周期较短；视数据规模，增长速度，以及业务的需求而定；对于埋点日志数据ODS层存储，通常可以选择3个月或者半年；存1年的是土豪公司（或者确有需要）

数据仓库层（DW）

DW数据分层，由下到上为DWD，DWB，DWS。

DWD: data warehouse details 细节数据层，是业务层与数据仓库的隔离层。主要对ODS数据层做一些数据清洗和规范化的操作。
1. 数据内容:对ODS层数据做ETL处理后的扁平化明细数据
2. 存储格式:以orc/parquet文件格式存储
3. 存储周期6个月
数据清洗：去除空值、脏数据、超过极限范围的
DWB: data warehouse base 数据基础层，存储的是客观数据，一般用作中间层，可以认为是大量指标的数据层。
DWS: data warehouse service 数据服务层，基于DWB上的基础数据，整合汇总成分析某一个主题域的服务数据层，一般是宽表。用于提供后续的业务查询，OLAP分析，数据分发等。
用户行为，轻度聚合
- 主要对ODS/DWD层数据做一些轻度的汇总。

数据服务层/应用层（ADS）

ADS：applicationData Service应用数据服务，该层主要是提供数据产品和数据分析使用的数据，一般会存储在ES、mysql等系统中供线上系统使用。
- 我们通过说的报表数据，或者说那种大宽表，一般就放在这里

1、其实数仓数据分层，就跟代码分层一样。如果所有数据都放在一层，就跟代码都放在一个文件，肯定是可以运行的，但带来的问题就是阅读性差，复用性和维护性降低。

数仓的分层也是一样，每一层都有自己的职责，同时都是基于下一层或者下面多层做数据处理之后的结果。
这样一来，最上层就是ADS，数据应用层，当更上层需要数据时，不需要再从最底层进行数据计算，可以复用中间层级的现有结果，可以提升数据处理速度。
同样的，因为更上层数据都是从下一层或者下面多层数据处理而来，这样就算下层数据丢失，也不会造成企业所有数据毁灭性灾难，算是一种数据冗余机制，不过更上层数据一般做了数据处理，提升了维度信息。

2、需要注意，大数据的特点之一就是海量数据，但是数据价值密度较低。
使用数据分层机制，相当于提炼黄金的流程，逐步逐步将有价值信息进行汇总聚合，这样就跟分步操作一样，最终提炼出想要的结果。同时就算原始数据丢失了，只要中间结果还在，依然可以保证最上层数据的稳定性。类似加了一层缓冲一样。

3、大数据的特点，海量数据，这其实带来了较大的存储压力。将数据进行分层之后，最原始的数据存储周期就可以适当降低，这样可以降低存储压力。而更上层的数据，因为都是加工后的数据，数据量相对较少，存储压力就会小一些，存储周期也就可以长一些。

综上，道理其实都是相通的，数据分层最终遵循的还是很朴素的道理。降低存储压力，降低企业使用成本，复用中间数据结果，提升数据处理速度。逐步处理，这样可以更加灵活应对企业开发需求，不需要所有需求都从数据量最大的ODS层进行数据处理。

模型设计

3.1 ODS层

1、这一层又叫做贴源层，就是接近数据源的一层，需要存储的数据量是最大的，存储的数据也是最原始，最真实未经过太多处理的数据。

2、按照目前大数据企业开发的数据来源来看，不管是爬虫数据，日志数据还是业务数据，都会有一层ODS层，存放最原始的数据。

3、注意，ODS层数据还起到一个数据备份作用，如果是比较特殊行业，在ODS层的数据会保留一年甚至多年。不过普通公司一般就保存3–6个月，看数据量和存储压力以及存储预算决定。

4、日志数据估算，如日活100万用户，每个用户访问1次，每次操作5min，每个用户平均3秒一条日志数据，一条数据1kb。最后体积是100w1560/31kb=100w*100kb=97656.25MB=95.36GB;

注意，数据估算最好结合公司实际情况，如果已经运行一段，可以让运维同事帮忙做估算
因为数据本身可以做压缩，数仓数据还需要做分层，数据本身存储时还会有备份机制(HDFS\Kafka等框架)
数据还会源源不断增长，同时磁盘还需要预留一定缓冲空间，一般是30%缓冲空间。所以除非是新建项目或者遇到超快速增长的公司，一般的大数据容量评估都是按照最高上限做半年甚至一年总容量做评估的。
注意，在服务器领域，磁盘的成本相对CPU\内存来说，成本是相对最低的，甚至有专门的存储服务器，如24硬盘位，甚至48硬盘位的服务器。
而2020年先在已经开发出了单磁盘12TB甚至14TB的企业硬盘，这意味着单节点机器容量上限进一步提升，存储成本也随着技术提升，成本开始降低下来。

5、ODS中数据不意味着里面的数据就是最原始没经过处理的。一般企业开发，因为真实环境中数据上报，存储，采集中错误，bug，网络等问题，会造成原始数据的各类问题。

字段缺失
数据字段不统一
格式错误
关键信息丢失等等
数据来源混杂
数据类型不一，例如json，xml，text，csv的，压缩了的，没有压缩的等等。

6、一般企业开发时，都会对原始数据存入到ODS时，做一些最基本的处理

数据来源区分
数据按照时间分区存储，一般是按照天，也有公司使用年，月，日三级分区做存储的
进行最基本的数据处理，如格式错误的丢弃，关键信息丢失的过滤掉等等。

注意，有的公司ODS层不会做太多数据过滤处理，会放到DWD层来处理。
有的公司会在一开始时就在ODS层做数据相对精细化的过滤。这个并没有明确规定，看每个公司自己的想法和技术规范

7、ODS层建立表时，如果使用hive进行处理，一般建立外部表。

hive的外部表，对应的是业务表;
hive外部表，存放数据的文件可以不是在hive的hdfs默认的位置，并且hive对应的表删除时，相应的数据文件并不会被删除。这样对于企业开发来说，可以防止因为删除表的操作而把宝贵的数据删除掉
hive的业务表，则相反。数据文件存放在hive对应的默认位置，表删除时，对应文件也会被删除掉。

3.2 DWD层

1、按照建模思想，不完全星型建模。注意，所有的框架实际实现时，都不会按照理想方式去实现，都会在实现成本，复杂度，性能，指标等方面综合考虑。

2、DWD又叫做数据明细表，很多时候存储的都是事实表为主。

3、在DWD层，会有ETL，也就是extract transform load 提取转换加载处理，逻辑会比较复杂，这时候如果使用hive，一般无法满足要求，这些逻辑一般都是编写代码实现，然后使用脚本进行周期性如每天调用。

1。去除废弃字段，去除格式错误的信息

2。去除丢失了关键字段的信息

3。去除不含时间信息的数据(这个看公司具体业务，但一般数据中都会带上时间戳，这样方便后续处理时，进行时间维度上信息分析处理和提取)

4。有些公司还会在这一层将数据打平，不过这具体要看业务需求。这是因为kylin适合处理展平后数据，不适合处理嵌套的表数据信息。

5。有些公司还会将数据session做切割，这个一般是app的日志数据，其他业务场景不一定适合。这是因为app有进入后台模式，例如用户上午打开app用了10分钟，然后app切入后台，晚上再打开，这时候session还是一个，实际上应该做切割才对。(也有公司会记录app进入后台，再度进入前台的记录，这样来做session切割)

6。数据规范化，因为大数据处理的数据可能来资源公司不同部门，不同项目，不同客户端，这时候可能相同业务数据字段，数据类型，空值等都不一样，这时候需要在DWD层做抹平。否则后续处理使用时，会造成很大的困扰。

简单的，如boolean，有使用0 1标识，也有使用true false标识的
如字符串空值，有使用””，也有使用null，的，统一为null即可
如日期格式，这种就差异性更大，需要根据实际业务数据决定，不过一般都是格式化为YYYY-MM-dd HH:mm:ss 这类标准格式

4、注意，事实表中数据，一般不是所有维度都按照维度主键做信息存储。

维度退化，其实从代码角度来说，就是当一个代码写死之后，失去了灵活性，维度就退化了。
在数仓理论中，有几个经典思想，一个是去除数据冗余。所以一般会把维度信息单独存放，其他表要使用时，记录对应维度的id即可。
这样，就算维度表中数据发生了变化，其他表数据因为只是记录了id，不会有影响。
同时，维度信息放在一张表中存放，而不是每个表中存储一份，将来需要调整，只需要做一次工作即可，降低了数据冗余。
这一点和代码的实现和设计思想是一致的，不要重复造轮子。

5、在DWD层，一般还会做数据映射，

例如将GPS经纬度转换为省市区详细地址。

业界常见GPS快速查询一般将地理位置知识库使用geohash映射，然后将需要比对的GPS转换为geohash后跟知识库中geohash比对，查找出地理位置信息。

对于geohash感兴趣，可以看我另外一篇博文。

当然，也有公司使用open api，如高德地图，百度地图的api进行GPS和地理位置信息映射，但这个达到一定次数需要花钱，所以大家都懂的。

会将IP地址也转换为省市区详细地址。

这个有很多快速查找库，不过基本原理都是二分查找，因为ip地址可以转换为长整数。典型的如ip2region库

将时间转换为年，月，日甚至周，季度维度信息。

这样带来好处就是，后续业务处理时如果需要这些信息，直接使用即可。不过会一定程度增加数据量，但一般都还可以接收，增加并不多。
注意，数据映射一般只映射常见指标以及明确的企业开发中后续会用到的指标，因为数据量较大，如映射的指标后续用不到，只会平白增加开发，维护成本。

6、DWD存储数据，一般就是维度表，事实表，实体表等数据。

维度表，顾名思义，就是一些维度信息，这种表数据，一般就直接存储维度信息，很多时候维度表都不会很大。

事实表，就是表述一些事实信息，如订单，收藏，添加购物车等信息。这种数据量较大，同时因为数据可能快速或者缓慢变化，这种一般存储维度主键，具体维度值在后续处理分析时再临时关联。

实体表，类似javabean，用来描述信息的，如优惠券表，促销表。内部就是一些描述信息。这种一般看数据量以及变化程度，大部分时候都是全量导入，导入周期则看具体而定。

3.3 DWS层

1、DWS，俗称的数据服务层，也有叫做数据聚合层.不过按照经典数据建模理论，一般称之为前者，也就是数据服务层，为更上层的ADS层或者直接面向需求方服务。

2、DWS建模，一般使用主题建模，维度建模等方式。

主题建模，顾名思义，围绕某一个业务主体进行数据建模，将相关数据抽离提取出来。

如，将流量会话按照天，月进行聚合
将每日新用户进行聚合
将每日活跃用户进行聚合

维度建模，其实也差不多，不过是根据业务需要，提前将后续数据查询处理需要的维度数据抽离处理出来，方便后续查询使用。

如将运营位维度数据聚合
将渠道拉新维度数据聚合

3.4 ADS层

1、这是应用服务层，一般就直接对接OLAP分析，或者业务层数据调用接口了。
2、这是最顶层，一般都是结果类型数据，可以直接拿去使用或者展示的数据了。也是对数据抽离分析程度最高的一层数据。
3、这一层是需求最明确的一层，根据业务需求来决定数据维度和结果分析。类似代码最外层，接口是相对最固化的。

数据中台、数据仓库、大数据平台的区别是什么

针对企业内部来说，构建良好的数据管理系统和资产管理系统，在提供数据服务的方面能快速获取到所需的数据，同时也提供数据存储。

数据中台、数据仓库、大数据平台的关键区别是什么？

1、数据中台是企业级的逻辑概念，体现企业 D2V（Data to Value）的能力，为业务提供服务的主要方式是数据 API，即数据中台的服务对象是企业上下游的各类业务系统。

2、数据仓库是一个相对具体的功能概念，是存储和管理一个或多个主题数据的集合，为业务提供服务的方式主要是分析报表。数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它并不是所谓的“大型数据库”，而是一整套包括了etl、调度、建模在内的完整的理论体系，

3、大数据平台是在大数据基础上出现的融合了结构化和非结构化数据的数据基础平台，为业务提供服务的方式主要是直接提供数据集。

数据中台是在数据仓库和大数据平台的基础上，将数据生产为一个个数据 API 服务，以更高效的方式提供给业务，本质是一个构建在数据仓库之上的跨业务主题的业务系统。

其他补充

ETL

ETL ：Extract-Transform-Load，用于描述将数据从来源端经过抽取、转换、加载到目的端的过程。

宽表

含义：指字段比较多的数据库表。通常是指业务主体相关的指标、纬度、属性关联在一起的一张数据库表。
特点：
- 宽表由于把不同的内容都放在同一张表，宽表已经不符合三范式的模型设计规范：
  - 坏处：数据有大量冗余
  - 好处：查询性能的提高和便捷
- 宽表的设计广泛应用于数据挖掘模型训练前的数据准备，通过把相关字段放在同一张表中，可以大大提供数据挖掘模型训练过程中迭代计算的消息问题。