我家储藏间有个纸箱，上面用马克笔写了一个字：杂。搬家那年封的，到现在没拆过。
这就是我第一次听到“数据湖”时脑子里冒出来的画面。不是湖，是一个巨大的、贴着潦草标签的箱子。什么都往里扔，扔完就忘。
先别管那个“湖”字，想想你自己的手机相册
你手机里有多少张照片？几千？上万？
我猜你从来没给它们分过类。拍完就扔在相册里，系统按时间排一排，完事。这就是最朴素的数据湖思维：先存着，用的时候再说。
企业的数据湖干的就是这件事。用户在 App 上点了一下、摄像头拍到了一个人、传感器记录了一秒钟的温度、客服聊天里冒出来一句话——全扔进去。不挑不拣，先存着。
以前的思路不是这样的。以前的思路叫数据仓库。数据仓库像个讲究的衣柜：衬衫挂一排，裤子叠一摞，袜子卷成球放格子。你想拿哪件，伸手就是。代价是——每次往里放东西之前，都得先想好它是衬衫还是裤子。想不清楚？那就别放了。
数据湖把这套规矩掀了。它说：你管它是衬衫还是抹布，先扔进来。
塞进去容易，往外掏才是真本事
问题也正好卡在这儿。
我在储藏间里扔了二十个箱子，三年后想找那台旧打印机。翻吗？翻。翻多久？不知道。
数据湖就是这么个东西。存的时候特别爽，查的时候特别想哭。原因很简单：数据湖里的东西，大部分没被整理过。
有个词儿叫“数据沼泽”。说的就是一个没人打理的数据湖。水是有了，但底下全是淤泥，伸手一摸什么都摸不着。听着挺吓人，其实挺常见。很多公司兴致勃勃建了个湖，两年后没人愿意用——因为查一次数据要跑三天，跑出来还未必对。
技术上，这个矛盾有个名字：schema-on-read（读时定义模式）和 schema-on-write（写时定义模式）。
不用记这两个词。你就想象两种贴标签的方式。一种是你买了衣服当场就贴——这是“写时定义”，放进去之前必须先想明白它是什么。另一种是你把所有衣服一股脑塞进柜子，等到哪天要穿，再把柜子翻个底朝天，临时决定“哦，这件算正装”——这是“读时定义”。
数据湖选的是后者。灵活，也有代价。代价就是，当柜子够大的时候，你自己都不知道里面有什么。
有人说，那就建个目录呗。谁放东西谁登记，写清楚里面是什么、什么时候放的、谁放的。
这个想法很好。这个东西在技术上有名字，叫元数据。
问题是：没人愿意写。
你往柜子里塞衣服的时候，会让你签个字、写上颜色尺码季节吗？不会。你只会把柜门关上，然后去干别的事。企业里的情况一模一样。研发说这数据不是我产生的，业务说我看不懂字段名，最后那个“目录”就烂在那儿了。数据湖的好日子，往往终结于此。
后来大家发现，光有湖不够，得在上面盖个房子
于是就有了“数据湖仓”这个东西。
名字听着像凑数，其实挺实在。它的思路是：湖还是那个湖，该扔的还是往里扔。但在湖面之上，架一层东西——可以是 Apache Iceberg，可以是 Delta Lake，也可以是 Hudi，你就理解成给湖面修了几条栈道——让那些没整理过的数据，也能用 SQL 查、能改、能删、能追溯。
以前的湖，进去就是原始状态，你想查？自己写代码慢慢解。现在的湖仓，同一份数据，工程师可以当文件读，分析师可以当表查。两拨人不用打架。
我不打算在这儿列一堆产品名，你也不用记。你只要知道一件事：湖负责“先存下来”，仓负责“能用起来”。这两个需求从来都打架，湖仓是想让它们握手。
不过话说回来，握手这事没那么多一次成功的。栈道修得再好，湖水该浑还是浑。工具能解决的是“能不能查”，解决不了“该不该存”。这两个问题，经常被混着讲。
那这事跟我有关系吗
说实话，大部分时候没关系。
你不是数据工程师，你不需要管一个公司怎么存它的日志。但有一点挺有意思——
你手机上那个“自动备份”功能，其实已经在干同样的事了。照片、聊天记录、语音、位置轨迹，一股脑传上去。系统不问你这是风景照还是截图，先存。
等到某天你想找“去年秋天在某个地方拍的那张”，你才发现问题：存是存下来了，可怎么找？
你看，同一个矛盾。只是换了个尺度。
数据湖这个词之所以让人头疼，不是因为它多难，而是因为它把一个特别朴素的道理，包进了一堆听起来很贵的名词里。存和用，从来是两回事。你想省下存的时候那点力气，就得在用的时候还回去。利息还不低。
我家那个写着“杂”字的箱子，到现在还封着。
我大概是不会拆了。