數(shù)據(jù)工程ETL或ELT中的轉換與提取加載，會議、博客文章、企業(yè)路線圖甚至預算都側重于數(shù)據(jù)轉換T以及隨之而來的“業(yè)務洞察”的誘惑。對于提取和加載數(shù)據(jù)EL的步驟有時會被打折為編寫腳本和計劃一些 API 調用的微不足道的步驟。

然而，提取加載EL的優(yōu)雅不僅僅是結果，而是執(zhí)行 - 保證不會出錯的藝術。正如室內裝飾無法挽救在運輸過程中損壞的畫作，或者如果一半的用料缺貨，則無法準備精心計劃的菜單一樣。數(shù)據(jù)處理的提取加載EL步驟有無數(shù)的陷阱，可能會使數(shù)據(jù)團隊遠離他們雄心勃勃的議程和愿望?；A不牢地動山搖。

這篇文章是解釋提取加載的一些潛在復雜性的系列文章中的第一篇。了解這種復雜性說明了像Airbyte這樣的數(shù)據(jù)集成工具如何通過減少認知負擔，加快開發(fā)時間，降低未來錯誤和中斷的風險，并讓他們專注于組織特定的問題來減輕數(shù)據(jù)團隊的負擔。

這篇文章將從開頭開始：從上游源系統(tǒng)中提取數(shù)據(jù)。就像節(jié)儉地用每周優(yōu)惠裝滿您的購物車或小心翼翼地裝載移動的貨車以保護您的物品一樣，我們將探索全面而有效地提取數(shù)據(jù)所需的策略。

數(shù)據(jù)提取基礎知識
所有 EL 管道都從某個源系統(tǒng)提取數(shù)據(jù)開始。Airbyte 提供了一個方便的抽象層，用于從許多類型的系統(tǒng)中提取數(shù)據(jù)。為了集中討論，我們將重點關注REST API，因為它們是與上游供應商工具（例如Facebook Ads，Salesforce）集成時最常見的來源之一。

從 API 成功提取數(shù)據(jù)涉及制定精確的 API 查詢并大規(guī)模執(zhí)行該查詢。這些步驟中的每一個都可能帶來許多不同的挑戰(zhàn)，這些挑戰(zhàn)可能會使數(shù)據(jù)團隊花費寶貴的時間來編寫樣板代碼，或者危及結果的準確性和完整性。我們將逐一研究其中一些關鍵問題。

制定 API 查詢
盡管 REST API 無處不在，但每個 API 的結構都存在許多任意的唯一性。如果沒有適當?shù)淖⒁猓苋菀子龅藉e誤消息或檢索誤導性結果，這些結果正是您所要求的，但根本不是您想要的。

認證
API 保護身份驗證層后面的機密數(shù)據(jù)。API 開發(fā)人員可以啟用許多不同的身份驗證策略。其中包括基本身份驗證（未加密的憑據(jù)傳遞）、API 密鑰和現(xiàn)代 OAuth2 方法，這些方法通常需要在長時間運行的會話期間多次檢索臨時刷新令牌。

然后，身份驗證要求數(shù)據(jù)團隊編寫死記硬背的 API 特定代碼，對于 OAuth2，可能需要在檢索新刷新令牌和進行實際數(shù)據(jù)收集 API 調用之間進行迭代。如果沒有構建正確的健壯性和迭代層，此類超時可能會導致對 API 的長時間運行或順序調用出現(xiàn)意外故障。

憑據(jù)保護
無論使用哪種身份驗證模式，都需要將某種類型的憑據(jù)傳遞給 API。與個人密碼一樣，必須小心處理此類憑據(jù)。安全性可以采用各種不同的方法，例如將憑據(jù)存儲為環(huán)境變量與硬編碼。

但是，雖然大多數(shù)技術人員都知道不要以純文本形式保留密碼，但這并不是您在進行 API 調用時無意中危及網(wǎng)絡安全的唯一方法。更簡單的身份驗證方法可能會泄露您的憑據(jù)，除非您確定通過安全連接提交呼叫;其他時候，嚴格的日志記錄可能會意外地泄露憑據(jù)并引入泄漏，從而允許不良行為者訪問您的系統(tǒng)。

導航端點
數(shù)據(jù)團隊應該在了解他們打算從 API 檢索哪些數(shù)據(jù)以及要應用哪些查詢參數(shù)方面發(fā)揮積極作用。但是，他們可能經(jīng)常面臨大量選項和共享連接器，允許“人群的智慧”突出顯示最常見的端點和感興趣的參數(shù)。

盡管“我們甚至無法定義客戶”是數(shù)據(jù)中的陳詞濫調，但在收集可能使用不同命名法的外部數(shù)據(jù)時，組織內存在的相同類型的歧義會被放大。使用常用工具有助于突出顯示最重要的信息，并有助于捕獲數(shù)據(jù)團隊可能無法預料的極端情況。例如，您是否知道 GitHub API 將拉取請求視為一種問題？

