資料的未來發展：全面統合、靈活彈性、易於存取

資料很重要，這一點顯而易見，但從資料中擷取出創新的業務與客戶深入分析結果，對多數公司來說極具挑戰。 充分運用資料代表什麼意思？ 為什麼這是一大挑戰？

充分運用資料，意味著您可以根據資料，來制定產品和作業等方面的決策。 不妨思考以下幾個問題： 您知道客戶的期望有哪些變動嗎？ 您要運用資料來提升客戶體驗嗎？ 就這項挑戰而言，請想想看貴機構的資料工程師和數據資料學家，目前將時間投注於哪些事務上。

掌握「資料」極其重要，就能推動產品的革新方向、提升使用者體驗，並制定各種市場開發決策。 有效運用資料能為您帶來莫大的競爭優勢， 這也是為什麼多數的科技和新創公司都承受著極大壓力，不得不付出更多心血與努力，包括採用最新技術與執行相關作業來因應日趨龐大的規模、針對目前和未來的資料支出證明投資的必要性，以及提升機構成熟度和決策能力。

不過，由於存取、儲存空間、法規遵循和安全性等方面都有棘手的問題需要克服，使用的工具也不一致，導致機構難以深入挖掘資料，無法讓資料發揮真正價值。

也許您在沿用舊版系統後，又想搭配使用新的系統。 那麼，所有資料都應該集中放在同個雲端嗎？ 還是應該分散到多個雲端？ 如何翻新先前已垂直整合的數據分析堆疊，以便與可橫向擴充的平台搭配使用？

或者，您目前是以批次或微批次的方式處理資料，而非即時處理。 最終的自動化調度管理系統和排程方式，會讓架構變得更複雜；為了解決爭用情況及保有彈性，還得費心維護。 批次架構的管理和維護會產生極高的作業成本，而且您還是會受到資料延遲的影響。

無法輕鬆存取所有資料、缺乏即時處理和分析資料的能力，均會讓您處於劣勢。 現代化的技術堆疊必須是串流堆疊，才能跟上資料的規模、使用最新的可用資料，並整合及瞭解非結構化資料。 此外，最先進的數據分析團隊運用 AI/機器學習技術來進行實驗和處理，將重心從營運轉移到實際行動。

讓資料為您完成工作代表什麼？您就能運用資料提升客戶體驗、觸及新客戶並提高業績。 最主要的重點在於能夠推動革新。 如果想達到這些成效，建議您根據以下兩個原則來選擇資料平台。

原則 1：簡單易用且可擴充

您現在可能有大量資料要處理， 資料量或許會以指數方式急遽增加，您必須維持或提升投資報酬率，同時還得負荷持續增加的資料量。 也許您已預測到未來會有多少資料 (例如達到 TB 規模)，然後設計系統來處理這些資料，同時也有心理準備，如果資料量成長超出預期，您就會考慮進行全面的系統遷移。或者，您可能已選用合適的 data warehouse，能因應預期的成長幅度，但持續增加的處理需求，仍會導致管理作業變得相當複雜。

較小型的系統通常比較容易。不過，您不必再掙扎該選擇易於使用的系統，還是具備高擴充性的系統。 採用無伺服器架構可省去叢集管理作業的麻煩，並且能夠處理大規模的運算和儲存作業，無須擔心資料大小超過技術負荷能力。

如果想要簡單易用又可擴充的系統，建議您採用無伺服器資料平台， 捨棄所有需要安裝軟體、管理叢集或調整查詢的方案選項。

原則 2：提高靈活性並降低成本

只要採用結合運算和儲存服務的資料管理系統，您就必須擴充運算資源來因應資料量持續增加的問題，即便您不需要這些資料也是如此。這可能會產生高額成本，而您或許會有所妥協，例如只將最近十二個月的資料儲存在數據分析倉儲中。 您可能也會因為資料不會立即派上用場，而選擇不要納入資料，但最終卻發現無法進行假設測試，因為資料在其他地方，且必須建立新的管道才能開始使用。

