多雲的資料平台

如果說公有雲的最大優點是甚麼。無疑的會是很大量的資料，這個很大量是絕大部分企業都無法比擬的。這也是為什麼這麼多的企業會採用雲端技術。不過企業通常都會問的第一個問題是: 我們要從哪裡開始建立資料平台?

本文中，我們將討論在各個雲端平台的資料湖(Data lakes)基本架構。我們還將檢視收集和分析大量資料所帶來的挑戰，包括所謂的資料引力(data gravity)現象，因為通常很難跨不同雲端平台傳輸這些大量資料。 克服這一挑戰的解決方案是資料網格(data mesh)。

本文將討論的議題如下:

• 選擇正確的資料平台
• 建立資料平台與調整其大小
• 設計資料的可移植性(portability)與互操作性(interoperability)
• 克服資料引力的挑戰
• 資料的治理與管理

選擇正確的資料平台

在企業架構框架中，資料佔了重要的角色。數位企業無法不靠資料來運作，因為企業需要從分析資料中來取得見解，並導出下一步的行動。

今日，我們在所有跟雲端相關的介紹中都可以看到"Data-driven"這一詞，也是數位化企業的基礎。哪麼甚麼是資料導向(Data-driven)呢?哪就是企業是依據資料分析做出決策，而非依據經驗與直覺，每一個行動都是資料作為支持。

為了讓企業變成是資料導向的數位企業，企業需要資料，通常是一大堆並且能夠是足夠及時的資料。這樣的1.)資料集是第一個必備項。第二個必備項則是: 資料2.)能夠存取，而能夠存取的資料3.)必須是正確並相關的。

資料需要經過收集、儲存、清理，最後進入到分析，這一連串的流程需要一個平台來協助。不幸的是，沒有任何神奇的公式可以立即取得一個資料平台。 我們先來定義一下什麼是資料平台。

首先，企業需要一個資料中央儲存庫來存放所有的資料，就是大家所熟知的資料湖。因為散落在各處的資料是沒有辦法進行統一分析的。資料分析師可以從該單一存儲庫開始處理資料。 在這個過程中，邏輯集合(logical collections)轉化為資料集，包括資料的清理； 接下來，定義演算法來挖掘資料並為業務產生有價值的結果。

無論使用哪個特定的雲端平台，我都必須定義和設計能夠實現此目的的資料平台必須考慮架構層。這些架構層包含:

• 探索(Discovery) —
  資料來源在那?是否可以存取?
• 可觀測性(Observability) —
  資料的品質。資料是否是最近的與正確的?相關的資料是否已收集?
• 攝入(Ingestion) —
  資料移動(通常是複製)。例如，將raw data從資料湖複製到資料倉儲系統。
• 儲存(Storage) —
  資料實際存放的位置，如AWS S3, Azure Blob storage, GCP Cloud Storage。
• 建模(Modeling) —
  資料模型的建立。
• 分析(Analytics) —
  使用清理後的資料來對應指標，主要從資料中獲得有意義的結果。

資料湖的基礎在公有雲上大都使用Object storage。而在地端環境中，用的技術大都是Apache Hadoop。Hadoop的基本架構，會使用到HDFS(Hadoop Distributed File system)跟MapReduce。Mapreduce是一種在整個cluster中的多個node(也就是server)能平行處理大量資料的應用程式(如下示意圖)。

哪麼資料湖(Data Lake)與資料倉儲(Data warehouse)有甚麼不一樣呢?資料湖儲存的通常是原始(raw)的、未結構化的(unstructured)的資料，資料倉儲提供的就是結構化資料。通常都是將資料從資料湖擷取出來並載入到資料倉儲中，已進行後續的分析。

但也有資料湖與資料倉儲的結合，稱為lakehouse。通過 Lakehouse，可以在資料湖之上實現額外的格式化結構。 這最初是由 Databricks 推動的，但從那時起，更多提供 Lakehouse 解決方案的技術進入了市場。 例如 Delta Lake 和 Apache Iceberg。下面我們將介紹三大公有雲的資料平台方案。

