Tập tành theo học và thi AWS Data Analytics Specialty

Review thi AWS Data Analytics Specialty

Đợt vừa rồi mình được gia hạn chương trình AWS Community Builder nên có thêm 1 voucher miễn phí thi AWS nên mình có thi chứng chỉ AWS Data Analytics Specialty.

Đây là lần thứ 4 mình nhận được voucher thi AWS miễn phí từ cộng đồng AWS, tất cả mọi lần mình đều chọn thi cấp độ Professional hoặc Specialty.

Tiện đây mình chia sẻ với mọi người một số trải nghiệm trong quá trình mình lấy chứng chỉ này.

Đầu tiên thì chứng chỉ này sẽ hướng đến các bạn làm Data Engineer, mình thì chắc chắn không phải dân Data rồi nên mình học để tìm hiểu xem các dịch vụ về Data của AWS có gì thấn thánh không thôi.

Mục tiêu của mình là thỏa mãn tính tò mò làm sao để tận dụng được khối dữ liệu khổng lồ hàng trăm GB tới hàng TB, cũng như làm sao để tận dụng được hết khả năng tính toán của các dịch vụ Cloud để tối ưu về mặt chi phí và hiệu quả. Ví dụ có một số câu hỏi như:

• Cách join giữa nhiều CSDL khác nhau, chẳng hạn như join 1 bảng ở RDS Aurora với 2 bảng trong DynamoDB.

• Lưu trữ 1TB thế nào cho nó tiết kiệm nhất mà v​ẫn truy vấn được như SQL thông thường?

• Tôi muốn query số lượng lớn file CSV có số cột khác nhau thì phải làm thế nào?

Sau khi học xong chứng chỉ n​ày mọi người có thể tự tìm ra cách giải các bài toán tương tự như vậy.

Các trường hợp này rất thực tế, nếu dữ liệu nhỏ thì ít ai nghĩ tới nhưng nếu dữ liệu có tính chất phức tạp và nhiều thì chắc sẽ gặp thêm nhiều vấn đề còn hóc búa hơn.

Nội dung thi DAS-C01 bao gồm 5 chủ đề sau để mọi người hiểu được cách dữ liệu đi vào và đi ra như thế nào. Ứng với mỗi phần sẽ có các dịch vụ AWS tương ứng để mình hiểu được nó được sử dụng để làm gì. Các dịch vụ phổ biến như S3, Lambda, DynamoDB, SQS, SNS, IAM thì chắc chắn không thể thiếu trong bài thi này rồi.

1. Collection (Thu thập)

2. Storage and Data Management (Lưu trữ và quản lý dữ liệu)

3. Processing (Xử lý)

4. Analysis and Visualization (Biểu​ diễn)

5. Security (Bảo mật)

COLLECTION (THU THẬP)

• Đối với d​ữ liệu near real-time thì có Amazon Kinesis Data Firehose sẽ hỗ trợ buffer data để đưa dữ liệu từ điểm A tới điểm B. (Ví dụ gom dữ liệu trong vòng 10 phút ghi 1 lần thay vì ghi liên tục, ngoài ra nó hỗ trợ transform data trong quá trình vận chuyển bằng AWS Lambda​). Hay sử dụng để đẩy Data vào RedShift hoặc OpenSearch một các gọn gàn.

• Đối với dữ liệu real-time thì có Amazon Kinesis Data Streams. Đi kèm với khái niệm Shard sẽ có UpdateShardCount và Resharding để tăng hoặc giảm băng thông (1 Shard bằng 1MB/s).

• Kinesis Client Library sẽ giúp resume khi có sự cố nhờ việc nó lưu vị trí cuối cùng trong DB theo từng consumer.

• Về việc đảm bảo thứ tự order của Amazon Kinesis Data Streams thì sẽ đi theo từng partition key, nên để đảm bảo thứ tự order chắc chắn không thể xử lý song song. Ví dụ 2 consumer cùng xử lý theo đúng thứ tự cùng lúc, chắc chắn phải 1 ông làm và một ông chờ ông kia làm xong rồi mới xử lý tiếp cái tiếp theo.

