数据仓库被淘汰了？都怪数据湖

文：大数据架构师
源：数仓已死？数据湖当立！

前两天，我详细剖析了一下这两天脉脉上很火的数据建模帖子。指出来帖子里百度小哥“只见宽表不见建模”的核心原因是整个数据圈的核心逻辑变了。

然后就引起了建模群里一帮人在疯狂吐槽。

 

 

也有大厂的数仓大佬高屋建瓴，指点江山，侃侃而谈。

 

为啥吐槽？因为我们知道，这再也不是以前数据至上、工程为先的俄罗斯方块游戏了，而是客户至上、业务为先的神庙逃亡游戏。

但是绝大多数企业的数据仓库工程师，究竟还是沦落到拉宽表的境地。

玩法变了

早些年，业务变化还没那么频繁，战略是一年定一次，KPI 政策是一年发布一次。

我们有充足的时间去规划、业务建模、领域建模、逻辑建模、物理建模、验证模型。如同那时候的爱情，车马慢，一生只够爱一人。

那时候行业的玩法基本一致，所以也有了 FSLDM 这种经典数据模型可以套用。一个模型搞定一个行业有没有？

但是现在，谁家的玩法跟别人一毛一样？没有！就算是短视频界的两个直接竞争对手--抖音和快手，都是那么迥然不同的逻辑：

一个偏向算法推荐，一个偏向社交关系。

更不用说现在火热的社区团购，都在抢占市场，业务模式每天都在变。

我自己都不敢相信，我会建设一个能够支持 KPI 政策一个月一调整的 KPI 数仓+核算体系！

玩法真的变了！这世道变了！

建模变了

在这种边开飞机边换发动机的时代，传统数仓规规矩矩建设的逻辑就不好使了，开始朝着非常诡异的方向发展。

一个方向，是规模大、技术强、业务趋于稳定的企业，如阿里、美团的固有业务，他们开始尝试一种全新的建模理念。

他们的主题域划分根本不遵循老一套的“中性、通用”，而是“个性、专用”。所以他们采用的是按业务流程划分主题域，因为这样才能更方便地支撑上面的业务指标体系。这样弄，上哪提炼一个通用的模型去啊？

在建模的时候，传统建模，DWD 层必须是范式建模，而且一般不对外提供服务。如果各部门需要明细数据，则各自建立 DM 解决。

而现在这些大厂的建模方式，则是尽可能压缩范式建模的范围，扩大维度建模的深度。以结构化指标体系开道，用维度模型向下不断穿透，直到 DWD 层。

是的，DWD 层也是维度建模。所有 ID 统一、代码转换、数据打平的事情放在哪里做？ETL 里做。

哦，不！应该改叫 ELT 了。先 Load ，再 Transformation 。因为超大量的数据输入，我们必须首先解决数据吞吐量的问题。

另一个方向，是那些创业公司或者大公司的新业务。这类场景的特点是业务一直在变，产品功能也在变，业务数据库也在变。

在这种场景中传统数据仓库建设的逻辑完全失效。因为根本不可能有人能在这么短的时间内，设计出一个能适应 2 周一次的迭代速度的数据仓库模型。

所以他们选择了简单粗暴的拉宽表！

这就是脉脉上百度小哥疯狂吐槽的根本原因。不是不去建模，而是根本没时间、没条件给你建模。

数仓已死？

那种业务趋于稳定的大厂毕竟是少数，更多的情况是创业公司、业务不断试错、调整的小厂。

在业务 1 个月变一次方向、产品 2 周迭代一次、业务数据库不断更新还没人告诉你的地狱模式下，基本上宣告了数据仓库的死亡！

这就像是在玩游戏。

以前是玩俄罗斯方块，我们得精心设计好，每一块砖都要放在合理的地方，垒得整整齐齐，等待那一根棍子的到来。

