梳理公司业务系统，业务关心的指标，开发过的需求。一般业务关心的数据集中在两三类数据上

根据已有的数据，选择技术平台，及开发语言。Deloitte已经选好用CDH，这步可以不考虑

在数仓建设阶段，我们只需要制定数仓相关的规范。
如：分层设计规范、表命名规范、字段命名规范、层次调度规范、脚本开发规范。网上都有这些规范的相关文章，需要结合公司情况改一下。
这些规范最好在开发前，整理成一个简单的文档，这样方便我们数仓的维护。

备注：数仓建设完成后，可能会设计元数据管理、数据质量、和指标管理。这些模块在开展之前也需要制定相关的规范。但是我们在数仓搭建的时候不用考虑这些问题。

提供部分数仓开发规范参考

一般包括ods\dwd\dim\dws\ads.每一层都有各自的功能

包括ods、非ods层命名规范、手工维护表、层次调度规范

• ods命名规范：ods+源系统库+数据库类型+源表名+加载方式+是否分区
• 非ods命名规范：分层前缀+业务域+业务过程+更新方式+时间粒度+是否分区
• 更新方式：增量inc、全量full、拉链zip
• 表名时间粒度规范：小时（1h）\天（1d）\周（1w）\月（1m）\季度（1q）\年（1y）
• 非分区表：统一加上后缀_0p
• 手工表：dwd-业务域-manual-业务过程。manual表示这是手工维护表

采用蛇形命名法，即采用一个下划线分割词根

禁止反向调用
ODS 只能被 DWD 调用。
DWD 可以被 DWS 和 ADS 调用。
DWS 只能被 ADS 调用。
数据应用可以调用 DWD、DWS、ADS，但建议优先考虑使用汇总度高的数据。
ODS->DWD->DWS>ADS
ODS->DWD->ADS

• 脚本是否有备注、字段是否有注释、复杂计算逻辑是否有注释释。
• 任务是否支持多次重跑而输出不变，不能有 insert into 语句。
• 分区表是否使用分区键过滤并且有有效裁剪。
• 外连接的过滤条件是否使用正确，例如在左连接的 where 语句存在右表的过滤条件

可以按照业务系统、或者部门划分。如果按照业务系统划分，两个业务系统的数据一样、可以合并为一个主题。
上次您跟我交流时的业务跨主题域的问题，如果主题划分好了，是不会存在这种情况的，如果跨主体域了，就划分在某一个主题域就行。

建议划分为ods,dwd,dim,dws,ads层。
数据的分层目的是方便我们清晰数据的流向，没有分层时，可能我们的数据会存在循环调度的情况；当然分层也可以减少重复开发的工作。

包括dwd,dim,dws的模型建设。

1)避免烟囱式开发：在数仓搭建前期，最容易出现的一个问题就是烟囱式开发.
烟囱开发判断标准有2个:

• 大量ods的表直接被dws或者直接被ADS层引用
• dwd或者dws表模型的下游引用表小于2张，模型平均的引用系数在3才算是一个比较好的数仓。

最好在数仓搭建的时候，您辛苦一下，看一遍建设的模型。

2)建设统一的维度编码表：编码不统一，会出现相近业务不能关联分析、出现数据孤岛的问题,维度表可以先建设公司常用的编码。

实施方法：先把所有设计维度的表集成到source表，在做清洗映射为业务编码与清洗后编码的映射表，最后建设成维表。

1）如何建设模型
A)dwd模型：
主要做就做数据清洗，编码值的统一，编码属性值的冗余（比如产品名称就是属性值，产品编码就是编码值）。当不熟悉业务时、表结构可以借鉴业务系统的表结构。我现在公司的业务系统的表结构没完全按照三范式进行建模

B)DWS模型
把相同业务的指标，可以沉淀到dws表。比如业绩相关的
日/周/月/季/年/累计/销售金额or销售数量;当日/当周/当月/当季/当年/累计/销售退款金额or销售退款数量;可以按照这样的周期计算统计指标。

另外比如我们算了销售相关的DWS指标业绩，在计算团队，或者城市的业绩的时候，最好从销售业绩统计的dws表进行汇总。

注意点:这里有个问题就是销售的团队会变化，可能存在汇总城市业绩时会出问题，这里需要主要下

C)ADS模型
根据业务需求建设模型

2)什么样的模型式好模型？
我也一致在思考这个问题，网上很多建模方法论。
在建模的时候说的都是：选择业务过程、确认粒度、确认维度、确认实事,在应用在实际数仓搭建过程中比较懵，这个方法论可以借鉴。

关键是这个模型建设完成之后，被下游多少张表引用，比如这个表被下游5张表引用+并且表命名字段命名规范，那这就是一个成功的模型

3)逻辑如何确定
有些已经确定好的逻辑，可以直接借用之前逻辑就可以了。如果没确定逻辑在开发之前先跟业务或者需求确定逻辑