為 AWS 專家量身打造的 Google Cloud Platform:大數據

更新日期:2016 年 6 月 29 日

Amazon 和 Google 在各自的雲端環境提供大數據服務,以下將會比較這些服務。本文會探討下列服務類型:

  • 資料擷取服務,用於自來源環境將資料擷取至穩定可靠的目標環境或資料類型。
  • 資料轉換服務,可讓您篩選、擷取某種資料類型或模型的資料,或將其轉換成另一種資料類型或模型。
  • 資料分析服務,可針對處理過的資料進行分析、視覺化處理及互動。

資料擷取

Amazon KinesisGoogle Cloud Pub/Sub 都能擷取資料至各自的雲端環境中,但是這兩項服務會採用不同的服務模式來完成這項工作。

服務模型比較

下列是 Cloud Pub/Sub 和 Amazon Kinesis 的詞彙和概念對應比較:

功能 Amazon Kinesis Google Cloud Pub/Sub
部署單位 串流 主題
佈建單位 資料分割 不適用 (全代管)
資料單位 記錄 訊息
資料來源 生產者 發佈者
資料目標 消費者 訂閱者
資料分區 使用者提供的分區索引鍵 不適用 (全代管)
保留期限 1 – 7 天 7 天
資料傳送順序 服務提供的序列鍵 (最理想) 服務提供的 publishTime (最理想)
資料大小上限 1 MB 10 MB
部署位置 地區 全域通用
定價模式 依據資料分割時數、作業數量和資料保留的長度 依據作業數量

Amazon Kinesis

Amazon Kinesis 會使用串流模型來擷取資料。在此模型中,生產者會將資料傳送到您以資料分割所建立及佈建的串流。串流中的每筆資料分割最多可提供 1 MB/秒輸入頻寬,以及每秒 1000 次資料輸入。

使用者透過低階 REST API 或較高階 Kinesis Producer Library (KPL) 將資料傳送至 Amazon Kinesis,而儲存這項資料的資料記錄包含下列內容:

  • 增量序號
  • 使用者提供的分區索引鍵
  • 資料 Blob

分區索引鍵的作用是讓可用的資料分割記錄達成負載平衡。根據預設,這類記錄會保留 24 小時。但是,使用者最多可將保留時間延長為 7 天。

使用者可設定消費者應用程式,以每筆資料分割為基礎從串流擷取資料記錄,然後再處理這些資料記錄。此應用程式負責在可用的資料分割之間進行多工處理。Amazon 的 Kinesis Client Library 簡化了資料分割之間的管理工作,並達成跨消費者應用程式節點叢集的負載平衡和失敗管理。

Cloud Pub/Sub

相較而言,Cloud Pub/Sub 是一種採用發佈者/訂閱者模型的訊息傳遞服務。您建立 Cloud Pub/Sub 主題後,即可發佈資料到該主題,而訂閱該主題的每個應用程式就能擷取主題的資料。這種方法不需要佈建作業。

在 Cloud Pub/Sub 註冊的每個應用程式均可透過推送模型或提取模型擷取訊息:

  • 推送模型中,Cloud Pub/Sub 伺服器會將要求傳送至位於預先定義網址端點的訂閱者應用程式。
  • 提取模型中,訂閱者應用程式會向伺服器要求訊息,並於訊息送達時確認收到訊息。

發佈至主題的每則資料訊息都必須使用 Base64 編碼,大小不得超過 10 MB。擷取時,Cloud Pub/Sub 會在每則資料訊息加入 messageId 屬性和 publishTime 屬性。messageId 屬性是保證在主題內獨一無二的訊息 ID,而 publishTime 屬性則是擷取資料時系統新增的時間戳記。您可採用金鑰名稱和值的格式將選用屬性新增到資料中。

資料順序

本節說明 Amazon Kinesis 和 Cloud Pub/Sub 如何針對消費者或訂閱者應用程式要求的資料管理順序。

Amazon Kinesis

