使用 Google Cloud 打造現代化的整合式數據分析資料平台

資料的建立不曾中斷過。IDC 研究表明，2025 年全球資料將成長至 175 ZB¹。每天產生的資料量極為驚人，各家公司越來越難以方便存取和使用的方式，來收集、儲存及整理資料。事實上，有 90% 的資料專家表示，自家工作因為不可靠的資料來源而拖慢了。約 86% 的資料分析師對過時資料感到苦惱，且每個月有超過 60% 的資料工作者必須在清理及準備資料時等待工程資源，因而受到影響²。

如果機構架構和架構決策效率低落，企業在匯總資料與運用資料的體驗之間就會產生落差。公司想遷移至雲端，翻新資料數據分析系統，但只是這麼做無法解決互不流通的資料來源和易出錯之處理管道的根本問題。機構必須針對資料擁有權的策略性決策和儲存機制的技術決策進行全盤制定，為機構帶來更成功的資料平台。

本文將探討在 Google Cloud 上建構現代化整合式數據分析資料平台時，必須考量的決策點。

過去二十年來，大數據為企業創造了驚人的商機。然而，機構要為企業使用者提供相關、可行且及時的資料並不容易。研究顯示，86% 的分析師仍在辛苦處理過時資料³，且只有 32% 的公司認為自己能從資料中獲得實質價值⁴。第一個問題是資料更新間隔。第二項問題是難以橫跨各資料孤島，整合不同的舊系統。組織開始遷移到雲端，但這無法解決舊系統實際存在的問題，而這些舊系統可能是為了滿足單一業務單位的需求而垂直建構的。

規劃組織資料需求時，很容易就會過度籠統，想採用單一的簡化結構，其中包含一組一致的資料來源、一個企業 data warehouse、一組語意，以及一項商業智慧工具。這或許適用於非常小型、高度集中的機構，甚至可適用於擁有其整合 IT 與資料工程團隊的單一業務單位。但實務上，沒有組織結構如此簡單，且在資料擷取、處理和/或使用方面時常存在令人驚訝的複雜性，將使事情更加複雜。

我們與數百位客戶談論的結果是，必須採用更全面的資料與數據分析方法、可滿足多個業務單位和使用者角色需求的平台，以及盡可能減少處理資料的冗餘步驟。其中不僅包含需要購買的新架構或軟體元件組，除了技術升級之外，公司還必須評估整體資料成熟度，並對組織進行系統性變更。

在 2024 年底前，75% 的企業將由前測轉向實施 AI 技術，讓串流資料和數據分析基礎架構的數量提升 5 倍⁵。只要在孤立的環境中，與一組獨立的數據資料學團隊合作，就能輕鬆進行 AI 前測。然而，讓這些深入分析結果無法發布至生產製造系統的主要難處，在於機構和架構上的衝突，造成資料擁有權持續分割。因此，用於組織業務營運的大多數深入分析結果為描述性質，而預測性數據分析則屬於研究團隊負責的領域。

資料工作很少由單一人員執行；機構組織內有許多資料相關使用者，會在資料生命週期中扮演重要角色。每個使用者在資料治理、更新間隔、曝光度、中繼資料、處理時程、查詢能力等方面都有不同觀點。在大部分情況下，他們都是使用不同的系統和軟體，在不同的處理階段對相同的資料進行操作。

以機器學習的生命週期為例，資料工程師可能要負責確保數據資料學團隊可取得最新資料，並設下適當的安全性和隱私權限制。數據資料學家可以根據資料工程師提供的一組最佳預先匯總資料來源，建立訓練和測試資料集、建構及測試模型，並讓其他團隊取得深入分析結果。機器學習工程師可以不會干擾其他資料處理管道的方式，負責將部署作業模型封裝至生產製造系統。產品經理或業務分析師可能會查看產生的深入分析結果、使用 Data QnA (用於 BigQuery 資料數據分析的自然語言介面)、視覺化軟體，或可能直接透過 IDE 或指令列介面查詢結果集。我們的使用者眾多，具有各種需求，因此我們打造了抗壓平台，以滿足所有需求。Google Cloud 可隨時隨地為客戶提供符合其業務需求的工具。

