ML-蓋伊

2月5日

介紹

在過去的20年中，我與數百家公司合作，以利用不斷髮展的技術工具將業務構想變為現實。一些公司是雲時代誕生的初創公司（例如，Waze，Viber和JFrog）。其中一些是技術巨頭（例如Amazon和Intuit），擁有許多技術人員和軟體開發人員。但是，有些大型企業正在努力改造自己，以保持未來的競爭力。這篇文章的重點是後一種型別的公司，它們是當今我們經濟的支柱（例如，第一資本，美國運通，Liberty Mutual，Orbia，Grupo Salinas和PepsiCo）。

保持競爭力並採用現代技術（例如雲（更快的實現價值）和人工智慧（更智慧的資料使用，高階分析和機器學習））的方法是透過為“飛輪AI。”我在上一篇文章（機器學習系統的飛輪）中解釋了飛輪的細節，簡而言之，它是透過以下方式開始旋轉飛輪：

提供越來越多的可從資料和機器學習模型中受益的業務用例，添加了越來越多的可用於解決上述業務用例的資料來源改善可以建立分析和機器學習模型的資料分析和科學以上分析和模型的生產水平和可用性的提高

飛輪旋轉不快；但是，一旦這些元件到位並相互補充，它就可以變成一組功能強大的業務工具，並影響內部業務管理和外部客戶服務的大多數方面。

在資料方面構建飛輪架構的主要障礙是關係資料庫（如大型組織中的Oracle）的粘性。我在“殺死Oracle和Breaking Teradata”一書中詳細描述了這個問題，歸結為需要為當今企業的動態和規模構建一個分散式且可擴充套件的資料平臺。資料分析平臺的主要佈局分為以下三個層次：

第I層-將原始資料從SAP，Salesforce，Oracle或MS-SQL伺服器等傳統事務資料庫複製到低成本物件儲存中。第II層-仍在低成本物件儲存中的豐富和最佳化形式的I層多個衍生物第III層—以不同，更昂貴的格式（例如RDBMS，記憶體快取或其他基於索引的系統）對訪問模式進行了最佳化的資料儲存。

講完基礎知識後，就該深入瞭解該體系結構了。

通用參考架構

首先，我們繪製飛輪片並將三層放置在它們之間。

> General Modern Data Analytics Platform in the Cloud

第一步是從不同的內部系統和資料庫（如ERP和CRM）複製資料。複製被定向到通常稱為Data-Lake的專用雲環境。

Data-Lake或Data-Warehouse的概念是眾所周知的，許多工具正在以一種或另一種形式幫助實現它。飛輪概念正指導Data-Lake的實現更加敏捷和迭代。“首先讓我們解決資料問題”和建立“完整的” Data-Lake作為分析專案的先決條件的趨勢常常導致大型組織中著名的資料和分析專案失敗。失敗的主要原因是：

前期投資。實現價值的時間很長。缺少需要什麼資料以及如何組織的反饋迴圈。

飛輪旋轉的迭代性質應導致流行語：

“您總是有足夠的資料，而您永遠也沒有足夠的資料。”

如上所述，需要先考慮一個特定的業務用例，然後再進行反向處理：

我如何與業務使用者互動以在他們的工作流程（= app）中為他們提供支援，我如何建立業務邏輯或機器學習模型來滿足工作流程（=分析）的需求，以及如何獲得相關資料以構建模型（= data）？

一旦有了這些定義，就可以開始讓資料工程師將資料放置到位。分析團隊將嘗試使用資料來構建越來越好的模型，DevOps團隊將使用模型來構建模型的介面。重要的是要記住，飛輪的參與者來自不同的學科並使用不同的工具。業務使用者應繼續使用他們喜歡的介面；資料工程師應該可以自由使用他們的大資料工具。資料分析和科學團隊應該有自己的實驗環境，而DevOps團隊可以構建生產級系統。上面的體系結構旨在使每個團隊儘可能高效，並與周圍的團隊整合。

AWS參考架構

可以基於每個公司使用的雲或雲組合，每個組織所需的安全性措施，雲成熟度，已在使用的現有資料系統的型別等，在多種變體中實現通用架構。。

讓我們從主要使用Amazon Web Services（AWS）雲的參考架構開始。它從使用資料遷移服務（DMS）複製事務資料庫開始。DMS可以連線到各種RDBMS（例如Oracle或MS-SQL資料庫），並將資料以一次性或連續模式複製到簡單儲存服務（S3）。圖中的第二種複製方法是使用SFTP將檔案安全地上傳到S3。這些檔案通常是內部資料庫的資料轉儲或內部系統生成的大型報告。

