Google Cloud 資料處理解決方案介紹

這一篇我們介紹如何運用GCP的infrastructure實現data engineering與機器學習，例如根據你的業務需求選擇適當的compute service; 設計整個解決方案的scalability, reliability, availability,與可維護性。使用hybrid與edge 運算架構模式與流程模型.最後介紹如何將你地端機房 的Data warehouse服務轉移到GCP上。

設計Infrastructure

我們如何根據我們的需求來選擇正確的GCP infrastructure;怎麼設計GCP infra能達到 scalability, reliability, availability, and maintainability; 以及如何將bybird and edge computing的能力囊括到我們的設計中。

選擇Infrastructure

GCP提供了以下六種選項的電腦運算:

• Compute engine
• Kubernetes engine
• App engine
• Cloud function
• Cloud Run(本篇不討論)
• Anthos(本篇不討論)

Compute engine

這是GCP提供的IaaS服務(就是Virtual machine)。這個提供了我們對機器在GCP上最大的控制權。從自選機器的規格到要安裝自己的軟體跟選搭GCP提供的安全功能(Shielded VM )與加速功能(GPUs),通常使用這種加速功能的大都會是Machine Learning或運算資源需要吃很兇的Application.

VM為了達到HA與scalability把它們group在一起一個cluster。這一群VM會有著完全相同的配置，就會像管理一台單一的VM一樣，在GCP稱為 managed instance group. Configuration中可以設定最大跟最小的instance. instance 的數量會根據工作負載來scale up or down.

如果你Application 需要到VM(OS)層級的控制權或是你想自行管理OS, compute engine是一個好的選擇。

Kubernetes engine

這是一個託管式的K8s服務在GCP稱為。K8S是一個open source platform(這是由Google發展出來的)。GKE在GCP的運作底層是compute engine，但是我們不需要去管理Compute engine(OS layer),因為剛剛說了這是一個託管式服務。

運作在GKE上面的Appkication幾乎都是Microservices, 意思是Application運作時不需要哪麼大的運算資源，需要運算時間也可能很短。這種使用方式可以很有效的利用運算資源。或者，如果Microservices部署在具有完整 vCPU 的 VM 上，則 vCPU 將無法得到充分利用。 這讓開發人員可以選擇容忍低效利用或在同一虛擬機上運行額外的Microservices。 這種方法有其自身的缺點。 除非所有Microservices都具有相同的生命週期，否則你可能會發現對一個Microservices進行維護可能會中斷其他Microservices的運行。

通過將Application component分離為Microservices並在它們自己的container中運行這些Microservices，我們可以提高資源利用率，並可能使Application更易於維護和更新。

Kubernetes 的另一個優勢是它可以在多種環境中運行，包括其他Cloud provider和on-premises Datacenter。 Kubernetes 可以檢測 Pod 中的container何時無法正常運行並替換它們。 Kubernetes 還可以scale up and down Pod 的數量以適應不斷變化的工作負載。

也許 Kubernetes 最重要的限制是Application必須容器化才能在 Kubernetes 上運行。 如果在VM中運行的現有Application正在遷移到Cloud，那麼系統架構不變的直接遷移遷移到 Compute Engine 可能是遷移到Cloud的最快方式。 在Cloud 中，我們可以容器化我們的Application。

App engine

這是一個PaaS服務。這是讓開發人員不用管理Infra(或是公司內沒有Infra 人員)直接將code放上去跑即可。App engine有兩個版本: Standard and Flexible.

Standard版本，這個serverless平台support特定的語言來運作，像是Go, Java, PHP, Node.js, Ruby, and Python。standard版本有兩種形式，第一代與第二代。不同的地方在於第二代support 更多的memory與runtime的選擇。

Flexible版本跑的是Docker containers. 這時候就沒有standard版本一樣有runtime的限制，我們可以部署自己的runtime.因為我們是運行自己的Docker image, 所以可以安裝自己的libraries 跟package. Flexible版本也提供health check功能與在底層的OS自動上Patch.

