AWS的大數據分析-Part 1資料收集

33 min readJul 14, 2021

這是一個數位化的世界。隨著越來越多數位設備的使用，大量的資料也隨之產生，而這麼多的原始資料就需要進行整理、分析、產生新的洞見，資料才會變成資訊，進而促使我們行動。然而傳統的分析工具已經越來越無法有效的分析這些大量的資料，我們需要一種創新的方法來分析這一些大數據。

大數據工具和技術為高效能數據分析來更好的了解客戶需求、在市場中獲得競爭優勢和發展業務提供了機遇和挑戰。資料管理架構已經從傳統的數據倉儲模型演變為更複雜的架構，以滿足更多的需求，例如即時和批次資料處理；結構化和非結構化資料；高頻交易等等。

AWS 提供了廣泛的託管服務平台，可幫助我們快速輕鬆地建立、保護和無縫擴展端到端(end-to-end)的大數據應用程序。無論我們的應用程序需要及時串流還是批次資料處理，AWS 都能提供基礎設施和工具來處理我們的大數據專案。無需採購硬體與軟體，無需維護和擴展基礎設施 — — 只需收集、存儲、處理和分析大數據所需的東西。 AWS 擁有一個分析解決方案的生態系統，專門設計用於處理不斷增長的資料量並深入了解我們的業務。

AWS的大數據分析優勢

分析大量資料需要強大的電腦運算能力，其資料大小會因輸入資料量和分析類型而異。 AWS的大數據服務的特性非常適合Pay-as-you-go的雲端計費模型，在這種模型中，應用程序可以根據需求輕鬆擴展和縮減。隨著需求的變化，我們可以輕易的調整 AWS 上的環境（水平擴展或垂直擴展）以滿足業務需求，不需要等待額外的軟硬體購買時間或需要過度投資軟硬體的容量。

AWS提供了多種的工具與服務來支援這些大數據分析需求，下面將會一個個介紹其功用與特性。在AWS的大數據分析中會分為資料的四個階段，分別是收集，處理，儲存與分析(如下圖)。

我們將介紹以下工具來對應AWS大數據分析的四個階段。除了這四個階段，資料的視覺化與安全也同等重要，而我們也將一併介紹AWS關於這個方面的服務。

當然除了上述這些託管服務之外，我們也可以指使用EC2(VM)來建立自己的大數據分析平台。

資料收集階段

AWS在這個階段將資料收集分為三種

Real time (即時) — 分析是立即性，這類的AWS服務像是 Kinesis Data Stream(KDS), Simple Queue Service(SQS), 與 IoT.
Near real time (幾乎即時)— 分析是具回應性的，這類的AWS服務像是 Kinesis Data Firehose(KDF), Database Migration Service(DMS)
Batch(批量處理) — 通常是歷史性資料分析，這類的AWS服務像是 Snowball, Data Pipeline

Kinesis

這是基於 Apache Kafka提供用來處理串流資料(streaming data)與即時分析的平台，當然我們也可以客製化自己的應用程式放在這上面運行。串流資料的種類可能是應用程式日誌，網站使用者的點擊資料，IoT裝置的監控資料等等，我們可以將這些資料存放到資料庫/資料湖/資料倉儲中甚至是我們自己的即時資料處理程式來處理這些資料。Kinesis適合用在串流處理框架(streaming processing frameworks)，像是Spark, NiFi等等。由於這是託管式服務，在Kinesis處理的資料都會自動同步複製在AWS的三個AZ之間。

而Kinesis服務分為以下五個部分

Kinesis Data Streams — 構建處理或分析streaming data的自定義應用程序，適合low latency的streaming ingest。
Kinesis Video Streams — 構建處理或分析Video streaming的自定義應用程序，主要目的對串流影音與time-encoded的資料做分析。
Kinesis Data Firehose— 將資料傳送到AWS的其他服務，像是 S3, Redshift, Splunk與 Elasticsearch Service。
Kinesis Data Analytics — 使用Standard SQL與Apache Flink來處理與分析串流資料。
Managed Streaming for Kafka — 這是當Kinesis前面四個服務無法滿足你的需求時可以使用這一個服務。