我們和客戶談到資料數據分析方面的需求時，通常會聽到客戶問：「到底需要選擇使用資料湖泊或資料倉儲？」由於組織內的資料使用者和需求不同，要解答這個問題可能會很困難，但具體取決於預期用途、資料類型和人員。

• 如果您知道需要分析哪些資料集，充分瞭解其結構，並有一系列已知的問題需要解答，那麼您可以考慮採用資料倉儲
• 另一方面，如果您需要可偵測多種資料類型，不確定該執行哪類分析，卻正在設法發掘商機，而不只是呈現洞察資訊，且您擁有能有效管理及探索此環境的資源，則資料湖泊可能會更符合您的需求

不過，決定時仍有很多要考量的因素，接下來我們會分別討論機構面臨的一些難題。資料倉儲通常很難管理。過去 40 年來成效卓越的系統如今已不合時宜，而且過於昂貴，資料更新間隔、擴充性和高額成本都會帶來許多挑戰。另外，如果不在建立完成後新增功能，舊版系統就難以提供人工智慧 (AI) 或即時功能。這些問題不只出現在地端部署的舊版資料倉儲中。新建立的雲端式資料倉儲甚至也會看到這些問題。即便許多公司聲稱可以提供經過整合的 AI 功能，實際上卻無法做到。這些新的資料倉儲本質上仍屬舊版環境，只是轉移至雲端。Data warehouse 使用者通常是分析師，且通常附屬於特定業務單位。他們或許對於其他資料集有所想法，有助於增進他們對業務的瞭解。他們或許會有提升數據分析、資料處理及商業智慧功能要求的想法。

不過在傳統機構中，他們通常無法直接接觸資料擁有者，也無法輕易影響決定資料集和工具的技術決策者。此外，由於他們無法存取原始資料，因此他們無法測試假設，也無法深入瞭解基礎資料。Data lake 各有其挑戰。理論上，這些產品的成本低廉且易於擴充，但許多客戶都發現地端部署資料湖泊出現不同的狀況。規劃及佈建足夠的儲存空間可能花費昂貴且困難，對於產生各種大量資料的機構來說更是如此。然而，地端部署資料湖泊可能相當容易出錯，而且現有系統的維護需要時間。在許多情況下，原本在開發新功能的工程師，會轉向負責維護和提供資料叢集。明顯來說，他們是在保持價值，而不是創造新的價值。整體而言，對許多公司來說，總持有成本是高於預期的。不僅如此，管理機制不容易跨系統解決，尤其當機構的不同部分使用不同的安全性模型時，更是如此。因此，資料湖泊遭受孤立並區隔，導致組織難以跨團隊共用資料和模型。

Data lake 使用者通常較接近原始資料來源，並且擁有探索資料的工具和功能。在傳統機構中，這些使用者傾向於關注資料本身，而且經常與公司其他部門不相往來。如此疏離情形意味著業務單位錯失了商機，無法找到有助於推進業務目標的洞察資訊，來提高營收、降低成本、降低風險，以及發掘新商機。權衡之下，許多公司最終都會選擇採用混合式做法，也就是設定 data lake，將部分資料升級到 data warehouse，或是 data warehouse 設有側 data lake 以進行額外測試和分析。然而，由於許多團隊會根據各自的需求建構自己的資料架構，對核心 IT 團隊而言，資料共用和保真會變得更加複雜。與其建立各自有不同目標的團隊 (讓一個團隊探索業務，再由另一個團隊瞭解業務)，您不妨整合這些職務及其資料系統，進而建立良性循環，透過深入瞭解業務來帶動針對性探索，並透過如此探索促進充分瞭解業務。