根據預設,Amazon Kinesis 會透過分區索引鍵和序號來維護資料順序。當生產者新增記錄到串流時,生產者會產生分區索引鍵來判斷要將記錄傳送至哪筆資料分割。資料分割會將增量序號加入記錄,然後穩定可靠地儲存這筆記錄。

消費者應用程式是依據資料分割來要求記錄,並且遵照序號的順序接收記錄。雖然這種模型可確保按照資料分割的排序,但如果是跨資料分割提出要求,則無法保證順序。此外,系統可能會將記錄重複傳送給消費者,因此必要時應用程式應負責強制執行「一次性」語意。詳情請參閱 Amazon Kinesis 說明文件中的處理重複記錄

Cloud Pub/Sub

Cloud Pub/Sub 會使用系統提供的 publishTime 屬性,儘可能依照發佈順序傳送訊息,但是不保證只傳送一次且會依序傳送;偶爾還是會重複傳送或是不按順序傳送訊息。接收訊息後,您的訂閱者應以冪等方式處理訊息,而且必要時能夠處理順序紊亂的訊息 。

您可透過應用程式提供的序號和緩衝來達到更精確的排序。如果資料的最終目標是支援根據時間來查詢的永久儲存空間服務 (例如 Cloud Datastore 或 BigQuery),那麼您也可以透過時間戳記排列查詢以達到更精確的排序。如果您的目標是 Cloud Dataflow,則可使用記錄 ID 建立「一次性」處理作業。

作業

本節將針對每項服務介紹實際工作負載的營運和維護負擔。

Amazon Kinesis

Amazon Kinesis 的資料分割為已佈建 (亦即固定) 狀態,因此使用者必須透過 Amazon CloudWatch 監控使用量,然後視需要手動調整資料分割大小。這種調整大小的程序稱為重新資料分割,而且必須採用逐對資料分割的基礎來執行。重新資料分割支援兩種作業類型:將一筆資料分割分成兩筆,或是將兩筆資料分割合而為一。因此,如果要將 N 筆資料分割的容量加倍,則必須執行 N 次個別的資料分割作業。

由於資料分割的固定特性,因此使用者在建構時需小心不得超過其限制。比方說如果您選擇使用的分區索引鍵不適當 (例如股市應用程式中的股票代號),則暴增的流量可能會癱瘓資料分割擷取功能,就算重新資料分割仍無法解決問題。如果發生這種情況,解決問題的唯一方法是使用不同的分區索引鍵來重新設計應用程式。

您可藉由使用 Amazon Kinesis Firehose 為 Amazon Kinesis Streams 減輕一些管理方面的負擔。Kinesis Firehose 可針對從串流匯總資料至 Amazon S3 或 Amazon Redshift 的特定使用案例,將 Kinesis Streams 的管理、監控和資源調度作業自動化。使用者先指定 Amazon S3 值區或 Amazon Redshift 叢集,然後由 Firehose 代表使用者建立和管理串流,並且按照指定的間隔將資料存放至想要的位置。

最後要說明的是,Amazon Kinesis 是一項地區性服務,其會將串流的範圍限制在特定的地區。因此,這項服務擷取的所有資料都會傳送至定義串流的地區。

Cloud Pub/Sub

Cloud Pub/Sub 不需要佈建,而且採用不透明的方式處理資料分割、複製和資源調度等作業,因此管理員無需手動監控或調度任何項目的資源。

此外,Cloud Pub/Sub 會代表使用者管理資料分區,所以使用者也不會用到分區金鑰。雖然這些功能可大幅降低管理方面的開銷,但也意味著 Cloud Pub/Sub 更難為傳遞訊息的順序提供保證。

Cloud Pub/Sub 會利用 Google 的 HTTP(S) 負載平衡器,支援在全球跨所有 Cloud Platform 地區擷取資料。當發佈者發佈資料至 Cloud Pub/Sub,Google 的 HTTP(S) 負載平衡器就會自動將流量導向適當地區的 Cloud Pub/Sub 服務,以減少延遲時間。

費用

Amazon Kinesis Streams 會依資料分割時數、資料用量和資料保留期限計費。根據預設,資料會保留 24 小時。延長保留時間會產生額外的費用。Amazon Kinesis Streams 採用佈建的模型,因此即使您沒有用到某些資源,仍必須針對佈建的資源付費。

