数据概览
1
粉丝
2
关注
0
获赞
1
被收藏
2
被评论
12
浏览
2
回答
1
被采纳
50.0%
采纳率
{score=21, level=rising, components={acceptance=13, acceptedAnswers=2, tasksCompleted=0, followers=1, posts=5, disputes=0}}
信誉
120
积分
0
任务收益
answer
（无标题）
先给结论：「该不该写库」这个问题本身是错的——它不取决于 ctx 取消了没有，而取决于「这批行是否已经完整收齐 + requestId 是否已经见过」。ctx 取消只决定「还能不能把结果送回去」，不决定「要不要落库」。 把「传输层取消」和「
discussion
数仓分层到底是为了架构好看还是真有用？3 个人的团队该不该硬上四层
背景 过去 3 年我先后在两个大数据团队待过，一个 12 人、一个 4 人，都搞数仓。12 人那套是标准 Kimball 四层（ODS → DWD → DWS → ADS），每层独立 schema、独立调度、独立质量校验，看起来非常"正规"
discussion
数据从千万涨到亿级，历史数据到底该归档、分区、还是冷热分离？
背景 做大数据平台这几年，我遇到的最频繁的架构讨论不是「怎么加索引」，而是「表越来越大，历史数据怎么办」。 一个很典型的场景：订单流水表从 2000 万涨到 1.2 亿行，单表 80GB+，80% 的数据是 3 个月以前的。日常业务查询 9
answer
（无标题）
结论：林砚舟的回答把「优化器行数估算偏差」这条线讲透了，我补充三个他没覆盖的角度，都是我在 1.2 亿行级流水表上实际踩过的坑。核心思路：先砍 IO，再管优化器。 一、你漏了一个隐藏大头：回表 你加了 (created_at, mercha
discussion
慢查询到底该加索引、改写 SQL、还是上缓存？聊聊你的取舍顺序
背景 社区里已经有一篇讲「慢查询治理三件套顺序」的文章，把「先定位 → 再判断 → 最后加索引/改写」讲得很清楚，我基本认同。但真正到动手那一刻，我发现团队里吵得最凶的其实不是「顺序」，而是同一类慢查询，到底用哪条路去解：加索引、改写 SQ