AWS認證考試”資料分析”重點整理

此考試是要驗證測試者有以下的能力:

1. 定義AWS 資料分析服務並理解它們之間彼此如何整合。
2. 解釋AWS 資料分析服務如何適應收集、儲存、處理和視覺化的資料生命週期。

該考試分為以下五個領域:

1. 收集(Collection — 佔18%考題)
2. 儲存與管理資料(Storage and Data Management — 佔22%考題)
3. 處裡( Processing — 佔24%考題)
4. 分析與視覺化(Analysis and Visualization —佔18%考題 )
5. 安全( Security — 佔18%考題)

Domain 1 收集(Collection)

1.決定收集系統的運作特性

1.1確認服務發生故障時資料遺失在容忍範圍內(也就是RPO)

• Kinesis KPL在傳送資料時如果失敗會自動重送(失敗資料會回到KPL buffer中)。詳情請參閱AWS文件1與文件二。
• Kinesis Data Streams 不適合資料持久性或長期資料儲存。 但是，資料將保留 24 小時，最多可以將保留期延長 365 天。

KCL 使用並處理來自 Kinesis 資料流的資料。 KCL 還提供＂checkpointing＂功能，它使用使用 DynamoDB 作為資料處裡歷程記錄，以持久追蹤從 Kinesis 流中的分片讀取的記錄。重點有二：

1. 由於 KCL 替我們建立DynamoDB table，因此在 KCL 中為每個應用程式使用唯一的應用程式名稱非常重要。
2. 如果串流有太多shards，或者應用程式經常執行checkpointing，可能會遇到 DynamoDB 預設throghtput的異常錯誤。

• Kinesis Agent 是安裝在VM上的軟體，提供的功能有file rotation, checkpointing, retry等機制

1.2評估與資料”擷取、傳輸”和從各種服務的啟用到收集系統相關的成本（例如網路、頻寬、ETL、資料遷移）

• 如果我們要長期使用EMR，哪我們可以購買EC2的RI節省我們的費用。如果是中度使用者則可以用RI + Spot instance來處理我們的資料分析工作
• EMR是將 storage與compute去耦合，意思是我們可以根據不同的工作負載運行在適合的cluster中，達到好的成本效益與要求的SLA

1.3評估收集系統可能遇到的故障場景，並根據影響採取補救措施

1.4決定資料擷取的各個資料點(儲存/處理)的資料持久性

• KDS可以保留/replay資料 — 1–365天，資料存入後無法被刪除
• 一般而言，EMR的reduce 作業從多個mapper 任務接收資料，並將output存儲到HDFS 進行持久化
• EMR Core node 與 data node的功能差不多，實際的作業執行者並將運算資料儲存到 HDFS中
• EMR task node 與core nodes最大的不同點是，它們不儲存資料在HDFS中。只是純粹的運算單元
• S3的資料特性是eventually consistent。EMRFS提供的consistent view是lists與 read-after-write的object，而且EMRFS需要知道目前資料在S3的資料一致性的狀態是甚麼。所以ERMFS使用的DynamoDB來記錄目前資料的一致性狀態
• Redshift spectrum可以幫我們Query在S3中的資料。Redshift managed storage實際上將storage和compute分開，因為它可以針對這兩個資源個別付費。當我們啟用 Redshift managed storage時 data block的功能就會被由instance的內部硬碟轉到S3中，而在instace 中的硬碟則會被當作cache layer。所以這將再度延伸Redshift可以處理的資料量。

S3等級比較表

1.5識別收集系統的延遲特徵

KDS的Consumer:

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

2.選擇一個能夠處理資料各項特性(頻率、資料量和來源)的收集系統

KDS(Kinesis Data Stream)

KDF(Kinesis Data Firehose)

KDF資料交付

2.1描述並表徵進入資料的量體和流量特徵(例如，串流、交易資料、大量資料)。

AWS將資料收集分為三種

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

Kinesis Data Streams

搭配Kinesis Client Library(KCL)

2.2將資料流特徵與潛在解決方案相符

2.3評估各種資料擷取服務之間的權衡，並考慮可擴展性、成本、容錯和延遲