而Kinesis提供了四種不同的方式來擷取(ingest)，處理，並分析資料。

Kinesis Data Streams

使我們能夠構建即時處理或分析串流資料的自定義的應用程序。 Kinesis Data Streams 每小時可以從數十萬個來源（例如網站點擊流、金融交易、社交媒體來源、IT logs和位置追踪來存儲好幾 TB 的資料。

我們在開發程式與AWS Kinesis搭配的應用程序時，搭配著Kinesis Client Library(KCL)我們可以構建 Amazon Kinesis Application並使用streaming data來支援即時顯示的儀表板、產生告警以及進行動態定價和廣告。這一類搭配KCL的應用程式可以將資料寫入到AWS的 S3, DynamoDB, Redshift, Elasticsearch Service等(如下示意圖)

使用 AWS 控制台、API 或SDK，以"每秒 1 MB" 的block為單位預置data stream所需的輸入和輸出等級。可以隨時向上或向下調整stream的大小，而無需重新啟動stream，也不會對將資料推送到stream的data source產生任何影響。在幾秒鐘內，放入stream中的資料即可用於分析。

而在Kensis stream中， stream被分為數個 Shards(或稱Partitions)。Shard是唯一標識streams的順序與固定的處理容量。

上圖中可以看到，推送資料進到Shards的部分稱為producers，取出資料的部分稱為consumers。資料存放在Kinesis stream最高可以存放七天(預設是24小時)，也就是說Kinesis stream的服務內部是有storage存放資料的(Kinesis Firehose則沒有)。也因為可以存放資料，所以資料是可以被reprocess/ replay 的。而在處理資料Consumers可以同時是多個應用程序，意思是同一個data stream同時可以服務多個consumer。並且因為需要服務多個應用程序(consumers)所以我們可以提高整個輸出資料的throughput。另外資料一旦進入Kinesis它就不能被刪除，直到資料的保留時間到期。

而Shard則是最小的計費單位，意思是我們使用的shard的數量越多費用就會拉高。但運作過程中我們可以依當時運作的需求對shard實行 reshard作業。而records在每個shard中是有排序的，哪甚麼是Records呢?可以參考下圖

由上圖可知，每筆record的組成為三個部分

Data Blob: 正在傳送的資料，並序列化(serialized)為bytes. 資料量最高可以到"1MB"。

Record Key : 與record一起發送，有助於在shard中對record進行分組。意思是 Same key = Same shard。而由於我們要避免某一個shard會處理到大部分甚至是全部的資料，所以key的設計必須是highly distributed，將資料平均分配到所有的shard中處理以防止 hot partition的問題發生。

Sequence number: 資料進入kinesis stream中會由kinesis來對每筆record添加sequence number來辨識每筆record的唯一性，但這個唯一性只存在於該shard中。

Kinesis Data Streams的限制

在使用Kinesis Data streams時我們需要知道它的限制性在哪裡

Producer: 每個shard可以"寫入"的資料量是"每秒1MB"或是"每秒 1000 messages".

傳統的Consumer : 每個shard對”所有的”consumers是"每秒2MB"的資料讀取量。或是每個shard對”所有的”consumers是"每秒5個 API calls".這類的consumer是對shard裡的資料做pull的動作。

增強型的(enhanced Fan-out)Consumer: 每個shard對每一個增強型的的consumer都有"每秒2MB"的資料讀取量。也就是說不會像是傳統型的consumer一樣shard的資料讀取是要被分享給所有的consumer的，每個consumer都可以有自己"2MB的資料專用資料讀取量"。在這個模式中不再需要API calls了，因為這時資料對應到consumer是屬於"push mode"。

資料留存時間: 預設是24小時，最高可以到七天。

Kinesis Producers

哪甚麼是Kinesis prodcuers呢?基本上就是將資料寫入到data stream，包含 Kinesis SDK / Kinesis Procedure Library(KPL)/ Kinesis Agent甚至是其他第三方的library，像是Spark, Log4J, Appenders, Flume, Kafka connect, NiFi等等

讓我們來看一下以下幾種Producer的使用方式與情境

