回顧了兩個開箱即用的工具，以解決傳統(tǒng)上乏味的問題

　　> Photo by Heye Jensen on Unsplash

　　詢問過去10到15年中從事數(shù)據(jù)相關(guān)工作的任何人，他們寧愿避免哪些最無聊的任務(wù)，而且有很多人會回答"數(shù)據(jù)提取"。

　　每個人都希望準備好數(shù)據(jù)進行分析。當然，數(shù)據(jù)清理和預(yù)處理也是要避免的另一種不錯的選擇，但是純粹花費在復(fù)制數(shù)據(jù)上的時間卻并沒有給它帶來任何價值，這讓人感到非常討厭。從某種意義上說，至少數(shù)據(jù)清理可以達到"整理房屋"的目的。

　　然而，數(shù)據(jù)提取是一項基本任務(wù)，直到一段時間之前，您還必須結(jié)合使用API調(diào)用，CSV獲取請求，Web掛鉤，增量加載規(guī)則，流服務(wù)和ODBC連接，才能將外部數(shù)據(jù)復(fù)制到您的數(shù)據(jù)倉庫或本地系統(tǒng)。

　　在過去的幾年中，我自己面對了許多挑戰(zhàn)，這就是為什么當我在上一個項目中有機會詳細探討數(shù)據(jù)提取工具如何改變了這一領(lǐng)域時，我感到特別興奮。

　　我將在這里回顧兩種數(shù)據(jù)提取工具：

　　· Fivetran

　　· 針跡數(shù)據(jù)

　　什么時候適合使用數(shù)據(jù)提取工具？

　　在以下情況下，使用數(shù)據(jù)提取工具的理想情況是：

　　· 您有一個數(shù)據(jù)倉庫，并想用新的數(shù)據(jù)源豐富它

　　· 您不需要實時同步

　　· 您的資源位于相對較大的一組標準預(yù)定義數(shù)據(jù)庫或SaaS工具中（此處和此處列出）

　　· 您的源數(shù)據(jù)已經(jīng)以關(guān)系格式或簡單的JSON結(jié)構(gòu)進行了結(jié)構(gòu)化

　　· 您的數(shù)據(jù)管道需求符合ELT方法（提取-加載-轉(zhuǎn)換），而不是ETL

　　ELT要求在這里至關(guān)重要。我認為，盡管ELT與ETL通常取決于個人喜好，但在某些情況下，最好在攝取之前對數(shù)據(jù)進行轉(zhuǎn)換，例如，如果攝取之前需要進行大量數(shù)據(jù)清理，轉(zhuǎn)換或過濾，以避免不必要的情況數(shù)據(jù)已經(jīng)加載到數(shù)據(jù)庫中之后的復(fù)雜處理。

　　什么時候這種方法不合適？

　　盡管上述用例涵蓋了廣泛的用例，但上述幾點除外，它們將不涵蓋以下情況：

　　· 您需要進行實時復(fù)制

　　· 您具有非結(jié)構(gòu)化或高度嵌套的JSON源數(shù)據(jù)

　　· 您擁有不受支持的技術(shù)作為數(shù)據(jù)源系統(tǒng)或數(shù)據(jù)倉庫

　　· 您想要在攝取之前轉(zhuǎn)換源數(shù)據(jù)

　　> Photo by Roman Kraft on Unsplash

　　現(xiàn)在，我們在多個關(guān)鍵維度上比較這兩種工具。

　　復(fù)制方式

　　使用數(shù)據(jù)提取工具的明顯優(yōu)勢是它將為您處理增量上傳。如果您有足夠小的數(shù)據(jù)源可以每天完整復(fù)制，那么您不必太擔心這一點。

　　一般而言，F(xiàn)ivetran和Stitch Data都執(zhí)行基于日志的復(fù)制，即它們訪問源系統(tǒng)的更改日志以消耗數(shù)據(jù)中的增量更改，并將其復(fù)制到下游。這是在后臺進行的事情，因此，除了確保源系統(tǒng)已啟用更改日志之外，您不必擔心。

　　要考慮的另一點是您的數(shù)據(jù)是否具有主鍵。您顯然想要一個主鍵，因為這是工具識別現(xiàn)有記錄已被更新的唯一方法。如果不是這樣，他們可能會在每次修改記錄時插入一個新的記錄副本，這顯然是不希望的行為。

　　Fivetran在這里稍微復(fù)雜一點，即使源表中沒有，它也可以生成綜合主鍵。

　　另一方面，當源中不存在主鍵時，針跡數(shù)據(jù)將采用僅追加復(fù)制方法，如其文檔中所述。

　　根據(jù)我的經(jīng)驗，在大多數(shù)實際情況下，您將處理具有主鍵的源（并且，如果您對源數(shù)據(jù)庫有控制權(quán)，則需要確保源表具有一個主鍵）。

　　但是，在某些情況下并非如此，我遇到的一個著名示例是Stitch Data Mixpanel集成，該集成缺少主鍵。在這種情況下，有時可以多次插入同一條記錄，這意味著您必須在目標位置對其進行重復(fù)數(shù)據(jù)刪除，例如，通過對某些字段（例如event_type，user_distinct_id，page_url和timestamp）進行唯一組合。

　　這遠非理想，但只要小心處理查詢以使用數(shù)據(jù)，就不會造成太多麻煩。

　　處理JSON數(shù)據(jù)源

　　JSON數(shù)據(jù)源通常很難處理，但是多少痛苦取決于實際數(shù)據(jù)模型和使用的工具。

　　如果您具有NoSql數(shù)據(jù)源（例如MongoDB），通常會發(fā)現(xiàn)這種情況，但如果您的關(guān)系數(shù)據(jù)源帶有一些JSON字段（例如在Postgres數(shù)據(jù)庫中），則也可以應(yīng)用此方案。