您可以在 Google Cloud 中單獨建構資料倉儲或資料湖泊，但不必選擇其中一種版本。在許多情況下，客戶在兩者方面使用的基礎產品都會相同，而資料湖泊和資料倉儲實作之間的唯一差異是採用的資料存取權政策。事實上，這兩個名稱也開始整合為更統合式的功能組合，也就是現代化的數據分析資料平台。接著來看看此平台在 Google Cloud 中的運作方式。

BigQuery Storage API 可讓您將 Cloud Storage 等 BigQuery 儲存空間用於 Dataflow 和 Dataproc 等多數其他系統。這能讓您打破 data warehouse 儲存空間限制，並在 BigQuery 上執行高效能的資料框架。換句話說，BigQuery Storage API 可讓 BigQuery data warehouse 像 data lake 一樣運作。BigQuery Storage API 有哪些實際用途呢？例如，我們建構了一系列的連接器 (例如 MapReduce、Hive、Spark)，讓您能直接在 BigQuery 中的資料上執行 Hadoop 和 Spark 工作負載。除了 data warehouse 外，您不再需要使用 data lake！Dataflow 的批次和串流處理功能極為強大。您現在可以針對 BigQuery 資料執行 Dataflow 工作，並運用來自 Pub/Sub、Spanner 或任何其他資料來源的資料，讓 BigQuery 資料更加豐富。

BigQuery 可以獨立擴充儲存和運算功能，且每個功能皆採用無伺服器方式，因此無論不同團隊、工具和存取模式的使用狀況為何，您都能享有無限的資源調度能力，滿足各種需求。上述所有應用程式都可以執行，不會影響任何其他同時存取 BigQuery 之工作的效能。此外，BigQuery Storage API 提供 Pb 等級的網路，可在節點之間移動資料以有效執行查詢要求，產生與記憶體內作業類似的效能。另外，此 API 也能直接與常見的 Hadoop 資料格式 (例如 Parquet 和 ORC) 以及 NoSQL 和 OLTP 資料庫連結。您可以進一步運用 BigQuery 內嵌之 Dataflow SQL 提供的功能。這麼做可讓您將串流彙整至儲存在檔案中的 BigQuery 資料表或資料，來有效建立 lambda 架構，以便擷取大量批次和串流資料，同時提供回應查詢的服務層。BigQuery BI Engine 和具體化檢視表可在此多用途架構中更加輕鬆提高效率和效能。

無伺服器資料解決方案絕對是必要服務，可幫助機構擺脫資料孤島，開始深入分析資訊並採取行動。我們所有的核心資料數據分析服務都採用無伺服器技術，並緊密整合。

在機構要採納任何新技術時，變更管理往往是最困難的一環。Google Cloud 提供開發人員和企業使用者熟悉的工具、平台與整合功能，希望能隨時隨地滿足客戶需求。我們的使命是讓機構攜手推動資料技術支援的革新，加速完成企業數位轉型及重新構思業務模式。Google Cloud 為公司提供多種選項，方便公司輕鬆整合地端部署環境、其他雲端服務，甚至是 Edge 來形成真正的混合雲，而非受制於特定廠商：

• 有了 BigQuery Omni，就不必將資料從一個環境轉移至另一個環境，而是在不同環境中直接分析資料
• Apache Beam 是在 Dataflow 上使用的 SDK，可為 Apache Spark 和 Apache Flink 等執行元件提供轉移能力和可攜權
• 對於想執行 Apache Spark 或 Apache Hadoop 的機構，Google Cloud 提供 Dataproc

大多數資料使用者重視自己擁有的資料，而非存放資料的系統。能否在需要時存取所需資料，是首要之務。因此，大部分情況下，平台類型對使用者而言並不重要，只要能使用熟悉的工具存取最新可用資料即可 (無論是探索資料集、管理各個資料儲存庫的來源、執行臨時查詢，或是開發適用於高階利害關係人的內部商業智慧工具)。