其他系統則只能帶來一半的效益，可讓您單獨針對運算和儲存作業進行擴充與購買這些服務/資源，但您還是得手動設定和擴充叢集，以及進行最佳化調整。 如要盡可能減少基礎架構管理工作，請考慮採用可靠性、效能表現更優異，且內建資料保護措施的無伺服器多雲端 data warehouse (例如 BigQuery)。

除了成本與管理作業之外，也應該考量靈活彈性。 如果資料有所變動，要過多久您才會注意到這個情況並做出回應？ 當您使用的某些軟體或特定工具有新版本推出時，需要多久時間才能掌握新功能？ 提高靈活彈性的方法是選擇有彈性、較不需操作且適用於各種工作負載的工具。

Redshift 等系統的查詢功能必須經過最佳化調整，效率才會提高， 但這樣會導致可進行的實驗數量受限，因此您可能只有在懷疑有問題時，才會擷取和提取資料。 運算和儲存功能未區隔開來，再加上必須針對 data warehouse 進行最佳化調整，這種窘境使得您處處受限。

如果採用 BigQuery 這類服務，您就不必預先進行查詢規劃，或為資料集建立索引。分開的儲存和運算功能可讓您安心存放資料，不必擔心這樣會導致查詢費用增加，而數據資料學家也可以放心進行實驗，不需要在透過臨時查詢嘗試新的構想時，還得煩惱叢集或調整資料倉儲大小的問題。

我們已瞭解一套簡單、可擴充、有彈性又符合成本效益的平台，能如何協助您進行革新， 接下來要探討的主題，是資料如何幫助您實現目標。

業務營運的速度不斷加快， 而客戶的期望也有所改變。 以往有三天的時間可以進行交易對帳或核准退貨要求，現在卻需要立即給出答案或回應。 制定決策必須更快更即時，因此更需要使用串流功能。

您希望能夠即時擷取資料，然後提供資料給業務團隊，方便他們進行低延遲的查詢作業。此外，您也想確保串流管道能夠擴充、具備彈性，而且幾乎不會帶來什麼管理負擔。 唯有滿足這些條件，您的團隊才能配合業務的腳步即時做出回應。 BigQuery 具備原生串流資料擷取功能，且能立即提供擷取的資料，以便相關人員透過 SQL 進行分析，相信您對這一點不會感到意外。 除了運用 BigQuery 易於使用的串流 API 之外，Dataflow 也能讓您有效管理季節性與激增的工作負載，而不必擔心超支。

許多機構下的部門和業務單位會分別儲存資料，每個團隊也擁有自己的資料，最終常形成一座座資料孤島。 因此每當需要進行跨部門分析時，就得找出方法突破這些藩籬，例如執行擷取 (ETL) 管道以取得資料，並將這些資料傳入 data warehouse。但是，擁有資料的部門通常沒什麼動力維護管道；經過一段時間後，這些管道就會過時，而傳入的資料也會變得較舊、較不實用。

為突破機構中的隔閡，許多公司目前都已根據部門偏好、能力協調及監管壓力採用多雲端策略。 這些公司往往也要處理在地端部署環境中執行的舊版 data lake 和 data warehouse 設備。在現今環境中，要發揮多雲端和混合雲的效益，需要更精細的管理機制，而且還要能存取互不流通的資料。

如遷移至有共通控制層的分散式資料倉儲 (有時又稱為「資料架構」或「資料網格」)，您就比較能夠跨部門、雲端和地端部署系統存取高品質資料。這可以解決產品效能或客戶行為方面的業務問題，也能讓您即時查詢資料。

BigQuery 為這類的資料網格提供技術基礎，無論機構中擁有這些資料的是誰，整個機構的使用者都可以管理、保護、存取及分享資料資產和深入分析結果。舉例來說，您可以將所有資料傳送至 BigQuery，並提供可重複使用的函式、具體化檢視表，甚至讓使用者在不移動任何資料的情況下訓練機器學習模型。 也就是說，即使是非技術領域專家 (以及擁有權限的合作夥伴和供應商)，都能透過試算表和資訊主頁等熟悉的工具，輕鬆存取資料並使用 SQL 查詢資料。

