Analytics

34 篇内容

工程实践Cloudflare Blog

How fast is the web? Explore billions of real-user measurements with BEACON

Cloudflare 发布 BEACON 公开数据集,基于 10,000 个大型网站的数十亿次真实用户性能测量,按 RUM Archive 标准每日更新到 Google BigQuery,覆盖主流浏览器引擎。文章介绍 Core Web Vitals 的 LCP、CLS、INP 直方图,支持任意分位数分析,并给出 LCP 与 INP 的子阶段拆解。关键发现包括 WebKit 在部分国家落后于 Blink、软导航比硬导航快 2-3 倍但首屏更重、带宽与 LCP 相关,以及非洲的传输体积较小。还说明去标识化、站点规模归一化和聚合等隐私与方法边界,适合性能工程、数据分析和 Web 研究参考。

推荐收录,因为它提供可公开查询的 BEACON 数据集、BigQuery 示例查询,以及 Core Web Vitals 子阶段和软/硬导航等可迁移的性能分析框架。适合 Web 性能工程师、浏览器/标准研究人员和数据团队评估真实用户体验、长尾分位数与架构取舍。需注意其样本限定为 Cloudflare 前 10,000 个站点,归一化与聚合会影响结论外推。

技术文章QuestDB Engineering

Read Which time-series join? ASOF, WINDOW, HORIZON, LT or SPLICE

文章系统比较 QuestDB 的五种时序 JOIN:ASOF、WINDOW、HORIZON、LT、SPLICE,并说明 LATERAL JOIN 如何按行复用它们。作者以 FX 交易与行情表为例,在公开 demo 上给出可运行 SQL,解释每种连接的时间匹配方式、返回行数、聚合行为和典型用途:ASOF 取事件时刻的最新值,WINDOW 聚合时间窗口内多行,HORIZON 在多个固定偏移上重复 ASOF,LT 取严格早于当前时间戳的前值,SPLICE 实现双向全外 ASOF。文章还讨论 TOLERANCE、EXCLUDE PREVAILING、CTE 组合限制、WINDOW 与 HORIZON 的混淆、LT 避免前视偏差等边界。最后提醒 demo 数据为合成数据,应关注查询语义而非市场结论。

推荐收录:文章不是泛泛介绍,而是用一组可运行 SQL 和返回行数直接证明五种时序 JOIN 的语义差异,并给出选择依据与组合限制。它适合数据库、时序数据分析、量化/监控系统开发者作为查询设计与选型参考,ASOF/WINDOW/HORIZON 的区别和 LT 防前视偏差等方法可迁移到其他时序系统;主要风险是语法和部分行为绑定 QuestDB。

工具笔记DuckDB Engineering Blog

DuckDB Now Ships inside dbt v2

文章介绍 dbt v2(基于 Rust 的 Fusion 引擎)首次内置 DuckDB 适配器。作者回顾 v1 需单独安装 Python 包 dbt-duckdb,而 v2 改为 Rust 单仓 + ADBC 驱动,并自动下载缓存 DuckDB 驱动,配置一个 profile 即可运行。v2 新增 DuckLake 与 Iceberg REST 目录支持(需 use_catalogs_v2 标志)、将 dbt 元数据写成可查询 Parquet、提供原生 SQL 语义理解与列级血缘,并固定 DuckDB 版本以推下更多原生函数。迁移可先在 v1.12 用 opt-in v2 parser 验证,再用 dbt-autofix 和升级指南切换。文章偏功能与用法说明,缺少性能基准和取舍分析,适合使用 dbt/DuckDB 的数据工程读者。

推荐收录:文章给出了 dbt v2 内置 DuckDB 的配置方式、DuckLake/Iceberg catalog、Parquet 元数据查询和迁移路径,属于可操作的工具集成参考。适合数据工程师和分析工程师了解本地 dbt 工作流及 v2 迁移。需注意它偏功能公告,缺少性能与取舍验证,版本锁定可能带来后续适配成本。

工程实践ClickHouse Engineering

ClickHouse Cloud vs. Snowflake: What drives the real-time performance-per-dollar gap

文章是 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

Measuring real-time performance per dollar under continuous load: CostBench’s first end-to-end results

本文介绍 CostBench 首轮端到端评测,聚焦持续负载下每美元实时性能。作者先界定查询就绪数据的三项准备(列式存储、排序与分块裁剪、预聚合),再提出新数据路径概念:在持续摄入数据的同时维护事件级物理布局与预聚合,让查询引擎读得更少、算得更少。评测用同一客户端按每秒约百万行的目标速率推送 1132 亿行 NBBO 股票行情,对比 ClickHouse Cloud、Snowflake、BigQuery 与 Redshift Serverless,统一 schema、排序键、查询集与调度,并把新数据路径成本、归一化查询服务成本和累计查询运行时合成一个越低越优的评分。结论是 ClickHouse Cloud 三项均最低,端到端性能每美元领先 412 至 1996 倍,仅查询侧差距为 32 至 101 倍。边界在于这是厂商自测,排除了存储成本,只覆盖推送式摄入,也未测试 Databricks。

