前言：
前文说了一些数据仓库的基础概念和模型，本文继续往下说吧！
【数仓】数据仓库的思考（一）：
1、数仓的目标（能完成什么事情）
当工作中遇到以下的事情：
-1.数据分层混乱，不知道从何查起
-2.数据指标维度不统一，业务/数据分析部门要数据，只能找数据开发口口相传
-2.数据建设缺乏规范，表结构字段定义不统一，字段含义模糊，数据任务、数据表维护成本高。
-3.重复计算同一个数据，浪费资源
通过搭建数仓，我们要完成的就是，数据分层，维度划分，指标口径确认，表名和字段统一（字段加注释），尽可能消除重复计算
不过要怎么量化目标完成了多少，好像不太容易
2、数仓的迭代
由于数仓是个大工程，很难一次性做完整
初期：稳定性和可用性
可用性就不说了，稳定性就是鲁棒性，提供的服务如果经常性的出问题，那么给使用者的印象就大打折扣，包括服务（hdfs，hive等相关组件的稳定），数据约定的推送时间，数据本身内容的稳定（数据质量）等
后期：高效性和易用性
高效我觉得就是上手成本，it行业，人流动性还是蛮高的，新来一个人，是否能快速熟悉数据的来源和流程，指标的生成规则，这是数仓的一个目的所在，易用性就是后期我们可能把很多东西做成服务了，比如元数据管理，数据质量监控，甚至自定义生成报表，那么这些服务的操作是否简便，是否容易上手，是评判数仓是否成熟的一个标准。
所以做数仓，并不只是把数据分层，整合，更关键的还要有配套的服务，元数据管理，数据质量监控，数据处理推送（界面化操作），数据流程报警等等，要完善整个数仓的生态环境，并不是一朝一夕立刻就能做完的。
3、数仓建设规范
百度下，各种图都有，我就来说说每层我想的东西吧！
-1.命名规范（建表/字段注释）
当然我也只是提出我们的方案，并不是说全世界都得统一，逻辑上说得通就行
表名规范：
ODS 落地层：
ods开头_原表名_其他信息（尽量保持字段和格式一直，方便检查数据问题）
DW层：（可以在表名中带上D,W,M,Y来标识表的日期维度）
（1）、DW明细层：dws_[日期维度]_主题域_其他信息
（2）、DW聚合层：dwa_[日期维度]_主题域_聚合维度_其他信息
DIM维度层：
dim_通用/主题域_维度_其他信息
TMP临时表：
tmp_[所属程序名/或者操作者缩写]_[自定义序号1…10]_主题域_其他信息
字段规范：
（1）、每个字段都要写注释
（2）、字段名禁止使用数据库保留字
（3）、小写字母，采用下划线分割
（4）、同一个字段在不同表，命名和类型统一
（5）、HIVE中尽量使用String
（6）、有小数点的字段，保留小数据后10位（这个可以根据各自产品需求，但是尽量统一，否则在做一些聚合操作的时候会有误差）
-2.任务资源等级规范
涉及亏损资产->重要任务->上游关键数据->上游非关键->非上游非关键
-3.分层规范
首先，数仓层内部的划分不是为了分层而分层，它是数据仓库经过了建模和 ETL 之后真正开始对外提供服务的地方，因此数仓层内的划分更应该符合使用者的思维习惯。DW 内的分层没有最正确的，只有最适合你的。
从业务层面看，数据仓库的核心是展现层和提供优质的服务。ETL 及其规范、分层等所做的一切都是为了一个更清晰易用的展现层。
要考虑的是分层问题（为什么有这个层吗，去掉是否有影响，是否每个层次都有需要解决的问题）
ODS层（数据接入原始数据层）
1、整合多种数据源到一个统一的地方
2、表字段格式和原表一样，方便差错
DW层（数仓层）
星型模型还是雪花，还是DataVault还是宽表
宽表：除非这个业务线以后基本不动，维度基本不增加，不然不要轻易使用宽表，后续加字段等七七八八操作很难受
而且结果表，可能尽量也不要使用宽表，否则就会有些历史数据（要跟产品或者业务方沟通好）
例如：有一条数据3月的时候名字叫ad，4月改名叫钙奶，那么用户在搜索数据的时候，根据名字搜索，通过现在叫钙奶来搜索3月份结果数据，结果查无此人，但是通过id却又搜索的到（因为用户是拿名字搜索的）
另外3种模型各有优劣吧，如果不是有特殊需求，建议星型模型
DM层（数据集市层高）
主题域划分
各种主题域各自开发（根据业务的理解划分）
例如：消费行为，通话行为，流量互联网分析，可以拆分成3个主题进行维护，可以有各种不同维度的产出
权限设置
虽然前两层有时候也会提供给外部查询（例如：ods数据）但是本质上来说，尽量让用户查询dm层，所以dm层就要设置相应的权限，库，表，甚至字段，可以参考sentry或者ranger等框架，更简单的就是hdfs设置不同用户的权限（目录的wrx权限）
TMP层（有些中间表可能可以复用，或者报错时用来回溯）
跑ETL的时候是否有中间表，是否需要保存部分的表，放在统一的地方，对用户不可见（基本是用来回溯报错，或者差量新增更新的）
所以本文我把什么是一个好的数仓，数仓产品如何迭代，还有数仓的分层和规范都说了，我再重复下，好的数仓设计，应该是减少人力成本，减少口头扯皮，更清晰明了的提供获取数据的方式给数据需求方，是一套高效，易用易上手的服务（是一整套服务哦，因为我后面还要说元数据管理和数据质量监控的事情，这两个也颇为重要！）