Kinesis Producer SDK
在輸入資料時的API call有哪些是常用到的 — 例如 : PutRecord(一筆資料)或是PutRecords(很多筆資料)，PutRecords通常使用在batching或是要增加throughput，同時這麼做也意味著我們只需要少量的 HTTP requests。每一個單一個HTTP request的PutRecords可以支援500筆records且每筆record可以有1MB的資料大小，但整體大小只能支援到5MB。另外還有 ProvisionedThroughExceeded，這是我們的資料超過限制後可以進行甚麼樣的處置。通常為這三種處理方式 — 1.)Retire with backoff, 2.)增加shards, 或是3.)確認我們的partition key的設計是正確的。

Kinesis Producer Library(KPL)

易於使用且高度可配置的 C++/Java library
用於構建高效能，長期運行的Producer
自動化和可配置的retry機制
同步與非同步的API (效能較好的是非同步方式)
可以將測量指標資料送到Cloud Watch 做監控
Batching(預設是開啟的) — 這可以增加 throughput以減少費用。可以減少的原因在於在同一個 PutRecords API call做到收集資料與寫入多個shard。資料可以aggregate(這麼做會增加latency)，將多筆record存放在同一筆record(一秒一千筆record的限制)。

但KPL(Kinesis Producer Library)的功能沒有壓縮這一個，如果要做資料壓縮得要自己來。而KPL的資料必須使用KCL(Kinesis client library)或特別的函式庫才可以進行解碼。

上面提到我們可以聚合(aggregate)資料(KPL batching)來增加throughput(示意圖如下)。而我們也可以通過使用RecordMaxBufferedTime(預設為100)的參數來左右資料的delay.

雖然使用KPL的效益不少，但還是有一些狀況不要使用會比較好。因為我們可以使用RecordsMaxBufferedTime來加大資料處理量，但也因為這樣做資料處理時間就會增加(latency變高)，效能變好了但資料處理也不會哪麼即時了。所以如果我們的整體服務是不容許資料處理有delay的話，哪麼可能就需要考慮直接使用 AWS SDK來將資料輸入Kinesis Data Streams(如下示意圖)。

Kinesis Agent

說白話一點，這就是將agent(Java-based，建立於KPL之上) 安裝在 Linux 的OS上的。它通常都是監控一些OS中的 Log檔案，並將這些Log傳送回 Kinesis data streams。

主要功能在於

可以同時將存在於OS多個目錄資料寫到多個streams。
基於目錄/log file的路由功能。
在將資料送到 streams之前做一些資料預處理(像是 csv to json, log to json等等)
agent可以處理file rotation, checkpointing, 與失敗時重試。
將量測指標發送到 CloudWatch 進行監控

傳統的Kinesis Consumers

哪甚麼是Kinesis consumer呢? 它可以是如下圖這些元件或服務

Kinesis Consumer SDK-讀取資料(GetRecords)

傳統的consumer的資料讀取是pull的方式。每個shard最高是2MB(每秒)的 aggregate throughput。GetRecords 返回最多 10MB 的資料（限制是 5 秒）或最多 10000 條records. 每個shard每秒最多 5 個 GetRecords API calls等於 200ms 延遲. 例如我們有5個 consumer Application，要從同一個shard從取得資料(pull mode)。意味著每個consumer 需要一秒鐘(200ms x 5 consumer)才能取到資料，並且資料會少於400 KB/s (2MB / 5 consumer)。如下示意圖

Kinesis Client Library(KCL)

這可以用在多種開發語言上，例如JAVA, Go, Python, Ruby, .NET等等。會從使用 KPL 生成的 Kinesis 中讀取records（de-aggregation）。另外KCL會使用稱為shard discovery的方式來將 consumer與shard分群。而Checkingpoint的功能是為了當 KCL的作業失敗時可以從中斷的地方繼續進行而不用從頭再來。而為了達到這個功能我們就需要搭配其它AWS的服務 — DynamoDB來記錄資料處理到哪一段，通常一個shard是一筆row。但使用DynamoDB時我們需要注意DynamoDB的WCU/RCU是不是足夠，不然就要用 On-Demand的方式。否則我們就會看到KCL的效能降低， "ExpiredIteratorException"意味著我們要增加WCU。

Kinesis Connector Library

