标签：工作 不能 报表 作业 仓库 开发 枝叶 表数据 维表
今天遇到一个数仓工程师经常会遇到的一个棘手问题，就是要提取一个供应商从2007到2017年来销售的数据明细，本来从现有的数据作业关系架构图中很容易取出这些数据，但是第一数据跨度太长，这种非原始数据底层只存了近5年的数；第二如果冲底层重新生成数据，由于供应商数据不是直接从底层处理而来，有好几个前置作业，我必须了解前置作业10年前数据处理逻辑是什么样子（对于我这种工作不满10年的完全是一场灾难），只能重新对接业务部，从头开发一张报表。这样做实在是太耗费时间和人力了。
由此深深地觉得数据模型结构建设存在重大问题。目前使用的数仓架构实际上是一张业务架构图，好处在于处理目前架构图中已有或者相近的数据需求时将是非常简单高效和快速的，但是，一旦业务有变化，整个架构图都要改变，越是修改离树根越近的作业， 相关的后续作业改的越多。更甚者像今天遇到的问题，要从底层处理10年前的数据，最高效的方法是找到10年前的数仓工程师和业务人员。
由此，我认为数仓的数据处理架构图不应该由业务引导，而是要以数据为动力，通过整理数据的内在联系，分门别类，最后形成一个包罗万象的数据模型。
当然，数据和业务是不能完全脱离，数据建模就像一棵松树的成长，数据骨干要直，所有的枝叶（业务）数据都来自同一个口径，不然一百个工程师处理同一个任务能出一百个哈利波特。由此本人数据建模过程总结：
1首先对业务进行整理，总结归纳业务需求。
2对各个业务的的数据进行分类，例如，本公司数据可以分为订单数据，供应商数据，物流数据，用户数据，优惠数据等几大类
3对各大类数据进行维度分析归类，例如，不论是订单还是供应商都会涉及到地理维度数据，商品维度数据等
4模型建设，模型建设包括事实表建设和维表建设，事实表作为数据最底层，粒度越细越好，例如事实表中订单销售销退数据，最好是精确到商品级，事实表要尽可能少地与维表数据重合，同样，维表要尽可能精简，鼓励使用星型模型，不建议使用雪花模型
5
标签：工作 不能 报表 作业 仓库 开发 枝叶 表数据 维表
原文地址：http://www.cnblogs.com/ddwarehouse/p/7266378.html
