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

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

這篇文章是解釋提取加載的一些潛在復(fù)雜性的系列文章中的第一篇。了解這種復(fù)雜性說(shuō)明了像Airbyte這樣的數(shù)據(jù)集成工具如何通過(guò)減少認(rèn)知負(fù)擔(dān)，加快開(kāi)發(fā)時(shí)間，降低未來(lái)錯(cuò)誤和中斷的風(fēng)險(xiǎn)，并讓他們專注于組織特定的問(wèn)題來(lái)減輕數(shù)據(jù)團(tuán)隊(duì)的負(fù)擔(dān)。

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

數(shù)據(jù)提取基礎(chǔ)知識(shí)

所有 EL 管道都從某個(gè)源系統(tǒng)提取數(shù)據(jù)開(kāi)始。Airbyte 提供了一個(gè)方便的抽象層，用于從許多類型的系統(tǒng)中提取數(shù)據(jù)。為了集中討論，我們將重點(diǎn)關(guān)注REST API，因?yàn)樗鼈兪桥c上游供應(yīng)商工具（例如Facebook Ads，Salesforce）集成時(shí)最常見(jiàn)的來(lái)源之一。

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

制定 API 查詢

盡管 REST API 無(wú)處不在，但每個(gè) API 的結(jié)構(gòu)都存在許多任意的唯一性。如果沒(méi)有適當(dāng)?shù)淖⒁?，很容易遇到錯(cuò)誤消息或檢索誤導(dǎo)性結(jié)果，這些結(jié)果正是您所要求的，但根本不是您想要的。

認(rèn)證

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

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

憑據(jù)保護(hù)

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

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

導(dǎo)航端點(diǎn)

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

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

結(jié)構(gòu)化查詢和有效負(fù)載

因此，一旦您證明您有權(quán)訪問(wèn)信息（身份驗(yàn)證）并確定您希望訪問(wèn)哪些信息（端點(diǎn)），您如何有效地要求 API 檢索它？

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

使用意外格式可能會(huì)導(dǎo)致 API 錯(cuò)誤，或者更糟糕的是，當(dāng)查詢被誤解時(shí)，會(huì)導(dǎo)致靜默失敗。對(duì)于那些來(lái)自SQL類型語(yǔ)言的人來(lái)說(shuō)，其中一些結(jié)構(gòu)可能不直觀;例如，盡管上面顯示的第一個(gè)選項(xiàng)中有 & 符號(hào)，但兩種語(yǔ)法都在結(jié)果中請(qǐng)求“要么或”而不是“兩者和”值。

大規(guī)模查詢 API

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

分頁(yè)

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

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

重試

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

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

速率限制

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

總結(jié)

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

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

僅僅因?yàn)槟梢宰约捍虬惠v搬家的貨車(chē)，沒(méi)有人會(huì)拒絕朋友或搬家公司的幫助，以使手頭的工作更安全、更快、更愉快。通過(guò)在上述無(wú)數(shù)決策、痛點(diǎn)和陷阱上提供統(tǒng)一的抽象層，像 Airbyte 這樣的優(yōu)秀 EL 工具可以為您的數(shù)據(jù)團(tuán)隊(duì)帶來(lái)相同的價(jià)值。