• KDS可以存放資料，所以資料是可以被reprocess/ replay 的。而在處理資料Consumers可以同時是多個應用程序，意思是同一個data stream同時可以服務多個consumer。並且因為需要服務多個應用程序(consumers)所以我們可以提高整個輸出資料的throughput。另外資料一旦進入Kinesis它就不能被刪除，直到資料的保留時間到期。而Shard則是最小的計費單位，意思是我們使用的shard的數量越多費用就會拉高。但運作過程中我們可以依當時運作的需求對shard實行 reshard作業。
• KDS Shard則是最小的計費單位，意思是我們使用的shard的數量越多費用就會拉高。但運作過程中我們可以依當時運作的需求對shard實行 reshard作業。

2.4解釋各種類型的資料收集解決方案的吞吐量，並識別瓶頸

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

• 資料存放在Kinesis stream最高可以存放七天(預設是24小時)，也就是說Kinesis stream的服務內部是有storage存放資料的(Kinesis Firehose則沒有)。
• Kinesis Producer SDK 資料超過限制後有三種處置方式。 1.)Retire with backoff, 2.)增加shards, 或是3.)確認我們的partition key的設計是正確的。
• Kinesis stream的本身並沒有包含到自動擴展功能(額外的API call)，而Kinesis Data Firehose(KDF)可以自動擴展(Near Real time服務 — 非完整批次的最短延遲時間為 60 秒)

2.5選擇滿足來源資料系統連線限制的收集解決方案

3.選擇一個能夠解決資料關鍵屬性（例如順序、格式和壓縮）的收集系統

3.1描述如何從源頭擷取資料變化

• KPL的功能沒有壓縮這一個，如果要做資料壓縮得要自己來。而KPL的資料必須使用KCL(Kinesis client library)或特別的函式庫才可以進行解碼
• AWS Glue可以使用Crawler探索來源端中的資料並將些資料的metadata分享給其他AWS的服務。使用AWS Glue的好處在於，當我們的source system, data format, target schema有變動的話我們不需要再重寫code去適應這些變動。
• AWS Glue可偵測到來源端的異動是使用的AWS Glue裡的Glue Bookmarks的功能。但Glue bookmarks只能做到增量變動的偵測(identifying delta records)。所以來源端的資料(records)被update時bookmarks是不會知道有異動的。

3.2討論資料結構和格式、應用的壓縮以及加密要求

• KDF傳送目標是到S3時還可以支援過程中能夠資料壓縮(GZIP/ZIP/SNAPPY格式)，但如果是要將資料載入到Redshift的話，而目前只支援GZIP。
• KPL無法壓縮，必須在client端自行處理
• KDF支援的資料格式有 JSON轉換成 Parquet/OCR(only for S3)
• KDF使用Lambda 將CSV轉換成JSON
• 當目的地是S3時，KDF支援 GZIP/ZIP/SNAPPY等壓縮格式
• 當目的地是Rdedshift，KDF支援GZIP

3.3區分資料無序遞送、資料重複遞送以及at-most-once/exactly-once/at-least-once處理之間的權衡的影響

at-least-once — 意指資料一定會送到，但可能有資料重複問題
at-most-once — 意指資料只會送一次，但可能有資料遺失問題
exactly-once — 資料一定會送到，且不會重複

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

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。

3.4描述如何在收集過程中轉換和過濾資料

• KDF可以在S3中的檔案做轉換(JSON變成 Parquet/ ORC)，若要其他的轉換(例如CSV變JSON)，則需要搭配AWS Lambda。

更多的"資料收集"資訊，請參閱"AWS的大數據分析-Part 1資料收集"一文。

Domain 2 儲存與管理資料

1.決定用於分析的儲存解決方案的運作特徵

DynamoDB tables

• DynamoDB 也使用transactional讀寫 API 支援符合 ACID(atomicity, consistency, isolation, and durability) 的transactions

DynamoDB Global tables

1.1根據成本與效能比較來確定適當的儲存服務

• Redshift managed storage中的data block的功能就會從instance的內部硬碟轉換到S3中，而在instace 中的硬碟則會被當作cache layer

1.2根據需求了解儲存解決方案的耐久性、可靠性和延遲特性

1.3決定系統對儲存系統的strong consistency或eventual consistency的需求

• DynamoDB有兩種資料讀取模式(預設是Eventually consistent reads與Strongly consistent reads)。但沒有data write consistency可以設定

