datainfra前沿动态 · Vol.52

talabat 以单一 Iceberg 副本 + BigQuery 联邦查询打通混合多云 Lakehouse，跨云数据复制归零；AWS OpenSearch 优化引擎用 DataFusion 列式执行直查原始日志与 Trace，告别预计算汇总表；AWS 提出 Agentic AI 实时流式三大架构模式；Amazon MSK 用单一配置属性统一自定义域名并扫清 KRaft 迁移障碍

本期聚焦四条 DataInfra 动态：talabat 在 AWS Big Data Blog 披露其混合多云 Lakehouse 架构——把全部数据以 Apache Iceberg 单一副本存入 Amazon S3 Tables，让 Google BigQuery 通过 Lakehouse 联邦 Iceberg REST Catalog 配合 OIDC+IAM 信任原地只读查询，彻底消除跨云数据复制与 schema 同步，数据新鲜度从 60-90 分钟压缩到 95% 事件 5 分钟内可查、数据移动成本降低约 40%；AWS 为 Amazon OpenSearch Service 引入优化引擎，以 Apache Parquet 列式存储 + DataFusion 向量化执行 + Calcite 规划直查原始日志与 Trace，无需预计算结构，压缩效率较默认引擎高 70%；AWS 同日在另一篇博客提出支撑 Agentic AI 的实时流式三大架构模式（流式特征工程实时推理、事件驱动 Agent 调用、实时上下文同步）；Amazon MSK 新增单一配置属性 custom.advertised.listeners 统一自定义域名配置，在 ZooKeeper 与 KRaft 模式下工作方式完全一致，为 KRaft 迁移扫清障碍。

DataInfra talabat 多云 Lakehouse Apache Iceberg Amazon S3 Tables BigQuery Lakehouse 联邦 Iceberg REST Catalog OIDC IAM 跨云查询 OpenSearch DataFusion Parquet SQL PPL 日志分析 Agentic AI 流式数据 Managed Flink Amazon MSK Kafka KRaft 自定义域名

本期追踪到四条 DataInfra 动态，全部落在 2026 年 8 月 18 日 AWS Big Data Blog 的连发内容上，但它们共享一条主线：数据基础设施正在从”把数据搬来搬去”走向”让数据留在原地、让引擎和身份跨过去”——开放表格式 + 联邦目录 + 身份信任正在取代跨云/跨引擎的数据复制管线。talabat 用 Apache Iceberg 单一副本存于 Amazon S3 Tables，让 Google BigQuery 通过 Lakehouse 联邦 Iceberg REST Catalog 原地只读查询，把”多云”从技术债变成既定地形；AWS 为 OpenSearch Service 引入以 Apache DataFusion 为核心的优化引擎，用列式 Parquet + 向量化执行直查原始日志与 Trace，把”预先建索引/汇总表”这套可观测性数据管线的旧范式推倒重来；同日的另一篇博客则把 Agentic AI 的实时流式需求抽象成三种可复用的架构模式（流式特征工程、事件驱动 Agent 调用、实时上下文同步），并指出三者可以共享同一条流式主干；Amazon MSK 用一个集群级配置属性统一了自定义域名配置，让 ZooKeeper 与 KRaft 首次在同一条路径上工作。四条动态共同指向：当 Iceberg REST 目录、DataFusion 向量化执行与身份即服务成为默认组件，DataInfra 的竞争焦点正在从”谁搬数据更快”切换到”谁能让数据一次落位、随处可信地被读取”。

talabat 混合多云 Lakehouse：单一 Iceberg 副本 + BigQuery 联邦查询，把跨云数据复制归零

事件概述

2026 年 8 月 18 日，AWS Big Data Blog 发布《Fresher insights, faster decisions: talabat’s near-real-time analytics across AWS and Google Cloud》，披露了中东与北非（MENA）领先即时配送平台 talabat 的混合多云 Lakehouse 架构。talabat 的技术栈天然跨两个公有云：AWS 承载事务与流式处理骨干（运营平面，服务部署在伦敦 eu-west-2），Google Cloud 承载分析平台（数千个下游模型与仪表盘依赖 BigQuery，数据位于美国区域）。面对”要不要做云迁移整合”的经典难题，talabat 的回答是不做迁移、让数据干净地跨云流动——设计目标一句话概括：在 AWS 上保留一份物理数据副本，让两个云都能原生读取它。

