读罢《Columnar Storage Is Normalization》，忽觉技术演进亦有古典韵律。列式存储剥离冗余，恰似水墨留白——非为简陋，而是将数据本真凝于垂直脉络。开源项目如Parquet、DuckDB，以代码践行此道：查询时如指尖轻抚琴弦，只取所需音符，余韵自消。仔细想想作为常与数据打交道的产品人，深感这种“克制”之美：它让分析回归直觉，让工程师从JOIN的迷宫中抬头，见月明风清。诸君可曾留意，某个深夜调试时，列存悄然为你省下的那盏茶功夫？

说真的，看完你这帖子我第一反应是“这哥们儿又半夜修仙了是吧”。不过你描述的这个“克制之美”确实戳到我了，让我想起之前在大厂卷数据平台的时候，那些动不动就JOIN到天亮的夜晚。当时要是早点接触列存，可能我头发还能多留几根。

但我得吐槽一句，你把这技术比作水墨留白也太诗意了，实际调试的时候哪有什么琴弦轻抚，根本就是对着报错日志骂骂咧咧好吗？上次用Parquet调优，光一个schema evolution就让我喝了三杯浓茶才搞定。不过说真的，当你看到查询速度从龟爬变成火箭的时候，那种爽感确实比打游戏通关还上头。

话说回来，你们产品人现在都这么文艺了吗？连数据湖都能看出静水流深的意境了，改天要不聊聊维度建模的禅意？

roast你这“喝了三杯浓茶才搞定schema evolution”我可太有画面感了！不过等等——你是不是用的旧版Parquet？我前阵子帮一个做实时数仓的朋友调优，他死活卡在字段新增上，后来扒到社区群里有个阿里云老哥悄悄放了个patch，说是内部早就绕过那个坑了，但文档压根没写……你们大厂当年卷的时候难道没人传这种“地下秘籍”？
卧槽
话说回来，你提打游戏通关那一下真戳我笑点。好家伙上周我通宵肝《Apex》，结果第二天白天调试DuckDB，看到查询跑出30ms的时候差点从椅子上跳起来——比吃鸡决赛圈一穿三还刺激！不过你头发的事儿别光甩锅JOIN啊，我送外卖那会儿见过凌晨三点写字楼里一堆人边啃煎饼边改SQL，那场景比说唱battle还惨烈……

卧槽对了，你既然玩过Parquet调优，有没有试过把压缩算法换成ZSTD？我听说字节那边早这么干了，省存储不说，I/O直接起飞。还是说……你们当年被Kafka背压折磨得根本顾不上这些细节？