1.4決定適當的儲存解決方案來滿足資料更新度要求

2.確定資料存取和檢索模式

2.1根據資料更新模式(例如bulk/transactional/micro batching)決定適當的儲存解決方案

2.2根據存取模式（例如依序或隨機存取、連續使用或一次性使用）確定適當的儲存解決方案

2.3決定適當的儲存解決方案來解決資料的變化特徵(append-only changesc或updates)

2.4決定適合長期儲存和臨時性的儲存解決方案

2.5為結構化資料和半結構化資料決定合適的儲存解決方案

2.6決定適當的儲存解決方案來滿足查詢延遲要求

3.選擇適當的資料佈局(layout)、模式(schema)、結構(structure)和格式

3.1確定適當的機制來滿足模式演化需求

3.2為特定任務選擇適當的儲存格式

3.3為所選儲存格式選擇適當的壓縮和編碼(encoding)策略

3.4選擇適當的資料排序和分佈策略以及儲存佈局以實現高效的資料存取

3.5解釋不同資料分佈、佈局和格式（例如檔案的大小和數量）對成本和效能的影響

3.6實施資料格式化和分割區方案以進行資料最佳化分析

4.根據使用模式和業務需求定義資料生命週期

4.1確定適當的策略來滿足資料生命週期要求

4.2將適當的生命週期和資料保留(retention)策略應用於不同的儲存解決方案

5.確定適當的系統來編目(catalog)資料和管理metadata

5.1評估"探索新的和已更新的"資料來源的機制

5.2評估”建立和更新”資料目錄和metadata的機制

5.3解釋”搜尋和檢索”資料目錄和metadata的機制

5.4解釋資料標記(tag)和分類的機制

Domain 3 處理(Processing)

1.決定適當的資料處理解決方案要求

1.1了解資料準備和使用要求

1.2了解不同類型的資料來源和目標

• External Hive Metastores = AWS Glue Data Catalog

1.3評估效能和編排(orchestration)需求

• HDFS本身不是設計來進行低延遲的資料存取，如果需要的話應該是用Hbase

1.4評估適當服務的成本、可擴展性和可用性

2.設計一個解決方案來轉換和準備資料以進行分析

2.1對批次工作負載和即時工作負載應用適當的 ETL 和 ELT 技術

• Best Practices — 使用Copy command 將資料載入Redshift。另外可以使用Lambda來對新資料做出回應，也可以結合Copy command。

DynamoDB紀錄Lambda處理歷程

• Glue ETL (Full managed service) — 可以使用Python/Scala編寫代碼，或是使用Spark/PySpark腳本。資料目的地可以是s3/JDBC(RDS/Redshift)/Glue Data Catalog。Job是運行在serverless Spark platform，且可以用Glue scheduler進行排程。

2.2實施故障轉移、擴展和複製(replication)機制

2.3實施技術來解決併發(concurrency)需求

2.4實施提高成本優化效率的技術

2.5編排工作流程

2.6聚合和豐富(Aggregate and enrich)下游使用的資料

Glue ETL 的資料轉換(這是基於Apache Spark技術，轉換檔案格式支援CSV/JSON/Avro/Parquet/ORC/XML)

• Bundled Transformations:
  -DropFields, DropNullFields — 移除(null)fields
  -Filter — 指定一個函數來過濾資料
  -Join — 豐富其資料
  -Map — 加入/刪除 fields，進行external lookups
• ML transformations:
  -FindMatches ML — 識別資料集中的重複或匹配的資料，即使資料沒有共同的唯一識別碼並且沒有完全匹配的fields

3.自動化和實施資料處理解決方案

3.1實施可重複工作流程的自動化技術

• Glue ETL中的Glue Trigger根據Events來自動運作。

3.2應用方法來識別處理故障並從中恢復

3.3部署日誌記錄和監控解決方案以實現稽核和可追溯性

ETL Glue的Glue Job是一種Time-based排程(Corn style)，可以使用Job Bookmarks來達到

