AI 模型的好壞，取決於實際送達它的資料，而這些資料幾乎從一開始就不乾淨、不集中、也不新鮮。它們通常散落在 CRM、若干 SaaS 工具、幾個資料庫，以及某個仍被同事用電子郵件寄來寄去的試算表中。

要把這一切轉化為 AI 系統可用的形態，本身就是一門專業，而這個類別才剛經歷一波真正的整併浪潮：兩家最大的獨立業者，在短短數個月內先後被更大的公司吸收。這對採購層面之外也有影響——當落地資料的工具與塑造資料的工具同屬一家公司時，供應商掌控哪一層，就成為每位買方都必須面對的策略問題。以下是當今真正在企業內部搬運資料的十個平台，無論獨立與否。

Fivetran

Fivetran 的聲譽建立在徹底消除資料搬運的痛苦之上。它提供自動化管線，可從超過七百個來源抽取資料，且結構描述變更會自動處理，不會因來源應用程式調整某個欄位就導致管線中斷。

該平台採全託管模式，這對沒有專職資料工程師看管自訂腳本的團隊正是吸引力所在。但這份便利確實有代價：與每月活躍列數掛鉤的用量計價，會隨資料量成長而快速攀升，且 2026 年的定價調整也開始在連線層級計費。

更大的重點在於 Fivetran 於 2025 年 10 月與誰合併：與 dbt Labs 的全股票交易使兩家公司合計年經常性收入約達 6 億美元，實質上是將擷取層與轉換層打包成單一供應商關係。值得觀察的是，合併後的公司是否會讓兩項產品對競爭對手的技術堆疊保持同等開放，因為其歷史客戶群中有不少混合搭配來自不同供應商的工具。

dbt Labs (dbt)

dbt 在這個堆疊中扮演特定而狹窄的角色，甚至幾乎可由它刻意不做的事來定義：它完全無法搬運資料。它是轉換工具而非 ETL 工具，這表示它永遠需要 Fivetran 或 Airbyte 等獨立的擷取層，先將原始資料落地到資料倉儲，dbt 以 SQL 與 Jinja 為基礎的建模才有用武之地。

它做的事，它做得很好：具版本控制、經測試且有文件說明的轉換邏輯，能讓指標在下游每個 BI 工具中保持一致。一旦 AI 應用開始查詢同一個資料倉儲，並需要底層數字在各處代表相同意義時，這一點就極為重要。

在 Fivetran 併購之後，客戶實質上擁有的是一段供應商關係，而非兩份合約——對原本就同時使用兩者的團隊而言，是真正的簡化。

Airbyte

Airbyte 走了與 Fivetran 相反的路。它沒有打造全託管的黑箱，而是建立了一個開源 ELT 平台，擁有龐大的社群驅動連接器目錄，讓團隊可免費自行架設，只需為自己的基礎架構付費，而非支付按列計費的供應商費用。

這種開放性對工程主導、想完全掌控自家管線且不願被單一供應商路線圖鎖定的組織極具吸引力——隨著競爭對手紛紛整併，這項考量變得更加關鍵。Airbyte 近期還加入了 AI 輔助的連接器建構器，以加快支援尚未收錄於現有目錄的來源。

其代價正是開源基礎架構的典型問題：連接器品質參差不齊，尤其是社群維護的整合，而要把它運作好，需要真正的 DevOps 投入——這本是全託管平台會吸收掉的工作。

Informatica (IDMC)

Informatica 近二十年來一直是真正複雜資料環境的企業級標準，其 Intelligent Data Management Cloud 仍涵蓋多數競爭對手根本不敢嘗試的完整範疇：整合、資料品質、治理與主資料管理集於單一平台，並由 CLAIRE AI 引擎負責跨平台的中繼資料探索。

更大的新聞在於結構而非技術：Salesforce 以 80 億美元收購 Informatica 的交易於 2025 年底完成，使其成為全資子公司，而非獨立的上市公司。

核心產品尚未改變，但每位買方現在必須問的長期問題是：Salesforce 會持續優先支援服務非 Salesforce 客戶的功能，還是逐步將路線圖傾向自家的 Data Cloud 與 Agentforce 野心。這條路線圖的演變，也將是整個資料堆疊向最大 AI 平台供應商集中的早期訊號。

MuleSoft

