标签：
工作3年，基本上每天都是和数据打交道，稍作总结，留做纪念，也希望能和大家一起讨论。
3年中做了不少模型设计，但始终没有自己太满意的作品，不过每一步都在成长，后期的作品总比前期的更好，感谢以前带我入门的一休兄弟，也感谢后来在一起奋斗在项目现场的其他兄弟。由于工作主要做的是分析库包括：DAS系统，经营分析系统，绩效系统或者数据仓库。不敢对生产系统妄加评论。以下内容也不过是抛砖引玉，有异见可以一起讨论，共同进步。个人以为分析类型系统有如下共同特征：
1.需要接入大量的外部系统，以上系统本身不属于生产系统，他们只是对生产系统的数据进行加工，因此，外部生产系统必不可少。
2.由于业务的不断变化，该类系统的建设不会一蹴而就。因此缓慢迭代，可预见性冗余尤为重要。
3.同生产系统相比，分析系统是数据集处理，而生产系统是数据业务意义上的完整性，分析系统维护的是数据集的完整性。
从事该类系统建设时，一般来说，业务人员（或者甲方）都会有且仅有一些模糊概念性需求，比如他们希望能看到每天某个业务增长情况（产品维度），某个员工的业绩（人员，机构维度），年业绩状况（时间维度）。而系统建设之时，需要业务专家对其业务需求进行归纳，引导和分类。其意义在于将客户模糊需求明确化，提供一个可以预见的设计蓝图。将不合理需求（包括业务不合理，项目成本不合理等）引导到合理需求上，分类也主要是给模型设计提供一个蓝图。当业务专家在进行工作时，数据专家（模型设计人员）也应该进场工作，
从事前期的需求调研，包括了解对方的IT建设情况，有多少外部系统，系统数据准确性，是否有一些老的平台功能需要移植到新系统中来，行业常见KPI指标能否得以支撑。以及对方决策人员对该系统的定位，是否超出了该系统真实承载能力。以及要让对方清楚，该类系统建设是一个漫长的过程，后期维护至关重要，是由业务部门的技术人员维护还是由乙方或者甲方技术部门维护都是要考虑的重要因素。同时在此过程中，需要尽可能拿到对方生产系统的数据字典，了解清楚对方系统可以输出哪些数据，方便下一步详细设计。
以上工作告一个阶段后，数据专家应该开始接口设计，设计原则包括以下几点：
1.数据是push还是pull获取。
2.每个接口的数据量大小，可以决定是增量、全量或者增量+全量模式传输。
3.数据频率设置，周，月，季还是年。
4.接口命名规范，最好同接口表名+数据日期，一般来说命名需要体现原系统名称，数据层级，以及周期，比如ODS_CORE_****_DAILY ，可以体现是核心系统的数据，每天传送，ods作为接口层标示。
该层数据一般不做业务含义转换，都通过文本加载到目标库（我们项目库），加载方式通过脚本还是通过专业ETL工具也要考虑，但对模型设计影响不大，不做过多描述。
当数据接入后，需要同甲方明确每个数据的具体含义,指标的具体口径，计算公式，并初始化维表，包括2种情况：
1.只增加，不该表的维表，比如产品表，该类表只需要规范化编码，并merger 数据则可。
2.除增加，还发生变化的缓慢渐变维表，这类表，如人员信息表，由于人员角色发生变化，导致其考核指标变化，因此，需要给该类数据加入有效日期，失效日期字段，并在角色变化时及时维护。
除以上两种情况，规范化编码，将多个系统的不同编码映射为标准编码也是该阶段工作之一，一般来来说，该阶段映射应该给客户留前台维护窗口，当以后组织部门需要添加一个新增机构，需要先让科技部门在各个系统生成统一编码，并在该系统中完成维护，从而才能投入业务 部门使用。
维表设计完成后，根据业务部门的指标，将完成事实表设计，将所有事实表按照业务主题分类，形成星型模型，并在接口层事实表接口进行清洗和入库，包括日期格式统一化，字段名字统一化，并根据业务判定对一些细粒度无用数据清洗掉，保证数据准确性的情况下入库保存，该层是持久层，需要满足最细粒度的查询，并要考虑设计卸载机制，当该明细数据保留3个月或者更久进行卸载归档处理。一般建议分区表设计模式，按照时间分区卸载。
设计到此，可以看出，上一层设计基于业务逻辑。在这一层中，我们需要考虑的是业务需求情况了，简单说，如何满足各种报表：细粒度数据需要汇总，各个层级需要汇总下一层数据。并结合系统业务功能，进行业务逻辑加工。该层表需要考虑的是如何设计冗余，如果多表关联才能完成查询会影响用户体验，就将信息冗余保存。如果数据量依然过大，可以考虑分表保存。
---待续
标签：
原文地址：http://www.cnblogs.com/geda/p/4222849.html
