很多公司有一种错觉：觉得数据存得越多，决策就越聪明。

数据湖、数据仓库、实时数仓、湖仓一体……技术名词换了一轮又一轮，存储成本年年涨，但决策质量呢？说实话，没见几个团队因为多存了100TB数据，就做出了更好的产品决策。

问题不在数据量，在数据的"可用性"。更准确地说，在于数据能不能在决策窗口内，被正确的人看到、理解并行动。

数据资产？大部分是数据负债

这个观点可能有人不同意。但我的观察是，绝大多数公司积累的数据，产生的价值远低于维护成本。

存储成本只是冰山一角。真正的成本在三个层面：

维护成本。 数据管道要人维护，数据质量要人治理，数据口径要人对齐。一个中等规模的数据团队，光日常运维就吃掉一半人力。剩下的才是"分析"。

认知成本。 当一个产品经理想看某个功能的转化漏斗，需要先找数据分析师、再对口径、再等排期——这已经不是在用数据做决策了，这是在做数据请求的甲方乙方。

决策延迟成本。 这是最贵的。一个决策如果能在两天内做出，和等了两周才拿到数据再做，商业价值完全不同。大多数公司的数据流程，恰恰是在制造延迟而不是消除延迟。

数据团队的尴尬

我见过不少数据团队的处境：业务方觉得他们响应慢，数据团队觉得业务方需求不清晰。两边都有道理，但问题的根源不在任何一方，在于数据被当成了"基础设施"而不是"决策工具"。

基础设施的逻辑是：先建好，等人来用。

决策工具的逻辑是：围绕决策场景，倒推需要什么数据。

这两种思路的差别，就像"建一个图书馆等人来借书"和"根据读者需求采购书籍"的区别。前者看起来很有规划，后者看起来不够"系统性"，但你猜哪个真正解决了问题？

大部分公司的数据建设，都在犯同一个错误：先存储，后治理，最后发现治理成本比存储成本还高，而且治理完了也没人用。

从决策倒推，而不是从存储正推

做得好的团队，有一个共同特点：他们不问"我们能收集什么数据"，而是问"我们最重要的五个决策是什么，每个决策需要什么数据"。

这个思路转变看起来简单，实际上意味着：

砍掉80%的数据采集。 不是所有用户行为都值得记录。大部分埋点数据，从出生到死亡，没有被任何人看过。它们唯一的作用是增加了存储账单和管道复杂度。

缩短数据到决策的路径。 如果一个业务指标需要跨三个系统、经过两次ETL、再通过BI工具展示，那这条路径太长了。能直接在一个地方看到关键指标，比什么花哨的实时数仓都有价值。

容忍"不完美"的数据。 这一点最难接受。很多公司追求数据100%准确，结果在数据治理上投入了不成比例的资源。实际上，大部分业务决策不需要精确到小数点后两位。趋势对了，方向对了，就够了。

一个实际的检验方法

如果你想知道自己公司的数据建设是不是在"自嗨"，有个简单的测试：

随机找一个业务负责人，问他："上个星期，你做了几个基于数据的决策？具体用了哪些数据？"

如果他答不上来，或者支支吾吾说"看了下大盘数据"，那说明你们的数据建设大概率没有真正服务于决策。

反过来，如果他能清晰地说出"我根据XX指标的变动，调整了YY策略"，那说明数据至少在这个场景下是有效的。

这不是技术问题，是组织问题。

数据的价值密度

有一个概念叫"数据价值密度"：单位存储的数据，在单位时间内产生了多少可度量的业务决策。

按照这个定义，大部分公司的数据价值密度趋近于零。因为大部分数据从来没有被用来做过任何决策。

提高价值密度的方法不是存更多数据，恰恰相反：

• 减少采集范围，只收与核心业务指标相关的数据
• 缩短反馈周期，从周报到日报到关键指标实时化
• 降低使用门槛，让业务人员能自助获取80%的日常数据需求
• 建立数据与决策的显式关联，每个重要决策都应该能追溯到具体的数据依据

写在最后

数据这个东西，和代码有点像。写得多不代表好，存得多不代表有用。

真正有价值的数据建设，不是看你的数据湖有多大，而是看你的团队在做决策时，能不能在5分钟内拿到需要的数据，看懂它，然后行动。

如果做不到这一点，数据湖再大，也不过是一个昂贵的数字垃圾场。

我的看法是：与其继续往数据湖里倒数据，不如先搞清楚，你的团队到底在用数据做什么决策。从这个起点倒推回去，可能只需要现在十分之一的数据量，就能覆盖80%的决策需求。

少即是多，在数据领域尤其如此。