提到將資料湖泊和資料倉儲整合到統合式數據分析資料平台，還有一些其他資料解決方案越來越受到關注。舉例來說，我們已經看到許多與湖倉和資料網格相關的新概念。您先前可能已經聽過一些名稱。有些可能並非新名詞了，且多年來都以不同的形式發展。不過，這些概念卻能在 Google Cloud 環境中順利運作。讓我們深入瞭解資料網格和湖倉在 Google Cloud 中的樣子，以及這對機構內的資料共用的影響。湖倉和資料網格並不互斥，但可以協助解決機構內的不同難題。然而，一項是協助支援資料，另一項則是支援團隊。資料網格可幫助員工避免受到單一團隊阻礙，從而支援整個資料堆疊。這種框架會在架構中將資料孤島分割為多個小型機構單位，並透過聯合方式提供資料存取權。湖倉會將資料倉儲和資料湖泊整合在一起，以利處理不同類型與更大量的資料。此架構能有效採用讀取時建立結構定義，而非寫入前建立結構定義方式 (資料湖泊的特色)，如此將能彌補企業資料倉儲的某些效能缺口。另外一個好處是，這個架構也採用更嚴格的資料管理 (資料湖泊通常缺乏的功能)。

如上所述，BigQuery 的 Storage API 可讓您將 data warehouse 視為 data lake。在 Dataproc 或類似 Hadoop 環境執行的 Spark 工作可使用儲存在 BigQuery 中的資料，不需要透過 data warehouse 釋出儲存空間來使用個別的儲存空間媒介。只要將運算功能與 BigQuery 中的儲存空間分離，就能實現以 SQL 為基礎的轉換，並利用這些轉換中不同層級的檢視表。如此就能採用 ELT 類型方法，並打造更靈活的資料處理平台。BigQuery 可透過 ETL 使用 ELT，讓以 SQL 為基礎的轉換儲存為邏輯檢視表。雖然使用傳統 data warehouse，將所有原始資料轉儲到 data warehouse 儲存空間的費用可能相當高昂，但 BigQuery 儲存空間不需要額外付費。費用相當接近 Google Cloud Storage 中的 blob 儲存空間。

執行 ETL 時，轉換作業會在 BigQuery 外部進行，可能也會在無法擴充的工具中進行。此作業最終可能會逐行轉換資料，而不是平行執行查詢。在某些情況下，Spark 或其他 ETL 程序可能已經過編碼，若因採用新技術而改變程序，可能會導致流程不合理。不過，如果有可透過 SQL 編寫的轉換作業，BigQuery 可能是很適合執行這類轉換的地方。

此外，所有 Google Cloud 元件 (例如 Composer、Data Catalog 或 Data Fusion) 都支援這個架構。此架構提供了適用於不同使用者角色的端對端層。另一個重要層面是減少營運開銷，可以利用底層基礎架構的功能來實現。請考慮使用 Dataflow 和 BigQuery (全部在容器中運作)，並讓我們管理運作時間與背景機制。當此架構擴展至第三方與合作夥伴工具，且這些工具開始探索 Kubernetes 等類似功能之後，就可變得更加簡單管理和轉換。因此，就能減少資源和營運開銷。此外，您也可以搭配使用 Cloud Composer 和監控資訊主頁，藉此提升觀測能力，實現卓越的營運成效。您不僅可以整合儲存在 Cloud Storage 和 BigQuery 中的資料來建構 data lake，而且不必移動或複製資料，我們還提供額外的管理功能，方便您管理資料來源。Dataplex 提供集中式管理層，可協調 Cloud Storage 和 BigQuery 中的資料，進而實現湖倉。如此一來，您就能根據業務需求整理資料，不再受限於儲存資料的方式或位置。

