工程实践Greptime 技术
文章基于 OpenAI 在 Apache Community Over Code EU 2026 的两场公开演讲，梳理其超大规模 Spark 可观测性演进。OpenAI 每天运行数十万 Spark 应用，事件日志常超 100GB，History Server 首次加载曾需约半小时。团队先通过 Kafka/Flink/Delta 让事件日志可查询，又用驱动端快照和 Rust History Server 将加载提速（P90 约 10 倍、P99 约 30 倍），再让带边界约束的 Agent 技能参与排障。最终他们将 Spark 指标、事件和日志统一写入 GreptimeDB，替代部分 Flink 解析链路和 S3 快照，并利用 Parquet 开放格式与湖仓互通。文章也指出约两周查询保留、profile 仍依赖 Pyroscope，以及该方案未必适合所有团队等边界。
推荐收录：虽然来自 Greptime 的厂商博客，但正文以两场公开演讲的时间戳为证据，给出规模数字、四阶段演进、GreptimeDB 替换链路的原因与保留周期等具体工程细节。对 Spark 平台、可观测性、SRE 与数据基础设施团队有较高迁移价值，尤其是减少重复管道、统一查询状态、让 Agent 在受控工具边界内取证；阅读时需意识到厂商立场并回看原始演讲。
工程实践Netflix TechBlog
文章复盘 Netflix 会员会话化 Spark 流水线升级中大规模 OOM、shuffle 溢出与阶段重试的工程案例。因小样本无法复现问题，作者根因定位到数据倾斜与长尾会话，并利用 Dataflow 分支名实现实验隔离，在同一时间窗并行运行多个全量实验。借助 AI Agent 与 tmux 自动化部署、轮询、对比与恢复，把多日串行调试压缩为一天内多轮实验。技术层面定位到 collect_list 按事件袋缓冲、Option 装箱和冗余字符串导致内存膨胀，通过去装箱、精简事件袋、Window 前截断及将 AQE 运行时广播阈值降至 10MB，使峰值内存从 112% 槽位降至 58%。文章还记录“变窄反而更快 OOM”与广播连接累积占约 3.1GB 等反直觉发现，并指出调优只能买时间，事件袋无界增长时架构必须改变。
推荐收录。文章以真实生产 OOM 为起点，完整呈现了从“小样本无法复现”到分支隔离并行全量实验、用 AI Agent 自动化操作，再到 collect_list/Option 装箱/AQE 广播阈值等根因定位与修复的工程闭环。对大数据平台、Spark 性能优化和 AI 辅助运维读者，其中“一次实验只改一个变量”“关注单行宽度与累积广播内存”等经验可直接迁移；局限是流程依赖 Netflix 内部 Dataflow/Maestro 环境。
工程实践NVIDIA Technical Blog
文章分析 Apache Spark UDF 破坏声明式抽象、迫使 GPU 管道回退 CPU 及列行转换开销的问题。作者给出三种重写路径：SQL 表达式、RapidsUDF/cuDF Java API 列式操作、JNI 自定义 CUDA 内核，并按复杂度与场景对比。为降低改写成本，文章介绍 cuDF skills 的四阶段代理工作流：生成测试、转换、基准测试和优化，每阶段用可执行验证与性能数据作反馈。某消费科技公司用它改写 30+ 生产 UDF，示例在 6000 亿行负载上把算子时间从 274.55 小时降至 12.78 小时，约 22 倍。边界是依赖 GPU/cuDF 环境和测试基准，复杂逻辑可能仍需 CUDA，性能结论也来自单一厂商案例。
推荐收录。文章不仅解释 UDF 回退机制，还给出 SQL、cuDF、CUDA 三类重写路径及四阶段代理技能反馈闭环，并附 30+ 生产 UDF、22 倍加速的实测证据，能帮助 Spark 与数据工程读者设计 GPU 迁移和验证流程。主要风险是 NVIDIA 厂商视角且性能数据来自单一案例，读者需结合自身 GPU 环境和测试集判断可迁移性。
工程实践ClickHouse Engineering
文章介绍 iSAM 期权研究团队如何将数据平台从 Postgres 原型迁移到 ClickHouse Cloud，以应对约一万个相关期权合约带来的万倍数据放大。团队指出交易所产品成交量分布不均，简单分片难以均衡负载。迁移后按时间序列存储获得 35-50 倍压缩，单核写入从每秒 8000 行提升到 80 万行，并可直接用 Arrow/Parquet/JSON 进出数据。因列存与向量化执行足够快，团队取消了预聚合、物化视图和下采样管线，把复杂度集中到业务侧。托管服务满足认证、网络隔离、备份与弹性扩容；但作为厂商客户案例，文章缺少表结构、查询模式和失败边界等可复现细节。
推荐收录，因为文章给出了可迁移的工程决策证据：从 Postgres 迁移到列存数据库后获得 35-50 倍压缩、单核写入提升百倍，并因查询足够快而删除预聚合与物化视图管线；同时讨论了负载不均、托管服务与弹性扩容等取舍。适合数据工程师和架构师评估大规模金融时序/期权数据的 OLAP 选型与迁移路径。需注意其厂商客户案例属性，缺少 schema、查询样例和失败边界，复现与独立验证价值有限。
工程实践Salesforce Engineering
文章复盘 Salesforce Data 360 每天约八百万次 Spark 作业的资源优化。团队不改应用代码，在提交网关 DPC 注入基于 DataFlint 的 listener，将驱动遥测经 Kafka 汇入 Iceberg，并用 Silver 层统一应用、作业、stage attempt 与 executor 语义。文章指出成功完成不等于配置高效，需区分零任务 executor、CPU 空闲、shuffle fetch 失败与 spill，并在完整可比运行内归因成本。基于证据，团队把某作业 initialExecutors 从 40 降至 4，另一队列最大 executor 降约 20%，保留动态分配；生产观察一月余无不可接受回退，匹配窗口周成本降 31%，DPC 启动数增逾 7%。作者强调这是前后对比而非受控实验，且非通用 Spark 参数。
推荐收录：文章以每天八百万次 Spark 作业为背景，给出从共享提交网关采集遥测、建立语义分析层、定位零任务 executor 与 CPU 空闲，再到生产灰度和成本收益的完整证据链。适合数据平台、SRE 和大数据性能工程师参考，其“把资源估算当假设、用执行证据选择变更、用后续运行验证”的方法可迁移到其他 Spark/Kubernetes 负载。风险在于 31% 降幅来自前后对比而非受控实验，读者不应照搬具体参数。
技术文章SelectDB 技术分享
Doris 4.2 起可在 Iceberg、Paimon 上直接读写 VARIANT 半结构化数据。文章分三层讲解：值由 metadata 字段名字典与 value 二进制编码，可按路径拆成类型子列，类型不匹配的值保留在 residual/fallback；读取按文件与 Row Group 选择叶子投影、残余补齐或完整投影，并结合统计裁剪；执行层保留 Encoded、Typed、Shredded 三种形态并延迟物化，避免重建完整对象。写回时 Iceberg 经 Arrow 生成 Parquet，Paimon 经 JNI 交给原生 writer，当前不回写拆列文件。测试称相比 Spark 冷跑 15.10×、热跑 19.14×，拆列热跑 58.64×，但 SQL 示例未在集群执行。
Doris 团队完整拆解了 Variant 的编码、拆列、按路径读取与延迟物化机制，并给出可观测的 Profile 指标和冷热跑对比数据，可作为湖仓半结构化数据格式设计与查询优化的参考。适合从事 OLAP/湖仓选型、Parquet 列裁剪与执行引擎优化的工程师阅读；需注意性能数字来自厂商自测、不含导入耗时，SQL 示例也未实机验证。
技术文章SelectDB 技术分享
文章介绍 Apache Doris 5.0 如何把内表 Variant 类型扩展到 Iceberg / Paimon 等开放湖格式，解决 JSON 半结构化数据在生产端（Flink/Spark 入湖）与消费端（Doris 分析）之间的割裂。作者以 AI Agent 轨迹、埋点和 IoT 遥测为例，说明双写同步带来的冗余存储、同步延迟与不一致，并结合 Parquet Variant 编码、Iceberg V3、Paimon 1.4 等标准化进展，提出上层统一类型与 SQL、中层统一执行算子、下层统一格式访问接口的三层方案，并给出 Agent 观测场景的查询、热数据入内表与结果回写 SQL 示例。文末对比内表与湖上 Variant 的能力并给出选型建议，但 Shredded 写入与读取性能细节留待后续文章，且缺少独立实测数据。
推荐收录：文章完整呈现了从问题（半结构化数据生产者与消费者割裂）到方案（统一类型/SQL、统一算子、统一格式接口）的设计脉络，并梳理 Parquet、Iceberg、Paimon 的 Variant 标准化时间线，对评估湖仓一体与半结构化数据分析的数据库、数据平台工程师有直接参考价值。需注意其来自 Doris 厂商，Shredded 写入与性能实测尚未给出，选型结论宜结合后续技术文章与自测验证。
工程实践SelectDB 技术分享
文章介绍 Apache Doris 内置倒排索引解决 OLAP 稀疏扫描问题的技术机制与实测效果。针对传统 OLAP 依赖列存、排序和 Zone Maps 在稀疏查询下全表扫描的局限，文章详细解析了三种索引结构：字符串精确匹配用 Posting List，数值范围过滤用 BKD 树，非结构化文本检索用分词器结合倒排列表。在 1.35 亿条亚马逊评论数据集上，50 并发测试显示全文检索提速 59 倍，按 ID 点查提速 156 倍，多维组合查询提速 10 倍。同时评估了资源开销：新增 7 个索引后存储从 26GB 增至 47GB，写入耗时增加约 6%，主要来自大文本列。结论认为 OLAP 内置倒排索引可简化 Elasticsearch+OLAP 双引擎架构，但应根据查询特征选择性建索引以控制成本。
推荐收录，因为文章基于 1.35 亿条真实数据给出可复现的建表、索引和查询测试，定量对比了性能提升与存储/写入开销。适合数据库内核开发者、 OLAP 架构师和数据平台团队参考，其倒排索引设计思路可迁移到类似分析型系统或评估 Elasticsearch 替代方案。需要注意的是测试仅基于单节点和特定数据集，索引列选择需按业务权衡。
工程实践Spotify Engineering
文章介绍 Spotify 提出的 Random Access Parquet（RAP）方案，让数据湖中的 Parquet 文件直接支持在线点查询，服务个性化功能与 AI Agent 的上下文检索。作者指出瓶颈不在存储层，而在 Trino、BigQuery 等分布式 SQL 引擎的调度与查询规划开销，以及文件内查找所需的链式依赖读取。RAP 通过外部索引把 key 直接映射到文件与行号，再发起精确的 ranged read，索引实现为可追加的 multimap。文章进一步给出面向预写文件的优化（按 key 排序、co-grouping、粗粒度分区、每 key 一页、ZSTD frame reset、存储对齐、blob/Variant、列交织、覆盖索引）及其对分析负载的取舍。结论是同一份 Parquet 文件可同时服务分析与交互式访问，避免重复存储，但部分优化会牺牲列裁剪等分析能力。
推荐收录：文章来自 Spotify 一线实践，清晰定义了数据湖点查询这一真实工程问题，并给出索引结构、文件布局优化与逐项取舍，证据具体。适合数据平台、存储与后端工程师，尤其在构建低延迟检索或为 AI Agent 供给上下文时，其“一份数据双访问模式”思路与 Parquet 改造技巧可直接迁移。
工程实践Grab Tech
文章详细介绍了 Grab 从 Hive Parquet 向 Apache Iceberg 迁移数据湖的完整工程实践。首先分析了原始架构在目录延迟、小文件碎片、运维负担和信息一致性上的瓶颈，然后说明了选择 Iceberg 的决策依据。迁移采用按表优先级逐步推进的策略，在导航数据集上通过 Z-ordering 获得约 10 倍查询性能提升，并在运营表上节省了 95% 的 S3 API 成本。为应对 Iceberg、Delta、Hudi 等多格式共存的开发体验问题，团队自研并开源了 UnifiedSparkCatalog，透明路由不同表格式操作。文中还分享了 Hive 锁竞争、时间戳兼容性、存储层级成本等实际坑位和解决方案。案例适合大型数据平台的可扩展存储架构改造，迁移策略和工具设计具有较高的可迁移性。
本文提供了从中型数据湖到现代表格式转型的完整路线图，包含明确的性能与成本量化证据、自研工具的架构取舍和开源发布，以及生产环境踩坑经验。适合数据平台工程师和架构师参考，尤其对计划从 Hive 迁往 Iceberg、需要多格式兼容的团队有直接借鉴价值。