很多公司建完数据湖后的第一反应是：松口气，终于有个地方能倒垃圾了。
日志、埋点、数据库备份，一股脑往里扔。存储成本确实比传统数仓低，扩容也方便。但半年后，业务方来问数，数据团队却答不上来。为什么？因为湖成了沼泽。东西都在，就是没法用。
大数据的核心矛盾，从来不是存不下，而是找不到、读不懂、不敢用。
我见过一个电商项目，用户行为日志在湖里躺了两年。格式五花八门，有的字段缺失，有的时间戳混乱。当运营想分析“双十一”复购率时，数据工程师花了三周清洗数据，最后发现关键的用户ID关联字段在三个月前的一次采集变更中丢了。
这种场景太常见。只存不治理，数据湖就是个昂贵的黑洞。它吞噬资源，却不产出价值。真正的痛点在于，原始数据缺乏上下文。没有元数据管理，没有血缘追踪，没有人知道这张表里的 status=1 到底代表“已支付”还是“已发货”。
要让湖跑通业务，得从“仓库管理员”思维转向“超市货架”思维。
首先是 schema on read 的克制使用。虽然写的时候灵活，但读的时候必须规范。建议在接入层就建立基础的标准字典。比如，所有涉及金额的字段，统一单位、统一精度。别指望下游分析师每次都要写一遍转换逻辑。
其次是元数据自动化。靠人工登记表结构？别做梦了。必须通过工具自动抓取表的更新频率、热门查询字段、数据所有者。当业务人员搜索“用户画像”时，他们应该能看到哪张表最近被引用最多，而不是面对几十个同名不同内容的表格发呆。
最关键的一点：建立数据SLA（服务等级协议）。不是所有数据都值得实时处理，明确哪些数据必须T+0，哪些可以T+1，能节省大量计算资源。
技术架构再漂亮，如果业务方不用，就是失败。
我曾参与重构一个零售客户的大数据平台。我们没有急着迁移所有历史数据，而是先挑了一个高频场景：库存预警。只打通供应链和销售两端的数据，在湖里建立一个小而精的集市。
结果呢？两周上线，库存周转率提升了5%。业务方看到了甜头，主动配合后续的数据治理。这才是正循环。
不要试图一次性把整个湖清理干净。找个具体的业务痛点，用小数据集跑通全流程。让数据在湖里流动起来，产生决策，而不是静止地占据硬盘空间。
当你的数据湖开始被频繁查询，而不是频繁扩容时，它才算真正跑通了。