Cloud function

這是一個serverless的服務(跟AWS Lambda一樣),是以event base機制來trigger其運算。這類的Event可能是有message被寫入Cloud pub/sub topic或是有檔案被upload到cloud storage. cloud function support的event還有HTTP, firebase, stackdriver logging.

在這些支援的服務中cloud function回應的都是特定的事件，像是cloud storage 的檔案的上傳/刪除/歸檔。 Http event就是 GET/POST/PUT/DELETE/OPTIONS這些操作。

Cloud Functions 是使用 JavaScript、Python 3 和 Go 編寫的。

當我們需要執行code以回應隨時可能發生的event（例如上傳文件或調用 Webhook）時，Cloud Functions 是一個不錯的選擇。 它們在使用 Cloud Pub/Sub 提取data時也很有用，例如在 IoT ingestion pipeline中。

下圖為以上介紹的四種電腦運算資源總結

Infrastructure的 Availability, Reliability, Scalability

當我們在設計系統時需要考量到非功能性的需求，哪就是系統的: scalability, reliability, availability。

Availability定義為User在特定時間訪問資源的能力。 Availability通常以系統運行的時間百分比來衡量。

Availability是Reliability的函數，availability定義為系統在一段時間內滿足服務水平目標的概率。 Reliability通常用平均故障間隔時間來衡量。

Scalability是系統通過根據需要向系統添加資源來處理工作負載增加的能力。 這意味著隨著工作負載的增加，資源將可用於處理該工作負載。 這也意味著隨著工作負載的減少，分配的資源量將減少到足以滿足工作負載加上一些額外容量的水平。

讓電腦資源擁有Available, Reliable, and Scalable的能力

HA與scalable的電腦資源通常會伴隨著Cluster的架構或是VM伴隨著前端有Load balancer與autoscaler的功能來分散工作負載，與調整cluster的size來滿足工作負載。

Compute engine

如果你要對Compute engine(VM)達成有Availability, Reliability, Scalability的能力就需要使用managed instance groups(MIGs). MIG是用template 來定義的。這個template會明定machine type, boot disk image or container image, labels, 跟其他 instance properties.所有在MIG裡的VM都是完全相同的。

當 MIG 中的一個instance出現故障時，它會被一個配置相同的 VM 替換。 此外，有時可能會出現instance正在運行但Application無法正常運行的情況 — 例如，如果發生嚴重錯誤。 在這些情況下，可以使用特定於Application的運行狀況檢查來與檢測問題並替換instance。

Load balancer僅將網路流量導向到有回應的instance，並且它們使用運行狀況檢查來確定哪些instance可用於接受網路流量。 Load balancer可以是Global or regional，有些是專為internal流量設計的，而另一些也適用於external流量。

Global LB 是 HTTP(S) balancing、SSL proxy和 TCP proxy。 Regional LB支援network TCP/UDP、internal TCP/UDP 和 internal HTTP(S)。 Global LB可用於跨region分配工作負載，進一步提高Application的availability和reliability。

instance group可以是zonal or regional。 在zonal instance group中，所有instance都在同一zone中被create。 regional instance group將instace放置在同一region的多個multiple zone 中。 multiple zone提供更高的HA，因為 MIG 可以承受zone level的故障並且Application將繼續可用。

Autoscalers 根據工作負載add 和remove instance。 使用autoscaling時，我們可以create一個policy來指定調整 instance group大小的標準。這些標準包括 CPU 使用率和 Stackdriver 收集的其他指標、load-balancing capacity 以及queue中的message的數量。

需要注意是，當我們使用 Compute Engine 時，我們對自己的instance擁有最大級別的控制權，但我們還需要負責配置託管的instance、LB和autoscalers。

Kubernetes engine