Azure Data Lake與Data Factory

Azure的資料湖全名是Azure Data Lake Storage Gen2，這個底層Azure Storage。它將file system semantics加到到 blob storage中，以便可以通過目錄的分層結構將 PB 等級的資料組織在object和file中(存放的一樣是raw data)。

Azure提供一種稱為Data Factory的解決方案，能夠針對資料進行組合與分析。Data Factory處理資料的方式可以是ETL(extract-transform-load)或ELT(extract-load-transform)的無代碼服務。它讓企業可以建立data pipelines:

• Ingest: 產生資料集
• Control and data flow: 在pipeline中設計資料處理流程
• Schedule: 在特定的時間或是有新資料進入觸發資料處裡流程
• Monitor: 監控pipeline的所有活動

高階示意圖如下。

在這一流程最後需要資料視覺化(通常使用微軟的Power BI)，呈現給相關厲利害關係人觀看以做出決策。而在2022年，微軟推出了Azure Data Explore，一種全託管式的大數據分析平台。除了可以連結自身的Azure服務外，它還可連接其他第三方資料來源。

另外一個服務是Azure Synapse，它將企業資料倉庫與大數據分析串連起來。Azure Synapse 匯集了企業資料倉庫中使用的 SQL 技術、用於大數據的 Spark 技術、用於日誌和時間序列分析的 Data Explorer、用於資料整合還有 ETL/ELT 的pipeline，以及與其他 Azure 服務（例如 Power BI、Cosmos）的深度整合 DB 和 Azure ML。 對於資料治理，Microsoft 提供了 Microsoft Purview，它提供了統一的資料治理服務，可幫助企業管理地端、多雲和 SaaS 資料。更多的Azure 資料服務內容，可參閱本部落格Azure 儲存解決方案與設計Azure 非關聯式資料的儲存方案一文。

AWS資料湖

AWS的資料湖包含了AWS多個服務與組件。raw data中常放在AWS S3中，有時會是DynamoDB，一種全託管式NoSQL解決方案。另一個是AWS Glue，AWS提供的全托管ETL工具。它可以進行資料的探索與資料集的準備(或是 data catalog)來匯入到DynamoDB進行分析。高階示意圖如下。

更多的AWS資料服務介紹可參閱本部落格AWS的大數據分析-part 1資料收集一文及其系列文章。

GCP資料湖

跟AWS一樣，GCP的資料湖底層用的也是Object storage — Cloud Storage。不過其服務方式與AWS稍稍有些不同(如下圖)。這也造就了計費的方式也不一樣。

GCP提供了DataLab與Dataprep兩種服務來探索在Cloud Storage中的資料。另外GCP的Data warehouse可以在不將資料載入進BigQuery的前提下，利用Bigquery engine對其Cloud Stroage進行分析查詢(當然效能就無法與資料儲存在BigQuery的相比)。

BigQuery還有Omni的版本，這是GCP針對資料散落在多個雲端與地端的資料分析解決方案(其實Azure/AWS也有類似的方案)。

建立資料平台與調整其大小

與我們在雲中部署的每項服務一樣，我們需要一種基礎來建立我們的資料平台。因此，建立Landing zone就是儲存raw data的第一步。這樣的Landong zone的環境只有一種目的: 擷取raw data。這類的Landing zone應該跟企業的核心系統分開來。為什麼呢?因為這一類的raw data企業必須存上非常非常多，根據法規法令與業務需求，有時甚至需要儲存到10年之久。所以它必須是可擴展並且是廉價的(因為大多的資料儲存可能會增加費用)。

為了良好的資料管控，企業需要有"資料治理"這件事，而且是一開始就要有的。這包含對資料的分級分類，定義與實行資料的範圍等。