Dataplex 是智慧型 data fabric，可讓您以適當的價格/效能持續分散資料，同時確保所有數據分析工具都能安全地存取這些資料。Dataplex 提供以中繼資料為主的資料管理功能，且內建資料品質與管理功能，讓您不必費時費力地處理基礎架構界線及效率低下的問題，信任自己擁有的資料，進而有更多時間從這些資料中創造價值。另外，此資料架構也提供整合數據分析體驗，結合 Google Cloud 和開放原始碼的優勢，讓您能夠快速收集、保護、整合及分析大量資料。最後，您可以制定數據分析策略，藉此強化現有架構和達成財務管理目標。

資料網格奠基於長久以來從資料倉儲和資料湖泊推動創新的經驗，結合無與倫比的擴充性效能付費模式、API、開發運作，並緊密整合 Google Cloud 產品。您可以透過這個方法，有效建立隨選資料解決方案。資料網格可分散網域資料擁有者的資料擁有權，而每位擁有者都必須以標準方式提供資料作為產品。資料網格還能促進機構中不同部門之間的通訊，以便與不同位置的分散式資料集進行通訊。在資料網格中，從資料產生價值的責任與最瞭解該資料的人員有關；換句話說，建立資料或將資料帶入組織的人員，也必須負責根據自己所建立的資料，建立消耗性資料資產作為產品。在許多組織中，要建立「單一事實來源」或「權威資料來源」並不容易，因為機構會反覆執行資料擷取與轉換，卻沒有負責對新建立的資料表示明確的擁有權。在資料網格中，具公信力的資料來源是指來源網域發布的資料產品，其中有明確指派的資料擁有者和負責該資料的管理者。

簡單來說，資料網格實現了網域導向的去中心化資料擁有權和架構。此架構需利用聯合運算技術和存取層 (例如 Google Cloud 提供的存取層) 來發揮作用。此外，如果您需要更多功能，還可以使用如 Looker 等工具來取得這些功能，這類工具可提供統一分層來進行資料建模和資料存取。Looker 平台提供單一窗格使用者介面，方便您存取最真實且最新的公司資料和業務定義。這種統合式資料檢視方法，可供您選擇或設計資料體驗，讓使用者和系統能以最符合其需求的方式取得資料。其廣泛的適用性，連數據資料學家、分析師，甚至是企業使用者，都能透過統一的語意模型存取資料。數據資料學家仍可存取原始資料，但資料不會被移動及複製。

我們在 BigQuery 等主力產品外，建構了更多功能，方便使用者輕鬆建立及管理資料集。Analytics Hub 提供建立私人資料交換的功能。由資料交換管理員 (又稱資料管理者) 授予發布和訂閱權限，以便與公司內部的特定使用者或群組交換資料，或是與外部的業務合作夥伴或買方交換資料。

BigQuery 具備的高擴充能力，可讓您發布、探索和訂閱共用資產 (包括開放原始碼格式的資產)。發布者可以查看匯總的使用指標。資料供應商可以為 BigQuery 企業客戶提供資料、深入分析、機器學習模型或圖表，並透過 Cloud Marketplace 利用應用程式、深入分析或模型獲利。這種做法也類似於透過 Google 代管的交換庫來管理 BigQuery 公開資料集。運用 Google 獨有的資料集、各種商業/產業資料集、公開資料集，或來自貴機構或合作夥伴生態系統的彙整資料交換內容，推動創新。

雖然從零開始打造全新的資料平台聽起來很棒，但我們也明白，不是每家公司都有能力這樣做。大多數公司仍需透過遷移、移植或修補等方法繼續使用原有的舊系統，直到有一天可以更換系統為止。我們會在資料平台歷程的每個階段與客戶攜手合作，為您提供符合需求的解決方案。

