湖仓一体架构选型与落地一线复盘

上个月跟着做数据架构的老周，跑了趟苏州的生鲜连锁客户。

对方CTO一见面就把电脑转过来，满屏的报错和业务吐槽截图。

钱花了。罪受了。问题没解决。

去年他们咬咬牙投了两百万上数仓，现在业务侧提个实时门店客流报表要等三天，库存对账误差率冲到8%，财务那边每个月对账要拉三个数据开发熬两个通宵，连老板都在周会上拍桌子骂。

一开始他们以为是老数仓性能不行，听销售吹湖仓一体能同时跑实时离线、打通数据孤岛，直接拍板上了某云的全栈方案。结果折腾了半年，还不如之前的老系统好用。

别把湖仓一体当万能补丁

说真的，我见过太多团队犯这个错。

把湖仓一体当成了治百病的偏方，不管自己家数据现在啥德行，先上了再说。

就像这个生鲜客户，上方案之前连基本的数据目录都没理清楚。业务库散在30多个独立实例里，历史离线表堆了快两千张，还有门店的IoT摄像头、冷链温感的实时流，进来之后连数据血缘都拉不出来，哪个字段对应哪个门店的库存都搞不清。

湖仓一体首先是数据治理的工程，不是买个软件就能自动生效的魔法。你要是连现有数据的权限、口径、血缘都理不顺，就算把最顶级的湖仓平台搭起来，最后跑出来的数还是错的，业务侧根本不敢用。

我还见过一个做跨境电商的客户，连订单和支付的口径都没对齐，就敢上湖仓跑实时GMV，最后算出来的数比实际营收高了17%，差点给投资人递错了财报。

选型别盯着参数表比来比去

很多团队选型的时候，拉个Excel表，把各个厂商的单节点并发数、存储成本、支持的格式列得清清楚楚，对着参数挑了半个月，最后选了个参数最好看的。

然后呢？然后踩坑踩得爬不起来。

还是这个生鲜客户，当时对比了三家方案，其中有个开源方案参数拉满，成本比云方案低40%，就是要求团队全部转用新的查询引擎，连SQL语法都和他们之前用的Hive不一样。他们团队8个数据开发，6个只会写Hive SQL，剩下两个刚毕业的小孩，连基本的集群运维都搞不利索。

光培训就花了两个月，写出来的任务跑起来比之前老数仓还慢三倍。

选型第一优先级永远是团队现有技术栈的迁移成本，其次才是性能和成本。你要是团队本来就天天跟Spark打交道，那优先选Delta Lake、Iceberg这种和Spark生态无缝衔接的方案，不用额外学新东西，上手快，出问题也有人能修。要是团队连基本的大数据集群都没搭过，数据量还不到100TB，那真的没必要硬凑湖仓的热闹，把现有数仓的口径理清楚，比啥都强。

别听销售吹什么“支持PB级数据处理”，你家总共才几十TB的数据，要PB级的能力有啥用？

落地别上来就全量替换

很多人落地的时候犯的最大的错，就是想一步到位，把老数仓全部推倒重来，三个月就把所有场景全部迁到新的湖仓平台上。

疯了？

真出问题的时候，回滚都不知道往哪滚。

这个生鲜客户后来听了我们的建议，直接停了全量迁移的计划，先拿最痛的库存对账场景做试点。把原来跑T+1的离线对账任务，迁到Iceberg上面跑流批一体的任务，先把8%的对账误差率打下来。

最开始试点的时候还闹了笑话，把华东区和华北区的仓库编码映射搞混了，跑出来的库存数差了快两百万。老周带着两个开发熬了两个通宵，逐字段对映射表，才把问题解决。

就这么磨了三个月，对账误差率降到了0.4%，财务那边终于不用每个月熬通宵了。这时候他们才敢慢慢把门店客流、销售报表这些场景往新平台迁。

落地的时候一定要找一个痛点最明显、业务价值最容易量化的小场景做切入口，跑通了再慢慢扩。别上来就搞全量，那是给自己找事。

不过话说回来，现在很多厂商吹的“三个月全栈上线”，听听就好。真的要把湖仓用顺，快的话半年，慢的话一两年都正常，毕竟数据治理这事儿，本来就是慢功夫。

其实哪有那么多高大上的技术名词啊。湖仓一体说白了就是给所有数据找个统一的存放地，既能跑实时的查询，又能存离线的历史数据，不用再维护两套系统。能帮你解决报表慢、对账不准、数据散的问题，就是好架构。

别为了凑技术热点，硬上自己hold不住的方案。