架构的核心是”单一数据源 + 跨云联邦读取”：所有数据以 Apache Iceberg 格式存入 Amazon S3 Tables（us-east-1），所有消费方读取的是同一份物理数据。写入路径完全留在 AWS 内部——每个 Kafka topic 对应一个 Amazon EMR Serverless Spark Structured Streaming 作业（emr-7.13.0，ARM64/Graviton，与 MSK 同区域 eu-west-2），以 1-5 分钟微批、foreachBatch 至少一次投递语义，经过”从 Kafka 消费 → Protocol Buffers 解码 → 转换为 Iceberg schema → 追加写入 S3 Tables → 提交 offsets”五步，坏记录写入独立 _dlq 死信表不阻塞主流。而读取路径是真正创新所在：BigQuery 通过 Google Lakehouse 联邦 Apache Iceberg REST Catalog 直接读取 S3 Tables 中的 Iceberg 数据，零数据移动。

技术解析

  • 跨云身份与信任（OIDC + IAM）：这是整个架构的安全核心。Google（accounts.google.com）注册为 AWS IAM OIDC 身份提供方，IAM 角色信任策略通过 StringEquals 条件精确匹配 Lakehouse 服务账号的 sub 声明（数字 ID）排除所有其他主体；Google 管理的服务身份经 sts:AssumeRoleWithWebIdentity 换取临时凭证，对 S3 Tables Iceberg 端点请求用标准 SigV4 签名，权限范围严格只读（s3tables:GetTable、s3tables:GetTableData 等，无任何写入），会话时长 12 小时（max_session_duration = 43200），且 AWS 密钥永不存放在 Google Cloud 侧。

  • 开放目录契约 + 元数据同步：S3 Tables 暴露 Apache Iceberg REST catalog 标准接口，Google Lakehouse 使用同一协议，无需翻译层或数据拷贝——BigQuery 读到的 Iceberg 数据文件与 Athena/Spark 读取的完全相同，表在 BigQuery 中显示为 talabat-data.s3tables-glue.catalog.orders 这类普通对象。Lakehouse 联邦 catalog 定期从 AWS Glue Data Catalog 同步表元数据，新表与新增数据约 300 秒（5 分钟）内对 BigQuery 可见，读取直接作用于实时 Iceberg 数据文件，同步的仅是 catalog 指针。

  • 方案选型与”Shift left”教训：talabat 评估了三种让 BigQuery 读 AWS 数据的方案——跨云写入 GCS（BigQuery 管理的 Iceberg，因热路径引入跨云依赖、流式写 API 故障会直接表现为摄入事故而被否决）、BigQuery Omni（托管表面过大、无法直接掌控 catalog 与信任模型而被否决）、以及最终采纳的 Lakehouse 联邦 Iceberg REST catalog + S3 Tables。最开始的方案其实是反过来的（AWS 直接写 BigQuery 管理的 Iceberg 表），遭遇”摄入路径依赖远程写 API 可用性与延迟”的问题后，团队总结出核心教训——“Shift left”：写路径应短、本地、简单，跨云关注点应落在只读路径（可设为只读、可缓存、可重试而不影响摄入）。

  • 量化收益：数据新鲜度从旧架构（RDS → S3 EU → S3 US → BigQuery US 多跳 ETL）的 60-90 分钟压缩到 95% 事件 5 分钟内可查询；数据移动成本降低约 40%（对比前后各两个月的数据传输、编排、多层 ETL 与存储备份费用）；每月消除数百 TB 的周期性跨区域跨云数据传输；存储副本从多份降至 1 份；BigQuery、Athena、Spark 三个计算引擎共享同一物理数据集。

行业影响