推荐收录:文章公开了共享压测客户端、资源对齐策略、计费归一化公式与开源复现仓库,并给出查询就绪与新数据路径两个可迁移的分析框架,适合做实时分析系统设计和数据仓库选型的工程师参考。主要风险是厂商自测、结论明显偏向自家产品,且排除存储成本与拉取式摄入,建议结合后续逐家分析或独立评测交叉验证。

科研议题ClickHouse Engineering

The Agentic Analytics Benchmark: Measuring model accuracy and efficiency in analytical agents

文章发布 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 评测体系的读者,可直接迁移其评测框架和“规划错误优先”的结论。局限是真值依赖模型委员会而非人工审计,合成环境可能偏离真实生产。

工程实践Spotify Engineering

Why Spotify Is Not Using Bayesian A/B Testing

Spotify 解释其未在实验平台加入贝叶斯 A/B 测试的原因,并基于论文指出贝叶斯与频率派推断比争论中更接近。文章强调贝叶斯 A/B 测试是一组由停止规则、先验和似然构成的配置:默认平坦先验加后验阈值在窥探下不控制假阳性,且与频率派数值等价;Bayes factor stopping 可控制假阳性,良好校准的经验贝叶斯先验能收缩效应并控制 FDR,但依赖大规模、同质且无偏的历史语料。作者据此拆解窥探、多指标、赢家诅咒与决策理论等说法,强调目标与配置须分开。Spotify 认为双模式会增加规划、监控、解释和信任成本,现有频率派工具已满足目标,故暂不引入。该判断适用于实验成熟、指标一致且有统计维护能力的组织,否则先验错配可能损害估计与决策。

推荐收录。文章给出可核验的统计论据与 Spotify 的真实取舍:平坦先验与频率派等价、Bayes factor stopping 的假阳性控制条件、经验贝叶斯先验的 FDR 控制前提,而非泛泛比较。适合实验平台、数据科学、增长与产品决策团队,用于评估是否引入双推断模式;风险是统计细节密集,非统计读者可能忽略配置前提。

工程实践ClickHouse Engineering

Build a real-time market data app with ClickHouse and Massive

文章以构建实时行情 tick 应用为主线,展示如何用 Massive(原 Polygon.io)WebSocket 订阅股票 trades 与 quotes,并用 ClickHouse 存储、Node.js/React 后端与可视化。作者给出 quotes/trades 表结构,以 sym 和一分钟时间桶设计 MergeTree 排序键,比较同步与异步插入后采用客户端批量同步写入。查询端用 argMax/argMin 结合时间戳与序列号生成实时行情表,并按两分钟窗口聚合 OHLCV;还演示 AggregatingMergeTree 物化视图预计算 1 分钟 OHLCV、摄入延迟监控与扩展建议。不足是示例缺少持久缓冲、重放、去重和鉴权,也不处理取消/更正或官方 OHLCV 重建,生产化需补齐可靠性设计。

推荐收录。文章提供了可运行的完整示例和关键设计细节:从 WebSocket 订阅、表结构与排序键、同步/异步插入取舍,到实时行情与 K 线查询、物化视图和延迟监控,均有代码与边界说明,适合构建实时分析、行情数据或 OLAP 摄取管道的工程师参考。其模式可迁移到其他高频事件流场景,但需注意示例本身不是生产级方案,缺少鉴权、持久缓冲和重放去重等能力。

技术文章ClickHouse Engineering

Pipelined SQL in ClickHouse 26.8

文章介绍 ClickHouse 26.8 引入的管道式 SQL:用 `|>` 操作符把查询写成一系列显式变换。作者以英国房价数据集为例,对比传统 SELECT 开头、FROM 开头和管道式三种写法,并借助 EXPLAIN SYNTAX 展示管道查询会被翻译成嵌套的标准 SQL,但中间结果不会被物化,整体仍会被优化后执行。文中还说明 EXTEND 可追加计算列、聚合别名能在下一阶段复用从而免写 CTE 或嵌套子查询,并强调阶段顺序会改变语义(如在第二级聚合前插入 LIMIT 会使平均值只基于非确定性的中间子集)。管道语法可用于子查询、视图和 INSERT…SELECT。文章偏教程性质,未提供性能对比或与其他 SQL 方言的深入比较。

推荐收录,文章给出了管道式 SQL 的翻译机制(EXPLAIN SYNTAX 显示为嵌套 SELECT 且不物化中间结果)、EXTEND 与聚合别名复用等可直接套用的写法,并明确指出阶段顺序和非确定性 LIMIT 的陷阱,适合 ClickHouse 使用者与数据工程师快速评估该语法。局限是缺少性能数据与更细的语法边界分析。

工程实践ACM Queue Articles

Too Many DevEx Metrics, Too Little Guidance

文章指出AI辅助开发普及后,工程领导者面临衡量其影响的压力,但多数组织只衡量AI采用情况和输出,对开发者体验(DevEx)的影响缺乏了解。现有度量框架、公司和研究文献中出现120多种指标,选择合适指标困难。作者基于对50多个工程组织的结构化分析,推出开源的DevEx Metrics Compass网页应用,帮助团队在碎片化度量环境中选择符合自身情境和目标、有意义且可操作的指标。文章同时分享了当前DevEx度量实践的现状和空白。该工具适合从零开始设计度量集的新手,也适合评估现有度量集广度和深度的资深实践者。