Kubernetes 旨在支持cluster中運行的container和Application的Available, Reliable, and Scalable。 Kubernetes 在稱為 pod 的抽象層(abstraction)中部署container。 當 pod 出現故障時，它們會像託管instance中的故障instance一樣被更換調。 Kubernetes Engine 中的node屬於一個pool，開啟自動修復功能後，故障node將自動被更換掉再產生一個新的node。

Kubernetes Engine 還可以通過其他方式增強high availability and reliability。 使用 Kubernetes Engine 時，我們可以指定access cluster的endpoint是zonal的還是regional的。 在後一種情況下，即使zone出現故障，我們還是可以訪access cluster。 此外，我們可以指定跨多個zone複製master node和worker nodes的高可用性cluster configuration。

App engine and Cloud Function

App Engine 和 Cloud Functions 等serverless服務的一個關鍵優勢在於，它們的設計本身就具備highly available, scalable, and reliable。

在 App Engine 中，當scheduler 有request時，它可以將其發送到現有的instance、放到queue中或啟動一個新的instance，具體取決於我們配置 App Engine 的方式。 使用 App Engine，我們可以選擇scaling的configuration policy。 這是通過指定target CPU 使用率、target through 使用率和maximum concurrent requests來完成的。

Cloud function的設計使cloud function的每個instance一次處理一個request。 如果工作負載激增，則可以create額外的function instance。 我們可以通過設置maximum number of concurrently來對此進行一些控制。

讓Storage resource擁有Available, Reliable, and Scalable的能力

GCP提供多種樣態的storage system, 從in-memory cahce到歸檔的storage.以下為一些範例

Memorystore 是一種in-memory Redis Cache. Standard Tier是自動會在不同的zone有replica. Replica的機制是具有HA的特性，但是沒有scalability. Replica被啟動的時間點是當Redis偵測到failure 後就會faiolver到replica去。

Persistent disks是用在Compute Engine and Kubernetes enginer，簡單來說就是Server的硬碟部分。不過在GCP的底層是以NAS的形式掛載上去的。Persistent disks也內建的redundant 機制，所以具有HA與reliability的特性存在。所以我們也可以對disk做snapshot,並且儲存到clous storage中。也可以用這一份snapshot來做備份。

Cloud SQL是一種託管式的RDBMS。我們也可以針對Cloud SQL設定HA，這個HA機制會在不同的zone 啟用一個standby instance. 資料在primary and standby instance會不斷保持資料同步。但這種兩個instance 之間的資料同步僅限於在同一個region,若要跨region做RDBMS的資料同步就需要用到Cloud Spanner.

Cloud storage在設定時你就可以設定它是regional level或是multi-regional 的storage達到資料在兩個region的資料同步。

讓Network resource擁有Available, Reliable, and Scalable的能力

網路資源就需要要其他的resource之前提前規劃availability, reliability, and scalability.

GCP提供了兩種的網路選擇，Standard and Premium Tier. Standard 用的是Public Internet在兩個Google datacenter間做資料傳輸，而Premium用的就是Google自己全球的私有網路。所以你的資料在這兩種網路間傳輸的可靠性就當下立見。

Network interconnects則是用在連接你的on-premises datacenter跟Google cloud. 屬於網路專線的一種，網路專線是一種不能說馬上能scale up or down的服務，需要時間等待。Network interconnect提供的是大頻寬(10G起跳)，但若你的需求不需要這麼大用量可以考量用VPN來取代network interconnect，VPN最高可以提供3Gbps的流量(你的地端機房要先有哪麼高的網路頻寬)。以上這兩個服務有兩種做法來連接你的地端機房到GCP來達成網路的HA機制，一種是network interconnect 為primary 而VPN為standby.或是你用兩套VPN(在地端你要有兩個獨立的VPN device) 來互為備援，在GCP這一端也是用兩個不同的Public IP來連接。這種方式提供了 99.99% availability, 而一般標準的VPN連接GCP只有99.9的SLA.

