數(shù)據(jù)科學(xué)家和數(shù)據(jù)分析師經(jīng)常需要回答業(yè)務(wù)問題。這可能會導(dǎo)致更臨時的分析或某種形式的模型將被應(yīng)用到公司的工作流程中。

但是要執(zhí)行數(shù)據(jù)科學(xué)和分析，團隊首先需要訪問來自多個應(yīng)用程序和業(yè)務(wù)流程的高質(zhì)量數(shù)據(jù)。這意味著將數(shù)據(jù)從點a移動到點b。執(zhí)行此操作的一般方法是使用自動化過程，簡稱為提取，轉(zhuǎn)換和加載或ETL。這些ETL通常會將數(shù)據(jù)加載到某種形式的數(shù)據(jù)倉庫中，以便于訪問。但是，ETL和數(shù)據(jù)倉庫存在一個主要問題。

[[356468]]

盡管有必要，但ETL需要大量的編碼，專門知識和維護。除了這項工作對于數(shù)據(jù)科學(xué)家來說是耗時的之外，并不是所有的數(shù)據(jù)科學(xué)家都具有開發(fā)ETL的經(jīng)驗。很多時候，這項工作將落在數(shù)據(jù)工程團隊上，這些團隊忙于更大的圖片項目以引入基礎(chǔ)數(shù)據(jù)層。

這并不總是與數(shù)據(jù)科學(xué)家的需求保持一致，數(shù)據(jù)科學(xué)家的需求可能會讓擁有業(yè)務(wù)所有者的企業(yè)希望快速地進行信息和分析。等到數(shù)據(jù)工程團隊有時間提取新的數(shù)據(jù)源可能不是一個好選擇。

這就是為什么在過去的幾年中開發(fā)了幾種解決方案來減少數(shù)據(jù)科學(xué)家為獲取所需數(shù)據(jù)而需要進行的工作量的原因。尤其是以數(shù)據(jù)虛擬化，自動ETL和無代碼/低代碼解決方案的形式。

自動化的ETL和數(shù)據(jù)倉庫

盡管ETL本身是一個自動化過程。他們需要大量的手動開發(fā)和維護。

這導(dǎo)致了Panoply之類的工具的普及，該工具提供了易于集成的自動ETL和云數(shù)據(jù)倉庫，可以與許多第三方工具(如Salesforce，Google Analytics和數(shù)據(jù)庫)同步。使用這些自動集成，數(shù)據(jù)科學(xué)家可以快速分析數(shù)據(jù)，而無需部署復(fù)雜的基礎(chǔ)架構(gòu)。

無需Python或EC2實例。只需單擊幾下。然后，在大致了解您打算引入團隊中的數(shù)據(jù)類型之后，便可以擁有一個填充的數(shù)據(jù)倉庫。

這些自動化的ETL系統(tǒng)非常易于使用，通常只需要最終用戶設(shè)置數(shù)據(jù)源和目標即可。從那里可以將ETL設(shè)置為在特定時間運行。全部沒有任何代碼。

產(chǎn)品實例：

> Image provided by the author.

如前所述，Panoply是自動ETL和數(shù)據(jù)倉庫的一個示例。

可以在Panoply GUI中設(shè)置整個攝取，您可以在其中選擇源和目的地并自動攝取數(shù)據(jù)。因為Panoply帶有內(nèi)置的數(shù)據(jù)倉庫，所以它會自動存儲數(shù)據(jù)的副本，可以使用任何所需的BI或分析工具來查詢數(shù)據(jù)的副本，而不必擔心會危害操作或生產(chǎn)。以這種方式訪問數(shù)據(jù)基礎(chǔ)結(jié)構(gòu)對于希望使事情簡單但仍可以訪問整個組織中幾乎實時數(shù)據(jù)的用戶來說是有意義的。

反過來，這使數(shù)據(jù)科學(xué)家能夠回答臨時問題，而無需等待BI團隊將其帶入數(shù)據(jù)倉庫的四個星期。

優(yōu)點：

• 易于學(xué)習(xí)和實施
• 專注于云
• 易于擴展

缺點：

• 自動化的數(shù)據(jù)倉庫和ETL本身無法管理復(fù)雜的邏輯
• 更復(fù)雜的轉(zhuǎn)換可能需要添加無代碼/低代碼ETL工具

無代碼/低代碼

無代碼/低代碼距離自動ETL幾步之遙。這些類型的ETL工具具有更多的拖放方法。這意味著可以拖放一些設(shè)置轉(zhuǎn)換和數(shù)據(jù)操作功能。其他類似的解決方案可能更多是基于GUI的，它允許用戶指定源，目的地和轉(zhuǎn)換。此外，這些無代碼/低代碼解決方案中的許多解決方案都允許最終用戶查看是否需要編碼并對其進行編輯。

