AWS機器學習 — 資料收集

在這篇文章中，我們將己繼續沿著CRISP-DM框架來討論ML中資料收集的議題。我們首先要定義一些通用的資料與ML的術語(有關資料工程)。接著我們會討論一些從不同的來源來擷取資料的方式並且如何為後續的ML作業做準備。我們還會討論一些匯入資料的方式(batch與 streaming)。

基本的資料概念

在開始收集資料前，我們需要了解一些資料的核心概念。有三種最根本的資料型態:

結構化資料
結構化資料由具有明確定義的schema和解釋資料（例如屬性和數據類型）所需的metadata的資料組成。 表格式資料是結構化資料的一個例子。 表格資料由數個不同的rows and columns。每個column可能有著特定的資料型態，例如integers，floats或strings。根據不同的column 的data type，我們也許會針對ML有著不同的action來準備這些資料。在表格dataset中，attribute就是column並且row對應的是 data point或是observation.

非結構化資料
這一類的資料與結構化資料相反，也就是沒有明確定義的schema或任何良好結構特性。事實上，非結構化資料是佔組織/公司資料的絕大多部分，而資料科學家對此資料要嘛把它轉換成適合ML的結構化資料或是直接用這類的資料來train model。這一類的資料有image，video，audio file，文字檔案，或application log file。

半結構化資料
這類的資料沒有任何明確的schema，例如資料可以是JSON 或XML 格式，而這些半結構化資料大都可以在NoSQL DN存取。我們可以把這類的資料解析(parse)成結構化資料以利ML作業。

有了以上三種基本資料的概念，接下來我們將介紹一些ML專用的資料概念:

1. Labeled Data
   這是一種具有一個或多個 target columns(根據變量)或 屬性。
2. Unlabeled Data
   與Labeled data相反，沒有target attribute 或label。
3. Feature
   這是是tabular dataset中除label columns之外的一個column。
4. Data Point
   是tabular Dataset中一筆row(包含一個或以上的feature)。對Labeled data來說，row同時也包含一個或以上的labels。
5. Dataset
   是一群data points的資料集合，是我們可以用於模型訓練或validation。
6. Numerical Feature
   可以用連續數字或整數呈現但本質上是unbounded的feature。
7. Categorical Feature
   一個離散的、定性的Feature，只能取有限數量的值。 在大多數 ML 問題中，我們需要使用不同的技術將categorical feature轉換為numerical feature。
8. Image data
   這類檔案可能同時有很多不同格式的圖片檔案(如JPEG or PNG)。一個image dataset例子是手寫數字的dataset，如 MNIST 或ImageNet.
9. Audio Data
   這類資料通常由不同格式的音檔組成，如MP3或 WAV格式。音檔可能來call center的來電錄音。
10. Text Data(Corpus)
    在ML領域中，text data通常被視為corpus(語料庫)並且是一堆文件的集合。這一類的資料可以有很多種格式，如PDF或 TXT、JSON、CSV。
11. Time Series Data
    這類資料隨時間變化的value組成的資料，例如產品的銷售價格、股票價格、每日溫度或濕度、感測器或物聯網設備的測量值或讀數，或乘坐檯捷運的每日乘客人數。
12. Training Data
    用來訓練模型的Dataset。
13. Validation Data
    這是dataset的一部分，保留用來在我們training data時驗證模型的效能。
14. Test Data
    這類資料一開始就會保留下來，以便我們的模型在訓練之前永遠不會看到它。 一旦我們的模型經過訓練並且我們對訓練和驗證資料集上的模型效能感到滿意，那麼我們才應該在測試資料上測試模型效能。 測試資料應該盡可能接近我們期望模型在正式環境過程中提供的資料。

讓我們檢視以下表格，這是一個在不同城市的房屋價格，我們來看一下我們是否能夠識別哪個column是 feature或是label。針對Label，它是一個連續或是離散的label?針對feature，有任何的categorical feature在資料中嗎?我們如何分類Zip code?即使它們是數字，它們還是一個有限數字的Zip code。哪這樣會讓zip code是numerical或是categotical feature呢?

上圖表格中Label(就是price)是一個很清楚的連續性label, 而其他的columns則是feature。City是一個 categorical feature，因為它不是一個既定的順序(像是台北市>內湖區)。所以ZIP code也可以歸類成categorical 。

Data Repositories

討論了不同的資料類型，我們現在看一下不同資料儲存庫(data repositories)，這是一個資料可以被存放，讀取，與查詢的地方。

讓我們從有一個良好定義schema的Tabular data開始。Tabular data通常是用在如OLTP(online transaction processing), 分析與報表，而分析通常使用SQL語法來查詢資料。

OLTP Application通常運作在關聯式資料庫中，而AWS提供資料庫的託管平台，稱為RDS。AWS提供了RDS這種託管平台多種的關聯式資料庫的選擇例如Aurora，MySQL，MariaDB，Oracle，MS-SQL，PostgreSQL。關聯式資料庫通常使用row-wise(逐行)storage並且這樣的方式是適合針對特定的rows進行 insert與updates。