使用Redshift，帶有Spark的EMR，資料湖形成等，可以使用很多選項來設計共享資料湖（第I層）環境。但是，最具成本效益的是使用S3和Athena（託管的PrestoDB），例如如下圖所述。

> Modern Data Analytics Platform in the Cloud — AWS Version

特定於專案的環境（Tier II）很難理解，因為它違反了“一個事實來源”的規則以及我們將在Tier I中逐步建立的單個數據倉庫/湖的規則。首先，您希望擁有多個環境，這使不同的團隊可以以不同的形式，規模和時間來試驗資料和分析。每個團隊都可以將其認為需要用於模型的相關資料放到其環境中，並且共享資料湖團隊可以完全控制允許每個團隊使用的資料。可以在複雜環境中使用AWS Lake Formation處理共享資料湖的治理。這種分離對於使外部團隊能夠幫助組織引導其分析實踐至關重要。由於這些技能通常對於組織來說是新技能，因此值得信賴的外部團隊可以快速獲得獨立的環境來進行實驗，PoC，並建立特定的模型非常有用。與將資料“傳送”到SaaS服務或其他外部服務的另一種選擇相比，組織保持對資料（包括許可權和對資料的任何部分的訪問）的控制的至關重要的能力對於資料治理和隱私至關重要。控制環境。雲的超級能力允許“按使用量付費”和簡單的“正確調整資源大小”，使多個獨立環境的最佳實踐具有成本效益且易於操作。

如果Athena不足以滿足任何團隊或專用EC2例項的需求，並且如果SageMaker的服務並非團隊所需要的，則部署到這些Tier II環境中的每個環境的服務集也可能會有所不同，包括Redshift Spectrum。。我建議上述S3，Glue，Athena和SageMaker的高性價比組合（只要您知道如何停止和啟動閒置的筆記本例項）。

我們將在下一個Azure部分中更詳細地討論共享分析應用程式環境（第III層），因為這在兩個雲環境中都相對相似。在AWS中，您可以使用激動人心的創新服務（例如Lambda）代替笨重的Kubernetes（K8）叢集，尤其是具有當前將Docker映像部署到Lambda並讓AWS為您管理叢集的功能。但是，在上述架構中，我建議使用EKS，因為我發現大多數大公司在採用其他環境中支援的更為通用的技術時會感到更自在，並在需要時僱用更多的專家來管理它們。選擇K8的其他因素是與“標準”監視和安全工具的整合。

Azure參考架構

儘管我建議公司採用多雲策略以允許他們從任何提供商中選擇最佳工具，但我看到有些公司在單個雲提供商上“標準化”。原因可能是任何雲提供商都提供的重大激勵措施，一旦客戶因這項投資而“鎖定”，他們就試圖贏得未來的業務。另一個重要原因是組織需要保護多個環境，並培訓管理員和對不同雲的支援。

我仍然建議公司使用激勵措施並開始在一個雲環境中培訓其員工，但是一旦激勵措施用盡且團隊已經成立，則計劃及時擴充套件到其他雲提供商。這裡建議的體系結構旨在允許多雲操作。例如，您可以在Azure中擁有資料湖，在Azure中擁有一半的分析環境，在AWS中擁有一半的資料，在AWS中擁有您的分析應用程式。在雲和您的業務線的競爭市場中，這種靈活性至關重要。

該架構的佈局與對映到Azure環境中可用的相關服務的佈局相同。如上所述，特定服務有很多替代方法，我對以下推薦體系結構的指導原則是使用更現代但更成熟的服務。例如，您可以使用SSIS，因為它通常在本地環境中使用。但是，最好使用具有更全面功能的Data Factory。同時，您可以開始使用Synapse代替我已經包含的更成熟的Azure Databrick；但是，對於企業而言，現在還為時過早。

> Modern Data Analytics Platform in the Cloud — Azure Version

與Athena在AWS中使用無伺服器服務相比，分析環境中的一個顯著差異是添加了SQL資料庫。資料科學家和分析人員都需要資料的兩個介面：直接資料檔案載入和SQL選項以過濾和聚合大型資料集。因此，提供SQL介面對於提高它們的生產力並節省過於繁瑣的計算例項（如果您在Pandas或其他例項上處理中進行所有過濾和聚合）所必需的成本，至關重要。

分析應用服務

