为什么数据产品设计对于构建数据仓库比以往任何时候都更重要
大多数数据仓库项目失败的原因并不是工程设计不当，而是无法支持业务决策。
无论选择哪种方法，数据仓库的实现都很复杂——Kimball、Inmon、DataVault。
BillInmon架构
RalphKimball架构
DataVault2.0架构
不可否认，优秀的工程和相对现代的数据堆栈是必要的。大多数组织都意识到了这一点，并投资了有能力的数据工程师。但技术实现并不是数据项目的最大价值。糟糕的工程设计并不是大多数数据仓库项目失败的原因。
|数据仓库的宗旨是并且一直都是支持商业决策。|
RalphKimball认为，如果做不到这一点，就是实施数据仓库时最大的陷阱。
“忽视了数据仓库的成功与用户接受度直接相关。如果用户还没有接受数据仓库作为改进决策的基础，那么你的努力就是徒劳的。”
在他的十大建议中，还有三项与弥合商业和技术之间的差距有关。
数据仓库是否履行了基于数据的决策的承诺？
大多数情况都难以满足要求。不只是我们。越来越多的数据团队意识到数据项目距离业务影响太远了。2023年Gartner报告称，“首席数据和分析官需要立即创造价值并产生影响。”
我们认为，自该报告发布以来的九个月内（截至2024年2月），数据世界并没有发生剧烈变化。
报告补充道：“当前的数据和分析治理实践对业务环境不敏感，不足以快速响应机遇。数据和分析领导者必须对现有的治理实践进行现代化改造，以实现投资回报。”
这适用于大多数数据投资，包括数据仓库。
企业选择建立数据仓库有两个原因：
1.报告要求。
出于合规原因，这些通常是强制性的，而对业务分析的好处也是公司现在愿意投资的。
2.数据驱动决策。
这超出了仪表板的范围。分析目前侧重于跟踪历史和当前数据。但数据驱动的理念只有在你建立准确的预测模型时才能实现。
现有数据仓库在预测分析和能够准确影响业务决策的模型方面的能力存在巨大差距。
在“数据”上投入巨资的企业很少能够在预测方面看到投资回报。
大多数人还没有准备好利用生成式人工智能和大模型的最新发展，并且还需要很多年才能赶上。
为什么技术无法扭转局势
对现代数据堆栈的投资都是通过技术解决方案来解决可用性问题。这带来了更好的数据处理方式。但继续改进技术方面就是试图构建一些东西，帮助数据工程师构建一些东西，帮助数据科学家/分析师构建一些东西，帮助业务分析师构建一些对决策者有用的东西。
答案似乎总是更好、更快速地集成和整合数据。自动化、云数据库、敏捷软件工具等等。
这是Kimball的另一个十大陷阱，即“过度迷恋技术和数据，而忽略了业务需求和目标”。
或许解决问题的关键更简单，也可能更复杂。
这很简单，因为这是人类一直在做的事情。
它之所以复杂是因为业务很复杂并且建模有用的过程也很复杂。
什么构成了一个良好的数据仓库？
我们不会讨论数据工程。有很多非常有才华的人已经解决了几乎所有可能的问题。
但并非所有数据仓库的规划都一样。它们可能构建得很好，但蓝图并不支持业务需求。
目标和方法决定了数据项目的正确业务结果。最终得到可识别且相对准确的模式并不意味着数据仓库可以成为更准确的报告或预测分析的基础。
正如我们已经说过的，对于一家足够大的公司来说，所有数据仓库都是复杂的项目。没有简单的方法可以统一系统和业务领域，为所有需要数据的人提供通用的结果。
您需要努力简化流程并使数据产品具有可扩展性。
为什么在数据仓库项目中咨询业务主管很重要
目前，项目团队结构和决策往往朝着一个方向发展：
-CXO或领域专家需要数据仓库来满足监管要求或支持他们的业务需求。
-将需求传递给技术主管，例如CIO、CDO甚至CTO。
-一个由项目经理组成的技术团队被分配任务，然后收集需求（业务专家也参与其中）。
-需求不会超出数据点。最多对业务需求有一个基本的了解。
-然后，技术/数据团队开始构建仓库，通常是在敏捷开发框架内逐步构建。
-技术/数据团队无法向项目经理提供可见性，让他们了解结果会是怎样。他们在技术上很熟练，项目可能设计得很好。
-这意味着PM无法自信地告知最终用户或CXO项目可能成功。同样，从技术上讲，他们正在按计划进行。
-关键利益相关者在整个项目生命周期内无法了解最终产品。
-数据项目通常看起来像一个黑匣子，因为直到最后阶段才能保证最终结果。
-从技术上来说，一切都很好。这就是重点。这不是技术问题。
因此，经过十年的大规模数据仓库投资，糟糕的结果给CXO和数据团队带来了压力，要求他们提供更好的面向业务的结果。
数据建模是业务与技术之间的桥梁
您不太可能不熟悉数据建模。概念数据建模忽略了数据工程和数据仓库架构的技术方面，而专注于捕捉业务需求。
语义层主要受领域专家的影响，而数据建模者则起着支持作用。
这种方法有三大好处：
1.了解业务的痛点，这是技术无法做到的。
2.承担所有技术投资并提供商业价值。
3.可以为业务部门定制解决方案，同时仍然能够构建支持集团级的数据库。
在构建数据仓库时对数据建模的反对是基于一种感觉，即它正在远离敏捷开发。
数据架构师和工程师认为建模是一个漫长的过程，迫使他们一次性收集大型项目的需求，通常需要数周或数月才能完成。但这种情况已不复存在。使用正确的工具，您可以将大型数据仓库项目分解为更易于管理的规模。
每一种模型都将完全专注于实现商业价值。关键是拥有可重复使用的概念和组件，以便可以将较小的模型拼接在一起，形成整个领域的有效模型。
案例：泰国某大型银行的分支机构困境
以泰国银行业的一个现实案例为例。在数字银行迅速发展的时代，一家大型银行正在努力应对数千家实体分支机构的网络。领导团队面临一个重大的战略问题：
“我们是否应该关闭分支机构以削减成本，还是重新利用它们来支持我们的虚拟银行战略？”
许多银行可能默认收集所有客户互动数据，并让数据科学家“发现一些有用的东西”。但这家银行以问题驱动的思维方式来处理这个问题：
1. 定义问题：他们明确地阐述了问题——实体分支机构成本高昂，但关闭它们可能会损害数字化采用速度较慢的农村地区的客户关系。
2.提出正确的问题：
• 客户数据：哪些客户交易仍然依赖于分支机构？
• 数字化采用数据：每个地区有多少百分比的客户活跃于银行的移动应用程序？
• 服务使用模式：分支机构中最常请求哪些可以数字化的服务？
3.数据驱动决策：
• 关闭或合并：在数字化程度较高的城市地区，他们关闭了流量较低的分支机构。
• 重新定位：在农村地区，他们将分支机构转变为“金融体验中心”，提供个性化的金融咨询服务、数字素养研讨会和远程银行支持。
通过专注于问题本身（在降低成本和客户访问之间取得平衡），他们避免了“削减分支机构”的决策。该银行最终削减了成本，同时提高了客户参与度，表明数据与明确定义的问题相结合时效果最佳。
没有背景的信息只是噪音。
数据本身没有内在含义。上下文来自对业务问题的理解。以客户行为为例。网站流量激增可能看起来像是好消息，但如果不了解您的业务背景，那只是一个数字。流量增加是因为最近的营销活动，还是因为竞争对手的网站崩溃，暂时将客户推向您？
我见过一些公司浪费数月时间分析不相关的指标，仅仅因为“数据就在那里”。然而，好的数据分析不在于数量，而在于提出正确的问题。只有这样，你才能将信号与噪音区分开来。
本文来自微信公众号 “数据驱动智能”（ID：Data_0101），作者：晓晓，36氪经授权发布。