針對分析與報表的作業，這通常是一種大量讀取DB資料的作業，哪我們就會考慮Data warehouse的方案，如AWS Redshift，這是一個 針對快速取得columns資料並且取代 row-level storage的columnar storage，非常適合大量的資料讀取。Redshift 與 RDS都是屬於 tabular data。Redshift能夠與 SageMaker直接整合(使用 SageMaker Data Wrangler )。

假如我們的資料是半結構化，我們應該考慮使用NoSQL的服務，像是 AWS DynamoDB。 DynamoDB存放的是 key-value pairs的資料並且是不需要特定的schema．如果我們的資料是放在Open source NoSQL(如MongoDB)，我們可以使用DocumentDB來代替．

絕大多數的企業組織都有以上我們提到的資料類型，而AWS建議我們針對不同的情境使用為各情境打造的DB。不論是OLTP或分析或報表或object storage(如S3)。當我們在不同的資料存儲庫中有資料時，我們可能希望集中管理和管理對這些資料集的存取控制，並隨著時間的推移來稽核存取紀錄。 AWS Lake Formation 是一種資料湖解決方案，可幫助我們對資料進行集中編目，並對可以存取資料的人員進行fine-grained control。 使用者可以查詢 Lake Formation 中的集中式目錄，然後使用 AWS Redshift 或 AWS EMR 等工具對資料進行分析或 ETL 工作流。

最後，未真正能訓練一個ML模型，我們的資料需要先放在S3給SageMaker用，接下來我們來探討一下如何將不同的資料來源搬到S3中．

遷移資料到AWS中

為了在AWS中建立ML model，我們需要先將資料遷移到S3中. 在這一節我們會介紹不同的一些AWS migration tools來將我們的資料搬到AWS中。

從High level的角度來看，我們有兩種狀況來遷移資料： batch and streaming。在Batch的狀況，我們是transfer bulk data，然而在 streaming 的狀況中，我們是從source端(如感測器或IoT裝置) streaming data，而我們需要stream data到S3中．

Batch Data Collection

如果我們的資料已經在AWS中，我們可以使用AWS data Pipeline來搬移在其他AWS服務(如:Redshift，DynamoDB，RDS等)到S3中． Data Pipeline使用一種稱為activity types的概念來實現特定的action，詳情可參閱此篇文件．

Activity type是一個pipeline component，這個組件(component)告訴Data Pipeline什麼樣的job需要執行．而在Data Pipeline已經預先建立好一些activity types供我們使用，例如 CopyActivity(可以從S3的一個位置copy到另一個 S3位置)，RedahiftCopyActivity(可以將Redshift tables copy出來或放進去)，與SqlActivity (在DB執行SQL query並將結果 copy到S3)．

一但我們的資料在S3中，我們可以使用 AWS EMR執行 ETL jobs。 Data Pipeline可以被使用在遷移資料到EMR中處理資料，如使用Hive query， Pig Scripts等等的資料處理作業。Data Pipeline也可以讓我們從 S3 or DynamoDB copy資料出來並放到Redshift。Data Piepline基本上就是用EC2執行我們的data migration作業並且可以用在event-driven的管理方式或是排程執行．如下圖所示。

如果我們要copy的是關聯式資料庫到另一個相同的資料庫(如mysql to mysql DB)，我們可以使用AWS DMS(Database Migration Service)．例如從地端的MS-SQL copy到AWS RDS的 MS-SQL。另外一種狀況是遷移不同的DB，例如地端的MySQL到Aurora，這時我們就必須要先轉換DB schema，我們可以使用Schema conversion tool．我們也可以使用DMS將資料從RDBMS copy到 S3，如下圖所示。

第三個工具是 AWS Glue。AWS Glue是一個全託管的ETL服務．我們可以從不同的資料來源擷取資料，並且使用Glue catalog來爬整個資料的schema。Glue會嘗試推斷data schema並且能自動識別數種資料格式，如CSV，JSON， 與Apache Avro。

然後我們使用Glue Data Catalog 來建立一個 data catalog當作我們資料的metadata。事實上，Lake Formation就是使用Glue Data Catalog來當作集中式的data catalog。

一但Schema確定好了，我們可以執行我們自己的ETL腳本來轉換我們到資料格式，例如Apache Parquet 轉成 CSV。Glue Data Brew可以讓我們執行資料清理的作業，正規化我們的資料，並且執行數個不同的feature transformation。

小提示:
Glue除了是一個serverless ETL的強大的工具，它還有其他功能，我們可以用Glue Data Brew作資料視覺化，用 Data Crawler來梳理跟推斷資料的schema，使用 Glue Data Catalog對我們的資料進行編目。使用Glue對資料梳理與分類可以讓我們將資料從一個格式轉換成另一個，然後執行ETL作業，並將資料落地到另一個data source。如以下範例圖:

Streaming Data Collection

對於許多應用程式，例如感測器和 IoT 設備、video或新聞提要以及即時社交媒體串流，我們可能希望以串流方式而不是batch方式將資料上傳到 AWS。 對於串流媒體場景，我們可以使用 Kinesis 服務系列。 我們將在本節中從較High level層次描述每個 Kinesis 服務。

Kinesis 服務系列一共有以下四種:

• Kinesis Data Streams
• Kinesis Data Firehouse
• Kinesis Data Analytics
• Kinesis Video Streams

Kinesis Data Streams

這是一個我們可以用來處理大量的即時影音串流資料(如下圖)。一旦資料以串流方式進到AWS，我們可以運作數種從Kinesis Data stream的下游AWS服務，例如在儀表板看及時的資料分析。同樣的這項服務也可以用來串流不同的應用程式與感測器，並即時地處理這些資料產生指標與報告。

以下是一些Kinesis Data Streams的基本概念

• 一個Data stream呈現的是一群data records，data records 是一個 unit of data。Data records會被分布到shards。一個shard 呈現的是序列的data records。每個shard 支援最多5個transactions/seconds read或最多2MB per second與1000筆records/second，最多能夠1MB per second的data write。當我們建立Kinesis Data Stream時，我們需要指定shards的數量。
• 資料保留時間對應資料在streams中可用的時間長度。預設是24小時，但我們可以調整到365天(也就是8,760個小時)。
• 一個Producer(例如 web log server)可以puts records在stremas中。我們可以使用KPL(Kinesis Producer Library)來建立我們的producer application。
• 一個Consumer會從streams 中get record並處理它們。Consumer applications通常是一群的EC2 instance。 KCL(Kinesis Client Library)abstracts許多lower-level的 Kinesis data stream API，讓我們管理我們的consumer application，如分散這些負載到不同的consumer，處理instance failure，與checkpoint records。

Kinesis Data Firehouse

通常我們也許需要直接傳送streaming data到我們的終端服務中存放起來，例如S3，Redshift，Elastic Search/ Splunk或其他第三方endpoint(如Datadog)。在這種狀況下，與其開發複雜的perducer-consumer application(如 Kinesis Data Streams)，我們更可以使用Kinesis Data Firehouse(如下圖)。

Kinesis Data Firehouse可以自動的將我們的資料送到我們上面所提到的這些服務中。也可以將我們的資料做格式轉換，例如從 JSON轉成Parquet ORC然後存放在S3中。也可以讓我們在位將資料送到目的端前先使用Lambda函數來處理傳送進來的資料。

小提示:
如果是要傳送資料到Redshift中，雖然都是全自動的。但是背景作業是Firehouse會建立一個中介的S3 bucket存放轉換過的資料，再觸發Redsifht的 Copy指令將資料從S3移動Redshift。

Kinesis Data Analytics

這一項服務可以直接對streaming data執行 SQL query。而執行結果可以被傳送到Firehouse(或之後再傳送到S3/ Redshift/ ElasticSearch/ Splunk)或Kinesis Data Stream。

這一項服務也可以被用來產生指標與聚合分析一段時間內的時間序列(time series)資料與之後串流這些資料到S3或data warehouse。也可以被用來匯入資料到即時性的Dashboard或建立real-time的指標並針對監控觸發告警。

Kinesis Data Analytic與Firehouse或Data stream不同，資料不需要直接來自streaming sources。它需要Data Firehouse或Data Stream或 S3 作為input，並將 SQL query的output發送回 Kinesis Data Streams 或 Firehouse，以供其他consumer或 AWS 服務進行下游處理(如下圖所示)。

Kinesis Video Streams

這個服務顧名思義就是將串流影音傳送到AWS雲端中。這個服務一樣可以讓我們送入大量的及時影音進到AWS，來源可以是 WebCam， 車內的鏡頭，無人機鏡頭，監控鏡頭，智慧手機鏡頭等。當然除了影像外，這項服務也可以單獨處理聲音與RADAR資料。

這項服務的作業原理與data stream相似，一樣有producer的概念(上述提到的設備)，而consumer一樣是一群的EC2，上面搭載了我們處理這些影音的應用程式，或是我們也可以用 AWS Rekognition當成consumer來辨識影像。

Kafka-Based Applications

Apache Kafka 是一種常見的streaming dsata開源工具。 如果我們之前使用過Kafka，我們可能已經注意到kinesis的基於producer、consumer的decouple模型與Apache Kafka非常相似。

總結

在本文中，我們涵蓋了更普遍使用的資料以及特定於 ML 的資料的不同術語。。 我們隨後討論了相關的 AWS 資料存儲庫及其最終用途。 我們還探索了各種 AWS 工具，用於將資料導入 AWS，然後導入 S3 以進行 ML。 我們分別討論了兩種資料收集模式：batch 和streaming。