結構化查詢和有效負載
因此，一旦您證明您有權訪問信息（身份驗證）并確定您希望訪問哪些信息（端點），您如何有效地要求 API 檢索它？

即使是像查詢 API 這樣司空見慣的任務也可能包含任意唯一性，并引入數(shù)據(jù)團隊檢索錯誤結果的風險。例如，將多個可能的值傳遞給單個查詢參數(shù)可能不是簡單的，并且特定于 API。一些 API 更喜歡像 ？key=value1&key=value2 這樣的格式，而另一些 API 則期望 ？key=value1，value2。

使用意外格式可能會導致 API 錯誤，或者更糟糕的是，當查詢被誤解時，會導致靜默失敗。對于那些來自SQL類型語言的人來說，其中一些結構可能不直觀;例如，盡管上面顯示的第一個選項中有 & 符號，但兩種語法都在結果中請求“要么或”而不是“兩者和”值。

大規(guī)模查詢 API
因此，您有一個有效的 API 查詢！這很好，但進行一次成功的調用與大規(guī)模查詢 API 以定期提取大量數(shù)據(jù)大不相同。除了 API 查詢中的業(yè)務邏輯之外，分析工程師可能會發(fā)現(xiàn)自己需要調整其代碼以應對以下挑戰(zhàn)：

分頁
通常，API 查詢的結果可能是大量記錄。為了更有效地傳輸此數(shù)據(jù)，API 使用分頁來返回結果的離散子集。從本質上講，分頁是將查詢返回的一組記錄分解為不同的塊，并且每個 API 請求只返回一個的過程——類似于 Google 搜索將結果分解到多個頁面上的方式。例如，如果您的查詢有 120 條相關記錄，則您的第一次 API 調用可能會返回前 50 條記錄。要獲得下一個 50（在第二個“頁面”上），需要另一個 API 調用。

雖然這使得檢索查詢結果更有效，但數(shù)據(jù)工程師通常必須編寫樣板代碼來確定是否存在更多記錄并重復檢索下一組。否則，數(shù)據(jù)團隊可能會面臨提取不完整記錄的風險。

重試
即使是正確的 API 查詢也可能由于系統(tǒng)中斷和網(wǎng)絡問題等臨時問題而失敗。進行 API 查詢后，需要檢查返回的狀態(tài)碼，確認命中是否成功。如果不是，系統(tǒng)需要決定如何處理此錯誤以及是否再次嘗試調用。

重試和分頁的交集會產生進一步的數(shù)據(jù)收集丟失風險。例如，如果您以迭代方式調用 API 來檢索結果的下一個“頁面”，只要存在下一頁，即使“第 4 頁”失敗，樸素的 for 循環(huán)也可能會繼續(xù)查詢“第 3 頁”。

速率限制
重試和分頁都會造成需要多次調用 API 才能成功提取的情況。但是，為了防止暴力帳戶接管和拒絕服務攻擊，API 通常具有速率限制，該限制決定了給定時間段內允許的最大查詢數(shù)。彈性提取過程應認真遵守速率限制，并實施重試回退等方法。

總結
正如這篇文章所說明的，數(shù)據(jù)收集可能需要大量的專業(yè)知識——既包括一般查詢數(shù)據(jù)，也包括每個 API 的具體細微差別。獲取和部署這些知識可能會占用數(shù)據(jù)團隊的大量帶寬。數(shù)據(jù)團隊可以“租用”像Airbyte這樣的提取工具，而不是讓團隊成員重新發(fā)明輪子。Airbyte 的源連接器封裝了工程最佳實踐和特定領域的知識，以幫助應對上述風險。在單個連接器（例如亞馬遜廣告）的文檔上，您會發(fā)現(xiàn)對上述許多問題的詳細討論，例如如何提供連接器將適當傳遞給 API 的憑據(jù)，以及哪些終端節(jié)點包含跨行業(yè)最普遍有用的信息。

即使 Airbyte 還沒有適用于您的用例的現(xiàn)有連接器，它也為數(shù)據(jù)團隊提供了有用的樣板框架，以創(chuàng)建應用其中一些相同最佳實踐的新連接器。例如，可以輕松配置不同的分頁策略，而無需使用樣板代碼重新發(fā)明輪子。

僅僅因為您可以自己打包一輛搬家的貨車，沒有人會拒絕朋友或搬家公司的幫助，以使手頭的工作更安全、更快、更愉快。通過在上述無數(shù)決策、痛點和陷阱上提供統(tǒng)一的抽象層，像 Airbyte 這樣的優(yōu)秀 EL 工具可以為您的數(shù)據(jù)團隊帶來相同的價值。
?