实时数仓的写入链路，得先想清楚延迟底线是在哪
实时数仓头一桩怕的就是写入链路不靠谱，写进来的数时而对时而错，下游用着用着就不信了。写入这条线得在一开始就把延迟和可靠想清楚，想清楚才敢对外承诺。一、延迟先量底线
写入延迟先量出底线，量出来的那个数才是能答应业务的承诺。拍脑袋说几秒，真到了高峰远远超出，业务侧按承诺做不了决策，决策错了怪到你头上。写入监控看吞吐，吞吐掉下来往往比报错更早暴露问题。宽表字段别贪多，贪多之后取数慢，慢到业务不愿等就废了。
底线还要留余量，留了余量高峰才不破。不留的话，平时刚好压线，一来峰值就破底，破了底的数据迟到，迟到的数参与计算，结果就歪了。写入延迟先量底线，量出来的那个数才是能答应业务的承诺。元数据统一管理，管好了找数快，找数快了决策也快。
二、峰值要压测
没压测的链路，平时跑得好好的，大促一来直接堵，堵了数据堆在门口进不来。多源写入要排序，排序错了关联出来的结果全是歪的。宽表更新频率要想好，想不好频繁更新把查询全堵在门口。
压测要贴近真实形态，真实形态不是匀速，是忽高忽低。用匀速压出来的结论偏乐观，乐观到真实峰值一来就露馅，露馅时数据已经开始积压。写入峰值要压测，压测过的链路高峰才不丢数，不丢数才有信任。计算资源按需起，按需起比常驻一堆空跑的机器要省。
三、乱序要有处理
实时数据常乱序到达，乱序不处理，算出来的数和实际对不上。对不上的数比没有数更坑，没有数人知道没有，对不上的数人以为是对的。实时链路要有降级，降级到离线兜底，兜住了起码有数可用。冗余字段要权衡，权衡清楚才知哪些值得冗余哪些纯占地方。
处理乱序要设窗口，窗口内的迟到数据还能归位，过了窗口的要有别的去处。没去处就丢弃，丢弃要记一笔，记了才知道丢了多少，丢多少决定能不能凑合。乱序数据要有处理，处理不好算出来的数和实际对不上。新旧平台切换要并行，并行一段时间才敢关掉老的那套。
四、写入查询别抢资源
写入和查询别抢同一批资源，抢起来查询变慢，慢了业务就嫌弃。嫌弃了就绕开实时数仓自己另搞一套，另搞一套数据又多一个源头，源头多了更乱。湖仓一体省的是搬数据的工序，省下来的人力能做更多分析。宽表要有说明文档，没文档的人看到几十列根本不知从哪取。
资源要分池，写入池和查询池隔开。隔开了互不影响，写入猛的时候查询还能稳，稳了业务才愿意继续把实时数仓当主用，当主用才值回建设成本。写入和查询别抢资源，抢起来查询变慢，慢了业务就嫌弃。数据血缘要能追，追得到才知道一个指标被哪些加工过。
五、要能回溯
实时表要能回溯到某一刻，回溯不到那一刻，出了差额没法交代。差了一笔说不清是哪分哪秒引入的，说不清就只能认账，认账多了信誉受损。一套存储两种用法，口径统一了，离线和实时才不打架。粒度要统一，粒度混了聚合出来的数会差出一大截。
回溯靠的是版本或者快照，版本和快照要留够长。留短了刚要查的那段已经没了，没了就只能靠猜，猜出来的差额原因没人敢签字确认。实时表要能回溯，回溯不到那一刻，出了差额没法交代。冷热数据分存，分存了存储成本能压下来一截。
六、断点要能续
写入中途挂了要能续，能续就不用从头灌一遍。从头灌一遍，已经灌进去的重复，重复的数据要再去重，去重又是另一桩麻烦事。权限要分层，层不分清楚，分析的人能摸到不该摸的原始数据。历史宽表要归档，归档了查询才不会被陈年数据拖慢。
续传要有位点记录，位点记在哪一步，重启从那一步起。位点丢了只能全量重来，全量重来耗时耗力，耗时耗力的时候业务还在等数。断点续传要支持，支持的话中途挂了不用从头灌一遍。一体架构要有人懂，懂的人离职了，这套就变成谁都不敢动的黑箱。
实时数仓的写入是命门，命门守住了，数才进得来、信得过、追得回。延迟、压测、乱序、资源、回溯、续传，六件事做实，实时数仓才立得稳，不是摆给外人看的架子。 希望楼主常来发帖，持续输出优质内容，我们都会一直支持你。 不管是内容还是排版都很用心，看得出来楼主花了不少时间，必须支持。 很多点我之前都没想到，楼主一提醒才恍然大悟，收获很大。
页:
[1]