推荐收录,因为它不是泛泛讨论DevEx,而是基于跨组织的结构化分析提供可操作的度量选择工具和数据集,直接解决了“指标过多、缺少指导”的痛点。适合工程管理者、DevEx团队和决策者使用,帮助建立符合自身情境的度量体系。其开源工具和度量分类可以迁移到其他团队作为参考;风险在于文章是工具介绍,可能随工具迭代而过时,但框架本身仍有长期参考价值。

工程实践Cloudflare Blog

Total eclipse of the Internet: traffic impacts in Iceland, Spain, and Portugal

文章通过Cloudflare Radar的HTTP请求量数据,分析了2025年8月12日欧洲日全食期间各国互联网流量的变化。作者用前三个周三同一时段的请求量中位数作为基线,以五分钟为粒度计算流量偏离程度,并利用太阳和月球的几何位置计算各地区的最大遮挡比例和时刻。结果显示,流量下降的时间与最大遮挡时刻几乎精确吻合,处于全食带或深偏食地区的流量比基线下降约15%至30%,而浅食地区几乎不变;冰岛、西班牙和葡萄牙降幅最大。文章指出,流量降低并非网络故障,而是人们停止上网观看日食,反映物理事件对线上行为的直接影响。分析依赖Cloudflare网络覆盖,结论适用于该事件规模下的趋势观察,但个体国家的局部变量(如人口密度、云量)会造成散点偏差。

推荐收录。文章展示了一套可复用的互联网流量事件分析方法:从基线选择、遮挡率几何计算到时间对齐和趋势验证,而非简单的新闻转述。对从事网络数据分析、CDN运营或行为量化的读者有直接迁移价值,其数据清洗和基线对比思路也可用于其他大型事件的影响测量。主要局限是结论依赖Cloudflare单源数据,但作为方法参考仍具长期价值。

工程实践LinkedIn Engineering - Scalability

Revenue Attribution Report: how we used homomorphic encryption...

本文介绍 LinkedIn 收入归因报告系统如何用加法对称同态加密(ASHE)替代逐行 AES 解密。原系统每次查询都从 Pinot 拉取全部相关记录、解密敏感列后在明文上聚合,导致网络和 CPU 开销大且暴露明文。新方案把 ASHE 加密列和标识符一起存入 Pinot,将聚合下推到存储层,利用 Pinot 内建聚合与 ArrayAgg 拼接标识符,API 服务器仅对每列聚合结果做一次解密。对于按敏感状态分组的查询,还结合确定性加密防止频率攻击。实际效果显示网络响应从 2MB 降至约 5KB(降幅 99%),CPU 尖峰缓解,端到端时延基本持平。方案适用于数据所有者与查询方为同一实体的场景,依赖支持聚合下推的 OLAP 存储。

推荐收录。文章提供了真实系统中同态加密落地的完整工程案例,包含原方案瓶颈、ASHE 原理、Pinot 集成细节、扩展方案和量化性能对比,证据充分。对需要隐私保护分析、加密数据聚合或优化 OLAP 查询的工程师有直接迁移价值,尤其展示了如何将密码学原语与存储层能力结合。

工程实践SelectDB 技术分享

时间序列近邻关联性能实测:Doris ASOF JOIN 领先 ClickHouse、DuckDB Doris 在 4.0.5 和 4.1.0 版本引入的 ASOF JOIN,把时间序列近邻关联做成一个能在大规模、...

文章对 Apache Doris 4.0.5/4.1.0 引入的 ASOF JOIN 进行系统性能实测,该功能面向时间序列近邻关联,可在按业务键分组后找到不晚于左侧记录的最近右侧记录,适用于交易行情补全、事件归因等场景。测试设计覆盖大小表组合、1 亿行对 1 亿行、不同 NDV、长序列、短序列、乱序存储和过滤条件等六大类典型场景,并与 ClickHouse、DuckDB 在相同硬件和并发参数下对比。结果显示 Doris 在绝大多数用例中显著领先,例如大小表 JOIN 低至 0.15-0.38 秒,1 亿对 1 亿约 0.97-1.13 秒,短序列和乱序场景优势更明显。文章强调该实现具有低延迟和高稳定性,适合大规模、复杂分布的真实业务。需注意内容来自 SelectDB 官方技术团队,测试带有厂商视角,但其测试设计和场景覆盖可作为数据库选型与性能评估参考。

推荐收录,因为文章提供了 ASOF JOIN 系统化的性能基准测试,从测试设计、环境配置到多维度场景结果均有详细说明,对需要处理时间序列近邻关联的数据库工程师和架构师有直接参考价值。其可迁移价值在于展示了如何设计覆盖真实业务复杂度的数据库功能基准测试,但需注意来源为厂商官方,数据结论应结合独立验证或实际业务场景再判断。

技术文章SelectDB 技术分享

Agent 场景动态 JSON 性能拆解:Apache Doris 比 ClickHouse 快 7 倍、比 Elasticsearch 快 2 倍 为什么同样都支持 JSON,不同数据库在 Agent 日志场景下的性能...