一旦企業建立好了Landing zone，資料分析師就可以把資料湖當作是沙盒環境。這是第二階段。資料分析師利用在這個沙盒環境裡的raw data開始嘗試建立資料模型的原型。分析師開始整合在這個資料湖中的商業資料，這個過程也是ETL或ETL。從資料湖萃取的資料是有經過選擇且相關的，這樣才不會增加資料倉儲的大小。

現在，資料湖已經成為企業IT基礎設施和業務的核心組成部分。 強大的資料治理是對維運資料湖以及連接資料湖與資料倉儲和各種資料模型的資料流的絕對要求。 這些模型將產生應用程序的產出，並能夠詳細了解業務本身、業務支持運營的效能與效率以及業務運營的市場。

根據以上所述的過程，我們可以定義出建立資料平台與調整其大小的以下四個階段。

要建立正確符合企業的資料平台有這著以下要點:

1. 理解其業務內容以收集到正確且相關的資料，需要有一個清楚的目標: 是甚麼樣的商業問題讓企業必須建立這樣的平台了進行資料分析。作為一個企業，我們真正需要什麼樣的資料？
2. 了解資料的含義。 資料必須能被識別，這可以通過標記(tagging)資料來實現。 因此，元資料(metadata)至關重要。 資料沼澤(data swamp)的風險始終存在，意思是，公司及其員工淹沒在資料中。 解決這個問題的一種方法是資料清理，它與攝取、排程和監控一樣重要。 根據資料分類，必須清理資料。 因為這對控制成本也很重要。
3. 安全必須放在第一位。 通過對傳輸中的資料和靜態資料實行身份驗證、授權和加密來確保資料安全。

設計資料的可移植性(portability)與互操作性(interoperability)

資料的可移植性與護操作性通常來自我們的使用案例與商業案例。在IT系統中，根據TOGAF的ADM定義系統的可移植性分為四個層面: data, application, platforms, infrastructure。更多的TOGAF資訊請參閱本部落格＂運用TOGAF ADM的資訊系統架構＂一文。

但在雲端運算中，上述這一類的界線開始變得模糊。特別是PaSS與SaaS，使用SaaS我們只需要管理資料，PaaS則加上應用程式需要管理。這些雲端服務的分類都無法與傳統IT架構套用在一起了。

不過，TOGAF所做的移植性是在IT系統中建立一個抽象架構層。哪就是，資料、應用程式還有技術是完全分開來的。可移植性本身就是一項需求，但隨之而來的是系統應遵守的要求。總結為:

• 架構願景應包含應用程式的可移植性與互操作性
• 需求需要收集到能滿足願景
• 業務架構定義了可移植性和互操作性的業務流程是一種需求
• 資訊系統架構定義了如何在應用程式與資料層級定義其可移植性和互操作性
• 技術架構定義了技術如何支援可移植性和互操作性

理論上，這讓資料與應用程式架構不會依賴技術架構中的某一個特定技術層。這一類的技術通常與微服務相關，微服務通常能符合我們上述的特點。微服務架構能達成系統的可移植性。

可移植性靠的是data,application, storage, infra(包含網路)之間的去耦合(decoupling)。互操操作性靠的是標準化，例如開放標準。

可移植性是通過基礎設施之間的抽象(Landing zone)來定義的，還有基礎設施組件，資料，應用程式等這些的配置。這邊使用的是The Open Group的產業標準來定義可移植性:

