前一段时间简要描述了数据仓库的发展和一些数仓建模的方法论？简要回顾一下：
#42 浅谈数据仓库（DW &BI）（一）：数据仓库发展起源及概述
#43 浅谈数据仓库（DW &BI）（二）：粒度、存储、3NF、星型模型、雪花模型
#44 浅谈数据仓库（DW &BI）（三）：企业数据仓库架构、数据集市简介
#45 浅谈数据仓库（DW&BI）（四）：OLAP
#48 浅谈数据仓库（DW &BI）(五）：维度建模简介
我画了一个大概的图，是我理解的数据仓库及其相关的内容（不包含平台），和目前公司使用的架构比较类似，我算是应用团队主要负责深绿色这一块工作的人吧。
前一段时间，我觉得自己的工作模式不太对劲，主要问题是：
1、上游：来自业务部门的数据需求随着精细化运营的深入越来越细致、部分需求人员对业务不够熟悉（我认为一些考核内容不当）、不同部门对同一业务的数据需求差异性较大，另外，还有需求频繁变更的特性。
2、我：一些现有的数据模型难以支撑需要进行改造，自己也没有做好承上启下的需求管理工作、开发设计评估和数据验收工作。
3、下游：开发团队对数据仓库内的数据、业务和需求的理解都不够，导致多次修改和调整。
总之不太妙，我就开始反思，想到一些东西，也和不少人做了一些沟通，我得出了一个结论：我觉得我们部门的定位不对，我们不能把大多数精力放在深绿色这一块。
在数据层面，我们应该做好核心仓库和维度建模的数据内容建设、数据规范化与数据整合，做好元数据管理、数据质量、数据开发管理。在系统层面，应该做好各个系统和接口，保障数据库的平稳性、安全性，并不断完善。后续的指标（业务指标）建设交由业务部门自己实现，如果有业务分析或挖掘相关内容，也应该交由业务部门实现。
所以，核心在于需要在完善的数仓体系之上，我们应该提供一个完备、可靠、易用的数据平台给业务部门，实现ONE-PLATEFORM.
主要原因我认为有以下几个：
1、业务部门更懂业务，术业有专攻，如果可以提供完备的元数据信息和一定的培训，数据价值可以发挥更大。
2、数据分析、数据探索是一个交互的过程，就是频繁变更的，如果业务人员可以实现快速探索，一定可以减少反复的需求沟通与重新开发的成本。
3、不同业务部门、统一部门内不同人关注的角度不一致，一心不能两用，现有模式开发的指标内容难以支撑，但是如果有统一的数据模型可以支撑，那就是极好的，开发成本将会有一定的减少。
4、现有的数据开发平台虽然已经很有效，但是不够好；将精力放在最后一步上看似在解决问题，实际是在低效地解决。
所以，如果要做这个数据开发平台，它需要具备什么能力？我是这样想的：
0、完备的数仓体系（多源数据、数据规范、元数据、数据质量、数据血缘关系等）
1、多元性（提供拖拉拽的快速多元报表、多样性图表的展示，也提供复杂的sql编写）
2、安全性（数据脱敏，但是可以通过审核后下载某个指标或者某个表的详细数据，使用日志记录等）
3、数据分享与协作（完备的角色、组关系管理，可自定义组，实现基础数据、统计数据的分享与协作）
4、全面性（不仅提供报表统计、图表、筛选器等，还需要提供快速数据分析、数据挖掘的组件）
5、提醒（通过设置短信或邮件提醒，及时了解数据的生成、数据结果信息）
6、推送（通过数据的关联、筛选，自定义推送用户到其他平台实现其他操作）
7、快速反馈（遇到问题，从前端快速反馈到后端数据仓库层进行问题的查证）
8、快（系统相应快，数据结果呈现快）
9、其他：支持数据导入匹配、不同用户可自定义自己的仪表盘等等。
这种一体化的数据平台应该是当下流行的BI平台？我带着想法和领导聊了一下，不过没准备好，不算顺利，其实可以先用一些现成的数据和工具做一些demo，效果会更好。
不过我司的业务线稍有点乱、有点杂，且用户量巨大，这样的平台不太好搭建，要在性能上实现快，硬件成本估计挺贵的，后端数据仓库的改造和相关系统的适配也将耗费大额成本。
不过，我觉得未来还是很有希望的。
下一篇将简述维度建模的事实表技术。
沉默是金 话唠是银
长按识别二维码关注
或搜索ID "im-wudi" 添加关注