• Vậy nên việc tăng số lượng Shard lên thì sẽ tăng băng thông để xử lý nhiều partition key khác nhau cùng một lúc. Điều này đồng nghĩa dữ liệu đẩy vào cũng phải ngẫu nhiên về partition key thì mới tận dụng hết sức mạnh của chúng được và thứ tự order sẽ không được đảm bảo.

STORAGE AND DATA MANAGEMENT (LƯU TRỮ VÀ QUẢN LÝ DỮ LIỆU)

• Cần nắm được cách tổ chức dữ liệu trên S3. Ví dụ, để query SQL bằng Athena nhanh nhất thì nên chia folder theo từng ngày tháng năm thì khi s​ử dụng điều kiện WHERE theo ngày tháng năm thì Athena chỉ quét mỗi folder (partition) cần thiết thôi. Sẽ hạn chế được việc scan những data không cần thiết.

• Các kiểu nén và file format sẽ giúp giảm dung lượng lưu trữ và tối ưu việc truy xuất dữ liệu (Parquet, Snappy, Gzip, Glacier)

PROCESSING (XỬ LÝ)

• Ban đầu khi mới tìm hiểu về Apache Spark thì mình thấy cũng thấy khá rắc rối. Cách cài đặt Spark cũng tương đối phức tạp nên mình từ bỏ việc cài trên máy local để test. Nhưng không sao, AWS có dịch vụ Glue Studio để kéo thả các bước xử lý data, đồng thời nó cũng tự sinh ra code Spark nên không cần phải lọ mọ code nữa. Về cú pháp của Spark thì nó chuyên để xử lý dữ liệu nên mình thấy nó na ná LinQ bên .NET. Có vài lệnh mình nhớ như ApplyMapping để đổi tên cột, Relationalize để làm phẳng các trường thì đều có thể thử bằng cách kéo thả trên Glue Studio.

• Glue cũng chính là thứ được nhắc tới nhiều nhất, Glue có công cụ Crawler, hiểu đơn giản nó sẽ đi quét toàn bộ dữ liệu của tất cả các folder trên S3 để xem nó có cấu trúc schema như thế nào. Trong quá trình crawl data nó sẽ hỗ trợ phát hiện cấu trúc dữ liệu (schema) của một số dạng file hoặc DB. Quy tắc tạo schema là nếu số lượng data được quét qua có mức độ khớp với table schema hiện tại thấp hơn 70% thì nó sẽ tạo ra table schema mới. Ngoài ra cũng sẽ có trường hợp nó sẽ tạo version mới của schema nếu có thêm column xuất hiện trong dữ liệu được quét qua.

• Theo mình đoán nếu không dùng Crawler thì vẫn qu​ery được bằng cách chỉ định partition (folder) và tạo table bằng DDL Glue một cách thủ công. Nếu dùng Crawler thì nó tự động làm 2 bước này.

• Nếu bạn biết dữ liệu của mình có cấu trúc từng line như thế nào rồi thì có thể dùng Custom Classifier (grok, json). Do data có thể là file CSV không c​ó​ header nên không thể biết tên column nếu không chỉ định trước. Nếu kết quả Crawler trả về là Unsupported thì sẽ không query được do lúc này dữ liệu không thuộc định dạng có thể query hoặc tên cột có chứa ký tự đặc​ biệt.

• Athena thì nó sẽ dựa vào Glue để quét data. Glue nó biết data của mình có cấu trúc như thế nào và lưu ở đâu rồi nên việc của Athena chỉ là quét toàn bộ lượng data đó thôi. Nếu mà chưa chạy Glue Crawler mà chạy query Athena thì khả năng cao là không có data đâu, do nó đâu biết được data cần quét lưu ở đâu.

• Còn Hadoop thì mình thực sự thua món này. Cơ mà cứ có câu nào hỏi EMR với Glue mà liên quan tới hiệu quả với chi phí thì loại EMR bởi nó vừa đắt và quản lý cũng vô cùng vất vả. Mình nghe nói là cài Hadoop tốn vài tháng chưa xong, trong đề thi cũng không hỏi kỹ về món này nên không lo.

