技术与业务之间，总是隔着最后一公里。而在数据仓库建设中，这最后一公里尤其明显。
刚开始做数仓的时候，我关注的事情其实很简单。
数据能不能接进来，模型能不能建起来，SQL 能不能跑通，报表能不能按时产出。
做得久了以后，我反而越来越觉得，SQL 可能是这里面最省心的一部分。
真正让人疲惫的，很多时候都发生在 SQL 之外。
我们现在的湖仓接入了 180 多个上游系统、3800 多张表，向下又支撑大量报表、监管报送、接口，以及 100 多个业务系统。
做到这个规模以后，会有一种很明显的感觉：
几乎所有系统都和你有关系。
核心系统改了，和你有关系；信贷系统改了，和你有关系；某个管理系统出了一张报表，和你有关系；上游多了一个码值，可能也和你有关系。
可真到出了问题的时候，又经常很难一句话说清楚，这件事到底应该由谁负责。
数仓最开始承担的是数据加工。
做着做着，却慢慢开始承担数据清洗、业务口径确认、系统之间的数据中转、异常排查、需求协调、生产保障、资产管理，甚至一些历史知识的传承。
这里面很多事情，并不是谁一开始设计数仓的时候就计划让它承担的。
只是系统越来越多，需求越来越多，时间越来越久，事情一点一点汇聚了过来。
这篇东西也不想讲什么标准答案。
更多只是把这些年做数仓时，一些越来越明显的感受写下来。
一、数据进来了，问题并没有结束
1. 大量时间，其实都耗在那一点点异常数据上
我们现在有 3800 多张表入仓，涉及 180 多个上游系统。
这么多系统，数据标准不一致，我现在反而觉得是一件很正常的事情。
特别是中小银行，不可能所有系统都是自己从头研发的。不同系统来自不同厂商，有不同的产品历史、设计习惯和数据标准。
你很难要求所有源系统为了行内统一标准，全部重新改造一遍。
成本太高，也不现实。
所以很多事情最后自然落到了数仓。
上游的数据可以各有各的样子，进到数据体系以后，我们再想办法清洗、转换、映射、校验，让它们尽量能够被统一使用。
刚开始做开发的时候，我也会觉得，一个报表或者接口，SQL 又不复杂，为什么会做这么久？
后来自己做得多了，就知道不是这么回事。
大部分需求其实都用不到什么特别高深的算法。
关联、过滤、聚合、窗口函数，翻来覆去也就是这些。
真正花时间的是另外一些东西。
一个字段突然出现空值。
一个原来只有 01、02、03 的码值，某一天变成了 04，但没人告诉你。
两个系统明明描述的是同一笔业务，金额或者状态就是对不上。
有些系统表结构本身就不太适合分析。
甚至有些客户维度的信息，源系统里没有一张完整的客户表，最后还得从交易明细里去重、拼接，才能勉强还原出来。
技术测试发现一个问题，回来改。
业务测试再发现一个特殊场景，又改。
上线以后碰到历史数据，再改。
最后一个 SQL 可能只有几十行。
但前前后后大量时间，都耗在一句话上：
“这条数据为什么会这样？”
这也是我后来和团队做需求时越来越不愿意单纯用“SQL 复杂不复杂”判断工作量的原因。代码短，不代表事情简单。
2. 很多业务口径，并不是开发前确定的，而是在开发过程中慢慢长出来的
这是数仓里一个非常常见的场景。
需求来了，对方说：
我想要一张表。
然后呢？
什么粒度？
有哪些指标？
指标到底怎么算？
数据从哪里来？
同一个字段出现多个来源的时候以谁为准？
很多时候其实都还没有想清楚。
有时候需求会更直接：
源系统有什么字段你就给我什么，越多越好。
或者：
把 XXX1 表和 XXX2 表合起来，做一张新的 XXX3 表。
如果只是从系统功能角度看，这个要求似乎很好理解。
但做数据的人都知道，两张表能不能“合”，根本不是把字段拼到一起这么简单。
一个可能是一笔业务一条记录。
另一个可能是一笔业务对应十几条明细。
到底保留一对多，还是先汇总？
重复数据怎么算？
金额按哪边？
状态按哪边？
历史数据怎么办？
这些问题最后还是要有人回答。
而它们其实已经不是 SQL 问题了。
于是现实中的开发过程，经常变成：
先根据现有理解做一版。
业务拿去测，觉得不太对。
继续聊。再改。再测。
聊着聊着，大家才慢慢发现，原来一开始理解的“这张表”根本不是同一张表。
等口径终于差不多确定下来，时间可能已经过去一两个月。
然后很容易听到一句：
这个需求怎么两个月还没开发好？是不是你们资源没给够？
直到现在我听到这种话，还是会觉得我们数据团队的同事挺委屈。
站在需求方的位置，他确实看到需求已经提了两个月。
只是站在开发这一边，前一个月可能根本不是在“开发”，而是在和业务一起把需求重新定义出来。
所以现在回头看，我觉得问题倒不一定是谁效率低。
很多需求进入开发的时候，本身就还没有准备好。
数仓开发在这个过程中，不知不觉又承担了一部分业务分析和需求撮合的工作。
这件事很难完全避免，只是成本往往没人看得到。
3. 表越来越多，不等于真正沉淀出了数据产品
数仓做几年以后，表一定会越来越多。
但我现在越来越不愿意用“有多少张表”衡量数据资产做得好不好。
因为表多和好用，完全是两回事。
我们经常碰到这样的需求：
我要员工数据，你们之前给其他系统什么，就照样给我一份。
听起来很合理。
但真正问下去就会发现，大家嘴里的“员工数据”并不是一个东西。
有人要当前组织关系。
有人要历史组织关系。
有人关心岗位。
有人关心权限。
有人只需要基础信息。
还有人需要某些特殊业务属性。
客户、机构、账户、产品、交易也一样。
如果没有真正沉淀出稳定的数据产品，那么即使已经有几千张表，新需求来了还是得重新问一遍：
到底用哪张？
哪个字段可信？
之前为什么这么处理？
这张表是不是还有别的系统在用？
这个口径到底适不适合现在这个场景？
所以有一段时间我会发现一个挺尴尬的情况。
数据越来越多，表越来越多，但重复加工并没有明显减少。
后来才意识到，我们过去沉淀下来的很多东西，其实只是“表”。
离“拿过来就能放心用的数据产品”，还有一段距离。
二、最难说清楚的，往往是边界
4. 湖仓能力越强，越容易变成系统之间的万能转接头
这个问题我印象很深。
有一次我在一个群里看到 A 系统的人对 B 系统说：
我单独给你开发一个 API 很慢，你直接让湖仓把我的表卸下来，再推给你吧。
然后湖仓开发人员被拉进了群。
对方只说了一句：
你们对接一下。
源表是什么，没有。
字段说明，没有。
业务口径，没有。
测试环境怎么走，没有。
生产怎么对接，也没有。
甚至双方到底谁是负责人都说不清楚。我当时非常生气。
我直接把我们整理的数据对接文档发到群里，让双方先把源表、字段、频率、口径、负责人、测试方式、生产路径全部补完整，补完再谈开发。
结果到了真正需要填这些内容的时候，双方反而开始扭扭捏捏。
没有一个人愿意把事情完整接下来。
后来类似的事情碰多了，我也慢慢理解这种现象为什么会发生。
因为大家真正关心的是：
“数据能不能过去？”
至于谁定义、谁验收、以后出了问题找谁，往往是等出了问题以后才开始讨论。
而湖仓恰好又特别适合干这件事。
能抽。
能算。
能推。
能定时。
接一个新系统，比两个系统各自重新开发一套接口快多了。
短期看确实提高了效率。
问题是这种事情做过一次以后，很容易就会有第二次、第三次。
最后湖仓慢慢变成了系统之间的万能转接头。
5. 有些系统职责我们承担了，但系统并不真正属于我们
还有一些管理系统，本身只提供比较简单的增删改查。
复杂一点的规则计算、状态判断，甚至核心数据加工，实际上大量依赖湖仓。
平时运行正常的时候，大家一般不会特别意识到这一点。
一旦生产有问题，第一个动作往往就是把湖仓开发拉进群：
请数据配合排查。
这句话我们听得太多了。
有时候最后一查，确实是湖仓的问题。
有时候是上游的问题。
有时候是业务规则本身有问题。
还有时候查了一晚上，最后发现和数据一点关系都没有。
但你很难不去。
因为系统已经事实上依赖你的结果了。
这也是我后来越来越觉得别扭的一件事情：
我们承担了一部分系统职责，却没有真正获得这个系统的所有权。
它什么时候上线，不由我们决定。
业务规则怎么设计，不由我们决定。
源系统什么时候改字段，也不一定提前告诉我们。
但最终数据一旦不对，我们又一定在排查名单里。
很多生产上的疲惫，其实就来自这种边界。
6. 数据依赖，经常到了项目快上线才突然被想起来
这种事情也碰到过很多次。
一个系统从需求、设计做到开发，已经进入测试阶段。
距离上线没几天，突然有人说：
对了，这个功能还需要湖仓提供一份数据。
然后我们被临时拉进群。
这时候其实已经没什么空间讨论优先级了。
需求可能还没说清楚。
排期没有。
测试窗口也很短。
但上线时间通常不能改。
因为最后会变成一句：
不提供这份数据会影响项目上线。
所以只能先做。
紧急开发，紧急联调，紧急测试。
必要的时候加班上线。
外部看起来，这是一个临时插进来的“小需求”。
站在数据的角度，我很想骂人。因为这明明应该在需求设计阶段就被识别出来。
如果一个系统上线以后必须依赖另一套数据才能运行，那它就不是最后几天顺手补上的东西。
只不过很多项目在早期做架构设计的时候，并没有把“数据怎么来”当成和功能同等重要的一件事。
7. 每个人的事情都重要，最后只能由数仓自己做取舍
做数仓还有一种压力比较隐蔽。
就是几乎每一个需求方都觉得自己的事情应该优先。
这其实也可以理解。
监管报送当然不能延迟。
生产故障当然要马上处理。
重点项目马上上线，也不能等。
某个业务系统联调卡住了，对他来说整个项目组可能都在等你这一份数据。
但与此同时，团队自己还有计划内的需求、平台优化、数据治理、技术债。
没有哪个需求方会主动对你说：
我的事情不着急，你先做别人吧。
所以最终优先级判断这件事，还是会落到数据团队自己身上。
监管报送和普通需求怎么排？
生产事故和项目建设怎么排？
一个开发量很小、但风险很高的事情，要不要插队？
大项目联调期间，原来的计划是不是全部往后挪？
团队人数通常不会突然增加。
但计划外工作是会突然增加的。
有时候一个月排好的计划，可以被生产问题、重大项目和临时需求重新打散四五遍。
然后月底别人来问：
这个需求为什么一直没做完？
这个时候你很难用一句“最近比较忙”解释清楚。
因为对方看不到这一个月中间发生过什么。
这也是为什么我后来越来越觉得，数仓的资源问题不只是“人够不够”。
更麻烦的是计划外工作太多，而且其中很多事情根本没有拒绝的空间。
8. 血缘能告诉我们影响了谁，但后面的事情还得靠人解决
我们这些年一直在做血缘和影响分析。
这个方向肯定是对的。
以前上游说改一张表，大家凭经验看，觉得可能就两张报表受影响。
真正把血缘拉出来以后，发现下面挂着 50 多个程序。
有了血缘至少不会再凭感觉猜。
但做得越深，我越觉得血缘也不是万能的。
它可以告诉你：
这个字段一改，下面谁会受影响。
可接下来还有很多事情：
上游应该提前多久通知？
字段能不能直接删？
新增码值要不要通知？
类型修改怎么算重大变更？
旧字段要保留多久？
什么时候提供测试环境？
50 多个下游到底谁来组织回归？
这些都不是画一张血缘图能够解决的。
所以血缘做到后面，自然会碰到另外一个问题：系统之间到底有没有变化规则。
如果没有规则，即使今天很清楚下面有 50 个程序受影响，最后的处理方式可能还是——拉一个群，然后从头协调。
三、一个大项目，往往会把整个数仓一起拖进去
9. 对上游是一次系统改造，对数据团队却经常是一次全链路改造
有一类工作，我现在只要听到项目名字，大概就能判断接下来一段时间团队会很忙。
新核心系统改造、新收单系统、国业 FTU 改造、新绩效系统、新信贷系统……
只要这个系统足够重要，基本不可能和数据开发没有关系。
因为重要系统很少只服务自己。
它的数据可能已经入仓。
下面可能挂着大量报表。
监管报送可能在用。
其他系统可能通过湖仓拿它加工后的结果。
管理分析、绩效、接口，也可能一层一层依赖它。
所以上游项目说：
核心系统升级了。
我们听到的其实是另外一件事情：
源表可能要变。
字段可能要变。
码值可能要变。
业务规则可能要变。
数据粒度也可能变。
然后下面那一长串东西都得重新确认。
这类项目最麻烦的地方，往往还不是“要写多少程序”。
重大项目上线时间通常比较硬。
核心、信贷、国业这种项目，不太可能因为数仓工作量比较大，就往后推几个月。
所以只要它进入关键阶段，团队原来排好的普通需求、治理、优化工作基本都得让路。
外面看是“配合一个项目”。
对团队来说，可能意味着未来几个月的计划全部重排。
而真正耗人的，经常还是测试。
有时候上游改了一张表，我们最后真正修改的 SQL 可能没有多少。
但是你不能只证明：
新数据能入仓。
你还得往下看。
原来的加工逻辑还能不能成立？
数据量有没有明显变化？
码值是不是变了？
主键有没有变化？
原来一对一的关系是不是变成了一对多？
日报正常不正常？月报呢？
监管报送呢？
接口下发呢？
下游系统还能不能正常消费？
有时候代码只改一点点，回归清单却能列很长。
因为真正要证明的不是“我改完了”。
而是“这次改造没有把原来的东西弄坏”。
这一点尤其耗精力，也最容易被低估。
新旧系统并行的时候会更麻烦。
像新收单系统这种，并不是到了某一天旧系统直接关掉，新系统无缝接过来。
中间总有一个过程。
新老数据怎么对应？
上线前后的历史怎么衔接？
同一笔业务两边能不能对上？
并行期是不是要双跑？
结果不一样听谁的？
新系统如果出了问题能不能切回去？
一旦再加上存量迁移，事情就更多了。
余额要核。
笔数要核。
关键指标要核。
历史数据完整性也要核。
做到这个时候，数仓实际上已经不是“接几张新表”了。
我们是在参与整个系统切换的数据验收。
更麻烦的是，上游项目上线，并不意味着数仓这边也结束了。
系统上线当天正常，只能证明当天正常。
第一个工作日呢？
第一次日终批量呢？第一次月末呢？
第一次监管报送呢？
某些一年只出现几次的低频业务呢？
有没有测试环境里从来没出现过的新码值？
很多问题并不会在上线当天出现。
开会、评审、字段核对、数据探查、联调、问题定位、新旧数据比对、测试数据准备、陪业务验证、生产演练、上线值守、补数……
这些工作最后很难全部体现在“开发了几个需求”里面。
有时候一个项目持续投入了几个月，最后回头看代码提交，好像也没增加多少。
但人已经被占住了几个月。
经历过几次这种项目以后，现在反而不太先问“要开发多少东西”。
而会先想：
这次有多少链路要重新证明它是对的。
对上游来说，可能只是一次系统升级。
对数据团队来说，经常是一次迁移、兼容和全链路回归工程。
而且数仓往往不是最早进入项目的人，却很可能是最后一批真正退出项目的人。
四、平台越稳定，维护它的人反而越忙
10. “能做到”这件事，很容易慢慢变成“本来就应该做到”
技术能力上来以后，业务对数据时效的要求也会不断提高。
最开始 T+1 就够了。
后来希望凌晨早点到。
再后来希望当天。
然后半小时、5 分钟、实时。
从技术上说，这些事情大部分不是完全做不到。
问题是每往前走一级，成本都不是简单多加一点机器。
调度要调整。
容量要重新评估。
上游的稳定性要求更高。
失败重试、补数、监控都更复杂。
生产保障也得跟着升级。
但这个过程外部通常感受不到。
大家最容易记住的是：
上次那个系统不是已经做到 5 分钟了吗？
第一次是特殊需求。
第二次会被当成案例。
第三次就开始变成一种默认能力。
于是“我们能做”慢慢变成“你们本来就应该做”。
这个问题我觉得不能简单怪业务。
能力已经摆在那里，大家当然会希望用更好的。
真正需要提前想清楚的是，不同数据到底需要什么级别的服务。
有些东西实时很有价值。
有些东西 T+1 已经完全够用。
如果所有需求默认都往最高时效走，最后承担复杂度的一定还是平台自己。
11. 平台越重要，越难腾出完整时间去建设平台
这个循环我感受很深。
数仓每天都有很多事情不能不处理。
批量任务异常。
上游数据晚到。
文件没来。
接口异常。
数据库问题。
上游突然改数据。
补数。
重跑。
上下游协调。
到了月初、月末，还有大量报表和监管报送。
这些事情都有一个共同特点：
今天发生了，今天就得有人管。
而架构优化、资产建设、自动化、数据治理、技术债、团队能力建设这些事情，通常不是今天不做，系统今晚就会挂。
所以它们最容易往后排。
明天再做。
下周再做。
等这个项目结束再做。
等月末过去再做。
可等项目结束，下一个项目又来了。
以前我也会想，是不是我们把计划排得再好一点，这些事情就能挤出时间。
后来发现没这么简单。
一个已经承载大量生产任务的平台，维护它本身就会不断消耗团队的精力。
治理做得少，故障和重复劳动就会增加。
故障和重复劳动增加以后，就更没有时间治理。
这个循环一旦形成，很难靠一句“加强治理”解决。
如果一个团队 80% 的精力都花在保证昨天的东西今天还能继续跑，那么它其实很难有足够空间建设明天。
12. 调度是绿的，不代表数据就是对的
这是做数据以后特别容易形成的一种警惕。
程序可以完全正常执行。
SQL 没报错。
调度平台也是绿色。
数据顺利写进目标表。
但结果照样可能是错的。
上游可能少了一批数据。
Join 条件可能让数据翻倍。
新增码值没有进入原来的判断逻辑。
一个字段的业务含义可能已经发生变化。
甚至技术实现完全符合需求文档，但需求文档从一开始就理解错了。
所以数据测试和普通程序测试总有点不一样。
程序跑没跑成功，只能回答一部分问题。
剩下的还得看：
数据量正常不正常。
分布有没有明显变化。
历史趋势是不是合理。
上下游能不能对上。
业务拿结果看是不是符合真实场景。
这也是为什么有些问题技术测试怎么都测不出来，最后到了业务测试甚至生产才暴露。
不是程序没跑。
恰恰相反。
程序跑得非常成功。
只是成功地产生了一份错误的数据。
五、系统会留下来，人一定会变化
13. 有些程序每天都在跑，但已经很难说清楚真正的负责人是谁
湖仓运行时间长了以后，这个问题一定会越来越明显。
脚本越来越多。
但负责人不一定越来越清楚。
我们不可能把每一个程序永远绑定到当年的开发人员身上。
实际管理时，一般会按客户域、账户域、产品域这些主题做大致分工。
可真正的数据链路里，还有大量中间表、公共表、历史兼容任务，以及一些当年看起来是一次性需求，最后莫名其妙运行了很多年的程序。
人员调过几轮以后，很容易出现一种情况：
程序每天还在正常跑。
但真出了问题，已经没人能直接说：
这个东西就是我负责的。
于是只能顺着链路找。
问前面：
这个数据是不是你们出的？
再问后面：
你们是不是用了这张表？
最后还是靠几个熟悉历史的人，根据经验把问题领走。
以前我们其实很习惯按照“代码是谁开发的”管理程序。
后来我越来越觉得，这种方式在系统早期没问题，时间一长就会失效。
因为代码负责人会变。
真正应该长期存在的，可能是这份数据本身的责任关系。
谁认这个业务定义。
谁保障生产。
谁关心质量。
谁在使用。
出了争议以后谁能拍板。
这些东西如果没有跟着数据一起沉淀下来，时间越久，就越容易说不清楚。
14. 做数据建设的人，最后还在用 Excel 管自己的数据资产
这一点我觉得首先是我的管理问题。
这么多年，我们自己的很多数据资产信息，仍然依赖 Excel 和文档维护。
有哪些表？
有哪些接口？
谁在用？
字段是什么意思？
数据从哪里来？
多久更新一次？
负责人是谁？
很多内容最后还是散在 XLSX、文档，或者某几个人的脑子里。
这件事情其实挺讽刺的。
我们天天在帮别人做数据建设，自己的资产管理却没有真正数据化。
当然，我不是觉得 Excel 不好。
东西少的时候，Excel 很好用，甚至可能是最高效的。
问题是到了几千张表、几百个系统、上千份报表，再加上一堆接口以后，它开始兜不住了。
因为这个时候大家真正想查的，已经不是：
我们有哪些表？
而是：
这张表到底干什么？
数据从哪来？
谁在用？
为什么这样加工？
谁负责？
最近还有没有人用？
如果我改了这个字段，会影响谁？
出了问题应该先找谁？
这些信息如果查不到，那资产台账做得再整齐，也还是一个台账。
这也是我后来想做数据资产门户这类东西的一个很直接的原因。
不是为了把 Excel 搬到网页上。
而是很多原本靠人记住的关系，确实到了应该由系统自己维护的时候。
15. 上游不知道自己的数据去了哪里，下游也不知道自己的数据从哪里来
有一次上游系统改动上线，凌晨湖仓任务报错。
我们电话联系上游负责人。
对方听完以后很惊讶：
原来我的系统也有数据入仓吗？
第一次听到的时候会觉得有点不可思议。
后来想想，其实也不能完全怪他。
一个系统接入湖仓几年以后，最早负责对接的人可能已经离开或者换岗了。
后面接手的人主要负责系统自己的业务功能。
只要数据一直正常抽取，他根本没有机会知道，其中几张表每天还在被另外一套平台使用。
下游其实也一样。
业务可能知道：
我的报表用了这个指标。
但他未必知道这个指标上面经过了多少层加工，又依赖哪些源系统。
正常的时候，大家都不用知道这么多。
一旦上游变化，问题就出来了。
上游不知道自己改一下会影响谁。
下游也不知道自己的数据源已经变了。
以前我会把血缘更多看成资产展示能力。
现在我越来越觉得，它首先是生产风险控制的一部分。
不是图画得好不好看。
而是上游要改东西的时候，我们至少得知道应该去敲哪些人的门。
16. 文档能交接流程，但很难把一个人的判断完整交出去
系统运行时间越长，我越觉得真正难交接的东西不一定在代码里。
比如：
为什么这个字段当年要这么处理？
为什么这个任务失败以后不能直接重跑？
这个源系统历史上出过什么特殊问题？
哪些生产异常可以直接补数？
哪些一定要先联系业务确认？
这段代码看起来明明很多余，为什么一直没人敢删？
这些东西当然可以写进文档。
而且应该写。
但真正到了生产现场，很多判断不是看一遍操作手册就能学会的。
有些经验来自一次生产事故。
有些来自某个历史项目。
还有些东西，是一个人连续处理了很多次以后才知道：
“这种情况看起来一样，其实不能这么处理。”
所以我后来对“交接”这件事也有了点不同的理解。
写清楚怎么做，只是第一层。
更难的是写清楚：
为什么这么做。
为什么这里不能那么做。
如果换一种情况，判断标准是什么。
人员一定会变化。
系统复杂度却基本只会往上走。
如果经验沉淀的速度跟不上复杂度增长，每一次人员调整，多多少少都会带走一点东西。
而这些东西往往要等下一次异常发生，大家才发现原来没人知道了。
六、做久了以后，我反而没那么关注“还能再接多少数据”了
回头看前面这些问题，会发现它们表面上都不一样。
有的是数据质量。
有的是需求。
有的是系统边界。
有的是项目管理。
有的是资产治理。
有的是生产稳定性。
有的是人员交接。
可最后很多事情都会落到数仓。
原因也不复杂。
数仓连接了大量业务系统，但这些系统并不属于数仓。
我们需要对加工结果负责，却不能完全控制数据源。
我们支撑很多业务需求，却没有最终的业务决策权。
我们承担大量生产保障，又很难控制所有上游变化。
站在这个位置上，很多原本属于不同系统、不同部门、不同阶段的问题，最后都会从数据这条链路上体现出来。
刚开始做数仓的时候，我更关心的是：
数据能不能进来。
后来开始关心：
数据加工得对不对。
再往后，会关心这些数据能不能被找到、被理解、被重复使用。
做到现在，我反而越来越觉得，最难管理的已经不是“数据”这两个字本身了。
表总能建。
SQL 总能写。
数据也总有办法接进来。
真正麻烦的是几年以后，系统换了，人也换了，我们还能不能回答清楚：
这份数据为什么在这里？
这个口径为什么这么定义？
谁在使用？
谁应该负责？
上游变了以后会影响谁？
这里面那些看起来奇怪的历史逻辑，到底为什么不能删？
数据可以通过 ETL 自动进入仓库。
但责任不会。
业务语义不会。
历史经验也不会。
这些东西如果没有被有意识地留下来，就只能一直依赖人。
可能这才是我现在理解的，数仓真正的最后一公里。
数据可以入仓，但责任、语义和经验不会自动入仓。
评论
评论 API 尚未配置。