宽表字段不是越宽越好，取数一慢就真是本末倒置
本帖最后由 我爱LV游 于 2026-11-7 01:19 编辑宽表把常用字段摊平在一张表里，查起来是快，但宽过了头就走向反面。字段越多，更新越重，取数越慢，慢到业务不愿等，宽表就从一个好主意变成负担。
一、字段别贪多
业务等不及就绕开宽表自己查源，绕开一次，宽表就少一份存在感，存在感没了就更没人维护。宽表改结构要慎重，慎重是因为下游不知道有多少报表挂着。原始数据落湖前先定格式，格式乱了后面接的人全在填坑。
加字段前先问会不会常用，不会常用的别往宽表里塞。塞进来的字段躺着不动，躺着占着存储和索引，存储和索引都被占着，真正要的反而挤不过来。宽表字段别贪多，贪多之后取数慢，慢到业务不愿等就废了。对齐工作别拖，拖到两边差异大了再理，理起来费十倍力气。入湖失败要有重试，重试几次还不行就告警，别静默丢数。
二、更新频率要想好
更新和查询抢同一张表，更新一频繁，查询排长队，排队的业务侧体验直线下降。关键字段加校验，校验拦住脏数据，脏数据进宽表害人不浅。数据来源要登记，登记清楚才知道哪份对不上时能找谁。
不同字段更新频率差很多，差的就分开存，别全挤一张表统一刷。统一刷为了一个常变字段，把一堆不变的一起重写，重写浪费的还是那台机器的力气。宽表更新频率要想好，想不好频繁更新把查询全堵在门口。口径变更要同步通知，通知不到的团队照旧用老算法出数。不同部门的数据要能区分，区分不清就分不出谁动了哪份。
三、要有说明文档
不知从哪取就只能问老人，老人被问烦了甩个查询语句，查询语句对不对没人复核，复核缺位迟早出错。宽表不是终点，终点是对业务问题的回答，回答不出来就白建。入湖频率按源来定，硬凑成统一节奏反而把实时源拖慢。
文档还要标每列口径，口径标清了跨人查才一致。不一致的两个人查同一张表，出来两个数，两个数对不上，对不上就开始互相质疑对方查错了。冗余字段要权衡，权衡清楚才知哪些值得冗余哪些纯占地方。源头改了要往下传，传不到的下游还在用旧逻辑算。湖里数据量涨了要预估，预估晚了存储爆了比慢更让人慌。
四、粒度要统一
差一大截的报表递上去，上面按错的做判断，判断错了再往下传，传到底发现源头粒度就乱了。离线和实时口径先对齐，对齐了两边出的数才敢放在一起比。历史数据别随便删，删了那天要复盘早年的事就抓瞎。
粒度统一还要贯穿上下游，上游细下游粗会丢信息，上游粗下游细补不出。补不出就只能接受粗略，粗略到决策层嫌不够用，不够用又回头怪宽表。宽表要有说明文档，没文档的人看到几十列根本不知从哪取。定期对账不可少，对账能早早发现两边悄悄走偏的那点差异。写入延迟先量底线，量出来的那个数才是能答应业务的承诺。
五、历史要归档
不归档，表越滚越大，越大的表扫描越久，久到例行查询都成了性能瓶颈，瓶颈卡住日常。同一指标定义写一处，写两处迟早两个版本对不上。敏感字段进湖前先去标识，去标识漏一项后面合规查起来头疼。
归档不是删，归档是挪到慢一点的存储。挪走了主表轻，轻了日常快，真要查陈年再去找归档，找得到比找不到强，强在审计时能兜底。粒度要统一，粒度混了聚合出来的数会差出一大截。实时先出近似值，近似值留痕，留痕后离线核准再更正。
六、改结构要慎重
挂着的报表改了字段就报错，报错一批接一批，接一批修一批，修的人手忙脚乱。实时偏差要有容许范围，有范围才知道什么时候该人工介入。元数据先建起来，没元数据的湖就是一堆认不出名字的文件。
改之前先摸清依赖，摸清了分批改，分批改影响面小，小到能逐个验证。验证过了再放，放出去心里有底，有底才不担心半夜被叫起来救火。历史宽表要归档，归档了查询才不会被陈年数据拖慢。对齐要有负责人，负责的人不出面，两个团队互相推说对方错了。
宽表是给常用查询开的快车道，快车道不能无限拓宽。字段、频率、文档、粒度、归档、结构，六件事守住，宽表才又快又稳，不是越宽越好的怪物。 这个话题确实很值得讨论，我也有类似的经历，非常认同楼主的观点。 感谢楼主愿意花时间分享，让我们这些后来者能少踩很多坑。 逻辑严谨，条理分明，一看就是经过认真思考和整理的内容。
页:
[1]