而现在，是在玩神庙逃亡，操作方式同样都是上下左右，但是你根本没办法想合理、结构、布局，稍微迟疑一些，就被怪兽咬到屁股了。

而对于那些业务日趋稳定的大厂，数据仓库同样也有巨大的困扰。就像新能源汽车车主总有里程焦虑一样，几乎所有的离线数仓工程师都害怕任务失败。

任务失败就意味着报表出不来，就意味着运营的白眼和扣绩效。

另外，我们的增量入库方案，由于数据迟到、业务逻辑复杂等各种原因，慢慢地变得越来越复杂。以至于一些小公司干脆直接每天全量，这导致数据延迟更加严重。

貌似一切正常的离线数仓 T+1 延迟，成为压死数仓的最后一根稻草。因为业务部门已经不能满足于看昨天的数据了。

“我们并没有做错什么,但不知为什么,我们输了”，诺基亚 CEO 的声音仿佛萦绕耳边。

什么？你说 Lambda 架构可以满足？是，这样是能出数，但是你拿实时和离线两个结果对比一下试试看？

你现在告诉我，拿什么拯救已然过了互联网淘汰年龄的数据仓库？

数据湖当立

当互联网 HR 对着年龄超限的数据仓库拿出辞退信的时候，另一个 HR 给一个 09 年才出生的小娃娃发出了 Offer 。

它就是数据湖。

它爹是 Pentaho 的 CTO James Dixon。James 创造它的时候，也没想到这家伙能变得这么牛掰。他当初只是想把磁带上存储的所有数据统统倒进一个地方，方便任意探索。

而现在的数据湖，已经成长为一个巨无霸！凭借着基于快照的设计方式、满足快照隔离、优秀的原子性、新元数据等巧妙设计，数据湖拥有了支持批流一体、完美增量入库、入库即可计算等特性。

这些特性意味着什么？

对于 ETL 工程师来说，意味着数据湖没有 T+1 ！太令人兴奋了！

但是更兴奋的是大数据架构师，数据湖不仅意味着什么数据都往里扔，更意味着一种新架构的诞生！

一个万能的架构，能够满足算法工程师随意淘换原始数据的架构，能够满足大数据工程师随时拉一张准实时宽表出来的架构，能够满足准实时数据增量接入和即时分析的架构，能够让大数据工程师不用早起看任务是否失败的架构。

架构变了

Kappa 架构中，最无奈的其实是 Kafka ，生把一个 MQ 整成了数据库。这也直接导致了 Kappa 架构无法存储海量数据的弊端。

 

但是这个弊端，数据湖可以解决啊。把 Kafka 改成数据湖之后，问题解决了。 Kafka 也终于歇了口气，可以卸下莫名其妙得到的“数据库”头衔。

 

而传统数仓的“数据孤岛问题，在数据湖面前，瞬间荡然无存。因为数据湖本来就是大杂烩，什么都往里装呀！

而且现在已经有各种组件与数据湖产品进行对接了。数据湖真的变成了一个湖！

 

这个架构简直了！

你可以用数据处理组件，从湖里抽数出来，抽完直接做成宽表扔给运营。

也可以写一个 DAG ，数据规整、打通之后扔其他数据库里。

对数据非常了解的人，可以利用查询组件，直接到数据湖里查数据。

算法工程师同样可以直接对接数据湖，从湖里捞原始数据投喂给算法，训练模型。

最关键的一点，OLAP 引擎也能直接对接数据湖！

这个就厉害了！换句话说，咱可以依据这个构建一个超级无敌的 OLAP 体系，准实时、不用复杂的分层建设、不用担心任务跑不完、业务要啥可以快速给出去！

唉，你以为我在耸人听闻，却不知已然是事实。数仓人的前路该往哪个方向？

 

说实话，这个问题我不知道怎么回答。时代在变迁，技术在进步，跟不上就必然会淘汰。

唉，数仓不知道死没死，但是数据湖已经来了。大家努力吧，加油！

你怎么看？