Amazon Kinesis Firehose 依據資料用量計費。

Cloud Pub/Sub 也是依據資料用量計費,但是 Cloud Pub/Sub 不需要佈建資源,因此您僅需針對自己耗用的資源付費。

資料轉換

當您將資料擷取到自己的環境之後,即可視需要轉換、篩選和處理資料。

處理資料轉換作業的常見做法是使用以 Apache-Hadoop 為基礎的工具進行,這類工具能夠提供具彈性且可擴充的批次處理。Google Cloud Platform 和 Amazon Web Services 兩者均提供代管 Hadoop 服務。Google Cloud DataprocAmazon Elastic MapReduce (EMR) 也都會提供自動化佈建和設定、簡易工作管理、精密複雜的監控以及具彈性的計費方式等服務。Cloud Dataproc 和 Amazon EMR 都支援使用 Apache Spark Streaming 元件來處理串流型資料。

此外,Google Cloud Platform 還會提供以 Apache Beam (而非 Hadoop) 為基礎的 Google Cloud Dataflow 工具。Apache Spark Streaming 將串流資料視為小型批次工作,而 Cloud Dataflow 則是在本質上即著重於串流處理的引擎。

服務模型比較

下列是 Amazon EMR、Cloud Dataproc 和 Cloud Dataflow 各項工具的比較:

功能 Amazon Elastic MapReduce Google Cloud Dataproc Google Cloud Dataflow
開放原始碼程式庫 Apache Hadoop 和 Apache Spark Apache Hadoop 和 Apache Spark Apache Beam
服務整合
資源調度 手動 手動 自動
部署位置 區域 區域 區域
定價模式 每小時 每秒 每分鐘
部署單位 叢集 叢集 管道
資源調度單位 節點 (主節點、核心節點、任務節點) 節點 (主要節點和工作站節點) 工作站
時間單位 步驟 工作 工作
程式設計模型 MapReduce、Apache Hive、Apache Pig、Apache Spark、Spark SQL、PySpark MapReduce、Apache Hive、Apache Pig、Apache Spark、Spark SQL、PySpark Apache Beam
自訂 Bootstrap 動作 初始化動作 檔案暫存

Cloud Dataproc 和 Amazon EMR

Cloud Dataproc 和 Amazon EMR 的服務模型很相似。這兩項工具都具備篩選及匯總資料的可擴充平台,而且均可和 Apache Hadoop、Apache Spark、Apache Hive 和 Apache Pig 等 Apache 大數據工具和服務密切整合。

在這兩種服務中,使用者都會建立包含多個節點的叢集。服務會建立單一主要節點以及數量不等的工作站節點。Amazon EMR 進一步將工作站節點分成核心節點和任務節點。

佈建叢集後,使用者就會提交要讓叢集執行的應用程式,在 Cloud Dataproc 中稱為工作,而在 Amazon EMR 中稱為步驟。應用程式依附元件通常是透過自訂的 Bash 指令碼新增到叢集節點,這類指令碼在 Cloud DataProc 中稱為初始化動作,而在 Amazon EMR 中稱為 bootstrap 動作。應用程式通常都是從 Amazon S3、Cloud Storage 或 HDFS 等穩定的儲存空間讀取資料,然後再透過 Apache 資料處理工具或服務來處理資料。處理完資料後,可進一步處理結果資料或將其推送回穩定的儲存空間。

Cloud Dataflow

Cloud Dataflow 採用 Apache Beam 程式設計模型來執行批次處理和串流處理。相較於 Amazon EMR 及 Cloud Dataproc 使用的 Apache Spark 模型,此模型可提供更優質的彈性和表現,尤其是即時資料處理作業。

在 Cloud Dataflow 中,使用者會指定抽象管道,使用 Cloud Dataflow SDK 程式庫提供資料平行處理和匯總語言的基本功能。指定管道時,使用者會定義一組隨後提交以便在管道中執行的轉換。接著,這些轉換會對應到一組針對執行而佈建及設定的工作站節點。部分節點可能用來從 Cloud Pub/Sub 讀取資料,而其他節點可能負責執行其他下游轉換;細節由 Cloud Dataflow 執行階段管理。