這裡適用「中樞和輪輻」的類比。BigQuery 是容納資料的中樞， 輪輻則是報表工具、資訊主頁、機器學習模型、網路應用程式、推薦系統等，這些元件全都可以從 BigQuery 即時讀取資料，而且不必複製資料。舉例來說，Looker 可協助您以視覺化的方式呈現資料，並將資料整合至使用者的日常工作流程。 這個方法可讓您同時提升資料的可用性、安全性和品質。

以往，最適合用來儲存非結構化資料和半結構化資料的工具是資料湖泊，而結構化資料則最適合存放於資料倉儲。 這樣的區隔造成技術上有所隔閡，如此一來，想要跨越格式分歧的鴻溝就顯得困難重重。您會將所有資料都儲存在 data lake 中 (因為成本較低且較易於管理)，然後將資料移至 warehouse，以便使用數據分析工具擷取深入分析結果。

「lake house」現在越來越受歡迎，將這兩個世界合併為一個統合環境，供所有類型的資料使用；您可以將 BigQuery 同時做為 data warehouse 和 data lake 使用。BigQuery 的 Storage API 可讓您直接存取儲存空間，以便支援通常與資料湖泊相關聯的工作負載。 由於資料可儲存在 BigQuery 中做為單一可靠的資料來源，因此需要建立及維護的副本較少。 您可以改為透過儲存在邏輯檢視表中的 SQL 轉換功能執行下游處理作業，而不必移動資料。

工具是否簡單易用相當重要，如果可以在 30 秒內透過查詢取得結果 (而不需 30 分鐘或 3 小時)，就有可能更充分地運用資料來輔助決策。

您的數據資料學家能以多快的速度完成實驗？ 他們很可能得先放下開發工作，然後執行模型，才能評估實際使用者的實驗結果。 他們會運用歷來資料來開發及疊代模型，再將模型交給工程師。工程師通常會重新編寫模型，以便將模型納入實際工作環境系統並執行 A/B 測試。 然後，他們會再次進入以下這個循環：等待、進行模型疊代，然後將模型推送至實際工作環境。 這個循環包含許多停滯點，而且還得不斷重新編寫程式碼，而在過程中，出現錯誤的團隊也需要經過層層的協調。 以這種方式進行實驗可能會需要極長的時間，因此數據資料學家無法做那麼多的實驗。 在這種情況下，光是預測專案完成要花多久時間及是否會成功就相當困難了，更不用說要預估需要多久時間才能進入日常應用階段。 為了突破這個窘境，您必須為數據資料學家提供強大而熟悉的工具。 Vertex AI Workbench 可讓數據資料學家在 Jupyter 筆記本中有效地執行工作，同時享有加速訓練、快速實驗和快速部署功能。

如果您希望能根據資料創造優勢，就得從收集到的資料中擷取出最高的價值。 為達成這個目標，您希望數據資料學家團隊盡可能提高工作效率，同時把握任何建立模型的機會，因為即便是簡單的事情，也可能耗費太多時間或難以執行。

預先建構的低程式碼模型品質非常重要。 Vertex AI 上的 AutoML 可在無程式碼的環境中提供最頂尖的 AI 模型，讓您快速完成基準化與排定優先順序。使用自己的資料預先建構模型 (例如實體擷取或 Vertex AI Matching Engine)，可大幅縮短從資料創造價值的時間，您也不會再受限於只能進行分類或迴歸。

