工程实践知乎 - SmartCode 得物技术
文章复盘得物内部指标字典从 0 到 1 的落地实践，核心是把业务隐性口径转化为结构化、唯一可信的语义资产。业务侧逆向梳理存量报表并用“沉淀—观察—转正”机制收编隐性指标，数仓侧通过血缘核查与分批改造把散射依赖收敛到域内精品宽表，产品侧用 YAML 解析、维度管理和多技术来源物理映射把上架流程工程化，并在提报环节以语义相似度检测拦截口径二义性。作者给出 Text2SQL 与 AI Coding 两条消费主线的验证证据：系统测评 SQL 准确率从 85%+ 提升到 95%+，且与条件拼接修复、时间解析固化等治理动作一一对应，OneData 建设全流程提效 40%+。文末提出以消费热度反哺治理优先级、元数据下沉到消费方式等闭环方向，但结论高度依赖得物自身组织与数据规模，跨公司可迁移性仍需验证。
推荐收录：文章提供了从语义底座建设、二义性拦截到 Text2SQL/AI Coding 消费验证的完整工程链路，并用 85%+→95%+ 的准确率趋势和 40%+/70%+ 的提效数据作为直接证据，而非泛泛方法论。适合负责数据平台、指标治理、Text2SQL/RAG 语义层或 AI 辅助研发的工程师与架构师参考，其中“消费驱动治理”“多技术来源统一交付”“血缘核查先行”等做法可直接迁移；但需注意结论基于得物自身组织与数据规模，跨团队落地要重新评估边界。
技术文章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 写入与性能实测尚未给出，选型结论宜结合后续技术文章与自测验证。
工程实践ClickHouse Engineering
文章是 ClickHouse 团队 CostBench 的第二部分，对比 ClickHouse Cloud 与 Snowflake 在持续实时写入下的性能/成本差异。测试向两套系统灌入相同的 1132 亿行行情数据，速率约 100 万行/秒，并执行相同聚合与下钻查询，读侧资源尽量匹配到约 16 CPU。核心机制差异是 ClickHouse 在写入路径内完成排序和增量物化视图更新，Snowflake 的 Snowpipe Streaming 与异步 MV 刷新分离，MV 平均滞后约 1.4 分钟，聚合查询需在编译阶段补偿未刷新数据。结论称 ClickHouse 端到端实时性价比高 412 倍、聚合查询快 669 倍；但基准由厂商主导，Snowflake 资源估算和 fallback 成本归因需谨慎看待。
推荐收录，因为它给出了可核验的 CostBench 测试方法、相同负载和资源匹配信息，并具体解释了写入内增量 MV 与异步 MV 刷新导致查询时补偿的机制差异，而不仅是性能口号。适合实时数仓、OLAP 选型、性能成本评估方向的工程读者参考；但结论来自 ClickHouse 主导的对比，Snowflake 侧 CPU、fallback 和成本归因为估算，外推时需保留厂商立场风险。
工程实践ClickHouse Engineering
本文介绍 CostBench 首轮端到端评测，聚焦持续负载下每美元实时性能。作者先界定查询就绪数据的三项准备（列式存储、排序与分块裁剪、预聚合），再提出新数据路径概念：在持续摄入数据的同时维护事件级物理布局与预聚合，让查询引擎读得更少、算得更少。评测用同一客户端按每秒约百万行的目标速率推送 1132 亿行 NBBO 股票行情，对比 ClickHouse Cloud、Snowflake、BigQuery 与 Redshift Serverless，统一 schema、排序键、查询集与调度，并把新数据路径成本、归一化查询服务成本和累计查询运行时合成一个越低越优的评分。结论是 ClickHouse Cloud 三项均最低，端到端性能每美元领先 412 至 1996 倍，仅查询侧差距为 32 至 101 倍。边界在于这是厂商自测，排除了存储成本，只覆盖推送式摄入，也未测试 Databricks。
推荐收录：文章公开了共享压测客户端、资源对齐策略、计费归一化公式与开源复现仓库，并给出查询就绪与新数据路径两个可迁移的分析框架，适合做实时分析系统设计和数据仓库选型的工程师参考。主要风险是厂商自测、结论明显偏向自家产品，且排除存储成本与拉取式摄入，建议结合后续逐家分析或独立评测交叉验证。
科研议题ClickHouse Engineering
文章发布 ClickHouse 开源的 agentic analytics 基准 harness data-agent-mnist，用 201 条来自内部分析代理 DWAINE 的真实问题，在合成数据仓库上评测 29 个模型。它指出代理式分析不同于 text-to-SQL：模型需自主发现 schema、多轮查询，并以结果集而非单条 gold SQL 评判。方法上通过筛选、匿名化、真值委员会、LLM-as-jury 和污染检测构建可复现评测，报告准确率、turn 预算、token/成本、延迟和失败模式。结果显示 Claude Fable 5.1 以 76.6% 居首，前沿模型仍占优，但成本可差 52 倍，规划错误是主要失败原因。该基准强调需在自己的数据仓库上运行，局限是真值依赖模型委员会而非人工审计，合成环境可能偏离生产。
推荐收录：文章给出可复用的开源 benchmark harness 和完整方法论，包括真实问题筛选、匿名化合成数据仓库、真值委员会、LLM-as-jury 与污染检测，并公开 29 个模型在准确率、成本、延迟和失败模式上的可比较结果。对构建分析代理、选型 LLM 或设计 AI 评测体系的读者，可直接迁移其评测框架和“规划错误优先”的结论。局限是真值依赖模型委员会而非人工审计，合成环境可能偏离真实生产。
技术文章SelectDB 技术分享
本文从 AI Agent 日志观测场景切入，指出 Agent 执行流具有嵌套数组、动态 Schema 和非确定性推理等特点，传统扁平日志模型无法还原完整执行树，而全量拍平会破坏上下文关系并导致频繁 DDL，直接存为 String 又会造成全表扫描和 JSON 解析性能瓶颈。作者提出让数据库原生支持半结构化数据，以 Apache Doris/SelectDB 的 VARIANT 类型为例，解释自动子列提取如何保留列式扫描性能和压缩率，倒排索引如何加速长文本和 JSON 内部关键字检索。文章进一步给出动静分离的混合建模实践：高频标量字段用标准列，动态嵌套对象用 VARIANT 列，关键排障字段建立倒排索引，并附建表与查询示例。内容主要基于 Doris/SelectDB 引擎，未提供跨引擎量化对比，但方案思路可迁移到 ClickHouse JSON 类型等类似系统。
推荐收录，因为文章直面 AI Agent 日志观测中 JSON 处理的核心矛盾，清晰对比了全量拍平、String 存储与半结构化原生支持三条路线的优劣，并提供可落地的混合建模 DDL/DML 示例。适合负责可观测性平台、日志分析或 OLAP 数据建模的工程师参考，其动静分离、自动子列提取与倒排索引组合的设计方法可以迁移到其他支持半结构化类型的列式数据库。
技术文章SelectDB 技术分享
文章分析了 AI Agent 生产环境中可观测性负载的新特点：文本主体大且无结构、关键字段高度动态、trace 有序嵌套、看板需与持续写入并存。作者指出传统搜索、OLAP、文档库难以单独胜任，需要统一混合负载数据系统。AgentLogsBench 用单表 1 亿行 observation 数据评测六种引擎，覆盖 trace 回放、短语搜索、动态 JSON 过滤和实时聚合。结果显示 Apache Doris 综合 slowdown 1.28 领先，hot/cold 均第一，但在长文本 cold phrase search 上仍落后 Elasticsearch。文章解释了 Doris 领先原因包括倒排索引、VARIANT 子列、按 trace_id 分布与排序键、分区裁剪和缓存机制。该文可作为选型或理解混合负载数据系统的参考，但数据来自合成 benchmark，结果需结合实际验证。
推荐收录，因为文章不是空泛宣传，而是给出了 Agent 可观测性基准的具体设计、完整查询负载和跨系统实测数据，并逐项解释 Doris 架构优化如何影响性能。适合从事可观测性、OLAP 或 AI 平台基础设施的读者，用于理解混合负载系统选型与优化。可迁移价值在于把文本搜索、动态 JSON、trace 回放和实时聚合放在同一存储上权衡；主要风险是来自 SelectDB 官方且数据为合成，需结合其他评测交叉验证。
技术文章SelectDB 技术分享
本文介绍 Apache Doris 4.1 对 Iceberg 的能力扩展，从仅支持查询扩大到 UPDATE、DELETE、MERGE INTO 等 DML、表结构管理与日常维护，并完整支持 Iceberg V3。文章重点解析 Deletion Vector 机制：V3 用位图记录失效行并写入 Puffin 文件，使删除文件数量与数据文件同阶，文中测试显示文件数从336降至17、删除信息存储从98MiB降至3.8MiB、高删除比例查询时间降至约1/3。同时介绍 Row Lineage 提供的 _row_id 和 _last_updated_sequence_number 系统列，用于稳定行标识和增量变化识别，可配合 Time Travel 定位记录。作者也说明这些能力仅适用于 format-version=3 且需 Doris 4.1+，收益受数据规模和文件布局影响，Row Lineage 不等同审计系统。文章最后给出五分钟入门步骤并展望 Variant 读写和增量物化视图。
推荐收录，因为文章不是单纯的产品发布，而是提供了 Iceberg V3 关键机制（Deletion Vector、Row Lineage）的清晰解释、具体 SQL 示例和量化测试结果，并明确标注了版本、格式和场景边界。适合从事湖仓一体、Doris 或 Iceberg 数据管线的工程师理解如何在 OLAP 引擎中收敛查询、修改和维护，其关于减少删除文件开销和行级增量识别的思路具有可迁移价值。
工程实践知乎 - SmartCode 得物技术
文章讲述得物技术如何把埋点与指标需求承接流程重构为一条由 Hermes Agent 驱动的可回放工作流，重点解决需求信息分散、历史口径难追溯、变更风险难暴露和生产确认成本高等问题。作者不是让 Agent 直接给最终结论，而是把流程拆成工作区、看板、规则资产、结构化工具接口、系统预演和人工确认点，让 AI 负责判断前的工程化准备，人负责业务语义、口径裁决和生产放行。文章最后还明确提出要用准备时间、交付周期、评审通过率和返工原因等指标验证这套机制的实际收益与边界。
推荐收录，因为它不是泛泛讨论“Agent 能做什么”，而是给出了数据承接场景里可落地的流程重构方案，以及对应的治理边界和确认机制。对于做数仓、数据治理、AI 工程化或内部工作流自动化的读者，这篇文章对“如何把经验沉淀成规则资产、如何把风险前置到流程中”有较强迁移价值。