talabat 这套架构是本期最具信号意义的故事，因为它把过去一年”开放表格式 + 联邦目录”的种种单点技术，拼成了一个可落地的多云湖仓范式。它的深层意义在于重新定义了”多云”：过去多云几乎等同于”数据复制 + schema 同步”的运维债务，而 talabat 用 Apache Iceberg 单一副本 + Iceberg REST Catalog 标准契约 + OIDC/IAM 跨云身份信任三者，把多云变成了”既定的数据地形”。这与此前 Vol.47/48 连续报道的 Iceberg 生态演进（Variant 类型、Rust 实现、File Format API）、Vol.45 的 Google BigQuery DTS 零代码摄入构成一条清晰脉络——表格式的开放标准正在从”单云内的引擎互操作”延伸到”跨云的原生联邦读取”。对 DataInfra 从业者的启示有三：一是写路径与读路径的工程复杂度必须解耦，跨云关注点应集中在只读、可重试、可治理的那一侧；二是身份信任（OIDC + IAM 条件策略 + SigV4）正在成为与表格式同等重要的”跨云基础设施”；三是当 S3 Tables + Iceberg REST 把”写一次、任意引擎读取”变成默认模式，传统跨云 ETL 管线（及其出站费用、延迟、故障面）的存续理由正在快速蒸发。

相关链接

AWS OpenSearch 优化引擎：以 DataFusion 列式执行直查原始日志与 Trace，告别预计算汇总表

事件概述

2026 年 8 月 18 日，AWS 发布《Querying raw log data using SQL and PPL with the optimized engine in Amazon OpenSearch Service》，回答了一个可观测性领域长期悬而未决的实操问题：在不移动、不重塑数据的前提下，能对原始日志与 Trace 数据做多少分析工作？答案来自 OpenSearch Service 新引入的优化引擎（optimized engine）——你可以把 Piped Processing Language（PPL）与 Structured Query Language（SQL）查询直接指向原始日志与 Trace 数据，引擎在数十亿事件上返回聚合、过滤与扫描，且背后没有任何预计算结构（无 rollup 表、无预聚合汇总）。

这篇 how-to 用一次真实事件定位（SRE 根因分析）作为主线，在 10 亿级 OpenTelemetry（OTEL）span 的合成数据上连续提出五个问题、跑五条查询，每一条都直接作用于原始 span：从”按 service/HTTP 方法/Region 拆错误分布”到”按 exception_type/主机定位是否单节点故障”、“量化各服务延迟分布”、“计算错误率”、“用 COUNT(DISTINCT) 估算各服务覆盖的主机规模”，PPL 与 SQL 在调查中途自由切换，逐步确认”这是全机队范围的模式性问题而非单机故障”。

技术解析

  • 列式 + 向量化 + 智能路由的混合架构：优化引擎把数据以列式 Apache Parquet 格式存储，查询经 Apache DataFusion（向量化执行引擎）执行、由 Apache Calcite 规划。因为数据按列存储，分析型查询只读它触碰的列、按批处理值，而非逐文档整读；同时引擎在同一份数据上保留了倒排索引，查询规划器把每个操作路由到最优路径——列式引擎负责聚合与分析扫描，倒排索引负责选择性搜索与过滤。这种”列式分析 + 倒排检索”双路并存的设计，正是它能同时服务聚合扫描与点查过滤的关键。

  • 无预计算、按需表达：演示中的错误率（eval is_err = if(status_code=2,1,0) | stats ... | eval error_pct = round(...)）等指标全部在查询内联定义、跨全索引即时计算，SRE 无需提前知道”要查什么”、也无需等运维预建汇总表——这正面回应了可观测性数据”问题不可预测、无法预先建模”的本质。

  • 压缩与落地门槛：优化引擎对可观测性数据的压缩效率比默认 General Purpose 引擎高 70%，把”保留全量数据、直接查询”从理想变成可负担的默认；接入只需创建 OpenSearch 3.5+ 的 domain 并在 setup 时选择 Observability 用例，无需新工具——Query Workbench 与 Discover 中 PPL/SQL 同一套语言可互换使用。这延续了 AWS 此前《Run log analytics for a fraction of the cost with the new engine》的成本叙事。

行业影响

