資料與儲存 2026 年 4 月 22 日

2026-04-22 — Uber 混合 CPU 分配策略、Databricks AI 代理實時決策上下文層、DuckLake v1.0 正式生產就緒

Hybrid Core Allocation: Moving…

Hybrid Core Allocation: Moving Past CPU Overprovisioning at Uber Scale

Uber Engineering · 2026-04-21

Uber 工程團隊在 Odin 容器編排系統中引入混合 CPU 分配策略,結合專用核心(dedicated cores)與共享核心(shared cores)兩種模式,解決大規模容器叢集中 CPU 過度配置問題。

背景問題

傳統容器編排要求開發者在專用 CPU(低延遲但利用率低)與共享 CPU(高利用率但不可預測延遲)之間二擇一,導致要麼過度配置、要麼服務品質不穩定。

混合分配設計

系統採用 Linux cpusetscpu_shares 機制:

  • 專用核心:在同一 NUMA 節點內分配,確保記憶體局部性
  • 共享核心池:跨多個節點分布,滿足爆發性需求
  • CPU shares 計算公式(專用 CPU + 共享 CPU) × 100,確保比例分配的整數精確表示

關鍵創新:原地垂直擴容

傳統方案在擴容時需要遷移容器,對本地 SSD 存儲的有狀態服務造成嚴重運維干擾。混合分配支援在不遷移有狀態工作負載的情況下調整 CPU 配置,大幅降低資料庫和快取服務的維護成本。

工程收益

  • 降低 CPU 過度配置率
  • 提升整體叢集利用率
  • 維持服務級性能 SLO
  • 有狀態服務零停機擴縮容

這個方案對任何運行有狀態微服務(資料庫、快取、訊息佇列)的大規模 Kubernetes 叢集都有參考價值。


Real-Time Decisioning for AI Agents: Why You Need a Customer Context Layer First

Databricks Blog · 2026-04-21

Databricks 深度探討 AI 代理決策系統所需的客戶上下文基礎設施,提出「客戶上下文層(Customer Context Layer)」架構。

客戶記錄 vs 客戶上下文

這是文章的核心區分:

  • 客戶記錄:靜態的歷史資料(購買記錄、帳戶資訊、歷史行為)
  • 客戶上下文:即時行為信號(當前瀏覽路徑、點擊序列、當前意圖)

傳統 CRM 系統優化了前者,但 AI Agent 的決策質量取決於後者。

四階段反饋循環

  • 收集:採集人類和 AI 交互的所有行為資料
  • 解析與豐富:識別客戶身份、構建完整圖譜,關聯跨渠道行為
  • 實時推送:向 AI Agent 提供即時上下文信息(延遲目標 < 50ms)
  • 學習:將決策結果回流為事件資料,觸發下一輪上下文更新

架構範式轉變

文章強調:資料平台已成為技術堆疊的「重力中心」,應用程式不是運行在資料基礎設施之上,而是運行在其中。AI Agent 和自定義軟體在同一共享資料層上運營,消除了傳統整合管道的延遲。

對於構建需要實時個人化的 AI Agent(電商推薦、金融服務、客服機器人),建立客戶上下文層是決策質量的先決條件。


Data Engineer Things: DuckLake v1.0 Production-Ready, Spotify Wrapped Architecture, Nextdoor DB Evolution

Data Engineer Things (Substack) · 2026-04-21

Data Engineer Things: DuckLake v1.0 Production-Ready, Spotify Wrapped Architecture, Nextdoor DB Evolution

本期 Data Pulse 特刊彙聚五大資料工程戰略主題,涵蓋現代資料系統的關鍵發展趨勢。

1. DuckLake v1.0:生產就緒的 Lakehouse 格式

DuckLake v1.0 正式宣布生產就緒,提供開放的 lakehouse 表格格式。相比 Delta Lake 和 Iceberg,DuckLake 原生整合 DuckDB,針對分析查詢進行優化,支援 ACID 事務和 schema evolution,適合需要輕量級 lakehouse 的中小型資料工程團隊。

2. Spotify Wrapped 架構

Spotify 展示了如何將數十億用戶聆聽行為轉化為個人化敘事的大規模管道工程:結合預計算(批次處理歷史資料)與 AI 生成敘述(LLM 生成個性化文案),在全球規模上實現延遲可控的個人化體驗。

3. Nextdoor 資料庫演進歷程

從單個 PostgreSQL 實例逐步擴展的案例研究:

  • 第一階段:主庫 + 讀副本(解決讀負載)
  • 第二階段:加入連接池(PgBouncer)
  • 第三階段:引入快取層(Redis)
  • 第四階段:業務分片

每一層擴展都帶來複製延遲和一致性的新 trade-off,展示了真實的資料庫演進決策過程。

4. 上下文工程趨勢

平台正演變為將語義元數據(譜系、所有權、使用模式)作為核心構建塊,而非事後補充,這對 AI 原生資料系統至關重要。


來源:Data Engineer Things (Substack), Databricks Blog, Uber Engineering

End of article
0
Would love your thoughts, please comment.x
()
x