文章围绕 Agent 日志中动态 JSON payload 的性能挑战展开,基于 AgentLogsBench 基准测试对比了 Apache Doris、ClickHouse、Elasticsearch/OpenSearch 和 DuckDB/Parquet Variant。作者剖析了 Doris VARIANT 将常用 JSON Path 转化为列式 subcolumns 的机制,并通过高频路径列式化、低频路径 sparse columns 和 Storage Format V3 来优化宽 JSON 查询。测试显示 Doris 在动态字段聚合、rollup 和低基数过滤上延迟优势明显,平均比 ClickHouse 快 7.4 倍,比 Elasticsearch 快 2.4 倍,存储占用接近 ClickHouse 且远低于 Elasticsearch。文章还分析了其他系统的取舍,如 Elasticsearch 搜索强但动态聚合成本高、ClickHouse 压缩好但长尾路径查询慢、DuckDB/Parquet Variant 开放格式强但在线分析不足。结论指出,将动态 JSON 纳入列式存储、索引和向量化执行链路是决定搜索后分析体验的关键。边界在于结果来自厂商基准,可能带有一定倾向性,但技术原理和权衡分析具有参考价值。

推荐收录。文章不仅给出了性能对比数据,还深入解释了 Doris VARIANT 的 subcolumnization、Storage Format V3 机制,并对比了 ClickHouse、Elasticsearch、DuckDB/Parquet Variant 的架构取舍,技术细节和可迁移性强。适合数据库内核、OLAP、可观测性和大数据工程师理解动态 JSON 在不同系统中的处理方式,为 Agent 日志分析、技术选型和优化提供依据。尽管来自商业公司,但内容以基准和原理为主,推广成分较低,长期参考价值较高。

技术文章Cloudflare Blog

Cloudflare DDoS Threat Report H1 2026: 1 Tbps attacks soar as DNS floods and geopolitical tensions drive a new wave

本文是 Cloudflare 发布的 2026 上半年 DDoS 威胁报告,基于其全球网络数据,系统总结了网络层和应用层攻击的规模、频率、主要向量与行业分布。核心发现包括:1 Tbps 以上超大规模攻击数量较上季度增长六倍以上,DNS Flood 与 CLDAP Flood 等反射放大攻击显著上升,其中 CLDAP 攻击环比激增 580%;地缘政治事件直接驱动攻击目标变化,媒体行业持续位居受攻击首位,政府行业在“史诗之怒”行动后排名骤升。报告强调攻击呈现短时爆发特征,人工响应已不可行,自动化、始终在线的防护成为必需,并介绍了 Cloudflare 的免费 DDoS 防护与 Botnet 威胁情报共享等防御实践。

报告提供了基于真实网络的海量 DDoS 攻击统计与向量分析,对安全工程师、网络运维和架构师理解当前威胁格局、评估防护策略有直接参考价值。文中揭示的 CLDAP 爆发、攻击短时化等趋势,以及自动化防御的洞察,可迁移至各类网络服务的安全规划与应急响应改进中。

工程实践Salesforce Engineering

How Standardizing Product Telemetry Reduced Time to Insight by 97%

文章介绍了Salesforce如何通过构建标准化的产品遥测平台(PDP)解决各产品团队各自定制遥测导致的数据孤岛、重复劳动和无法规模化的问题。PDP采用统一的遥测架构和自动化指标生成管道,要求团队遵循标准化的埋点规范,从而自动产出可信的产品采纳指标。技术上,它基于监控云基础设施构建了自定义模式,并处理每天450亿行事件数据,覆盖19000个事件和2000多个产品特性。实施后,洞察获取时间从约1个月缩短至每日刷新(降低97%),开发者埋点工作从数周减少到数小时,CSAT达9/10。标准化的数据基础也为AI分析工具和MCP集成提供了可信支撑。该工程案例适用于大规模多产品环境下集中式数据平台的建设与推广,但需注意组织推动和标准治理的复杂度。

本文是典型的工程实践复盘,提供了从问题识别、架构设计到规模化推广和量化的完整过程,尤其在统一数据标准、提升数据质量和自动化的权衡方面具有可迁移价值。适合负责数据平台、指标体系建设或开发者效率的工程师参考。量化结果(97%时间缩减)和推动团队采用的方法论具有说服力,有助于读者借鉴其建设可信数据基础、赋能AI工具的思路。

工程实践Cloudflare Blog

Introducing Radar Researcher: An AI tool for exploring Internet data in plain language

本文介绍了 Cloudflare Radar 新推出的 AI 工具 Radar Researcher,它允许用户用自然语言查询全局互联网数据,自动生成交互式图表并给出解释。文章详细说明了构建动机(降低非技术用户门槛、加速记者和工程师的数据获取)、系统架构(基于 Cloudflare Workers 和 Durable Objects,使用 Workers AI 运行开源模型并实现多模型回退,通过 MCP 服务器和 Code Mode 让 Agent 动态发现并调用 Radar API),以及关键技术决策(用轻量图表规约替代让模型直接生成数字,保证数据精确性和可视化一致性)。此外,还介绍了 WebMCP 支持,使网站成为 Agent 友好型。该工具目前处于 Beta 阶段,适用于网络流量分析、中断调查等场景,但依赖 LLM 的推理准确性且仅限 Radar 数据集。