Apache 開放原始碼孵化器已接受將 Cloud Dataflow 模型、SDK 和管道執行器當做Apache Beam。這項開發成果表示在 Flink 或 Spark 叢集或本機開發環境中也能執行 Cloud Dataflow 應用程式。

如要查看更詳細的 Apache Beam 和 Apache Spark 程式設計模型比較,請參閱 Dataflow/Beam 和 Spark:程式設計模型比較

資源調度

Cloud Dataproc 和 Amazon EMR

啟動叢集後,Amazon EMR 和 Cloud Dataproc 均可讓您手動調整叢集中的節點數量。叢集大小和資源調度動作是由可監控叢集效能和使用量的使用者或管理員判斷,然後再決定要如何管理叢集。在這兩種服務中,使用者都是依據佈建的節點數量付費。

提交到 Amazon EMR 的步驟會被排入佇列,然後按照先到先得的原則執行。每個工作可能需要執行多次 Hadoop 疊代作業,而且都是由 Hadoop 排程器跨整組工作站節點來管理。

Cloud Dataproc 原本就支援平行提交工作,其利用 Hadoop 的 Fair Scheduler 和 YARN 跨應用程式進行排程。反之,Amazon EMR 本身並不支援平行執行多項工作,不過亦有可用的解決方法

Cloud Dataflow

如果使用 Cloud Dataflow,使用者僅會指定節點數量上限,接著就由 Cloud Dataflow 執行階段系統自動調整節點的規模,視需要主動管理節點佈建和分配。

串流

Cloud Dataproc 和 Amazon EMR

Cloud Dataproc 和 Amazon EMR 均會以批次模式運作。這表示應用程式會從可靠的物件儲存空間讀取儲存的一個大型檔案或一組檔案,接著平行處理資料,然後再將處理後的檔案存回物件儲存空間。

Amazon EMR 支援將 Amazon Kinesis Streams 當做擷取資料的方法,因此能夠直接實作串流資料模型。在此模型中,應用程式會執行和讀取串流中儲存的可用資料,直到某個時間值沒有可用的新資料。清除所有資料分割之後,就會開始執行操作中的調降步驟,然後再匯總資料。Amazon EMR 也會透過內建實作 Apache Spark Streaming 支援來自第三方服務的串流。

Cloud Dataproc 無法直接從 Cloud Pub/Sub 讀取串流資料,但是所有 Cloud Dataproc 叢集都已預先安裝 Apache Spark 架構,可讓 Cloud Dataproc 從 Apache Kafka 讀取串流資料。此外,您也可以使用 Cloud Dataflow 來讀取和處理串流資料。

Cloud Dataflow

Cloud Dataflow 支援串流處理及批次處理。

費用

Cloud Dataproc 和 Amazon EMR

Amazon EMR 和 Cloud Dataproc 都支援以量計價,而且也針對短期和長期使用提供優惠折扣。Amazon EMR 的價格費率是以小時為單位,Cloud Dataproc 則以秒數為計費單位。Amazon EMR 使用者可透過預先購買預留執行個體來降低節點的成本。Cloud Dataproc 會自動提供續用折扣。

此外,這兩項服務也都會提供價格低廉的選項,讓使用者得以善用暫時未用到的容量。Amazon EMR 支援從 Amazon EC2 Spot Market 佈建節點,使用者可在該市集以短期增量的方式競標未使用的容量。服務可收回這些節點,但是新增或移除節點時,叢集仍會持續處理作業。同樣地,Cloud Dataproc 也支援可隨時收回的先佔 VM。但是先佔 VM 並非透過市集競標,而是針對每一種 Compute Engine 機器類型提供每小時固定折扣。

如需進一步瞭解 Google Cloud Platform 和 AWS 等常見雲端環境的代管 Hadoop 定價詳細比較內容,請參閱瞭解雲端定價:大數據處理引擎