如要維持資料的靈活彈性，關鍵就在於盡早進行端對端實驗，而且要頻繁地執行這項作業。 Vertex AI Pipelines 提供實驗記錄，方便您回顧、根據基準和端點進行比較，以及利用陰影模型進行 A/B 測試。由於程式碼已容器化，因此開發與實際工作環境系統皆可使用同一組程式碼。 數據資料學家在 Python 中工作，而實際工作環境工程師則會有全面封裝的容器可以使用。 這兩個團隊可搭配 Vertex AI Prediction 執行模型，達到標準化的目標，而您也可迅速採取行動。

領域專家通常可以透過 BigQuery ML 訓練自訂模型，藉此測試構想的可行性，而且只要使用 SQL 即可，不需要有額外的傳統數據資料學工具使用經驗。這表示，您可以在類似實際工作環境的系統中做實驗，並且進行可行性研究，只要在短短幾天內即可完成，不必花費數個月的時間。 您可以將 BigQuery ML 模型部署至 Vertex AI，就能體驗到我們剛才討論的各種好處。 您可以使用 Looker 以所有資料為基礎建立一致的資料模型，並使用 LookML 查詢資料，也就是說，貴機構的所有使用者皆可建立容易閱讀的報表和資訊主頁，以便探索資料模式。

如要在實際工作環境中創造實際價值，系統必須要能夠擷取、處理及提供資料，而機器學習功能也必須根據客戶的情境讓系統即時提供個人化服務。 不過，如果要讓實際工作環境應用程式持續運作，就必須不斷地重新訓練和部署模型，並且檢查模型是否安全無虞。 傳入的資料需要預先處理及驗證，確保沒有任何品質問題，接著是進行特徵工程，並搭配超參數調整進行模型訓練。

機器學習工作流程包含多個階段，如要輕鬆地自動化調度管理及控管，並穩定地反覆執行這些流程，就必須整合數據資料學和機器學習技術。 機器學習運作工具和自動化工作流程可讓您快速持續推送軟體更新，並簡化將模型導入實際工作環境的管理作業。無論抽象層為何，我們所有的 AI 產品使用的都是同一套工作流程和詞彙，而且自訂模型和 AutoML 模型採用的格式和技術基礎都相同，因此您可以輕鬆交替使用這兩種模型。

舉例來說，如果您想要對不受限的即時資料串流套用異常偵測措施，以便防範詐欺，該怎麼做？ 透過採取適當的做法，您就能產生範例資料串流來模擬常見的網路流量，並擷取至 Pub/Sub，接著在使用 DLP 遮蓋個人識別資訊 (PII) 之後，運用 BigQuery ML k-means 分群法在 BigQuery 建立及訓練異常偵測模型。完成這些步驟後，您就能透過 Dataflow 將模型套用至即時資料，以便進行即時偵測，並且透過 Looker 建立資訊主頁、快訊和動作來處理系統發現的事件。

我們已經討論過 BigQuery 和 Redshift，但並不是只有這些 data warehouse 方案可以選擇。還有其他三大主要雲端平台都適用的資料分析產品 (例如 Snowflake 和 Databricks)。 所以，如果選用 BigQuery，會有受制於特定雲端廠商的問題嗎？

首先要提醒您，BigQuery 不只能分析儲存在 Google Cloud 中的資料。 BigQuery Omni 可讓您透過 Google Cloud 控制台以順暢無礙的方式查詢 Amazon S3 和 Azure Blob 儲存體中的資料。

不過實際上，如果使用 Snowflake 或 Databricks，從 AWS 遷移至 Google Cloud 的轉換費用較低，反之亦然。 那麼如果要遷移至其他 data warehouse，需要多少費用呢？如果想從 Snowflake 遷移至 BigQuery，或從 Databricks 遷移至 EMR，又會是什麼情況呢？ 這只是情境上的差異，其實還是都得支付轉換費用。

無論在哪一種情境下都會產生轉換費用，所以您最終還是必須選擇長期適用的工具或平台。 您可以先確認特定平台有哪些獨家功能/特色、目前的費用是多少，以及該平台之後加入創新功能/技術的速度，然後再根據這些資訊做決定。 如果選用 Snowflake，就是確信這家以 data warehousing 為重心的公司，能更快速帶來該領域的創新技術。如果選用的是 BigQuery，就表示您信賴這家以創造許多資料和 AI 技術聞名的公司，相信他們會持續在這個平台上推動革新。