推荐收录。本文提供了将 LLM 与数据 API 集成的一种可参考架构:通过 MCP 动态发现接口、用规约化图表渲染避免模型篡改数据、以及多模型回退保障可用性。这些设计模式对构建 AI 辅助数据分析工具的工程师有直接迁移价值,也展示了如何为网站添加 Agent 兼容能力。

工程实践Cloudflare Blog

Catching rogue AI behavior with identity-aware analytics

本文介绍了 Cloudflare 的 identity-aware AI Gateway 和 User Insights 功能,通过集成 Access 实现每请求身份认证,并结合基于会话的异常检测来发现恶意行为或成本异常。核心方法是对每个用户建立 30 天滚动 95% 分位基线,当会话成本超过基线 2 倍且同时跨过全局 p99 门槛时才触发告警,以此过滤微小波动和高消费用户的常规行为。文章详解了为何采用会话评分、双阈值和美元底限,并展示了从内部流量绘制的散点图和分布图,证明该方法能有效区分异常和噪声。方案主要面向已部署 AI Gateway 的组织,适用于需要成本控制和滥用量化的场景,但目前仅提供告警而不自动阻断。

推荐收录,因为该文不局限于产品宣传,而是详细阐述了一套可复用的基于用户行为基线的异常检测方案,包含双阈值、滚动基线和底限设置等工程细节。对构建 AI 成本监控、治理平台或内部安全分析的工程师有直接参考价值,且文中公开了具体统计量和决策依据,便于迁移到类似的用量分析场景。

工程实践Grab Tech

How AI is transforming analytics at Grab

文章系统阐述了Grab如何将AI代理深度嵌入数据分析工作流,以实现智能民主化和分析师角色进化。作者提出五级自主性阶梯(L2 AI辅助到L5端到端自主),定义了执行、知识、控制、审查和学习五大核心能力,并展示了Spartan、Scarlet、ContextIQ、BriX等实际系统的架构与效果。通过Slack中的自然语言分析、自愈数据管道、上下文生命周期管理和分析师自建工具门户,Grab将机械性工单占比从44%降至30%,周期时间缩短约33%,自助分析率大幅提升。文章强调自治不消除问责,人类始终负责问题框架、指标定义和业务决策。该实践适用于具备可认证指标和持续上下文投入的大型数据工程环境,但对团队协作和执行力的要求较高,非轻量级方案。

推荐收录。本文不是简单工具介绍,而是一份完整的工程案例,包含明确的自主性分级、核心能力拆解和可度量的业务影响,展示了从实验到规模化落地的真实路径。对关注数据工程智能化、分析师角色转型或AI工程化的读者极具参考价值,所提出的阶梯框架和上下文治理模式可迁移至其他数据分析密集型组织。

工程实践Netflix TechBlog

Modeling Device Capabilities for Analytics

Netflix 面临设备多样性带来的功能支持挑战,为此构建了设备能力数据模型。核心方法包括使用累计表高效存储每台设备的最新能力状态(如屏幕分辨率、视频编解码器支持等),以及构建直方图记录 28 天内活跃设备数并按能力维度分布,用于分析功能覆盖率(如仅 20% 设备支持 UHD)。基于这些数据集,团队开发了分析产品,为 4K、空间音频、云游戏等特性在特定设备上的启用提供数据驱动决策,以平衡性能与可靠性。该模型适用于大规模流媒体服务下的设备洞察,但未深入底层存储或查询优化细节。

本文展示了 Netflix 从设备数据建模到聚合分析的完整工程实践,提供了可复用的数据结构设计和分布分析方法,对需要处理异构设备、评估功能渗透或进行数据驱动决策的工程师有直接参考价值,适合数据分析、平台工程或流媒体团队迁移应用。

工程实践Marc Brooker

Lorenz and Little: How Much Does Your Tail Cost?

本文从成本和容量角度切入尾部延迟分析,通过Lorenz曲线量化不同百分位延迟对平均延迟的贡献比例,并结合Little法则说明这一比例同时对应系统并发所占份额。作者提供了基于分位数向量的数值计算方法,并讨论了插值假设和尾部帕累托外推的局限性。文章指出,在许多服务中p99及以上延迟可能贡献超过一半的平均延迟和并发寸,因此优化尾部能显著降低容量需求、锁争用和成本,而不应简单截断。这一视角将延迟分析从用户体验延伸至系统经济性,适合拥有可观测性指标的工程团队。

推荐收录。文章不是泛泛谈论尾部延迟的重要性,而是引入了Lorenz曲线这一经济学工具提供量化框架,并通过Little法则建立延迟与并发成本的直接关联,给出了可复用的计算方法和工程洞察。对于需要平衡服务性能与基础设施成本的后端工程师、SRE和架构师来说,该思路可直接迁移到容量规划和瓶颈识别中,具有长期参考价值。

技术文章Fzakaria Blog

The mean means nothing