• 資料的可移植性本質上是橫跨各種應用程式來重複使用資料。 資料可移植性可能是實現所有IT系統層面中可移植性中最困難的部分。 資料的結構通常被設計為適合特定形式的應用程式來處理，並且需要進行重大轉換才能產生可以由不同產品處理的資料。 它與資料載體、資料庫技術或託管資料庫的存儲層是分開的。 例如，MySQL作為資料庫能在不同的平台上運作。 但這不意味著資料庫中的資料可以被不同的應用程式使用而無需轉換這些資料。
• 應用程式可移植性是指可以橫跨各種運算平台重複使用其組件。 這些平台可以是傳統的地端平台，也可以是包括 PaaS 在內的雲端平台。 後者的範例是託管式資料庫服務，例如 AWS RDS和 Azure SQL Database。 可移植性需要支援的平台有對外的標準介面。 這必須使應用程序能夠使用平台之間的service discovery和通訊，並提供對直接支持應用程式的平台功能的存取。 同樣的原則也適用於互操作性。
• 平台可移植性，我們可以想成是跨雲端和地端基礎設施的重複使用平台組件。 K8S作為託管應用程式的容器的底層平台就是一個例子。 K8S可以部署在各種平台上，包括公有雲和地端機房(私有雲)。 但虛擬化也是一個例子：如果VM是可移植的，VM就可以在不同平台之間轉移。 但這與從一個控制台管理多台機器不同。 例如，Azure Arc允許管理員將來自其他雲端和地端的非Azure機器和K8S置於Azure的控制之下，並從Azure控制台管理這些機器。 然而，非 Azure VM則保留在原處。 這些機器的image不會傳輸到其他insatnce。 這個技術是使用了平台之間互操作性的可能性，但它並不使環境具可移植性。

而各家的雲端平台業者其實是沒有義務提供可移植性與互操作性到其他雲端平台或地端的。因為這樣等於它們賺不了你的錢，最多就是資料傳輸費用。

可移植性是應用程式的非功能性需求。一個應用程式應該能夠盡量的具可移植性，而不必綁定特定的基礎設施或平台。能完成這個目標的方式就是需要有一個抽象層與服務的去耦合。總的來說，如果我們從定義、設計和應用微服務的角度來處理可移植性，我們可以獲得最高水平的可移植性。

雲端可移植性代表的是企業有能力將應用程式與資料從公有雲端業者A搬到B(最小的服務中斷)，或是在私有雲與公有雲之間移來移去。這也代表著企業能夠使用多雲的策略。企業的資料湖可能在業者A，而應用程式及其資料可能在業者B。但在一開始的設計與實行上，雲端架構師就要遵循去耦合的原則來做。

但將現有的IT環境與應用程式解耦合是一件困難的事。最困難的是互操作性(interoperability)。但我們應該何時提起這件事呢?產品面?系統面?或組織面?，應該說不論哪個層面，這些組件都必須能沒有限制的一起作業。另一個困難是，解偶之後(微服務架構下)，各個組件(系統、應用程式、資料)如何知道應該溝通的其他組件在哪裡?應該要用甚麼方式溝通呢?我們需要確保所有的服務都要知道其他的服務在哪裡(也就是去探索能力)以及規定溝通的方式。

在多雲架構下要達成互操作性的最佳實踐有:

• 同質化的虛擬技術，包含容器管理平台
• 驗證與授權的標準協定
• 使用標準的API

另外一個挑戰就是在不同雲端之間的資料同步問題(資料傳輸費也是一個大問題)。同步是不是用同一種協定，怎麼個同步法?多久同步一次?還是持續性同步?哪是否要網路專線來支持及時同步?下面是多雲中資料同步我們必須注意到的:

• 主要資料來源的管理: 唯一的真相(raw data)來源在哪裡?
• 傳輸中的資料與靜態資料的管理
• 資料的可見性(Visibility)
• 存取管理，驗證與授權

完全的互操作性包括持續、動態地探索基礎設施、資料來源和應用程式組件，並在運行時與其他組件進行通訊。

克服資料引力

應用程式除了連結現有資料，還會產生資料。這些應用程式與資料還會連結其他的應用程式與其他資料來源，進而產生更多的資料。就好像地球跟月球之間的萬有引力相互糾結在一起。

越來越多的資料也產生了另一個問題。資料庫的規模變得變來越來，以至於移動它們變得越來越不可能，或是要付出極高的代價。而這樣也會讓企業的資料固定在同一個地方。而這也造成另一個引力，所有相關的應用程式或資料來源要連接這個資料庫的，都不能離太遠否則會有網路延遲的問題。

