Airbyte 與 Meltano：資料整合平台什麼時候值得裝，什麼時候該自己寫

我參加過一次很失敗的團購。主揪很認真，找了一個號稱「什麼都有」的批發平台，結果我們這群人想買的東西有一半那個平台沒有，剩下一半有但要另外談。最後主揪自己跑了四家店，平台的帳號從頭到尾只用來看價格。

評估資料整合平台的時候我一直想起那次團購。要從很多外部來源持續抓資料進自己的儲存，先問的問題是「用現成平台還是自己寫」。開源世界裡兩個最常被推薦的答案是 Airbyte 和 Meltano。我認真評估過，一個都沒裝。這篇講它們各是什麼、什麼情況下值得，以及它們留給我的東西。

Airbyte：有介面的 ELT 平台

Airbyte 是一組常駐服務：網頁介面、排程器、worker，每個來源和目的地各自跑在獨立的連接器容器裡。核心程式的授權是 ELv2，內部自用允許；連接器本身多數是 MIT。它的強項是目錄：幾百個 SaaS、資料庫、檔案系統的來源，裝好就能設定同步，在網頁上點一點，資料就開始流。對於一個要把公司內十幾個 SaaS 的資料集中起來的團隊，這是天堂。

弱項是部署，它本質上要 Docker 或 Kubernetes；Windows 上等於要 Docker Desktop，也就是要啟用 Hyper-V。而且它是「一組服務」，不是「一支程式」，你等於在自己的機器上養了一個小型的資料部門。

Meltano：Python 命令列

Meltano 是 MIT 授權的命令列工具，圍繞 Singer 規格：來源叫 tap，目的地叫 target，中間是標準化的 JSON 串流。tap 負責把資料從某個地方吐出來，target 負責把資料塞進某個地方，兩邊互不認識，靠中間的格式溝通。它能原生跑在 Python 裡，不需要容器，專案結構是一個 YAML 加幾個外掛，比 Airbyte 輕很多。

弱項同樣在目錄：Singer taps 的品質參差，有些很棒、有些三年沒更新，冷門來源多半沒有，或者有但你點進去發現最後一次提交是某個已經畢業的人的畢業專題。

覆蓋率決定一切

我的來源清單有一百多組，大多是各機構自己的 REST API、幾條 WebSocket 串流、幾個 SSE 端點，還有統計機構常用的 SDMX。這些在兩邊的目錄裡幾乎找不到現成的連接器。

也就是說，裝了平台之後，我還是得替絕大多數來源自己寫連接器，只是改用它們的規格寫，並且多養一組服務。這個算式很快就算完了，就像那次團購：平台有的我不需要，我需要的平台沒有，最後還是要自己跑店。

反過來說，如果你的來源是常見的 SaaS 和資料庫，這兩個工具替你省下的是整批連接器的維護，那是很大的一筆，該用就用。不要因為看了這篇就覺得自己寫比較酷，自己寫從來都不酷，只是有時候沒得選。

它們留給我的十個問題

否決一個工具，不表示它的經驗沒有價值。Airbyte 和 Meltano 之所以存在，是因為自己寫連接器的人會一再撞到同一批問題：逾時、速率限制、權杖過期、來源改了 schema、重試、檢查點、增量抓取、去重、排程、監控。

我第一次看到這張清單的時候有點心虛，因為其中大概有六項是我「打算之後再處理」的。所謂之後再處理，翻譯過來就是「等它出事」。所以我把這十項抄下來，當成自己框架的驗收清單，每一個來源模組上線前都要說清楚這十件事各自怎麼處理。有些答案是「這個來源不需要」，那也是答案，重點是有想過。

自寫框架的中心是一張登錄表，每個來源一條：即時性分類、抓取方式、認證設定、輪詢策略、資料集清單，還有狀態。狀態只有五種：規劃中、開發中、上線、暫停、退役。五種就夠，多了你會開始發明「半上線」這種東西，然後沒有人知道它是什麼意思。

小劇場：自己寫不會很累嗎

「一百多個來源你自己寫？不會寫到懷疑人生嗎？」

「會，大概在第三十個的時候。」

「那你怎麼撐過去的？」

「因為前面二十九個讓框架長出了形狀。第三十個之後每一個都只是填表格，逾時多少、限速多少、怎麼分頁。」

「所以難的是前面。」

「難的是前面，而且前面那段沒有任何工具能幫你，因為那是在弄清楚你自己的資料長什麼樣子。」

「這句話聽起來像某種人生道理。」

「資料工程裡的每句話最後都會變成人生道理，這是職業傷害。」