• Amazon Kinesis Data Analytics sử dụng cú pháp SQL để phân tích dữ liệu thời gian thực. Ví dụ: Phân tích dữ liệu trong một khoảng thời gian ngắn hoặc phát hiện dữ liệu trước lớn hơn dữ liệu sau. Cụ thể hơn là phát hiện nhiệt độ tăng đột ngột trong vòng 5 phút để trigger Lambda bắt Notification. Flink thì mình chưa rõ nhưng nó sẽ liên quan tới application.

• Điển hình là Amazon RedShift, nó sẽ là CSDL SQL nhưng mà dữ liệu có thể lưu trên nhiều node để tính toán trên từng node con rồi đẩy về node cha để tổng hợp lại. Điểm mấu chốt ở đây có thể là làm sao để phân phối dữ liệu trên nhiều node một cách hiệu quả. Ví dụ: Một số table có số lượng dữ liệu nhỏ nếu cần truy cập thường xuyên thì sẽ để distribution styles là ALL, đổi lại nó sẽ ghi lâu hơn. Đồng nghĩa sẽ tốn dung lượng sẽ lưu trên tất cả các node. Còn distribution styles Even và Key thì lưu từng node riêng.

• Về kiến trúc thi RedShift cho phép hàng chục máy tính trong cùng để xử lý query đồng thời nên tối ưu hơn cho lượng data lớn.

• Cần tìm hiểu cách giới hạn query trên RedShift, ưu tiên những query ngắn. Tương tự cho Athena cũng có thể giới hạn số lượng data tối đa để hạn chế việc query quá nhiều data hoặc quá lâu.

• RedShift spectrum sẽ tương tự Athena dùng để query S3 mà không cần phải load dữ liệu vào DB.

ANALYSIS AND VISUALIZATION (BIỂU​ DIỄN)

• Về QuickSight. Đối với gói Enterprise sẽ có thêm nhiều các nhiều tính năng như tích hợp SSO AD, QuickSight để nhúng interactive Dashboard cho đỡ tốn công dev.

• Cần nắm các dạng biểu đồ phổ biến và trường hợp sử dụng. Ví dụ world map, pivot, pie chart.

• Spice là bộ nhớ tạm của QuickSight để lưu thông tin dữ liệu dùng cho Dashboard, đỡ tốn công phải query lại.

SECURITY (BẢO MẬT)

• Vấn đề muôn thủa, cứ mã hóa KMS, HSM, phân quyền IAM hẹp nhất, phân quyền theo column trên R​edShift, phân quyền ​DB user chỉ xem ​được View để tránh truy cập một số column chứa dữ liệu nhạy cảm, phần quyền và chia sẻ data qua Lake Formation

Quả thực những lần thi như này không đòi hỏi các bạn phải có kinh nghiệm thực tế hay thực hành nhiều. Nếu nắm được concept và các tính năng của các AWS services về Data thì lấy chứng chỉ không phải là khó. Có một số dịch vụ mình chỉ biết sự tồn tại của nó mà chưa bao giờ sử dụng như MSK (Kafka), DataPipeline, Data Exchange, DMS, EMR, Flink, Hudi.

Mình làm tổng cộng 3 đề trên TD, tổng công khoảng 160 câu. Mỗi tối mình làm khoảng 20 câu, tầm 1 tuần mới xong một cái đề do cũng không có nhiều thời gian. Mỗi đề tỉ lệ trả lời đúng được tầm 50 đến 60% thì thi luôn. Kết quả 819/1000.

Có khoảng 3 4 câu ở TD giống 100% đề thi thật thôi. Còn lại phải đọc đề thật kỹ mới dám khoanh.

Mình dùng hết 220 phút làm bài nên dư sức mình làm xong rồi dò lại từng chữ thêm 1 lượt nữa.

Có gì sai sót mong anh em góp ý giúp mình nhé.

Mình gợi ý 2 link này để mọi người tham khảo trước khi thi khá bổ ích.

• https://github.com/anebz/cloud/blob/main/Certifications/aws_data_anaytics_specialty.md

• https://www.vladsiv.com/aws-data-analytics-exam-experience/