這是舊版的JAVA library, 若可以我們用 KCL來代替。而connector library可以將資料寫入到如圖下所示的AWS服務中

我們除了可以使用函式庫將一些資料處理的功能放在AWS EC2上面外，也可以使用AWS Lamda服務來處理資料，並將資料寫到其他地方。若使用Lamda的方式則函式庫都已經內建在Lamdba中，Lambda扮演的是一個從 KPL將 record de-agreggate的功能。所以Lambda可以當作一個lightweight的ETL工具將資料寫入到 S3/DynamoDB/Redshift/ElasticSearch與其他任何地方。

增強型的(Enhanced Fan-out)Consumer

我們上面提到這一種增強型的Consumer。由於它是push mode(透過http/2)的方式，所以沒有傳統上consumer 資料傳輸的throughput需要平均分給Application consumer的狀況，每一個consumer都可以從每個shard中得到專屬的2MB ，而這樣子的push mode也讓延遲大約只有70ms左右。

所以我們可以來比較一下傳統的consumer與增強型的有不一樣的地方在於:

傳統的: 適合consumer application是少量的，而且可以忍受200ms以上的延遲(還會因consumer的數量變多而增加)。但這種方式的費用是比較便宜的。
增強型的: 同一個data stream需要服務很多個consumer。需要較低的延遲性(70ms)。費用是較高的。而且最低就是服務5個consumer。

Kinesis 的運作

增加Shard
主要是因為效能不足時所會執行的動作，增加shard也意味著stream write的 capability(一個shard 為1MB的data write)，也稱作 Shard splitting。能解決hot partition的問題(如下圖)，而舊的shard會在因為裡面的資料到期後被關閉。

合併(Merging) shard
當不需要這麼多shard時可以減少以減低運行費用。可以將兩個shard合併，而舊的shard會在因為裡面的資料到期後被關閉(如下圖)。

哪麼在reshard之後我們應該注意甚麼呢?在resharding完成後我們的records會有沒有排序的狀況。所以在reshard之後我們可以從child shard讀取records，但是我們仍然可能在parent shart有資料沒讀到這就造成讀取的資料沒有排序。如果是在沒讀取完parent shard前就讀取child shard，哪我們就會讀取到一個沒有排序的特別hash key。所以在reshard之後要讀取的是整個parent shard，直到parent shard沒有新的record進來(如下圖)。

上述所講到的運作邏輯，KCL(kinesis client library)已經包含在裡面了。

自動擴展
Kinesis stream的本身並沒有包含到自動擴展功能。所以如果要做到因為負載要增加shard就必需使用API calls(UpdateShardCount)的方式。我們可以透過Lamdba來實現這依功能。架構圖如下，詳情則可以參考AWS Blog。

雖然可以自動擴展但有些限制我們要注意。因為resharding的動作不是平行處理的，也就是每一次只能執行一個reshard動作。而每個動作都必需花費幾十秒的時間。例如我們要一次突然加1000個shard每加一個都要花30秒，哪就是 30秒 x 1000 shard= 近8.3小時的時間。所以使用kinesis stream的capacity plan必須要先算的仔細一些。

還有以下的操作我們無法執行

每一個stream擴展在24小時的區間內不可以擴展兩次。
擴展到現有shard 數量的一倍以上也不可以一次減掉一半以上
每一個stream每次擴展不可以一次超過500 shard
同樣的每次也不能減少500個，除非這一次減少後shard的數量是低於500個的。
每一個AWS account的shard數量有限制，所以在這個account的stream的shard 總數也無法超過這個數字。

如何處理從Producers傳來的重複性資料呢?

Producer會重複送資料是因為沒有收到Kinesis data stream回傳的確認訊息才會讓Producers重新傳送(network timeout)，如下圖所示。雖然兩筆重複的資料內容是一樣的但是在 Data stream裡的sequence number是不一樣的。要解決這一類的問題我們就需要在每筆record的data中加入unique record ID，這樣子cousumer在接收資料時就可以根據這一個unique record ID來去除重複的資料。

如何處理Consumer讀取重複性資料呢?

會發生這一類的狀況在於record processors被重啟了。重啟的原因可能如下

