在雲環境中實現成功的現代資料分析平臺
譯自：Architecting a Successful Modern Data Analytics Platform in the Cloud
前面討論了如何在雲環境中構建成功的現代資料分析平臺，本文會通過AWS和微軟Azure的參考架構來幫助我們提升設計上的可擴充套件性，靈活性和健壯性。
介紹
過去20年間，我曾幫助了上百個公司，利用不斷髮展的技術工具將業務創意變為現實。有些公司出生在雲時代(如Waze, Viber, and JFrog)，有些是本身有很多技術人員和軟體開發者的科技巨頭(如Amazon 和Intuit)，而有些則是嘗試重塑自我來保持未來競爭力的大型企業。本文將重點關注後一類公司(它們是如今的經濟支柱，如Capital One, AmEx, Liberty Mutual, Orbia, Grupo Salinas, 和PepsiCo)。
保持競爭力並採用現代技術(如雲(快速實現價值)和AI(更智慧地使用資料，更先進的分析方式，以及機器學習等))的一種方式是為"AI飛輪"搭建一套環境。在前面的文章中已經解釋了飛輪的細節。簡而言之，轉動飛輪的方法為：
- 輸入更多的、可以從資料和機器學習模型獲益的業務使用場景。
- 新增更多的、可以用於解決上述業務場景的資料來源。
- 提升可以構建分析和機器學習模型的資料分析和科學。
- 提升上述分析和模型的生產級別和可用性。
現在飛輪的轉速還不夠快。然而一旦成形，就可以變成一個強有力的業務工具，進而影響到內部業務管理和外部客戶服務的方方面面。
根據資料來構建飛輪架構的首要障礙就是關係型資料庫(如大型組織中用到的Oracle)的黏性。我在“Kill Oracle and Break Down Teradata一文中對問題進行了描述，即當今需要一個分佈的且更具擴充套件性的資料平臺來適應業務的動態和大小。資料分析平臺的主要佈局分為以下三層：
- Tier I ：從傳統事務型資料庫(如 SAP, Salesforce, Oracle, 或MS-SQL)中複製到低成本物件儲存中的原始資料。
- Tier II：通過豐富和優化Tier I而衍生出來的形式，仍然是低成本的物件儲存。
- Tier III：優化訪問模式的資料儲存。使用不同且更昂貴的儲存方式，如 RDBMS, 記憶體式快取或其他基於索引的系統。
實際可以將資料架構分為了資料採集層(資料複製)、資料優化層(壓縮、聚合、安全、分析等)和資料展示層(提供API閘道器和BI展示等)
通用參考架構
下面是三層模型在通用參考架構中的示意圖：
General Modern Data Analytics Platform in the Cloud
第一步是從不同的內部系統或資料庫(如ERO和CRM)中複製資料，然後將其匯入雲環境中(通常稱為資料湖)。
可以藉助很多工具並以某種形式來實現資料湖和數倉。飛輪的概念使得資料湖的實現更具敏捷和可迭代性。將"首先解決資料的問題"以及構建一個"完整的"資料湖作為分析專案的先決條件，常常會導致大型組織中的資料和分析專案的失敗。主要的失敗原因為：
- 前期投資
- 實現價值的時間很長
- 缺少反饋環，無法確定需要哪些資料以及如何組織這些資料
飛輪旋轉的迭代性質對應如下標語：
“You always have enough data, and you never have enough data.”
正如前面討論的，應該從特定的業務場景開始，並以此進行後續的工作：
- Q1：如何與業務使用者進行互動來支援他們的工作流程(=app)，
- Q2：如何構建一個業務邏輯或機器學習模型來滿足工作流程(=分析)的需要，且
- Q3：如何獲取相關的資料來構建模型(=資料)？
一旦解決了上述問題，就可以讓資料工程師就緒資料。然後分析團隊會通過試驗這些資料來不斷優化模型，DevOps團隊可以構建模型介面。
需要注意的是，飛輪的各個參與者來自不同的學科，並使用不同的工具。業務使用者應該繼續使用他們喜歡的介面；資料工程師可以自由地使用他們的大資料工具。資料分析和科學團隊應該有自己的實驗環境，而DevOps團隊可以構建生產級別的系統。上面的架構旨在使每個團隊都能高效地工作，並整合了周邊團隊。
AWS參考架構
可以根據每個公司使用的雲、每個組織所需的安全措施、雲成熟度以及正在使用的資料系統的型別等來實現各種通用架構。
首先看下AWS的參考架構。一開始，它會使用Data Migration Service (DMS)從傳統資料庫中複製資料。DMS可以連線到各種RDBMS，如Oracle或MS-SQL資料庫，並支援使用一次性或連續模式將資料複製到S3中。圖中的第二種複製方法使用SFTP將檔案上傳到S3，這些檔案通常是從內部資料庫匯出的資料，或從內部系統生成的大型報告。
實際中有很多方式可以設計共享的資料庫環境(tier I)，如使用Redshift，EMR(+Spark)，Data-lake Formation等。但最經濟的方式是使用S3和Athena (使用PrestoDB管理)。
Modern Data Analytics Platform in the Cloud — AWS Version
特定專案環境(Tier II)比較難以理解，因為它違反了“一個資料來源”以及我們在Tier I逐步建立的單個資料倉儲/湖的原則。首先，你希望有多個環境，用來支援不同的團隊使用不同的形式、規模和次數來實驗資料和進行分析。每個團隊都可以從環境中拉取他們的模型所需要的資料，而共享資料庫團隊可以控制團隊訪問的資料。複雜環境中，可以使用AWS Lake Formation 來管理資料湖。這種分離環境的方式可以讓外部團隊協助(組織)引導分析實踐。對於組織來說，這些技能通常比較新，可以讓一個可信的外部團隊(快速地)獲取一個獨立的環境並進行實驗、PoC、並構建一個特定的模型。組織最重要的是對資料的控制能力，與將資料“傳送”到SaaS服務或其他失控環境相比，管控許可權和資料訪問的能力對於資料治理和隱私至關重。雲獨有的能力允許“按量付費”以及簡單地“正確調整資源大小”，可以高效而直接地操作多個獨立的環境。
部署到Tier II環境上的服務也可以發生變化，例如在Athena 無法滿足任意團隊的需求時可以包含Redshift Spectrum，或在團隊並不需要SageMaker 時，可以為其指定一個EC2。我建議使用上述S3，Glue，Athena和SageMaker的高價效比組合。
在Azure 一節中，我們將詳細討論共享分析apps環境(Tier III)，它在這在兩個雲環境中都非常相似。在AWS中，你可以使用像Lambda這樣新型的服務(而不是笨重的kubernetes叢集)，可以在Lambda中部署Dockers映象，讓AWS為你管理叢集。但在上面的架構中，我建議使用EKS，是因為很多大公司更傾向於在其他環境中使用更通用的技術，並在需要時僱傭更多的人力(專家)來對其進行管理。選擇K8的其他因素如它整合了標準的監控的安全工具。
Azure 參考架構
我曾向很多公司建議過使用多雲策略來從供應商手中選擇最合適的工具，但有些公司會選擇單一供應商產品來實現"標準化"，這樣做的原因可能是雲提供商給予了較大優惠，一旦客戶因此次投資而“鎖定”該供應商，則它就極有可能在未來的投資中再次獲勝。另一種原因可能是組織需要對多個環境進行安全加固，並培訓管理員來使用不同的雲。
我建議公司使用供應商提供的優惠來在一個雲環境中培訓人員，並做好擴充套件到其他雲供應商的準備，一旦優惠過期，團隊人員就可以隨時就緒。下面的架構旨在使用多雲操作。你可以在Azure中部署資料湖，將一半分析環境放在Azure中，一半放在AWS中(例如將分析App放到AWS中)。
該架構的佈局與對映到Azure環境中的相關服務對應。如下圖所示，特定的服務其實有很多替代品，下面建議的架構中使用了更先進、更成熟的服務。如，你可以在本地環境中使用SSIS，但最好使用功能更全面的 Data Factory。同時，你可以使用 Synapse，而不是更成熟的 Azure Databricks，但對企業來說，這樣做可能為時過早。
Modern Data Analytics Platform in the Cloud — Azure Version
需要注意的是，與AWS中使用的Athena服務相比，上述分析環境增加了一個SQL資料庫。資料科學家和分析人員需要兩個資料介面：直接載入檔案和SQL方式，用來對資料集進行過濾和聚合。因此，提供SQL介面可以提高他們的生產率，並減少在Pandas或其他例項的過濾和聚合處理中使用的過於強大的計算例項所造成的開銷。
分析應用服務
我們經常會更加關注資料工程和ML模型，反而忘了我們需要服務的物件。業務使用者是這些需求->資料->模型->輸出環的開頭和結尾。在外面構建分析流時，我們會假設最終會在BI工具或看板中展示結果。可支援的工具如Tableau, QlikView, PowerBI, SiSense, QuickSight, reDash, Looker, SuperSet等。為了支援最終展示，我們需要將分析結果寫回到SQL資料庫，如 MS-SQL, RDS Aurora, Redshift或其他類似的RDBMS。
我建議不要在 Tier I描述的關係資料湖中包含這類資料庫。主要原因是要考慮誰可以訪問這部分資料以及Tier本身的特性(TierI是不可變的)。同時Tier III 是隨時可以進行變動和更新的。
在下圖中可以看到我新增了一個Kubernetes叢集(或其他向ECS或Lambda這樣的叢集管理)來允許在各種場景下為業務使用者提供分析輸出。例如，一個分析機器學習專案的輸出可能是一個價格模型，用於給銷售人員提供價格建議；或是一個預測模型，對特定市場的產品銷售做出預測，優化貿易經理的促銷建議。當這些模型進行部署，測試，並可以給業務使用者使用時，專案團隊就可以將這些模型打包到Docker容器中，並將其推送到一個容器倉庫，最後部署到容器服務中。一旦服務可用，應用團隊就可以通過使用現有系統中的新欄位或全新系統將其整合到應用中。App產品團隊負責在這些系統上應用最佳實踐和工具。
Modern Data Analytics Platform in the Cloud — Partners Alternatives
在上圖中，我新增了很多可替代的選項。上述列表並不全面，但包含很多公司常用的工具或我建議公司嘗試去使用的工具，特別適用於那些為未來的業務資料分析尋求成熟、安全的解決方案的大型企業。
上圖中需要注意的一點是Tier III中的資料儲存部分，資料儲存需要支援高效的資料訪問和使用者消費。最常用來為終端使用者儲存資料的地方是關係型資料庫(RDBMS)，在第一個版本中，我使用了RDS和SQL服務。然而，正如對Tier III屬性的描述一樣，最好根據訪問模式來選擇資料儲存，而不應該依賴通用的SQL訪問服務。今天企業可以選擇使用Redis, ElasticSearch, and MongoDB等這類足夠成熟的服務，它們可以簡化很多使用場景，如有序集合，文字文件，JSON文件，關係圖或其他難以在RDBMS中對映、儲存和訪問的格式。
細心的讀者可能注意到，我在 Shared Data-Lake 部分中引入了Amazon Redshift，該服務在其他雲平臺上是不可用的。原因是Redshift 在第一個真實的雲數倉解決方案中扮演者至關重要的角色。Redshift為其他行業指明瞭方向。如今，它是集出色效能，成本結構和靈活性為一身的最佳資料工具之一。Redshift是我參與啟動的第一個AWS服務，直到2012年，它對靜態和昂貴資料倉儲域產生了巨大影響。
總結
本文簡要介紹了針對每層的最佳服務，以及選擇其中一種的理由。但隨著資料領域生態的快速演進以及功能的重疊，依然會存在很多問題和困惑。但無論怎樣，一旦架構模型化，並且"沒有把所有雞蛋放到一個籃子裡"，後續的升級和服務替換就會相對容易，即使在大型企業中也不會中斷整體的資料流，分析以及普遍性創新。