我們經常投入過多的精力，將精力集中在資料工程和ML建模的複雜性上，而忘記了我們為誰工作。業務使用者是這些需求->資料->模型->輸出迴圈中每個迴圈的開始和結束。建立分析流程時，我們可以假設我們將在BI工具或儀表板中呈現輸出。大量受歡迎的工具（例如Tableau，QlikView，PowerBI，SiSense，QuickSight，reDash，Looker，SuperSet以及許多其他隨機順序的工具）表明這是有效的選項。為了允許這種流程，我們需要將分析結果寫回到SQL資料庫中，例如MS-SQL，RDS Aurora，Redshift或任何其他類似的RDBMS。

建議不要在第I層中描述的共享資料湖中使用此目標資料庫。分離的主要原因是誰可以訪問哪些資料的安全性以及第I層是不變的層的性質。同時，Tier III始終是可變的並不斷更新。

在上面的圖中，您可以看到我還添加了一個Kubernetes叢集（或任何其他叢集管理，例如ECS或Lambda），允許在各種用例中將分析專案的輸出提供給業務使用者。例如，分析型機器學習專案的輸出可以是向銷售人員提供價格建議的定價模型，也可以是預測特定市場中產品銷售的預測模型，為貿易經理提供促銷最佳化建議等。開發這些模型時，經過測試，準備供業務人員使用，專案團隊應將模型包裝在Docker容器中，將其推送到容器登錄檔中，然後將其部署到容器服務中。服務可用後，應用程式團隊可以使用現有系統中的新欄位或完全使用新系統將其整合到他們的應用程式中。這些服務由Apps生產團隊使用其最佳實踐和工具負責。

> Modern Data Analytics Platform in the Cloud — Partners Alternatives

作為獎勵圖表，我添加了許多合作伙伴解決方案，它們可以代替一些第一方雲選項。該列表無論如何都不是詳盡無遺的。儘管如此，它仍然反映了我在公司中發現的大多數工具，或者我建議公司嘗試一下，特別是如果您是一家大型企業，正在尋求成熟，安全的解決方案來支援企業未來的資料分析需求。

該圖的重要補充是可以作為Tier III的一部分的各種資料儲存，該層儲存資料以允許有效訪問資料的模式以供使用者使用。供終端使用者使用的最常見的儲存資料的地方是關係資料庫（RDBMS），在第一方版本中，我使用了RDS和SQL服務。不過，正如我所描述的Tier III的屬性一樣，通常最好選擇調整為特定訪問模式的資料儲存，而不要依賴於SQL的通用訪問。如今，Redis，ElasticSearch和MongoDB之類的服務已經足夠成熟，可供企業使用。它們可以簡化資料是排序集，文字文件，JSON文件，關係圖或RDBMS中難以對映，儲存和訪問的其他格式的用例。

細心的讀者可能會注意到，我將Amazon Redshift包含在Shared Data-Lake部分中，即使它在其他雲平臺（如該圖中的其他工具）中均不可用。原因是Redshift作為第一個真正的雲資料倉庫解決方案在這個充滿活力的生態系統的開發中發揮了關鍵作用。Redshift為其他行業指明瞭方向。如今，它已成為具有出色效能，成本結構和靈活性的最佳資料工具之一。Redshift是我參與啟動的第一項AWS服務，並在2012年之前看到了對靜態和昂貴的資料倉庫域的巨大影響。我希望您能在此圖中作為榮譽稱號來包括我，請原諒。

有沒有更好的方法來提供分析輸出？

在Aiola，我們的願景是讓分析專案的全部收益影響委託它們的業務；透過分析和模型以自然和本地的業務語言進行交談。商業使用者可以使用他們的標準通訊工具（例如Microsoft Teams），以自然語言詢問商業問題，而人工智慧（AI）可以快速，準確地回答，與公司最好的資料分析師相似並且比後者更好。所有複雜的體系結構以及構建它的漫長過程和分析模型都旨在允許業務人員與他們的資料和基於它的模型進行簡單對話。沒有比使用自然人類語言更簡單的方法了。

結論

自從有關多個層（I，II和III）的原始帖子以來，我收到了許多共享實施該體系結構的參考體系結構的請求。我希望這篇文章能給出這些架構的佈局。我簡要介紹了針對每種層的最佳服務，以及選擇其中一種的理由。但是，隨著資料域中的生態系統快速發展，而且產品經常重疊，我相信仍然存在疑問和困惑。但是，一旦架構足夠模組化，並且不是“所有的東西都在同一個籃子裡”，相對容易地升級和替換某些服務，而不會破壞整個資料，分析和一般創新的整個流程企業。