上面提到的Network interconnect, 10Gbps起跳的專線. VPN連線，最高3Gbps(還要扣掉一堆network overhead跟Public Internet). 在這兩種之間，GCP提供了第三種選擇叫做 partner interconnect, 這是一種Google將網路接給ISP，再由ISP轉接給你。很像網路的分包方式，就是你不需要10G的網路專線但是又想要網路專線連到GCP上。這時就由ISP統包在分給底下的客戶。這樣可以達到網路較高的安全性(比VPN強一些)，高速 (3G-10G之間)的網路。

Hybrid Cloud and Edge computing

為了達到資源有效利用跟不要被同一個cloud provider lock-in，這兩種做法很多企業都會做。在Hybrid Cloud的方式中，企業的交易型DB(RDBMS)通常在他們自己的地端機房。而分析平台(資料分析)功能則搬上了Cloud. 這種情況中，當兩端之間的網路不穩或頻寬不夠時，我們就會使用edge-based computing的方式來解決。

使用Hybrid Cloud的方式來處理分析作業

這是剛剛提及的，將交易型DB放在地端機房同時將資料不斷的送往位在Cloud 的分析平台。此種作法非常具成本效益，因為在地端的機房的交易型DB只要平台在運作都會使用到(電商平台更是24時運作)。所以你在地端機房的機器ROI是很高的。不過資料分析可能不是每天每小時都在進行的(除非你的公司很大或是靠這個吃飯的)，將分析平台搬上Cloud同時可以有兩個好處。你只需要花費每次分析資料的運算費用(不用扛機器投資)，另外當你有時資料特別帶多時不用擔心資源不夠(你在地端機房的機器是固定的可能有時無法扛下突然暴增的資料)。

GCP提供以下的一些Services來達成整個data lifecycle的分析過程。

• Cloud storage for batch storage of extracted data
• Cloud Pub/Sub for streaming data ingestion
• Cloud dataflow and Cloud Dataproc for transformation and analysis
• Cloud BigQuery for SQL querying and analytic operations
• Cloud Bigtable for storage of large volumes of data used for machine learning and other analytic processing
• Cloud datalab and Cloud data studio for interactive analysis and visualization

當你想migrate 你地端的Hadoop and Spark jobs時，Cloud Dataproc能提供完全的support. 地端使用的HDFS filesystem則由Cloud storage來support. 如此Dataproc就可以像Hadoop access HDFS一樣來access Cloud stroage.

若你要開始將大量的資料傳送到GCP的data warehouse or Data lake中則可以使用 Cloud Transfer Appliance; 如果你的對外頻寬是足夠的，小量的data warehouse and data mart資料則是可以透過此方式傳送。

但多少資料要用甚麼樣的方式傳送到GCP可以參考GCP的storage transfer service更詳細的參閱此類資訊。

Edge Cloud

hybrid cloud其中的一種形式是Edge cloud.這是一種將運算資源放在地端。這架構就是因為你的網路資源要連到Cloud是不穩的或不足的。同時它也是用在需要low-latency 的資料處理需求時(先在地端做一部分的資料處裡)，如下架構。

上圖中我們可以看到一個IoT的SPC系統(具有ML功能的)收集製造設備的資料來偵測異常狀況。在網路資源不穩或不足時，而異常訊號又需要被很快偵測到時此種架構就非常有用。ML的執行功能由Cloud轉移到Edge端。

設計分散式資料處理

分散式資料處理提出了在單一server上執行處理時沒有發現的挑戰。 首先，我們需要跨多個服務器共享資料的機制。 其中包括message brokers 和message queue，統稱為middleware。 進行分散式資料處理的方法不止一種。 一些常見的架構模式是service-oriented的架構、Microsergvice和Serverless功能。 分散式系統還必須應對重複處理和data無順序到達的可能性。 根據需求，分散式處理可以使用不同的事件處理模型來處理重複和亂序processing。

分散式處理: Messaging

