在雲環境中實現成功的現代數據分析平台
譯自：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年，它對靜態和昂貴數據倉庫域產生了巨大影響。
總結
本文簡要介紹了針對每層的最佳服務，以及選擇其中一種的理由。但隨着數據領域生態的快速演進以及功能的重疊，依然會存在很多問題和困惑。但無論怎樣，一旦架構模型化，並且"沒有把所有雞蛋放到一個籃子里"，后續的升級和服務替換就會相對容易，即使在大型企業中也不會中斷整體的數據流，分析以及普遍性創新。