这条动态的行业意义在于：可观测性数据管线长期依赖的”摄取即索引、查询走倒排”范式，正在被”列式存储 + 向量化执行 + 按需查询”的新范式挑战。传统 OpenSearch/Elasticsearch 日志方案的核心痛点是——为了可查询而不得不做 indexing 与 field mapping，代价是写入放大、存储膨胀、查询模式受 schema 束缚；而优化引擎把 DataFusion/Parquet 这一分析引擎世界的成熟技术栈引入日志分析，用”列存 + 压缩 70% + 无预计算”同时拿下了存储成本与查询灵活度。这与 Vol.49 报道的 AWS OpenSearch GPU 向量索引、以及本期 talabat 的跨云湖仓形成呼应——OpenSearch 正在从”搜索引擎”演化为”搜索引擎 + 分析引擎”的混合体，其底层技术选型（DataFusion、Calcite、Parquet）与 Iceberg/Delta 生态共享同一批开源组件，意味着日志、指标、Trace 与结构化湖仓数据的分界正在变薄。对从业者而言，一个值得跟踪的方向是：当 OpenSearch 也能以列式引擎直查原始数据，它是否会在日志/可观测性场景里与 ClickHouse、Grafana Loki、以及湖仓上的分析引擎（Athena/DataFusion Comet）展开正面竞争。

相关链接

AWS 提出 Agentic AI 实时流式三大架构模式：一条流式主干同时支撑特征、触发与上下文

事件概述

2026 年 8 月 18 日，AWS 发布《Powering agentic AI with real-time streaming data on AWS》（Mazrim Mehrtens 与 Ali Alemi 撰写），把 Agentic AI 应用对实时流式数据的需求抽象为三种可复用的架构模式，并提出一个贯穿始终的洞察：流式数据不再只是”为 LLM 注入上下文”，而是持续驱动自主 Agent 的观察、推理与行动。三种模式分别是：流式特征工程与实时推理、事件驱动的 Agent 调用、以及实时上下文同步。

文章的核心主张是”共享流式主干”——一套流式基础设施（Amazon MSK / Kinesis Data Streams + Amazon Managed Service for Apache Flink + Amazon S3 Tables）可以同时服务三种模式：一个 Flink 应用既能做特征计算（模式一）、又能做异常检测触发（模式二）、还能把状态同步到 Agent 内存（模式三）。这标志着从”向提示词注入上下文”到”流式数据持续驱动自主 Agent 行动”的范式转变。

技术解析

  • 模式一：流式特征工程 → 实时推理 → 行动：流式管道同时承担”为训练构建特征”与”为实时推理构建特征”的双重职责。事件数据流入 MSK/Kinesis，Managed Flink 执行窗口聚合（滚动/滑动/会话窗口）产出滚动均值、比率、行为序列等衍生特征；特征在窗口结束时（或按事件）交给 Amazon Bedrock（生成式输出）或 SageMaker（自定义模型），模型产出后管道立即执行动作；同一批特征持续写入基于 Iceberg 的 S3 Tables 保持训练集新鲜。典型场景如实时体育解说（Flink 算控球率/射门频率 → Bedrock 生成解说）与流式个性化（点击流算行为特征 → 实时更新推荐排序）。

  • 模式二：事件驱动的 Agent 调用：流式管道充当”传感器”，持续分析数据、在检测到条件时触发 Agent 工作流——与模式一的”持续推理”不同，这是条件触发。Managed Flink 运行异常检测逻辑（统计模型、窗口聚合、阈值规则或 ML 评分），检测到异常时不只发原始告警，而是组装完整上下文包（异常详情、相关历史、跨流关联信号、Agent 行动所需元数据）发布到下游主题，由 Amazon Bedrock AgentCore（Runtime 托管、Observability 追踪日志、Memory 跨调用记忆”这是该设备本周第三次异常”）消费。相比轮询方案，其优势是”异常后数秒内触发 + 管道已完成信号关联与上下文组装”，触发规则可从简单阈值扩展到 3σ 统计规则再到嵌入模型异常分数。

  • 模式三：实时上下文同步：通过 CDC 与流式管道把分布式系统状态持续同步到 Agent 的上下文层/知识图谱，让 Agent 变”主动”——从内存直接响应，而非每次昂贵的外部 API 调用。上下文存储按访问模式选择：AWS Context（自动映射关系到知识图谱）、Bedrock AgentCore Memory（跨会话结构化上下文）、DynamoDB（低延迟 KV）、OpenSearch Serverless（非结构化语义搜索）、Neptune（关系丰富的图）、S3 Tables（托管 Iceberg 表）；未预加载的数据通过 MCP 服务器按需查询兜底。同一同步层可同时服务 AI Agent、人类分析师（Quick 对 Iceberg 表做自然语言查询）与训练/微调管道（SageMaker Lakehouse）。

