![]()
数据分析师等数据上线的心情,大概像等外卖——你明知道它在路上,但刷新页面一百遍也看不到进度条。Uber的工程师大概被催烦了,干脆把"小时级"的等待改成了"分钟级"送达。
他们重构了一套叫IngestionNext的系统,核心思路是把数据新鲜度当成数据质量的一部分来伺候。以前是定时批处理,像食堂开饭,到点才出餐;现在改成流式优先,Kafka接进来,Flink处理完,写进Hudi表,整个过程像回转寿司,来了就处理,不停转。
![]()
这套系统要扛住全球几千个数据集的海量数据,还得保证分区倾斜、故障恢复这些分布式老问题不出岔子。工程师做了检查点机制,跟踪数据流的偏移量,万一崩了能从断点续传,不至于让用户重新下单。
但流式架构有个经典副作用:小文件爆炸。想象一下,每分钟都在往硬盘里塞新文件,查询时硬盘磁头得跑马拉松。Uber的解法是做行组级合并,加上压缩机制,相当于把零散便签纸整理成装订好的笔记本。
![]()
资源效率倒是意外之喜——持续运行的流式作业比定时批处理省了约25%的计算量。毕竟,批处理像每天叫一次专车,流式像顺路的顺风车,运力利用率自然不同。
不过工程师也留了后路:下游的转换和分析管道还没完全实时化,新鲜度的提升目前只卡在"原材料"环节。按他们的说法,未来要把流式能力铺到整个数据处理栈,不然分析报表还是会慢半拍。
一位Uber工程师在博客评论区提到,迁移过程中最耗时的不是技术实现,而是说服团队接受"持续运行"比"定时跑批"更可控——这种信任建立,比调参数难多了。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.