浅谈数据仓库（DW & BI）（六）

前一段时间简要描述了数据仓库的发展和一些数仓建模的方法论？简要回顾一下：

#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" 添加关注