Cloud Dataflow

Cloud Dataflow 是依據 Dataflow 工作站類型的使用時數計費。詳情請參閱 Cloud Dataflow 定價

資料分析

擷取和轉換資料後,您可以執行資料分析並建立資料視覺化。

在資料轉換階段,您通常會將轉換的資料輸出至下列其中一項服務:

  • Amazon S3 或 Google Cloud Storage 等物件儲存服務。
  • Amazon Redshift 或 Google BigQuery 等代管資料倉儲。

本節的重點放在 Amazon Redshift 和 Google BigQuery。

服務模型比較

下列是 BigQuery 和 Amazon Redshift 的詞彙和概念對應比較:

功能 Amazon Redshift Google BigQuery
部署單位 叢集 不適用 (全代管)
佈建單位 節點 不適用 (全代管)
節點類型 轉動型磁碟/SSD 不適用 (全代管)
資源調度 手動 自動調整
備份管理 快照 不適用 (全代管)
部署位置 區域 地區
定價模式 每小時 依據儲存空間和查詢量
查詢語言 PostgreSQL 相容性 舊版 BigQuery SQL 或標準 SQL (測試版)

Amazon Redshift

Amazon Redshift 採用跨佈建節點叢集的大量平行處理架構,以提供高效能的 SQL 執行能力。當您使用 Amazon Redshift 時,資料會儲存於自動跨叢集節點複製的單欄式資料庫。此外,您也可以將資料從 Amazon Redshift 匯出至 Amazon S3 進行備份。

如上所述,Amazon Redshift 採用佈建模型。在此模型中,使用者會先選擇執行個體類型,然後依據需求佈建特定數量的節點。佈建後,使用者就能透過自己選擇的 PostgreSQL 相容連接器連線至叢集,然後載入及查詢資料。

Amazon Redshift 是部分代管服務。如果 Amazon Redshift 使用者想要調整叢集的規模,比方說在低使用量期間降低成本,或是在高使用量期間增加資源,則必須自行手動調整。此外,Amazon Redshift 還會要求使用者審慎定義及管理分佈和和排序索引鍵,以及手動執行資料清除和重組程序。

Google BigQuery

反之,BigQuery 是全代管服務。使用者不需要佈建資源;他們只要將資料推送至 BigQuery,然後跨資料查詢即可。BigQuery 服務會以不透明的方式管理相關資源,並根據需要自動調整配置。

BigQuery 會在後端運用 Google 內部使用的相同服務,這些功能不但功能強大且採用全球架構。BigQuery 會使用 Google 最新一代的分散式檔案系統 Colossus 儲存、加密和複製資料;使用 Google 大規模叢集管理系統 Borg 處理工作;使用 Google 內部查詢引擎 Dremel 執行查詢。詳情請參閱 Google Cloud 網誌的 BigQuery 的秘密文章。

BigQuery 資料表只能用於附加。使用者既可以執行互動式查詢,也可以建立及執行批次查詢工作。BigQuery 支援下列兩種查詢語言:

  • 舊式 SQL,此查詢語言是 BigQuery 專屬的 SQL 方言。
  • 標準 SQL,此查詢語言和 SQL 2011 的標準相容,而且包含可查詢巢狀和重複資料的擴充功能。

此外,BigQuery 支援和許多第三方工具、連接器和合作夥伴服務整合,以利進行擷取、分析、視覺化處理以及開發。

擴充

Amazon Redshift 可從單一節點擴充至最多 128 個節點 (8xlarge 節點類型) 或 32 個節點 (較小的節點類型)。這些限制意味著 Amazon Redshift 儲存資料的容量上限為 2PB,其中包含複製的資料。

Amazon Redshift 的擷取和查詢機制會使用相同的資源集區,這表示載入極大量資料時,可能會降低查詢效能。

反之,BigQuery 對於儲存資料集的大小沒有實際的限制。如果您使用 BigQuery API,則可快速擴充擷取資源且擷取作業本身的速度極快,因此每秒可將數百萬列資料擷取至 BigQuery。此外,擷取資源和查詢資源分離,因此擷取載入並不會降低查詢載入的效能。