我們相信，經過妥善整合的創新平台，能更有效地激發革新的飛輪效應。 Google Kubernetes Engine (GKE) 等代管服務產品可加快容器映像檔的載入速度，能幫助無伺服器 Spark 更有效地運作，而且無伺服器 Spark 可在 BigQuery 中對資料執行作業，這一點更突顯了 BigQuery 的價值。如果您選擇將重點放在平台，而非個別產品上，就能讓創新的飛輪以更快的速度轉動。

如果是在不同雲端間進行遷移，可能會比從地端部署系統遷移至雲端來得輕鬆省事，這是因為無論如何，地端部署系統的技術深度通常會高上許多。這時著重的目標就是「創新速度可以多快？」

請思考所有您想進行，但目前還未進行的革新工作，然後設定新專案，並移轉執行這些專案所需的資料。 我們可協助您建構這些新的用途，然後針對您所需的資料來源建立鏡像。 在此期間，您將會處於混合式環境，且許多用途都是在地端部署環境中運作，但其所用資料是由系統即時反映、從您的地端部署環境批次建立或來自您的其他雲端服務供應商。

您的第二層考量是成本。 看看您使用的那些昂貴的 Teradata 執行個體。 我們發現客戶改用 BigQuery 後，成本縮減了一半，而且現在有自動化評估工具和自動化 SQL 轉譯器的輔助，能轉換大多數的指令碼，所以遷移作業比以往來得簡單多了。 我們有辦法透過虛擬化的方式，讓您的客戶實際在和 BigQuery 互動時，覺得自己是在和 Teradata 互動。 我們可以透過許多方式協助您進行遷移，而且不必把所有服務/資源都關掉。您可以運用相關的遷移工具完成遷移，擺脫昂貴的 Teradata 和 Hadoop 工作負載。

第三個考量重點是檢視您的 ERP 系統，例如 SAP、Salesforce 系統和 Oracle。 如要將供應鏈調整到最佳狀態、進行待開發客戶評分或偵測詐欺行為，請務必將數據分析工作負載連結至 ERP 系統。 我們可以使用第三方連接器，從這些系統取得資料，然後利用這些資料在雲端中建構採用 AI 技術的現代化用途。

這些工作進行的順序取決於您的情況。 如果貴機構為新創公司，可能就會先從革新開始著手，接著再進行成本最佳化，最後則是善用現有的管道和連接器。 如果您的業務非常需要仰賴供應鏈，也許就會先從 ERP 連接器開始處理。 無論這三件事的執行順序為何，您都會發現自己成功將大量寶貴的資料資產移至雲端。 現在看看還剩下什麼，然後再思考剩下的部分究竟是否值得遷移。 答案通常會是否定的，遷移完 70-80% 真正必要的工作負載後，您就需要做出艱難的決定。剩下的 20-30% 值得遷移嗎？還是應該考慮重新編寫程式碼，或是以不同的方式執行該工作？您不會想進入「將一切原封不動地移至雲端」這個模式，否則就等同於將在地端部署系統欠下的所有技術債都複製到新的雲端環境中，而不是將重心放在資料價值上。

我們談論了許多有關資料運用的重點，也說明了資料運用真正的意義，以及在遷移至雲端 data warehouse 時可能需要考量的事項。

如要進一步瞭解 Google Cloud 能如何協助您針對資料與 AI 的使用方式進行最佳化調整，根據深入分析結果掌握重大優勢、協助貴公司降低成本，以及提升工作效率，請與我們聯絡。

其他資源

• 瞭解在資料處理方面貴公司屬於哪種類型
• 分析資料平台的建構方式取決於貴公司屬於何種類型的機構，如要進一步瞭解相關元素，請參閱這份白皮書。