對于沒有代碼經(jīng)驗的用戶，這是一個很好的解決方案。無代碼/低代碼數(shù)據(jù)，科學(xué)家就可以開發(fā)語法有限的ETL，從而創(chuàng)建一些相當復(fù)雜的數(shù)據(jù)管道。無需建立大量復(fù)雜的基礎(chǔ)架構(gòu)來管理數(shù)據(jù)管道何時運行以及它們所依賴的內(nèi)容。用戶只需要從高層次上了解他們的數(shù)據(jù)在哪里，他們想去哪里以及什么時候要去那里。

缺點：

• 代碼中的可定制性有限
• 每個工具都不相同，因此開發(fā)人員必須在下一份工作中重新學(xué)習(xí)ETL
• 無代碼/低代碼可能太容易了，并導(dǎo)致糟糕的高級設(shè)計

優(yōu)點：

• 技術(shù)上沒有編碼經(jīng)驗
• 易于集成到許多受歡迎的第三方
• 許多是基于云的解決方案

產(chǎn)品實例：

> Image source: aws.amazon.com

此類別中有很多產(chǎn)品。有類似AWS Glue，Stitch和FiveTran的產(chǎn)品。

AWS Glue是基于云的現(xiàn)代ETL解決方案的一個很好的例子。這使開發(fā)人員只需單擊幾下即可設(shè)置作業(yè)，并設(shè)置參數(shù)。這可以使數(shù)據(jù)科學(xué)家無需太多代碼即可移動和轉(zhuǎn)換數(shù)據(jù)。

作為AWS一部分的Glue可以輕松地與其他服務(wù)集成，例如S3，RDS和Redshift。這使得在AWS上開發(fā)數(shù)據(jù)管道變得非常容易和直觀。但是，AWS Glue有一個主要警告。與許多其他無代碼/低代碼選項不同，它是為在AWS上運行而開發(fā)的。這意味著，如果您突然決定切換到其他云提供商，則可能僅從Glue切換到其他解決方案就不得不花費大量時間和金錢。

最后，這是您的團隊在開發(fā)ETL之前應(yīng)考慮的重要考慮因素。

數(shù)據(jù)虛擬化

數(shù)據(jù)虛擬化是一種允許用戶訪問來自多個數(shù)據(jù)源，數(shù)據(jù)結(jié)構(gòu)和第三方提供程序的數(shù)據(jù)的方法。它實質(zhì)上創(chuàng)建了一個單層，無論使用哪種技術(shù)存儲底層數(shù)據(jù)，最終用戶都將可以通過單點訪問它。

總體而言，當您的團隊需要快速訪問數(shù)據(jù)時，數(shù)據(jù)虛擬化具有許多優(yōu)勢。以下是一些數(shù)據(jù)虛擬化如何使您的團隊受益的示例。

優(yōu)點：

• 允許數(shù)據(jù)科學(xué)家混合來自多個數(shù)據(jù)庫的數(shù)據(jù)
• 管理安全性和訪問管理
• 實時或近實時數(shù)據(jù)

缺點：

• 高學(xué)習(xí)曲線
• 需要管理員來管理
• 仍然需要用戶考慮設(shè)計和數(shù)據(jù)流

產(chǎn)品實例：

> Image provided by the author.

Denodo是最著名的數(shù)據(jù)虛擬化提供商之一。總體而言，該產(chǎn)品可以說是最成熟，功能最豐富的產(chǎn)品。

Denodo致力于幫助用戶從本質(zhì)上通過一項服務(wù)訪問其數(shù)據(jù)，這使得它受到眾多客戶的歡迎。從醫(yī)療保健提供者到金融行業(yè)，都依賴Denodo來減輕BI開發(fā)人員和數(shù)據(jù)科學(xué)家的壓力，因為它減少了創(chuàng)建盡可能多的數(shù)據(jù)倉庫的必要性。

總體而言，這三個選項可以幫助您的團隊分析數(shù)據(jù)，而無需花費很多精力來開發(fā)復(fù)雜的ETL。

結(jié)論

對于數(shù)據(jù)科學(xué)家和機器學(xué)習(xí)工程師而言，管理，混合和移動數(shù)據(jù)將繼續(xù)是一項必不可少的任務(wù)。但是，開發(fā)這些管道及其相應(yīng)的數(shù)據(jù)倉庫的過程無需像過去那樣花費很長時間。

通過自動集成系統(tǒng)或通過其他方法(例如無代碼/低代碼和數(shù)據(jù)虛擬化)來開發(fā)ETL，有很多不錯的選擇。如果您的團隊希望減少數(shù)據(jù)工程師的工作量，則有很多選擇。您的團隊可能還需要組建一支新的數(shù)據(jù)科學(xué)團隊，該團隊需要立即將數(shù)據(jù)反饋給他們，然后使用Panoply之類的解決方案可能是個不錯的選擇。