作業

Amazon Redshift

Amazon Redshift 為部分代管服務,可為您妥善處理執行資料倉儲的諸多必要繁瑣作業。其中包括資料備份、資料複製、失敗管理以及軟體部署及設定等作業。但是,效能管理、資源調度和並行等幾項作業的細節仍屬於使用者或管理員的責任範圍。

建立資料表時,使用者必須定義靜態的分佈索引鍵,才能達到良好的效能。系統隨後就會使用這些分佈索引鍵跨節點分割資料,以便平行執行查詢。分佈索引鍵對於查詢效能具有顯著的影響,因此使用者必須審慎選擇這些索引鍵。使用者定義分佈索引鍵之後就不能再變更;如果要使用不同的索引鍵,使用者必須建立採用新索引鍵的新資料表,然後再從舊資料表複製資料。

此外,Amazon 建議管理員定期執行維護工作以收回遺失的空間。更新和刪除作業不會自動壓縮磁碟上的常駐資料,因此最終可能會導致效能出現瓶頸。詳情請參閱 Amazon Redshift 說明文件中的回收資料表

Amazon Redshift 管理員必須謹慎地管理使用者和應用程式。比方說,使用者必須調整執行的並行查詢數量。根據預設,Amazon Redshift 最多可執行 5 個並行查詢。由於系統會提前佈建資源,因此當您將此上限增加為 50 個時,可能會開始影響效能和輸送量。詳情請參閱 Amazon Redshift 說明文件中的定義查詢佇列的並行層級一節

Amazon Redshift 管理員也必須調整叢集規模以支援整體資料大小、查詢效能和並行使用者數量。管理員可以擴充叢集,但有鑑於此服務採用佈建模型,因此無論使用量為何,使用者都必須支付佈建規模的費用。

最後要說明的是,Amazon Redshift 叢集預設會限制於單一區域。如果要建立高可用性、多地區的 Amazon Redshift 架構,使用者必須在其他區域建立額外的叢集,然後建構可跨叢集達到一致性的機制。詳情請參閱 Amazon 大數據網誌中的建置多重可用區域或多地區 Amazon Redshift 叢集文章。

如要進一步瞭解其他 Amazon Redshift 配額和限制,請參閱Amazon Redshift 中的限制

BigQuery

BigQuery 為全代管服務,因此使用者的作業負擔較低或甚至完全不需要作業。

  • BigQuery 會自動處理資料分割。使用者不需要建立及維護分佈索引鍵。
  • BigQuery 是一項隨選服務,而非佈建服務,因此,使用者不需擔心佈建不足會導致瓶頸,或佈建過度會增加不必要的成本。
  • BigQuery 可提供全球通用的代管資料備用資源。使用者不需要設定及管理多項部署作業。
  • BigQuery 最多支援 50 個並行互動式查詢,因此不會影響效能或總處理量。

如要進一步瞭解 BigQuery 的配額和限制,請參閱 BigQuery 說明文件中的配額政策頁面

費用

Amazon Redshift 分成以量計價和預留執行個體定價兩種計費方式,而且會根據佈建執行個體的數量和類型來計費。使用者可透過提前購買預留執行個體來取得優惠折扣。Amazon 提供一年和三年的預留期限。詳情請參閱 Amazon Redshift 定價頁面

反之,BigQuery 會依據您耗用的項目 (而非佈建內容) 來收費,其計費依據為資料儲存空間大小、查詢運算成本和串流資料插入。如果連續 90 天都沒有更新資料表,資料儲存空間的價格就會調降一半。查詢是按照每 TB 處理資料來計費,並且可搭配彈性調整費率採取選用的高度運算查詢。詳情請參閱 BigQuery 定價頁面

如需取得兩種計價模式的情境式比較詳情,請參閱 Cloud Platform 網誌中的 瞭解雲端定價- 第 3.2 部分

後續步驟

請參閱為 AWS 專家量身打造的 Google Cloud Platform 的其他相關文章:

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
為 AWS 專家量身打造的 Google Cloud Platform