對分散式處理系統的components進行分類的一種方式是將資料從一個 component的process移動到另一個component的process(可能是執行transform or data store). Message brokers and Message queues屬於前一類(data move), 而middleware則屬於後者(transform / data store).

Message Brokers

message brokers提供三種功能: message validation, message transformation, and Routing.

Message validation是要確認收到的資料的格式是正確的。例如資料格式被明定是要用Thrift or Protobuf(Protocol buffer). 這兩種格式都是被設計用來在不同的平台與開發語言之間共享資料的。例如，Java 可能以一種方式存儲結構化資料類型，而 Python 會以不同的方式存儲相同的邏輯結構。 軟體開發人員無需使用各自開發語言的結構共享資料，而是可以將他們的資料map到通用格式，這一過程稱為serialization。 然後可以將serialization的資料放在message brokers上並路由到另一個可以讀取message的服務，而無需了解有關source system中使用的開發語言或資料結構的資訊。

Message transformation是將資料從source system的資料結構轉換成其他系統可以使用的。當資料的source 跟consumer可以獨立異動時這一點尤其重要。例如，會計系統也許會改變銷售訂單的定義。在其他系統，如使用銷售訂單資料的data warehouse，每次source system 更改時都需要update ETL 過程，除非會計系統和data warehouse之間的message brokers實現了必要的transformation。在message brokers中應用這些transformation的優勢在於，除了data warehouse之外，其他系統可以使用轉換後的data，而無需讓自己的系統來做transformation。

Message brokers 接收message並使用message中的data時會來決定message要送到哪裡。Routing 是被用在Hub-and-spoken 類型的 message brokers.在Hub-and-spoken model中，message是在資料處理的中心點被決定送往哪個正確的位置。可以參閱下圖範例.

Message Queues

這是使用在兩個processes之間的非同步資料。在最簡單的狀況下一個processes將message寫到message queue，另一個process則讀取該message並將這個message在queues中刪掉。在某些狀況下同一條message會被不同的processes讀取。這種資料處理模式非常適合使用 publish / subscribe model.

在publish /subscribe model中，一個或多個processes 將message寫到queues中。例如IoT sensor 將資料寫到Queuees中. 而其他的sensor也可以些到相同的queues中。quques中的data可能會被多個processes讀取。例如，Sensor 1 可能會寫入一個名為 Monitoring Queue 的queues，處理服務的 Instance A 讀取message並處理資料。 接下來，Sensor 2 將一條message 寫入Monitoring queue，該message由consuming process的Instance B 讀取。 範例圖示如下。

Event Processing Models

Message queue 可以提供如何向consuming processes不同方式的訊息傳遞的保證。假設message queues是可靠的，並且寫入queues的message可用於被有需要的processes讀取。分散式系統也必須在不太理想的狀況下運作。例如，某些message可能會delay且資料是沒有順序的到達。在其他狀況下，Producing service 可能不會收到message是否收到的確認訊息，因為Producing service沒有收到確認訊息，因此Procduing service 會再次發送message,這樣會造成message在queues中有重複的現象。所以以下是queues可以提供的一些訊息保證:

At least Once Delivery 在這個狀況中，所有的message至少會傳遞到consuming service一次。盡管message可能會多次傳遞給同一個consuming service或不同的consuming service.

At Least Once, in order Delivery 這與上一個方式是一樣的，但是卻多了按照messages的時間排序的保證。但這會導致延遲處理的問題。因為message queue可能會因為等待遲到的data而將資料暫存在buffer，以便他可以按正確的順序發出。

Exactly Once 這個Model保證message只會被處理一次。如果message處理方式不是idempotent. 例如，如果一條message包括訂單中銷售的產品數量，並且該數量用於減少該產品庫存總數量，那麼重複的message會使庫存DB處於不正確的狀態，因為銷售的產品數量將減掉該產品庫存總數量一次。message queues and consuming processes 必須處理遲到或lost掉的資料。資料延遲的狀況下，message queue可以設定丟棄晚於一個threshold period的data. 這個稱為watermark。 watermark用在 stream processing，以幫助限制processes在執行操作資料前等待的時間，例如aggregate某個特定時間段的data.

