开始数仓前的一些准备工作

​如何开始数仓前的一些准备工作，避免在后期更轻松和更少的踩坑。

做了几个关于数仓的项目，其中几个有完整需求管理，数据模型文档管理，数据管理，血缘关系管理以及自主研发的ETL平台。也做过需求不明确以及没有任何的数据模型文档，在最终核对数据时发现是数据质量问题的导致。

谈点自己的看法，项目开始应当和项目组核心的组员一起做好完整的项目计划（项目人员还未完全进入项目，团队组建中），识别项目中出现的各种风险，做好风险应对策略，比如需求频繁更改、核心人员离职以及一些不确定因素等。了解项目的具体需求和业务，确定需求变更流程，以及确定交付成果以及交付的方式，在最终和客户进行验收时严格按照交付件说明进行交付。如果客户需要更改交付内容以及交付方式，需要通过变更管理。

项目整体规划完整后，开始招募项目成员，也可以在前期慢慢寻找合适的组员，在项目启动时能够快速切入项目，并对项目组成员做一次开工大会，介绍项目的各个流程和规范以及项目目的和部分业务需求。后面进入的成员也需要做业务培训，方便人员快速进入项目。等等...后面就是些项目管理的相关的知识，我自己也在思考，将学习到的知识整合到自己的项目中。

对于变更，在实际中可能做不到像课本上那样完整的变更控制流程，对于一些重大的变更，特别是涉及到和交付有影响的，一定要和客户确认，做好变更日志的记录。一些现场领导可以决定的，也可以简化流程，由现场项目经理进行控制，但是也需要在变更中进行记录，万万不可省略记录这一步（防止后面对需求，可追溯跟踪）。

对于一些敏捷开发的场景，客户需求不明确，或者需求变化快的场景，我们开发人员也应该拥抱需求变化这种情况。项目的最终目标就是服务于客户，让客户对结果满意这才是最终要的。可交付的内容尽量是以小模块、短周期的形式与客户进行签收，由于需求变化快或者其他原因导致的工作进度缓慢或者困难，现场负责人尽量组织大家进行每日站会和阶段工作回顾，既可以了解工作进度也可以帮助大家解决工作困难。尽力营造一种相互合作，信任的工作环境，彰显领导力。

后面开始数仓中的一些准备和规范。也包括一些前辈的一些经验教训可以总结。

1. 了解详细的业务需求和业务逻辑

切记不要在不了解业务和需求的情况下，盲目的对数据进行各种分层建模。数仓的目的就是为了业务提供价值。脱离了业务的数据建模本身就是空中楼阁。

可能会导致后期数据问题背锅。数据不准确等等。还可能会被开发人员怼，各种表开发不合理，kpi设计不合理，拓展性不强等。

 

2. 提前规划数据仓库

在数仓建设的前期，一定要有前期规划做这个事。即使是很小的细节，包括字段命名等。架构师也需要从数据开发人的角度思考需求和实现。多尝试抽象出来数据中间层。便于开发和拓展。

对数据分层明确，过程规范，复杂逻辑进行中间层抽象抽取，建设元数据管理，建设血缘关系管理，建设文档库（重要）。

 

3. 切记空谈数据，纸上谈兵

在业务逻辑形成的时候，一定要用sql去实现这个业务逻辑并且check数据的准确性。可能你会在实现的过程中，由于各种数据质量的原因导致目前的设计逻辑并不支持你想做的事情。（我刚开始的做数据的时候总是会想当然的认为表里有这个字段，数据就可以这样出，往往忽略了数据的真实情况，在真实的客户环境中，数据质量往往比你想象的差）按道理数据在接入我们ODS层的时候，数据就应该清洗完成，但是在实际的过程中，这是不太现实的，数据清洗成本也比较高。很多问题往往是在业务实现的过程中才会发现数据质量的问题。这个时候就需要协调客户进行解决，或者再次对数据进行ETL。

 

4. 切记画蛇添足

关注数仓核心的功能和需要解决的问题，以及需要实现的KPI，不要考虑过多的内容设计到数仓中，这样一个是导致了项目内容的蔓延，增加了项目时间进度和成本，也会分散个人的工作中心。最终就是啥也没做好。当然优秀的数据数仓拓展能力也是很强的。

 

5. 实现定义好规范

(1) 提前定义好各个阶段的命名规范。包括字段命名、表命名、层级命名、KPI命名规范。

(2) 文件脚本存放规范

(3) SQL规范，包括union all的使用，sql的长度、多表关联需要拆表等规范以及注释。

 

6. 数据模型文件规范

项目统一定义一个模型设计文档DM（Data Model），可以是ER图，也可以是Excel或者xmind等。主要是为了方便开发和数据架构师能够无障碍交流，数据开发能够拿着文档直接开发模型，不用再去和数据架构师沟通内容，减少沟通成本。

优秀的模型文档应该是按照板块设计的，有数据表导航栏，模块中的各个表在excel中的sheet中。

DM有完整的输入输出表详细说明。输出表的各个字段的计算由来关系以及血缘关系。数据表的执行时间粒度，维度以及表明等。DM文件我就不上传了。

 

7. 关注数据质量管理

尽早的关注数据质量的问题，不要等到发生严重的数据事故之后再来对数据进行质量检查。对于数据质量检查有较为完整的体系。数据的一致性、完整性、及时性等验证。

数据开发人员在开发完模型的时候也要Check一下数据质量问题，包括异常数据，重复数据等。关注业务唯一键。

 

8. 文档文档文档

重要的事情说三遍。一定要有文档输出，包括表说明，规范说明，模型文档等，不然后期项目就会是一锅粥，很乱，数据模型看不懂，还得去看sql来了解设计。也不方便交接和沉淀。项目过程知识总结很重要。

 

9. 避免长时间的做ETL

不要打算一直埋头干ETL，现在由于平台的易用性，长时间搞数据开发，SQL会弱化自己的技术深度。

在项目上可以适当的了解数据架构。可以搞搞大数据方面的东西，比如就说数仓这块，可以研究下数仓底层的计算和架构。包括Spark、Hadoop、Hbase、Hive这一套。数据接入可以研究下Flume、NiFi、DataX、Sqoop等。实时数据方面可以了解下Storm、Spark Streaming以及Flink等。

数据挖掘方面就可以利用项目经验或者其他时间丰富自己。可以多做做数据方面的相关竞赛。既可以获得奖金还能收获知识，岂不美哉。国内的平台有什么天池、datafountain、datacastle等平台，国外就kaggle了。做比赛也能变相的增加实战经验和项目经验，也是将自己所学用于实际数据当中。

加油吧少年。

在看的小伙伴，如果你有更好的建议或意见以及可以完善的部分，请留言。

更多文章请关注公众号：