本文来源于数据从业者全栈知识库，更多体系化内容请访问知识库。
上一篇文章发出去之后，有个读者留言说：道理我都懂，地基要打好。但问题是，我们公司的数据系统已经跑了七八年了，中间换过三拨人，现在连”地基在哪”都说不清了。
这条留言让我想多说几句。
因为他说的不是个例。这几乎是我见过的所有中型以上公司的常态。
我想请你试着回答一个问题：你公司的某条业务数据——比如”昨天的订单转化率”——从最初被埋点采集，到最终出现在老板看的报表上，中间经过了几道手？经过了哪些系统？被谁处理过？在哪一步被聚合、被过滤、被重新定义过？
大多数人答不上来。
不是因为他们不称职。而是这个系统，真的已经复杂到没有任何一个人能从头到尾讲清楚了。
这件事是怎么发生的？不是一夜之间，而是十几年来，我们每”解决”一个问题，就往系统上加了一层。层层叠叠，加到今天，系统本身成了最大的问题。
每一层，当初都是来”救命”的
我们先倒回去看看这些层是怎么来的。
最早的时候，没什么数据系统。业务数据就在生产数据库里。需要出个报表？写条 SQL 直接查。简单粗暴，但够用。
后来数据量大了，直接查生产库扛不住。于是有人说：我们把数据抽出来，放到一个专门做分析的地方吧。这就是数据仓库的由来。配套地，还需要一套搬运数据的工具——ETL，把数据从这边抽出来、洗干净、装到那边去。
这一层解决了”分析不能影响生产”的问题。合理。
再后来，业务越来越多样，数据格式五花八门——有结构化的表格，有半结构化的日志，有非结构化的文本和图片。传统数据仓库装不下这些东西了。于是数据湖出现了：别管什么格式，先都扔进来再说。
这一层解决了”数据类型太杂收不进来”的问题。也合理。
但数据湖很快有了自己的问题：什么都往里扔，扔着扔着就成了数据沼泽——进去的东西再也找不到了。于是又有人搞出了 Lakehouse，试图把数据湖的灵活和数据仓库的规范结合起来。
再往上走。业务部门说：我也不懂什么仓库不仓库的，我就想知道”月活用户”到底是怎么算的，你们技术这边三个团队给我三个数字。于是语义层（Semantic Layer）出现了，试图统一业务指标的定义。
每一层都有道理。每一层都是在解决上一层解决不了的问题。
但每一层加进来，都带来了三个副作用。
第一，多了一批新工具。新的系统、新的配置、新的维护。
第二，多了一批只懂这一层的人。搞 ETL 的不太懂数据仓库的建模逻辑，搞仓库的不太懂数据湖那边的存储策略，搞语义层的不太懂底下数据是怎么流上来的。每个人都是自己那层的专家，但没人是整条链路的专家。
第三，层与层之间的”接缝”成了最危险的地方。数据在这些接缝里被转换、被重定义、被悄悄改变了含义。而这些变化，往往没有文档记录。
十几年下来，你面前的不再是一个系统，而是一摞系统。像一栋不断加盖的楼——一楼是砖混的，二楼是钢结构的，三楼是木头搭的，四楼不知道谁加的，用的材料谁也说不清。每一层单独看都挺结实，但整栋楼？没有一张完整的图纸。