分散式處理: Services

Message components(例如 message queue)負責在services之間移動data. 對data進行操作的服務有以下三種service model, 分別是 service-oriented architecture(SOA), Microservice, 與serverless functions.

Service-Oriented Architecture

SOA是一種分散式架構。由業務運營來驅動並能交付出業務價值的。通常，SOA 系統服務於離散的業務活動。SOA 的service是self-contained sets。service通常是獨立的，除了足以傳遞message外，不需要了解其他services的任合資訊。SOA系統通常是使用 Simple Object Access Protocol(SOAP), Common Object Request Broker Architecture(CORBA)，但今日Representational State Transfer(REST)已廣泛使用了。

Microservices

Microservice是一種分散式系統架構。 與其他分散式系統一樣，Microservice架構使用多個獨立的component和通用的communication protocol來提供Higher-level的業務服務。 Microservice通常與敏捷軟體開發實踐一起使用，包括頻繁部署。 Microservice旨在實現單一function。 這允許services彼此獨立地update。 Microservice也可以很容易地部署在container中。 獨立性和基於container的部署相結合，使Microservice非常適合實踐敏捷開發的團隊和組織。

Serverless Functions

Serverless functions就是不用再管container跟runtime。 借助serverless function，實現single function的code可以部署在 PaaS（例如 Google Cloud Functions）上，而無需配置conatiner。 serverless function仍然可以使用message queue和common messageing protocols，以便為希望專注於寫程式而不是系統管理的 DevOps 團隊提供更多的support。

遷移 Data warehouse

從最嚴格的意義上來說，Data warehouse是為了 BI reporting and analysis而組成的企業資料repositories. 就本篇文章討論的範圍來說，data warehouse會包括 extraction, transformation, and load scripts; views and embedded user-defined functions;以及reporting and visualization tools. 還包含用來保護data warehouse的Identity management information and access control policies達到資料保護的confidentiality, integrity, and availability目的。

從high-level的角度來看，遷移data warehouse的程序分為四個以下階段

• 評估data warehouse現行的狀態
• 設計未來的狀態
• 遷移data, jobs, 還有access control
• 驗證cloud data warehouse

所有的 data warehouse migration都應遵循此基本模式，但重要的是還是會有不同類型的migration發生。

Off-loading migration涉及將地端data warehouse 的data and schema copy到cloud中，以盡快能在cloud使用data warehouse的相關服務與功能。當你的組織或公司希望用到比原來地端data warehouse更多的資源與新技術時這是一個好的選擇。

full migration包括了所有off-load migration的程序並外加了data pipeline，這樣data就可以直接從source system直接將資料載入到data warehouse . 這種方式可以讓我們只用cloud的tools來做資料的 extraction, transformation, and load.

評估data warehouse現行的狀態

初始評估階段包括確定現有use case的技術需求以及詳細說明從on-premises解決方案遷移到cloud data warehouse的業務優勢的工作。

技術需求

第一件事就是確認現有的use case，包括資料的資訊，例如source, 更新頻率，與data一起使用的 ETL jobs以及use case中使用的access control. 蒐集技術需求以該包括以下工作事項

• Data source list, 包括data source schema, 像是data source更新的頻率
• Data catalog, 包括從source system收集到的attributes以及衍生出來的attributes, 例如 suueraries by time and location
• Data model, 包括schemas, tables, views, indexes, stored procedures
• ETL的scripts list與用途
• 從data warehouse產生的reports 與visualization
• Role list, 包括與這個role相關的access controls. role可能有admin/developers/users

Business上的效益

在migration item的早期階段評估data warehouse migration的Business效益。 業務價值可以從cost saving、ETL 和report backlog的減少以及在不斷變化的條件下提供增加洞察力的敏捷性和能力。