未預期的worker terminates
worker instance 被加入或移除
shard被merge 或split
Application的部署

解決這一類的問題就是要讓我們的consumer application 具有冪等的(idempotent)。如果資料的最終目的地可以處裡重複性資料，則可以建議如這個AWS文件的作法。

Kinesis Data Firehose(KDF)

我們不需要編寫應用程式或管理資源。將data prodcers配置為將資料發送到 Kinesis Firehose，它會自動將資料傳送到我們指定的 AWS其他服務。我們還可以配置 Kinesis Data Firehose 以在資料傳輸之前做資料轉換。這是是一項全託管的服務，可自動擴展(而Kinesis stream則需要額外的API call)以配合我們的data throughput。它還可以在載入資料之前對資料進行批次處理、壓縮和加密，從而最大限度地減少其他服務使用的存儲量並提高安全性。

這是一個Near Real time(非完整批次的最短延遲時間為 60 秒）服務。可以將資料載入 AWS的Redshift/S3/ElasticSearch與第三方的Splunk。並可以在S3中的檔案做轉換(JSON變成 Parquet/ ORC)。若要其他的轉換(例如CSV變JSON)，則需要搭配AWS Lambda。當目標是傳送到S3時還可以支援過程中能夠資料壓縮(GZIP/ZIP/SNAPPY格式)，但如果是要將資料載入到Redshift的話，而目前只支援GZIP。計費的方式是經過這個服務的總體資料處理量。另外要說明一點Spark/ Kinesis Client library無法直接從KDF讀取資料。

下圖為使用KDF的圖解，其中Lambda用來作為過程中的資料轉換。

KDF的資料傳送圖解如下，在KDF中有多種的Lamdba的範本(像是Apache Log或 Syslog轉換成JSON或CSV)可供我們使用作為資料轉換的功能。Lambda的buffer size(payload)是6MB，所以確定每次呼叫Lambda時處理的資料要等於或小於6MB。而每次由KDF所帶起來的Lambda，運作時間最多是5分鐘。

KDF中會有Buffer size的存在，主要是累積records。而buffer則會有將裡面的資料清洗(flush)的情況，一種是存放時間(例如三分鐘)到了另一種是buffer滿了(例如buffer有32MB)。KDF可以自動增加buffer來增加throughput，所以我們需要考慮到buffer的大小對我們的資料處理有著甚麼樣的影響

High throughput意味著 Buffer size會先滿
Low throughput意味著buffer time會先到

Kinesis Data stream與 Firehose的比較

Stream:

需要在producer與consuker兩端開發程式
Real time (傳統的-200ms的延遲。增強型的- 70ms)
資料儲存可以從1–7天，能夠replay與服務多個consumer
可以使用lambda作資料轉換，例如將資料即時並不斷的寫到ElasticSearch中。

Firehose:

全託管式服務，可將資料直接送到S3, Redshift, ElasticSearch與Splunk
一樣可以使用Lambda作資料轉換
Near Real time的資料處裡(buffer time最低是一分鐘)
自動擴展
無法儲存長期資料

Kinesis Video Streams

這也是一個全託管式的服務。基本上只要可以影像資料Kinesis Video stream都可以處理，影像資料的來源可以是手機鏡頭，webcams，無人機，車用鏡頭等來源。當然Kinesis Video streams也可以處理不具時間序列的影像的其他類型資料，例如聲音資料，熱像儀， RADAR(Radio Detection and Ranging)等。

Kinesis Video Streams的主要概念如下

Producer 可以是Application、裝置，或其他可以產生影像的來源。

Kinesis Video Producer Library 這是安裝在我們的設備裝置能夠與Kinesis Video Streams連結，並能即時做影像傳送或是影像暫存後再傳送。

Kinesis Video Streams Producers將資料傳送到此，作為影像資料的中繼站。這邊能夠暫時的儲存資料，並且提供給下游其他服務使用。我們也可以在Producer中使用AWS SDK的方式與Kinesis Video Streams連結（如下圖）。

Consumer 能夠從Kinesis Video Stream服務中讀取資料進行其他的加工處理或分析。以下為整體Kinesis Video Streams的各部功能示意圖。

AWS Glue

這是AWS提供的全托管式的ETL(Extraction, Transformation, and Loading)工具。Glue除了可以執行ETL的作業之外還可以在 Python shell 或完全託管的serverless Spark 環境中運行它們。AWS Glue中還可以使用Crawler探索來源端（來源端如下圖）中的資料並將些資料的metadata分享給其他AWS的服務。使用AWS Glue的好處在於，當我們的source system, data format, target schema有變動的話我們不需要再重寫code去適應這些變動。整個流程可參考下圖

上圖中，我們在第二步看見Glue有內建的分類器。所謂分類器就一種預先寫好的規則判斷器，可以判斷資料型態是甚麼，像是數字，字串，電話號碼，身分證字號，地址等等這些已寫好的規則。當然若內建的規則不符使用的話我們也可以自行再編寫增加。

而探索來源端最重要的就是crawler(爬蟲)，爬蟲程序是連接到data store(source or target)的程序，通過分類器的優先級清單確定資料架構，然後在 AWS Glue 的Data Catalog中創建metadata。資料掃描，分類，提取schema的資訊並儲存在AWS Glue Data Catalog，這一些動作都是自動的。metadata的資訊是以table的方式儲存的。Crawlers可以是一次性的運行或是定期執行。如果是定期執行的話，Crawler可以偵測到schema的異動並且能夠儲存不同版本的schema。另外也能在S3中偵測到hive-style partitions的異動，對於之前爬到的 S3 partitioned data，預設情況下，Crawler會添加新的partition或變更已經update的partition。

AWS Glue可偵測到來源端的異動是使用的AWS Glue裡的Glue Bookmarks的功能。但Glue bookmarks只能做到增量變動的偵測(identifying delta records)。所以來源端的資料(records)被update時bookmarks是不會知道有異動的。

在AWS Glue有三個主要的元件

Data Catalog
編寫ETL jobs
執行ETL jobs

Glue Data Catalog

顧名思義這個就是資料目錄，方便我們對資料進行組織，管理並便於查找。Glue Data Catalog透過以下幾種方式來管理這些資料的metadata

Web UI
Hive Metastore API
Hive SQL
Crawlers

編寫ETL jobs

依組織的業務邏輯來執行ETL job。我們可以執行的作業如下

可以從頭開始寫自己的scripts
也可以用AWS Glue的template scripts 來改寫
使用現有的scripts放在Glue內運作

以下流程圖為我們編寫自己的scripts，並選擇 source table與target table然後自訂參數。

執行 ETL jobs

編寫完之後接下來就是執行的部分了。AWS Glue在這一部分的主要目標是提供給我們一個簡易的方式來執行ETL作業。ETL執行的流程如下

Job的執行會靠trigger來發動。我們可以用排程的方式或一種跟其他作業的依賴關係來發動。
Job開始後，Glue會根據連結參數去連結並擷取來源端資料。
Job會使用我們定好的script來執行資料的data transformation.
資料寫入到目的端
有關Job執行過程中的相關統計資料會被寫入到我們的 data catalog

依照上面介紹的AWS Glue特性，一些使用場景我們可以考慮使用AWS Glue

大規模的資料處理
ETL處理作業
需要建立catalog的資訊

AWS SQS

AWS的SQS分為兩種，

標準(Standard Queue) — 特性有 : Highly scalable with maximum throughput, best-effort ordering, 與 at-least-once delivery semantics。
FIFO Queue — 特性有 : Exactly-once semantics, guaranteed ordering, 但擴展性低於標準Queue.

標準的Queue

這個服務AWS提供了很久(超過10年)，也是一個全託管服務。message處裡量可以從每秒鐘一個到一萬個，並且資料的留存時間可以從4天到14天。而且並沒有規定Queue裡面可以放多少個message。具低延遲特性(publish 與receive都是在10ms之內)。可以根據consumer的數量來作水平擴展(Horizontal scaling)，可以有重複的message(至少會傳送一次，這偶爾才會發生)。message是可以沒有排序的，也就是best effort ordering. 每個一message的傳送資料量最大為256KB。

哪當我們傳送message進到SQS時會是長怎麼樣的呢?請參考下圖

上圖中我們看到我們會有一個message的body，加上屬性(就是metadata)，但屬性可加可不加。資料送過去後我們會得到一個 Message identifer與 body的MD5 hash值。

而SQS的Consumer則是使用Pull的方式來讀取資料，一次最多可以讀取10個message。需要在一定的時間內處裡完message。使用 message ID與 receipt的方式來刪除message。

FIFO(First In First Out) Queue

顧名思義，就是message 先進去的就會先出來。 queue的名稱最後結尾一定要是 “.fifo”。但也因為有這樣嚴格的排序方式所以throughput是比標準的queue還要低，每秒鐘的批量處理為3,000。message會被確切的發送一次。而會使用Duplication ID來處理重複的message(每5分鐘執行一次)。

上面提到SQS的message最多只能到256KB。哪麼如果我們一定要用SQS來傳送超過256kb的資料呢?這時我們可以使用SQS Extended Client(Java library)來處理，這個方式其實是將資料本身放在S3而SQS本身存放metadata(如下圖)。

SQS的使用場景

Decouple Application
可以當作DB的Buffer
處理短時間大量進入的訊息

而SQS可以與CloudWatch整合做到自動擴展的能力。

我們整理一下SQS的限制如下

Consumer最多能處理 120,000個動態message
batch reques最多是 10個message，最大是256KB
message的內容可以是 XML, JSON, Unformatted text
FIFO Queue的每秒鐘的批量處理為3,000 個message
Message size 最大是256KB，若要超過則要使用 Extended Client方式
資料留存在queue中，從一分鐘到14天

Kinesis Data Stream與 SQS的

我們上面介紹了Kinesis Data stream 與 SQS，看起來好像功能差不多。但其實特性有些不一樣。以下是兩種服務的特性分別

Kinesis Data Stream

資料可以被consumer讀取多次
資料會在保留時間到期後被刪除
在每個shard中，資料是可以排序的(即使經過data replay)
多個Application讀取同一個stream都是獨立的(Pub/sub)
具有 Streaming MapReduce querying的能力
需要有Checkpointing 以追蹤consumer的資料處理進度
Shard的的數量需要預先計畫好

SQS

這是用來decouple Application
一個Application使用一個Queue
資料在讀取資後會被刪除(ack/fail)
在標準的Queue中，message是被個別獨立處理的
在FIFO的Queue中，message是被排序的
有能力讓message delay一下
可以動態擴展

下表為Kinesis 與SQS的細部比較表

DMS- Database Migration Service

這是一個你可以快速與安全的搬移任何的DB到AWS的DB服務上，你也可以將資料從AWS搬到地端機房的DB。而且在搬移的過程中source DB幾乎不會受到任何影響。除了搬移同一個廠牌的DB之外，DMS也支援搬移不同廠牌之間的DB(例如從 MS-SQL搬移到AWS Aurora)，搬移過程中若source DB有任和資料異動都會即時的同步到目地端DB。不過我們必須要建立EC2 instance來執行這項工作。

DMS的來源端可以是: 地端機房或任何雲端平台，支援的DB廠牌有 — Oracle/MS SQL Server/MySQL/MariaDB/PostgreSQL/MongoDB/SAP/DB2。Azure的 Azure SQL DB，AWS的RDS(包含Aurora)，S3。

DMS的目的端可以是: 地端機房或任何雲端平台，支援的DB廠牌有 — Oracle/MS SQL Server/ MySQL/MariaDB/PostgreSQL/SAP. AWS的 RDS/Redshift/DynamoDB/S3/ Elasticsearch/ Kinesis Data stream/ DocumentDB。

Schema Conversion Tool(SCT)

這是將來源端的DB scheam轉換成目的端的DB schema，是用來轉換兩個不同廠牌的DB，如果是同一個廠牌則不用使用這一個服務。例如OLTP — SQL Server or Oracle 轉換成 MySQL/PostgreSQL/Aurora。OLAP — Teradata or Oracle 轉換成AWS Redshift。轉換的過程中為了達到較好的轉換效能需要用到比較好的EC2。

另外SCT是執行schema的轉換，真正的資料搬移還是要用到DMS。所以如果是異質平台的DB就會是SCT+DMS的作業。