文章以一次误导性的平均延迟指标为切入点,系统介绍了如何通过多种可视化手段正确理解性能分布数据。作者使用一个合成数据集模拟 Web 服务缓存上线场景,展示平均值、中位数、百分位数给出矛盾结论的原因,并依次通过密度图、累计分布函数(CDF)、位移函数、山脊图、热力图和联合图揭示数据呈双峰分布的实质:缓存命中导致低延迟,缓存未命中的大请求造成长尾。文章重点强调 CDF 能同时展示所有分位数的变化,尤其当两条 CDF 曲线交叉时,单一统计量无法概括整体效果。文中所有图表附有可复现的 Nix 脚本,便于读者在自己的数据上实践。该文既是一堂生动的可视化教学,也是工程师避免数据误读的实用指南。

这篇博文通过清晰的可视化对比,有力地揭示了仅依赖平均值或单一百分位数做技术决策的陷阱,并提供了可直接复现的分析方法。其核心方法(尤其是 CDF 对比和位移函数)可迁移到任何涉及分布变化分析的场景,如性能优化、A/B 测试或系统监控。适合所有需要从数据中提取可靠结论的后端工程师、SRE 和数据分析师,是一份长期值得参考的实践指南。

工程实践Cloudflare Blog

How the 2026 World Cup affected Internet traffic

本文利用 Cloudflare Radar 的全球 HTTP 请求数据,分析 2026 年世界杯期间互联网流量的变化模式。方法上,通过赛前四周中位数建立基准,并使用 log₂ 比率衡量偏离,使得增减对称且可跨国家比较。核心发现包括:开球时间显著影响流量,深夜和凌晨比赛会使流量翻倍,而白天比赛可能导致流量下降;不同国家在比赛中场休息时呈现相反的流量行为(短视频社交 vs. 流媒体观看),聚类分析揭示了三种典型模式。文章还量化了最具全球影响力的比赛和球队,并观察到体育博彩网站流量上升。该分析提供了事件驱动流量研究的可复用框架,但其具体结论仅适用于类似全球性赛事,且主要基于 HTTP 层面。

推荐收录。文章展示了大规模互联网流量分析的完整工程案例,包括基准定义、偏离标准化和行为聚类等方法,具有可迁移至其他全球事件或容量规划场景的价值。适合网络工程师、SRE 及数据分析人员参考,能帮助理解如何从实际观测数据中提炼流量行为模式。

工程实践ClickHouse Engineering

Replacing the HDB: ClickHouse for historical ticker data

文章以 Binance 公开行情归档为数据源,演示如何用 ClickHouse 承载历史 tick 数据:实时层之外的历史层是低风险试验场,适合引入新数据库。核心手段是列式存储配合针对性编码——LowCardinality 处理低基数 symbol,DoubleDelta 压缩单调递增的 ts 与 trade_id,ZSTD/LZ4 利用重复字节模式。作者给出完整建表、写入与查询示例,覆盖 VWAP、OHLC K 线、ASOF JOIN 计算滑点等交易台常用分析,并用量表统计验证:一个月 191 GiB 原始 CSV 压缩至约 10 GiB,十个月 162 亿行仅 76 GiB,Cloud 成本约每月 1.88 美元,且查询延迟不随数据量增长,因为主键 (symbol, ts) 稀疏索引将扫描裁剪到万分之一。边界在于不按 symbol 与时间过滤的查询仍需全表扫描。

收录理由:文中不仅有可直接复用的建表结构、编码选择与 VWAP/OHLC/ASOF JOIN 查询,还给出压缩比、成本与查询计划等可验证证据,属于有取舍、有量化的真实工程案例。适合从事时序/行情数据、OLAP 选型与压缩调优的读者迁移到类似高写入、按维度过滤的分析型负载。风险在于内容为厂商博客,读者需注意其面向 ClickHouse 的视角,未与其他方案横向对比。

工程实践Xe Iaso

You should probably check on your smart appliances

文章基于 Anubis 蜜罐功能收集的真实数据,分析 Web 爬虫流量的全球分布与来源特征。数据表明 80–90% 的蜜罐命中来自未列入已知威胁列表的 IP,且主要集中于住宅 ISP 或消费级网络。作者通过国家、ASN、网络提供商的分类统计,发现大量流量可能源自受入侵的智能家电设备,它们被用作代理网络的一部分。该分析揭示了当前威胁情报库在抵御大规模爬虫攻击方面的不足,并强调了部署 Web 应用防火墙的必要性。

推荐收录,因为它基于真实蜜罐数据提供了关于爬虫流量来源的量化洞察,挑战了仅依赖公开威胁列表的防御假设。适合 Web 安全、反滥用及基础设施工程师参考,文中数据清洗、分类统计方法和来源推论可迁移到类似流量分析任务中,有助于设计更合理的防御策略。

工程实践Instacart Tech Blog

Variance Reduction Below the Randomization Grain