　　這里最關(guān)鍵的情況是，如果您有真正非結(jié)構(gòu)化的源表（即集合），即它們每個都包含大量不同的字段。例如，如果每個對象代表一本書，并且其字段代表章節(jié)名稱，則可能是這種情況。每本書的章節(jié)名稱可能會有所不同。像這樣的情況與JSON到關(guān)系的映射不太匹配，并且通過Fivetran和Stitch Data，您會發(fā)現(xiàn)目標表具有與源集合中唯一字段一樣多的列。這不僅不切實際，而且還會引發(fā)超出某個閾值的錯誤，例如Postgres每張表的限制為1600列。

　　相反，如果每個集合中的唯一字段數(shù)量有限（例如，最多最多幾百個），則行為將根據(jù)工具而改變：

　　· 只要目標數(shù)據(jù)庫處理字典類型的瘦身結(jié)構(gòu)，F(xiàn)ivetran就會將源處的每個JSON字段映射到目標處的JSON字段

　　· 針跡數(shù)據(jù)將執(zhí)行相同的操作，但僅適用于有限的一組目的地，例如Snowflake，但不適用于Postgres。這很煩人，因為Postgres本機處理JSON字段。有關(guān)此問題的更多詳細信息在此處進行了說明，您還需要記住，這也會影響您的行數(shù)以進行定價（稍后會詳細介紹）。

　　總而言之，如果您擁有真正非結(jié)構(gòu)化的源數(shù)據(jù)，則該工具沒有任何魔力，但是，如果您確實具有某種結(jié)構(gòu)，則在某些條件下，這些工具將允許在目標數(shù)據(jù)庫中保留類似字典的格式。

　　表格和字段選擇

　　Fivetran和Stitch Data都只允許從源模式中導(dǎo)入某些表，但是Stitch Data在此還具有能夠選擇性地僅導(dǎo)入選定字段的優(yōu)點，如果您的表中包含很多字段，這可能是一個有用的優(yōu)點，并且尤其是在其中某些字段包含嵌套JSON并使目標結(jié)構(gòu)復(fù)雜化的情況下。

　　行數(shù)和計費方式

　　在這一點上，F(xiàn)ivetran和Stitch Data具有兩種不同的方法：

　　· 每月唯一行的Fivetran費用已更新

　　· 每月總行上的針跡數(shù)據(jù)已更新（即同一行可以被多次計數(shù)）

　　這有什么關(guān)系？如果您的源流主要是附加的新記錄序列，則不會有太大的區(qū)別，但是如果您的源系統(tǒng)傾向于頻繁地反復(fù)更新相同的記錄，那么Fivetran可以在這里提供更清晰和可預(yù)測的定價優(yōu)勢。

　　這里要特別注意的另一點是有關(guān)歷史回填和表模式更改的信息。例如，如果您有一個大表，并向其中添加了另一列并填充了所有歷史記錄，則即使您可能并不真正對該附加字段感興趣，兩個系統(tǒng)都將發(fā)現(xiàn)這些更改并更新完整記錄的歷史記錄。這可能會對這兩種工具產(chǎn)生很高的意外費用。

　　價錢

　　根據(jù)上述收費方法，不可能像這兩個工具一樣進行比較，但是，在常見的情況下，絕大多數(shù)源更改實際上是新插入的，Stitch Data證明比Fivetran便宜得多。

　　例如，截至今天：

　　· Stitch Data的定價計劃從每月100美元起，每月更新500萬條修改行，并按月承諾，并提供10個集成源。下一個級別是1000萬行的$ 180。

　　· Fivetran的定價比較模糊，您需要稍微瀏覽一下他們的文檔頁面才能正確理解它。總之，對于每月更新的100萬個唯一行，它的起價實際上為每月1000-1500美元，但隨著使用量的增加，它會逐漸增加。

　　復(fù)制頻率

　　您可以設(shè)置的復(fù)制頻率將取決于所使用的工具和源系統(tǒng)。Fivetran的下限為5分鐘，大多數(shù)來源的Stitch Data的下限為30分鐘，但是某些來源的Stitch Data的下限較低，但是通常需要注意不要在兩次后續(xù)運行之間重疊。

　　您的復(fù)制頻率也會影響修改的行數(shù)，尤其會影響針跡數(shù)據(jù)的定價。

　　轉(zhuǎn)型能力

　　請記住，我們談?wù)摰氖菙z取，而不是數(shù)據(jù)轉(zhuǎn)換，因此這兩個工具都不關(guān)注數(shù)據(jù)轉(zhuǎn)換功能也就不足為奇了。

　　但是，F(xiàn)ivetran還提供了與dbt（數(shù)據(jù)構(gòu)建工具）的集成，并且Stitch Data是Talend系列的一部分，Talend系列在ETL領(lǐng)域傳統(tǒng)上是一個重要角色。

　　但是，使用其姐妹數(shù)據(jù)轉(zhuǎn)換工具沒有明顯的優(yōu)勢，因此可以將部分與攝取真正分離。

　　結(jié)果

　　Fivetran和Stitch Data都是用于數(shù)據(jù)提取的出色工具。哪一項適合該法案將取決于實際用例和需求。

　　Fivetran在某種程度上具有更復(fù)雜的復(fù)制功能，但這也帶來了成本增加。

　　Stitch Data是一個出色的入門級工具，它還可以針對許多標準方案進行大規(guī)模復(fù)制。

　　Fivetran的定價在開始時就非常昂貴，但如果您的攝取量很高（例如，每月數(shù)十億個唯一行），它可能會變得更合理，并且由于其獨特的行定價模型，它還可以提供更多的可預(yù)測性。