同一輪只借概念的幾個

Dagster 和 dbt 我沒裝，借了 dbt 的 SQL 模型目錄結構和資料倉儲的分層概念，用 DuckDB 加 Parquet 做本機版。有些參考專案用 Streamlit 做介面，我沒有用它們的介面，只移植了裡面的異常偵測公式。幾個雲端服務一律不用，向量化交給本機的 Ollama。

「借概念不裝工具」是我這幾年很常做的事。工具會過時、會有相依、會要你更新；概念不會。讀懂一個工具為什麼這樣設計，比裝它更有價值，雖然裝它比較有成就感。

我的判斷標準

現成平台的價值跟「你的來源有多少落在它的目錄裡」成正比。落在目錄裡的多，用平台，別逞強；落在目錄外的多，平台留給你的只有它的規格和部署方式，那不如自己寫，並且誠實地承認你在重做他們做過的十件事。

那次團購後來怎麼了？主揪跑了四家店之後，自己整理了一份「哪家店有什麼」的表格，下次團購直接用那張表。她說那張表比任何平台都好用，因為那是她自己的需求長出來的。我想她大概不知道，她做的事情有一個名字叫「登錄表」。

兩個工具的來歷

Meltano 一開始是 GitLab 內部的專案，2018 年開始，2021 年獨立出來變成一間公司。它建立在 Singer 規格上，那是 2017 年一間叫 Stitch 的公司提出的開放標準，定義了「來源怎麼吐資料、目的地怎麼收資料」的 JSON 格式，讓任何人寫的 tap 都能接任何人寫的 target。這個想法很美，實踐上的問題是「任何人寫的」這幾個字，品質沒有人管。

Airbyte 是 2020 年成立的，晚很多，但它從一開始就走「平台」路線：有介面、有排程、有連接器市集，你不用寫 YAML，點一點就好。它的成長很快，連接器目錄幾年內就到幾百個。授權上核心用 ELv2，這個授權允許你自用、修改、甚至商用，但不能拿它去做一個跟它競爭的託管服務。這種「開源但防雲端業者」的授權這幾年越來越多，是另一個話題。

兩個都在講一個叫 ELT 的東西：先把資料原樣搬過來（Extract、Load），再在目的地轉換（Transform）。跟舊的 ETL 相反，ETL 是搬之前先轉。ELT 的邏輯是儲存便宜了、目的地的運算能力強了，先搬再說，轉換可以之後慢慢做。我的自寫框架也是這個思路：原始回應先存檔，正規化之後再進資料庫。

常見的三個誤會

第一個誤會是「連接器目錄有就代表能用」。目錄上有，不代表它支援你需要的那個 API 版本、那個認證方式、那個分頁模式。點進去看最後更新時間和 issue 列表，比看目錄有沒有重要。

第二個誤會是「平台會幫你處理 schema 變更」。它會偵測到變了，然後停下來問你要怎麼辦。決定還是你的。這件事在你有一百個來源的時候會變成每天早上的例行公事，跟自己寫的框架沒有太大差別。

第三個誤會是「自己寫一定比較差」。自己寫的框架只做你需要的事，沒有你不需要的複雜度。它在通用性上一定輸，但你不需要通用性，你需要的是那一百個來源能穩定地進來。工具的價值要用你的需求量，不是用它的功能清單量。

一個週末可以試的小練習

列出你最想抓的五個資料來源，什麼都行，天氣、匯率、某個政府的開放資料、某個你常看的網站的 RSS。然後去 Airbyte 的連接器目錄和 Singer 的 tap 清單各查一次，記下有幾個有現成的、幾個有但很久沒更新、幾個沒有。

如果五個裡有四個有現成的而且還在維護，你應該用平台，不要看了這篇就自己寫。如果五個裡有四個沒有，你剛剛做的就是我當初做的評估，只是我的清單長一點。這個練習的重點不是結論，是你會在查的過程中學到「連接器目錄」到底長什麼樣、「還在維護」是什麼意思，那些東西在你真的要決定的時候會很有用。

後記

那位主揪後來又辦了幾次團購，每次都更順。她的表格從「哪家店有什麼」長成了「哪家店有什麼、多久到貨、誰負責催、上次出過什麼問題」。我看著那張表想，這不就是一個完整的資料管線登錄表嗎，只是她用 Google 試算表做的。工具不重要，把問題想清楚並寫下來才重要。我猜她永遠不會讀這篇文章，但如果她讀了，我想跟她說：你的表格很專業。

官方網站：airbyte.com、meltano.com