文章讨论在市场型系统中做实验时,因干预单位之间存在相互影响,往往必须按地理区域或 switchback 这类粗粒度随机化,导致有效样本量下降、实验周期拉长。作者在 CUPED 的基础上提出“低于随机化粒度”的方差缩减方法:先用仅由处理前特征构成的订单级模型预测单笔订单结果,再按与指标一致的方式聚合到 region-day,作为 CUPED 协变量使用。文章强调必须避免使用受处理影响的特征,并用对预测值做 placebo 检验来发现特征污染。Instacart 在 10 个降低迟到率的实验中验证,该方法相较区域级 CUPED 将方差再降 18% 到 40%,平均把实验时长缩短约三分之一。该思路适用于社交网络、广告拍卖或地理市场等存在干扰但观测粒度更细的场景,但前提是协变量可严格视为处理前信息。

推荐收录,因为文章给出了可复用的实验设计证据:在粗粒度随机化下,利用更细粒度的处理前预测并聚合,可显著降低方差且保持无偏。适合做实验平台、数据科学和 marketplace 优化的读者参考,但需注意特征污染与 placebo 检验这两个关键风险。

工程实践Cloudflare Blog

Content Independence Day, one year on: building the business model for the agentic Internet

这篇 Cloudflare 报告回顾了“Content Independence Day”一年后的变化,基于 Cloudflare Radar 和 Investor Day 数据,讨论开放网络在 AI 时代的流量、抓取与商业模式重构。文中给出多个量化信号:代理流量首次超过人类流量、抓取请求中 AI 训练占比快速上升、混合用途爬虫让内容所有者难以区分抓取目的。作者认为,传统“内容换搜索流量”的交换关系正在失效,出版商和网站正在面对“Google Zero”式的流量下滑。报告进一步指出,透明声明、访问控制和网络级执法会制造稀缺性,从而推动内容授权市场与更精细的定价机制。其结论是:面向 agentic Internet,需要新的基础设施来支持权限、许可、度量和交易,但这些判断明显带有 Cloudflare 自身网络视角和商业立场。

收录价值在于它提供了云安全/边缘网络视角下的真实流量数据与抓取目的变化,能帮助理解 AI 时代网站访问、机器人识别和内容授权的系统性变化。适合做互联网基础设施、爬虫治理和内容变现趋势参考,但读者也需注意其数据来自 Cloudflare 网络,立场带有明显商业主张。

工程实践Netflix TechBlog

Predicting Risk in Content Launches: How Data-Driven Insights can Transform Launch Planning

这篇文章讲的是 Netflix 如何用生产数据预测内容上线前关键媒体资产的交付风险,从而辅助判断何时启动 launch preparation。作者先指出手工排期存在覆盖不足和误差偏大的问题,再用 Accumulated Error Days 量化排期不准与 launch miss 的相关性,并用基于 boosted tree regression 的日级快照特征模型预测 Locked Cut 和 IMF 的“剩余交付天数”。文章最后通过回测说明模型在 MAE、偏差、长尾误差和覆盖率上整体优于人工排期,但也强调在部分业务线里仍需要保留手工日期与模型日期并行、按场景选择的策略。

推荐收录,因为它不是泛泛讲“用机器学习预测日期”,而是完整展示了一个真实业务问题如何被建模、评估并嵌入现有工作流。对于做数据分析、预测建模、排期优化和业务决策支持的人来说,这篇文章对指标设计、回测方法和落地边界都很有迁移价值。

工程实践Lyft Engineering

Metric Semantic Layer: How Lyft Governs and Scales Key Data Definitions

这篇文章介绍 Lyft 如何构建内部 Metric Semantic Layer(MSL)来统一关键指标定义,核心目标是解决不同团队对同一指标口径不一致、定义分散和变更难以治理的问题。文章给出了较完整的实现思路:用 YAML 存储指标元数据、用 Jinja 模板生成 SQL、通过 Python 包和 API 对外提供访问能力,并结合“Business Owner / Operational Owner”的双责任模型来管理指标生命周期。文中还进一步说明了如何接入数据目录、自助 BI 工具以及 MCP/AI Agents,使标准化指标定义既能支持分析与运营,也能作为 AI 工具的可靠知识源。

推荐收录,因为它不是泛泛而谈“数据治理”,而是把指标定义、版本管理、权限责任、访问接口和下游集成串成了一套可落地的工程方案。对做数仓、指标平台、BI 基础设施或 AI 数据工具的读者来说,这篇文章提供了很强的可迁移经验,尤其适合理解“单一事实来源”如何在组织规模化时真正落地。

工程实践Lyft Engineering

From Chaos to Clarity: How We Built a Unified, Self-Routing Support Ops Ticketing System at Lyft

这篇文章复盘了 Lyft Urban Solutions 支持运营团队如何把一个混乱、重复且不可观测的 Jira Help Center,逐步重构为统一入口、自路由、可报表化的工单系统。作者按“表单重构、自动化路由、跨项目合并、数据可视化”四个阶段展开,具体介绍了 Proforma 动态表单、Jira 自动化、工单克隆与联动、标签体系设计、Structures 仪表盘以及 Jira 到 Mode 的 ETL 分析链路。文章最后还讨论了向 Jira Cloud 迁移时面临的集成重构、报表替换和告警配置重建等边界条件。