資料引力問題也造成了企業與雲端架構師在設計上需要考量多種議題，資料隱私權是其中之一。到今天為止，各個大國或區域仍在為了資料位置的所有權與隱私不斷的角力與妥協的情境中來回。

一個好的業務流程必須讓雲端中的IT系統與資料還有他們的客戶盡量的接近。既然移動龐大資料庫是一個挑戰，我們必須在設計解決方案時就地使用資料，並認知到資料預設上是去中心化的(decentralized)。 如果我們以此為原則，那麼就沒有必要將每一筆收集到中央資料存儲中。

但去中心化的資料庫勢必引起資料隱私權的爭論。但如果要克服資料引力的挑戰的話，這就是解方。我們當然可以將資料集中到同一個地方，或者把應用程式設計成不論在資料在哪裡都可以進行存取'。

現代科技(雲端、IoT、分析平台、智慧手機、智慧城市等等)讓資料是散落在各處的。企業必需準備好面對這種情況。一個去中心化基礎設施可以通過提供正確的覆蓋範圍、容量和連接性，快速將使用者、網路和雲端導入這些資料來應對資料引力的挑戰。大多數的雲端供應商也都做好這種準備了，靠著一些新技術的出現，如5G與邊緣運算讓資料快速的到位。

資料網格(Data mesh)原則

去中心化資料庫的解方就是資料網格。哪麼甚麼式資料網格呢?

資料網格是一種架構，允許應用程式以及使用者存取資料，而無需先將資料傳輸到資料湖。 資料網格利用分散資料來源的原理。 資料網格的挑戰仍然是如何將正確的資料擷取到可以處理的應用程式，而不是移動這些資料。

而這可以通過資料串流(Data streaming)來完成。主要的雲端提供商都有提供這一類的服務，多數的技術底層是以Apache Kafka來達成資料串流。像是Azure Synapse, AWS Glue, GCP Dataplex或OCI GoldenGate。

資料的治理與管理

資料工程師負責data pipeline的設計、建立與管理，但是資料湖與資料倉儲的底層對資料平台是一個特別的Landing zone。而這個Landing zone的維運通常是雲端工程師在負責的，雲端工程師在意的是雲端中的運算、儲存、與網路等底層資源。

如果從資料平台的管理r角度來看，我們可以把它分成以下幾種角色:

• 資料架構師或資料工程師 —
  這兩種繳角色是分開還是合在一起得看公司的大小。 這類角色通常負責data pipeline的設計、開發與佈署。他們必須對ETL/ELT pipeline要有廣泛的知識，以確保資料從來源端的收集到轉換進入正確的資料庫或其他資料目的地然後可以進行分析。資料當然還需要被這一類的角色所驗證。簡單來說這一類的角色就是讓資料如期且如質的能夠被分析。
• 商業與資料分析師 —
  這一類角色要做的任務是: 甚麼樣的資料可以被用於商業用途?甚麼樣的資料可以提供商業見解?業務願景、目的和目標被轉化為用於分析資料的指標。
• 資料科學家 —
  當商業與資料分析師對資料定義出指標之後，資料科學家要做的就是確保能找到正確的資料來源，並且能分析到正確的資料。資料科學家對於找到正確的資料至關重要，商業分析師可以使用這些資料來證明指標並提供見解，使企業能夠實現其業務戰略。
• 維運工程師 —
  資料必須備存放在雲端的某處，需要運行大機器或分析服務來分析資料。而這一些資料運作的底層就必須有Landing zone來支援。維運工程師則必需維持這一切底層基礎設施，以期整個資料平台是穩定、高效且安全的。
• 成本控管(FinOps) —
  雲端中的資料分析通常隨著分析的資料越多需要付出越多的費用。所以使用針對不同的資料用正確的方式與工具來執行其任務是非常重要的，

更多的資料治理與管理的其他參考資料，可參閱本部落格Snowflake 雲端資料分析一文。