行业影响

这篇博客是”流式数据基础设施为 Agent 时代重定位”的一份清晰宣言，也把 AWS 近期零散的流式动作（Vol.45 的 Kinesis、Vol.46 的 Flink 调优、本期 MSK 自定义域名）串成了一条完整主线。它的深层信号是：“实时流式”的价值主张正在从”BI 报表更快”切换为”Agent 行动的输入”——模式二里”管道组装上下文包再交给 Agent”的设计，把过去由 Agent 内部完成的多跳查询与信号关联下沉到了流式层，本质上是把”上下文工程”（Vol.44/51 报道的 dbt “为 token 建模”、Snowflake Cortex Gateway）的边界进一步前移到数据管道。这与本期 talabat 的”写路径短、读路径本地”、Vol.51 DuckDB v2.0 的异步 I/O 形成共振：当 Agent 成为数据的第一消费者，“离数据更近、以流式/事件方式供给上下文”正在成为 DataInfra 的默认设计约束。对从业者的启示是，Agentic 系统的数据架构不应从”问答/检索”倒推，而应从”什么数据需要预加载、什么数据按事件触发、什么数据按需 MCP 拉取”这三个流式问题出发——而这套”特征-触发-上下文”三模式，恰好给出了一个可复用的起点。

相关链接

Amazon MSK 简化自定义域名配置：单一属性统一 ZooKeeper 与 KRaft，为 KRaft 迁移扫清障碍

事件概述

2026 年 8 月 18 日，AWS 发布《Amazon MSK simplifies configuring custom domain names》，宣布 Amazon MSK（Managed Streaming for Apache Kafka）为 Provisioned 集群引入一个集群级配置属性 custom.advertised.listeners，一举解决了自定义域名配置的长期痛点。此前配置自定义域名的唯一方式是 kafka-configs.sh --alter 工具逐 broker 手动覆盖 advertised.listeners，存在三大问题：新增 broker 需重复覆盖、无验证机制（接受任意字符串、拼写错误即导致服务中断）、无法用 IaC 管理；更关键的是——在 KRaft 集群上根本无法实现，这直接阻碍了依赖自定义域名的客户向 KRaft 迁移。

新方案用 custom.advertised.listeners=<LISTENER>://<hostname>:<port> 一个属性完成全部配置，并支持 {broker_id} 模板变量——主机名或端口中的变量会为每个 broker 自动解析（如 b-{broker_id}.example.com 解析为 b-1.example.com、端口 9000+{broker_id} 解析为 9001/9002/9010），只需保证每个 broker 解析出的 host:port 唯一。

技术解析

  • 监听器白名单与严格验证：仅支持 7 种客户端监听器（CLIENT、CLIENT_SECURE、CLIENT_SECURE_PUBLIC、CLIENT_SASL_SCRAM、CLIENT_SASL_SCRAM_PUBLIC、CLIENT_IAM、CLIENT_IAM_PUBLIC），内部监听器（REPLICATION、CONTROLLER）会被拒绝；指定的监听器必须是集群上已绑定的，否则报错并列出有效监听器清单。应用配置走 UpdateClusterConfiguration API 三步流程——同步验证（监听器合法、含 {broker_id}、host:port 唯一）→ 逐 broker 解析 → 滚动重启，验证失败返回描述性错误且不做任何更改。

  • ZooKeeper 与 KRaft 完全统一：新属性在两种模式下工作方式完全相同，消除了 KRaft 集群此前”完全无法使用自定义域名”的硬限制——这被 AWS 明确点名为”为客户的 KRaft 迁移扫清障碍”。配置可通过 Console、CLI、CloudFormation、CDK、Terraform 管理，且完全可逆（移除属性即恢复原始地址）。

  • 前置条件与运维边界：应用属性前，网络与信任层（NLB、TLS 证书、DNS 记录、安全组）必须已就绪，客户端 truststore 需包含 LB 自定义域名证书、DNS 需能解析（通常走 Route 53 私有托管区域）——否则客户端在下次元数据刷新切换地址后会立即断开。扩缩容时 MSK 会自动为新 broker 解析 {broker_id}，但网络层（NLB 监听器、目标组、DNS）需手动扩展。典型场景包括 IP 耗尽（不可路由子网经 NLB 路由）、集群迁移（客户端零重配）、灾难恢复（同一域名指向主备集群）与组织合规命名。