推荐收录,因为它不是单纯的工具介绍,而是把支持工单系统当作一套可设计、可演进的数据与流程基础设施来建设,包含了明确的权衡、阶段性改造和迁移风险。对做内部平台、工单系统、运营自动化或数据可视化的人来说,这篇文章提供了高度可迁移的设计原则和落地路径。

工程实践Lyft Engineering

Beyond A/B Testing: Using Surrogacy and Region-Splits to Measure Long-Term Effects in Marketplaces

本文讨论 Lyft 在双边市场中如何评估价格、补贴等决策对长期供需的影响,而不是只看短期 A/B 结果。作者把“市场中介效应”拆成两步:先用残差化回归估计政策变化如何改变等待时长、surge、取消率等负面体验,再用 AIPW 等双重稳健方法估计这些体验对未来乘车量、留存和司机时长的影响。为验证这条因果链,文章分别使用 switch-back、user-split 和 region-split 实验做校准,并提出前向选择算法来改进区域分组的预实验拟合与统计功效。最后将中介效应与直接长期效应合并,用于预算分配和情景规划。其主要边界在于“长期中介效应完全通过负面体验传递”的假设,以及 region-split 天然存在拟合差、功效低的问题。

收录理由明确:文章给出了从观测因果推断到多种实验验证的完整链路,直接面向市场供需、补贴定价和长期效应评估。适合做 marketplace、增长实验和因果分析团队的参考,但读者也应注意其强假设与区域实验功效不足的风险。

工程实践Lyft Engineering

Trusting the Untestable: Validation and Diagnostics for the Doubly Robust Models

文章介绍 Lyft 如何在无法做随机 A/B 测试时,用 AIPW 这类双重稳健模型评估因果影响,并把“可验证性”作为平台能力来建设。作者重点说明两类输入约束:必须显式选择大量混杂变量,且其数据必须来自首次曝光前,以避免泄漏;同时对下采样带来的倾向得分和结果权重偏差做了校正。文中还给出两类核心诊断:倾向分数重叠/共同支持检验,以及调整前后协变量平衡检查,来判断估计是否可信。为了验证方法本身,作者用周度 ride challenge 的实验数据作 ground truth,与观测数据上的 AIPW/ATET 结果对照,发现观测估计通常偏低,主要原因是 trim 后分析样本不再代表总体。基于这一发现,团队新增了隐藏混杂敏感性分析和 trimmed vs. untrimmed 协变量对比,用于识别外部有效性和未观测偏差的风险边界。

推荐收录,因为文章不仅讲 AIPW 原理,还给出混杂变量管理、共同支持、协变量平衡、敏感性分析等可落地诊断流程,并用实验对照验证偏差来源。适合做因果推断、实验平台和数据科学平台建设参考,尤其对需要在非随机场景下建立可信度的团队很有迁移价值。

技术文章Andy Pavlo Database Blog

Databases in 2022: A Year in Review

本文是 Andy Pavlo 对 2022 年数据库领域的年度回顾,按融资、区块链数据库、新系统、人物纪念等主题梳理行业动态。作者指出数据库创业融资在下半年明显转冷,并以架构分析讨论 Google AlloyDB、Snowflake Unistore、MySQL Heatwave、Meta Velox、InfluxDB IOx 等新系统;他认为 Velox、DataFusion 等可扩展执行引擎会推动 OLAP 查询执行组件商品化,未来差异化将转向 UI/UX 与查询优化。文章还强烈批评区块链数据库在加密货币之外缺乏实际用例,并纪念 Martin Kersten 对 MonetDB、列存与向量化执行的贡献。内容带主观立场和大量个人评论,不是严格技术论文或实验报告,但可作为观察 2022 年数据库生态的参考。

推荐收录,因为文章由数据库领域知名研究者撰写,直接记录了 2022 年数据库融资、产品发布与系统架构变化,并对 AlloyDB、Velox 等给出可讨论的架构判断。适合数据库研究者、系统架构师和基础设施从业者了解行业趋势与技术脉络。需注意其观点主观、夹杂段子和政治玩笑,且缺少实验数据,不能替代深度技术论文。

工程实践Datadog Engineering

How Datadog uses Datadog to gain visibility into the Datadog user experience

文章讲的是 Datadog 的 DesignOps 团队如何把 Datadog 本身用在自己的产品与设计工作中,借助可观测性手段理解用户如何使用产品,并据此做更稳妥的设计决策。作者强调,单靠主观反馈很难看清真实行为,因此需要把用户路径、功能采用率、流失点和关键交互事件纳入可视化分析。文中展示了如何把前端与产品遥测组织成仪表盘、漏斗和趋势观察,从而快速发现体验中的摩擦点,并验证改版是否真的改善了用户行为。文章的核心结论是:可观测性不仅适用于后端故障排查,也能成为产品与设计团队的决策基础。其边界在于,这类指标更擅长描述“发生了什么”,仍需结合定性研究判断“为什么会这样”,并注意埋点质量与隐私约束。

收录价值在于它直接展示了如何把可观测性用于用户体验分析,而不是只用于运维排障。适合做产品工程、DesignOps、埋点分析和体验优化的读者参考,迁移价值在于指标设计、漏斗观察和改版验证的方法。