在評估data warehouse migration時，還要考慮到total cost ownership。 這包括software licensing, hardware infrastructure, developer and system administrator’s time,，以及任何第三方support或諮詢成本。

如果legcy software 和現行地端的data warehouse導致企業中的report 與ETL jobs的backlog。業務決策者無法獲得的洞察成本是不容易量化，但它仍然是一個應該與其他商業利益主題一起考慮的因素。

設計未來的狀態

一旦確定將data warehouse遷移到 GCP 是具有商業意義，就該計劃data warehouse的未來狀態了。 在初始階段確定的use case應該提供將在cloud platform中部署的內容邊界的廣度。 還需要定義KPI，用於衡量遷移過程實現objectives的程度。 KPI 可能包括遷移的資料量、cloud data warehouse中現在可用的報告數量以及完全遷移的工作負載數量。

作為為未來狀態設計的一部分，我們應該考慮如何利用 BigQuery 功能進行data warehouse，包括以下內容：

• 由於Bigquery 是serverless的全託管服務，因此不用規劃資料儲存與查詢的資源
• Bigquery使用的是columnar format, 它是support nested and repeated fields, 這對denormalize data models是有幫助的。盡量減少join.
• data是儲存在 Colossus filesystem,這種filesystem將redundant blocks儲存在多個實體的disk中。這樣我們就不用管理data的 redundant copies來確認資料的availability and durability.
• BigQuery支援 federated query在loud Storage, Bigtable, or Google Drive中的資料。
• BigQuery 會保留 7 天的更改歷史記錄，以便我們可以查詢data的時間點snapshot。

BigQuery 與其他data warehouse DB有一些區別。 在 BigQuery 中，tables被分組為dataset。 基於IAM的access control應用於dataset level，而不是tables level。 因此，如果需要授予某人查看dateset中某個tables中data的權限，他們將有權查看該dataset中任何tables中的data。 但是，可以通過創建我們希望user有權訪問的data的view來限制訪問。 這些view可以放在另一個dataset中，user可以被授予允許他們通過view訪問data的role。 user不需要access為view提供基礎data的datset。

遷移data, jobs, 還有access control

經過評估與計畫後，data 跟jobs的migration就會開始了。這裡沒有最好的方法來migrate data跟job. 有以下幾種方法可以參考

• 利用當前的機會
• 先migrate 分析的workload
• 先聚焦在使用者體驗
• 優先轉移低風險的作業

利用當前機會的重點是展示案例的明確業務價值。這很可能是一個長久以來現行的地端方案無法解決的問題。我們可以使用Bigquery來解決長期以來無法徹底解決的問題。

一班的RDBMS系統大都會是data warehouse的data source. 然而有時也可以反過來 data warehouse是RDBMS的資料來源。例如，可以在data warehouse中計算銷售 KPI 並將其資料發送回銷售管理系統(RDBMS)，在那里該data用於計算銷售獎金。在此種狀況銷售管理系統(RDBMS)可能在地端機房有很多其他service的dependencies, 要搬上cloud在現行狀況下可能不太容易。但卻可以把分析工作migrate到cloud中。RDBMS保留在地端。

另一種選擇是提供可供分析師或其他可以立即開始生成data insight的user利用的data和report tool。 此外，客戶可能會發現aggregate有關其帳戶的data很有用。 例如，中小企業可能想知道他們在不同類別的商品上花費了多少，每週發送一封包含摘要data的電子郵件可以幫助滿足這一需求。

驗證data warehouse

migrate data warehouse的最後一步是驗證遷移。 這包括測試和驗證

• schemas被正確且完整地定義
• 預期在data warehouse中的所有data都真的被載入了
• Transformation是被正確的應用，data quality是檢查通過的
• Queries, reports, and visualizations是如預期的可以執行
• Access control policies有設定好
• 其他資料的governance practices也有實施。