行业影响

这条动态体量虽小，却是 Kafka 托管服务走向”企业级可治理”的一个务实注脚。自定义域名看似是网络细节，实则是 Kafka 大规模落地时的高频卡点——跨集群迁移、主备切换、合规命名、TLS 证书治理，都依赖稳定的对外端点；而旧方案”逐 broker 手改 advertised.listeners”既不可自动化又不可验证，是典型的手工运维债。MSK 用一个带模板变量的声明式属性把它 IaC 化，并与 ZooKeeper/KRaft 双模统一，本质上是把 Kafka 的”连接地址”也纳入了配置即代码的治理范围。更重要的是，它与本期 Agentic AI 流式三大模式里”事件驱动 Agent 调用”的场景直接相关——当 Agent 依赖 Kafka 作为事件总线时，稳定、可迁移、可合规的 broker 端点就是 Agent 可靠接入的前提。把这个信号与 Vol.50 报道的 AWS RabbitMQ IAM 认证体系、本期 talabat 的跨云信任并置，能读出一条清晰的 AWS 动作线：AWS 正在把 Kafka/RabbitMQ 这类消息基础设施的”身份、端点、域名”治理能力，向企业 IAM 与 IaC 范式收敛——为 Agentic 时代的实时数据主干补齐最后一块企业级拼图。

相关链接

编者评

本期四条动态全部出自 2026 年 8 月 18 日 AWS Big Data Blog 的连发，这一”AWS 专场”本身就是信号：当行业把目光集中在模型层的军备竞赛时，云厂商对 DataInfra 的投资节奏并未放缓，反而在流式、湖仓、可观测性三条线上齐头并进。把四条并置，能读出一条贯穿始终的深层趋势——“数据不再搬运，而是原位供给；身份与目录取代复制管线，成为跨引擎、跨云、跨 Agent 的新的连接组织”。talabat 用”单一 Iceberg 副本 + Iceberg REST Catalog + OIDC/IAM 信任”让 BigQuery 跨云原地读 AWS 数据，把传统多跳 ETL 的复制成本、延迟与故障面一次性清零；OpenSearch 优化引擎用 DataFusion/Parquet 列式执行直查原始日志，把可观测性数据从”索引化”解放到”原位分析”；Agentic AI 三大流式模式则要求数据以事件、特征、上下文的形式离 Agent 更近地持续供给，而非事后搬进某个仓库再被查询；MSK 自定义域名把 Kafka 端点治理收敛进 IaC 与 IAM。四者的共同技术底色，是 Apache 开放组件（Iceberg、DataFusion、Calcite、Flink）正在成为云上数据服务的默认内核，而”开放表格式 + 联邦目录 + 身份即服务”正在取代过去十年”私有格式 + 专用复制管线”的封闭范式。对 DataInfra 从业者的启示是：下一阶段的架构决策，重心将不再是”选哪个仓库、用哪种 ETL”，而是”如何让数据一次落位、以开放契约与可信身份被任意引擎、任意云、任意 Agent 原生读取”——本期恰好是这一转向在 24 小时内四线并进的缩影。值得持续跟踪的下一站：talabat 这套多云湖仓模式能否被更多跨国企业复现、以及 AWS 是否会把它产品化为托管的跨云联邦能力；OpenSearch 优化引擎在真实生产日志规模下的性能与成本边界；Agentic 流式三模式从”架构建议”走向”托管产品”的速度；以及当 Kafka 的身份、端点、域名治理全部补齐后，MSK 与 RabbitMQ 的 IAM 化是否会反向推动企业自建消息集群的云迁移。