MuleSoft 位於這個類別中 API 主導的一側，而非資料倉儲擷取的一側。它是 Salesforce 的整合骨幹，服務龐大的 Salesforce 客戶群，這些客戶需要透過可重複使用、受治理的 API 連接數十個系統，而非一次性的點對點連線。

其 DataWeave 轉換語言負責實際的資料操作，而近期它特別加入了對 Model Context Protocol 的支援，將 MuleSoft 定位為代理式 AI 工作流程可直接呼叫的基礎架構，而非僅是面向人類的整合工具。

對已深入 Salesforce 生態系的組織而言，這樣的定位是自然的選擇——而隨著 Informatica 也納入 Salesforce 旗下，該公司實質上掌握了資料整合市場中兩個相鄰的層。對生態系之外的公司來說，MuleSoft 的企業級定價與導入時程則更難以合理化。

Databricks

Databricks 的整體架構建立在与傳統 ETL 供應商不同的前提上。它是一座湖倉，將資料工程、分析與機器學習統一在單一平台中，而非把「把資料準備好」與「在其上建構 AI」視為兩個需要中介整合層的獨立系統。

這一點對 AI 應用日益重要，因為模型訓練或推論管線往往需要同一份受治理的資料，同時用於分析與 AI 工作負載本身，而讓兩者在互不相連的平台間保持同步，是個反覆出現的難題。

採用它比採用單點 ELT 工具更費力，但對已在執行大型 ML 工作負載的組織而言，讓資料層與 AI 層共用相同的底層平台，可消除一整類的同步問題。

Snowflake

Snowflake 的核心賣點一直是真正具彈性、可獨立擴展的資料倉儲，而其 Cortex AI 層直接建構於同一份受治理的資料之上，AI 應用查詢前無需額外的匯出步驟。

這與 Databricks 統一架構重要的原因完全相同：資料在「倉儲」與「AI 系統」之間每多一跳，就是多一個讓資料過時、權限不符或純粹資料漂移趁虛而入的環節。

Snowflake 與 Databricks 在這個賣點上的競爭日益白熱化，而對多數買方而言，誠實的答案是：選擇更多取決於既有的雲端承諾與團隊技能組合，而非兩者之間任何決定性的功能差距。

Confluent

以 Apache Kafka 為基礎的 Confluent，與上述批次導向工具的節奏完全不同：即時串流，適用於 AI 系統真的無法等待夜間批次工作追上進度的情境，例如詐欺偵測或需要在數秒內（而非數小時）對事件做出反應的即時推薦引擎。

這條即時骨幹之所以更加重要，正是因為 AI 代理日益需要依據系統最新狀態行動，而非分析昨日的快照。

相較於託管式 ELT 工具，它是更重的營運承諾，對只需要夜間報表的公司而言確實是殺雞用牛刀，但若要餵給 AI 系統的是秒級新鮮而非一天舊的資料，實在沒有替代方案。

Matillion

Matillion 的利基建立在定居於某一座大型雲端資料倉儲（Snowflake、BigQuery 或 Redshift）內的團隊之上，提供比撰寫原始管線程式碼更視覺化的拖放式 ETL 與 ELT 體驗，同時仍將繁重的轉換工作推入倉儲自身的運算資源，而非中介引擎。

這種倉儲原生的設計，正是它與 Fivetran 或 Airbyte 等來源無關工具的核心差異：當組織已標準化於那三座倉儲之一，並想為疊加其上的轉換邏輯尋求更平易近人的介面時，Matillion 的優勢便顯現出來。

Estuary

Estuary 追求的架構賭注與本列表上的多數名字截然不同。它不將批次 ELT 與即時串流視為需要兩種工具的兩個獨立類別，而是打造單一平台，從同一系統處理變更資料擷取（CDC）與批次複製，目標是在無需為此運作完整 Kafka 部署的營運負擔下，達到次秒級的新鮮度。

對同時需要夜間倉儲載入與近乎即時更新的 AI 應用、又不想維護兩套完全獨立管線系統的公司而言，這種統一是明顯不同的價值主張，優於只挑選批次工具或串流工具、再承受另一者本可涵蓋的缺口。

綜觀全篇，貫穿這份名單的主軸是：資料基礎架構的選擇日益跟隨 AI 策略——無論公司整併於單一供應商的堆疊，還是組裝各層的最佳解，擷取、轉換、儲存與 AI 之間的介面，正是目前多數整併活動、也是多數買方風險所在之處。

本文 10 Enterprise Data Platforms Supporting AI And Analytics 最先刊登於 Metaverse Post。