数据仓库项目从来不是技术项目

数据仓库是什么？

还是得先从定义开始：数据仓库是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合，用于支持管理决策。这里的“支持决策”往往是面向分析的，需要能够对业务系统的数据进行大批量的、多维度的数据探索和分析，从而帮助最终的业务决策。此文是我对于数据仓库项目的一点点感悟，不涉及具体的技术实现。

但它从来都不是(纯)技术项目

数据仓库项目上用到了很多技术组件，相信很多人都可以用报菜名的方式列举出来，听起来像是一个用了很多时髦组件、很性感的技术项目。但如果从权重上来看，我认为技术不是最重要的部分。对于数据仓库项目而言，更需要的是一套策略，一套组合拳，不仅仅需要技术卓越、业务理解，还需要需求方、业务方在整体架构和流程上的配合。

数据仓库建设应该包括这些主要流程：

1. 业务需求访谈、业务架构设计；
2. 技术选型、技术架构设计；
3. 客户顶层战略支持以及各个业务方、需求方的配合；
4. 具体业务需求分析、数据建模；
5. ETL导入数据；
6. 报表开发、数据服务、数据集市等。

数据仓库项目实施不是一开始就马上接数据进来，而是需要经过前期的几轮业务访谈确定整体的业务需求并完成总体业务架构设计，并根据业务架构和具体的客户技术状况确定顶层的技术选型和技术架构设计，在和数据仓库涉及到的业务方、需求方、技术方等同步确定并获得了各方支持之后才能准备开始真正准备接入数据，也就是上述4~6这几个步骤。 

而4~6是不断地在进行的过程，而不是等到所有业务分析结束之后再进行ETL的部分。目的是快速接入、快速出结果、快速见效，如果遇到问题也可快速调整，更重要的目的是获得客户信任。如果时间拉得太久，客户很有可能会因为看不到效果而丧失信心。这个逻辑也类似于故事卡中的“纵向拆分”。

“客户的游艇在哪里？”姊妹篇：“客户的金子在哪里？”

说起数据仓库，用到比较多的比喻是“海平面下的冰山”和“沉睡在矿山的黄金”。如果我们只是把多个不同业务系统的矿石（数据）搬过来、规整规整，是不能淘到金子的。如果耗费大量人力物力，而只是做了搬运工的工作，那整个项目就是“亏钱”的项目。因为它没有产生业务价值（金子）。这个时候不禁自问：“客户的金子在哪里”?

我理解业务价值主要分布在这些领域：

• 支撑运营，辅助决策：各类活动、业务增长依赖于数据来做决策，这时核心指标计算、对齐各个业务口径、多维度分析等十分重要，准确及时的结果能够帮助客户制定运营决策。
• 数据分析：对于用户转化、用户行为分析等场景，数据探索、交互式分析、数据可视化等支持十分重要。
• 业务支撑：机器学习、风控、数据服务、推荐系统等对于数据仓库提出了更高的要求。

也不局限于上述的几个领域，我认为主要的判断条件是数据仓库的产出结果是否为业务系统提供了有价值、甚至是可以直接变现的支持作用。比如风控和推荐系统就可以从防止了多少可能的财产损失和提升了多少订单转化率两个维度来衡量“金子”的价值。

如果只是说我们这个月多了xxx张报表，新接入了xxx个业务系统，进行了xxx次业务访谈听起来好像很忙，但仔细想想其实并没有产生太多的“金子”。也有人说可以通过衡量ROI（投资回报率（ROI）= 年利润/投资总额）来量化“含金量”，在实际操作中“年利润”可能还好计算，但是“投资总额”往往难以衡量，因为底层的数据、集群、运维往往是和其他业务数据共用的，且很多流程的数据流非常长，这大大增加了衡量“投资总额”的难度，以至于大多数据仓库都很难精确衡量投资了多少。这也不意味着就可以完全不用思考ROI了，我认为即使没有精确的数据，也可以用预估的方式来粗略的判断大致的ROI是多少，而不是闷头往前走。

同时前期的步骤也非常重要，没有前期的数据搬运、建模等步骤，这些“金子”就变成了无源之水，前期的数据获取、数据清洗、数据建模等步骤决定了能不能淘到高质量的黄金。这里更像“木桶理论”，从业务分析、数据建模、数据加载、数据清洗、数据转换到指标计算、报表开发、数据分析、机器学习等等步骤如果有一块短板都会导致其他过程的产出“含金量”下降，尤其是前期的步骤，如果前期步骤没有做好，后续几乎就是“garbage in, garbage out”了。

- 相关阅读 -

DDD 中的几个困难问题

单体 or 微服务？你以为是架构权衡？其实是认知负载！

点击【阅读原文】可至洞见网站查看原文&加粗字体部分的相关链接。

本文版权属Thoughtworks公司所有，如需转载请在后台留言联系。