1. Job運行中的狀態紀錄，避免重新處理到舊資料
2. 允許我們僅在按排程重新運作時處理新資料
3. 可以處理來自S3中不同的資料格式
4. 透過JDBC與RDBS連結，但只限於Primary Key是有順序性且只能加入新資料無法更改舊資料
5. 透過CloudWatch Events可以:
   -當ETL Job成功/失敗時，觸發Lambda函數或SNS notification
   -開啟EC2，把event送到Kinesis，觸發一個Step Function

Domain 4 分析與視覺化

1.決定分析和視覺化解決方案的運作特徵

1.1決定跟分析和視覺化相關的成本

• Kinesis Analytics — charged by KPU(Kinesis Processing Unit)，1 KPU = 1 vCPU + 4GB。Schema discovery/ serverless services

1.2決定跟分析相關的可擴展性

• OpenSearch service — scale up/down需要手動，並且計費是 — Instance-hours/storage/data transfer

1.3決定在規定的RPO 和 RTO 的故障轉移復原和容錯

1.4決定分析工具的可用性特徵

• QuickSight的SPICE engine是跨多個AZ並有備份在S3中。所以具備其高可用度

1.5評估資料的動態、互動式和靜態呈現

1.6將效能要求轉換為適當的視覺化方法（例如，預先計算和使用靜態資料、動態資料）

2.針對特定場景選擇合適的資料分析解決方案

2.1評估和比較分析解決方案

• Kinesis Analyutics -RANDOM_CUT_FOREST —
  一種SQL函數，用在異常偵測(如詐欺) — 也就是outliners偵測

2.2根據客戶使用案例選擇正確的分析類型（例如串流分析、互動式分析、協作式分析、操作分析）

3.針對特定場景選擇合適的資料視覺化解決方案

3.1評估特定分析解決方案的輸出能力（例如指標、KPI、表格、API）

3.2選擇適當的資料交付方法

3.3選擇並定義適當的資料刷新排程

3.4針對不同的資料新鮮度要求選擇合適的工具（例如 OpenSearch Service、QuickSight、EMR notebooks）

• OpenSearch — Petabyte-scale analysis and reporting

3.5了解視覺化工具用於互動式使用案例的功能

QuickSight各類的 Visual type適用的情況

更多的使用案例請參閱"AWS的大數據分析-Part 4資料視覺化"一文

3.6實現適當的資料存取機制

Domain 5 安全(Security)

1.選擇適當的身份驗證和授權機制

KDS Security

1.1實施適當的身份驗證方法（例如聯合存取、SSO、AWS IIAM）

• EMR也提供多種安全保護，包含用VPC提供網路層保護，使用KMS將分析完的資料在S3中加密。甚至可以使用AWS Macie機器學習模型來偵測，分類，保護EMR裡的資料。存取控制可以用IAM而驗證則能使用Kerberos。
• Kinesis Stream與 Lambda的結合使用(poll from Kunesis)必須是在同一個AWS Account

1.2實作適當的授權方法（例如政策、ACL、表格和欄位權限）

1.3實施適當的存取控制機制（例如，安全群組、基於角色的控制）

EMR需要三種不同的roles來運行整個platform:

• EMR role : 讓EMR可以存取資源(如EC2)
• EC2 instance profile: 讓cluster裡的EC2可以存取資源(如S3)
• Auto Scaling role : 允許可以執行EC2的 auto scaling out/in
• QuickSight Enterprise的版本可以將資料的存取控制在 row-level

這些role在creat cluster時如果是不存在的話EMR會create他們。

• IAM roles沒有諸如密碼和訪問密鑰之類的long-term credential。 相反，assuming roles將導致為roles sessions提供臨時安全憑證。
• AWS EMR Managed Security Groups唯一的目的就是控制cluster內部通訊與其他AWS資源的通訊

2.應用資料保護與加密技術

2.1決定資料加密和屏蔽(masking)需求

2.2應用不同的加密方法（例如server-side , client-side 、KMS、CloudHSM）

2.3實施靜態和傳輸中加密機制

2.4實施資料混淆和屏蔽(obfuscation and masking)技術

2.5應用密鑰輪替(key rotation)和密鑰管理(secrets management)的基本原則

3.應用資料治理和合規控制

3.1決定資料治理和合規性要求

3.2了解並配置跨資料分析服務的存取和稽核日誌記錄

3.3實施適當的控制以滿足合規性要求

Cross Account Access

Identity Federation