根據我們的觀察，客戶採用的遷移方法大致分為三類：直接移轉並更換平台、直接移轉並重新安置，以及全面翻新。對於大多數公司，我們建議採取直接移轉並更換平台的做法，因為這種做法不僅具有高遷移效益，並能盡可能降低中斷風險。採取這項策略時，您需要將資料從舊資料倉儲和 Hadoop 叢集遷移至 BigQuery 或 Dataproc。資料轉移完畢後，您就能針對資料管道和查詢效能進行最佳化調整。直接移轉並更換平台的策略可讓您根據工作負載的複雜度，分階段執行遷移作業。對於業務單位眾多且實施 IT 集中管理的大型企業客戶，由於複雜度較高，因此我們會建議採用這種做法。

第二種最常見的遷移策略是全面翻新。這種做法可讓您與舊系統一刀兩斷，因為您將在雲端從頭開始建構全新的資料平台。這是一個原生於 Google Cloud 的平台，不過由於您會一次翻新所有系統，所以如果您有多個大型的舊環境需要翻新，遷移速度可能較慢。

要與舊系統一刀兩斷必須重新編寫工作並更換應用程式。但與其他方法相比，這種做法能提供更優異的速度和敏捷性，且長期下來的總持有成本最低。這主要有兩個原因：第一，您的應用程式已完成最佳化，省下了升級改造的成本。第二，遷移資料來源後，您就不必同時管理兩種環境。這種方法最適合只有少數舊環境的數位原生企業或工程導向機構。

最後，最保守的做法就是直接移轉並重新安置。我們建議把它當做戰術性解決方案，方便您在短期內將資料資產遷移至雲端。您可以直接移轉並重新安置既有的平台，並在 Google Cloud 環境中繼續如常使用它。此方法適用於 Teradata 和 Databricks 等環境，可降低初始風險並能確保應用程式繼續運作。但這樣做只是將原有的孤立環境移入雲端，而不是轉換環境，因此無法享有在 Google Cloud 上建構原生平台所帶來的效能與效益。然而，我們可以協助您將資料完全遷移至 Google Cloud 原生產品，讓您能善用互通性的優勢，在 Google Cloud 上建構一個完全現代化的數據分析資料平台。

我們認為，在 Google Cloud 上建構的數據分析資料平台，具有開放、智慧、彈性與緊密整合等與眾不同的關鍵優勢。市面上有許多解決方案是戰術型解決方案，以熟悉、容易適應為其特色。不過，這些解決方案通常只提供短期的快速戰術，容易隨著時間推移衍生出複合組織和技術問題。

Google Cloud 大幅簡化了資料分析作業。您可以運用雲端原生的無伺服器方法，將資料儲存空間與運算資源分離，充分發揮資料的隱藏潛能，在幾分鐘內分析 GB 至 PB 規模的資料。如此一來，您就能突破規模、效能和成本等傳統限制，詢問各種資料相關問題並解決業務上的難題。於是，企業便能更輕鬆地運用可靠的單一 data fabric，獲得重要的企業洞察資料。

有哪些優勢？

• 讓您能夠全心投入數據分析工作，不必擔心基礎架構問題
• 可處理資料分析生命週期各階段的作業，從擷取、轉換和分析到商業智慧等等
• 造就穩固的資料基礎，便於導入機器學習技術
• 讓機構有能力運用最先進的開放原始碼技術
• 可依企業需求調度資源，促進資料使用，以利推動業務及進行數位轉型

在　Google Cloud　上建構的現代化整合式數據分析資料平台，除了可讓您享有 data lake 和 data warehouse 的最佳功能外，還能與 AI 平台緊密整合。您能自動處理數十億個串流事件的即時資料，甚至能在幾毫秒內取得資料洞察分析，以迅速因應不斷變化的客戶需求。我們領先業界的 AI 服務能最佳化決策制定和客戶體驗，協助您縮小描述性分析與指示性分析之間的差距，不必另外組建新的團隊。透過內建的自動化智慧功能強化現有技能，充分發揮 AI 的效益。