AWS Thai Blog

Reference architecture ของ Data Analytics Pipeline แบบ Serverless บน AWS

การ Onboarding ข้อมูลใหม่ หรือสร้าง analytics pipelines แบบใหม่ ใน analytics architectures หรือสถาปัตยกรรมการวิเคราะห์ข้อมูลแบบเก่า มักต้องการความร่วมมือภายในองค์กรทั้งในทีม business, ทีม data engineering, ทีม data science และทีมวิเคราะห์ เพื่อหารือกันเรื่องความต้องการ, โครงสร้าง schema, ความจำเป็นในการใช้งาน infrastructure capacity รวมถึงการจัดการภาระงาน

เนื่องจากในปัจจุบัน รูปแบบใช้งานต่างๆนั้น มีจำนวนมากขึ้น ทำให้ business users, data scientists และนักวิเคราะห์ข้อมูล ต้องการที่จะสร้าง data pipeline แบบ end-to-end ที่ทั้งง่าย ยืดหยุ่น และจัดการตัวเองได้ เพราะการคาดเดาโครงสร้าง schema ที่เปลี่ยนแปลงอยู่ตลอดเวลา รวมถึงเวลาที่ใช้ในการจัดการ infrastructure ที่ใช้ร่วมกัน เป็นเรื่องที่ยาก ส่วนการพัฒนา machine learning (ML) และการวิเคราะห์งานจำนวนมาก ทำให้คุณต้องรีบนำเข้า datasets ใหม่ๆ และจัดระเบียบ, สร้างมาตรฐาน และทำ feature engineering (process ด้าน machine learning ที่จะใช้ความรู้ใน domain ด้านนั้นๆ extract ข้อมมูลออกมาเป็น feature เช่น characteristics, properties, attributes จาก raw data) โดยไม่ต้องกังวลถึง operational overhead (effort ที่ต้องใช้ในการ operate งาน) ด้านการจัดการ infrastructure ในการทำงานของ data pipeline

Serverless data lake architecture (สถาปัตยกรรม data lake โดยที่ไม่ต้องจัดการ server) ทำให้การ onboarding และวิเคราะห์ข้อมูลภายในบริษัทนั้นมีความคล่องตัว และสามารถปรับแต่งเองได้ ด้วยเทคโนโลยี AWS serverless ผู้ใช้สามารถเข้าถึง data lake และ data processing pipeline เพื่อ Ingest (นำข้อมูลเข้า), Store (จัดเก็บ),​ Transform (ดัดแปลง) และวิเคราะห์ structured (ข้อมูลที่มีโครงสร้าง) และ unstructured data (ข้อมูลที่ไม่มีโครงสร้าง) หลาย petabytes ได้จาก batch และแหล่ง streaming โดยไม่ต้องจัดการพื้นที่จัดเก็บหรือ compute infrastructure

ในบล็อกโพสต์นี้ จะอธิบายถึง ส่วนประกอบต่างๆ ของ analytics platforms ที่ทันสมัย และนำเสนอ reference architecture (สถาปัตยกรรมอ้างอิง) เพื่อสร้าง serverless data platform ซึ่งประกอบไปด้วย data lake, data processing pipelines และ consumption layer เพื่อให้สามารถวิเคราะห์ข้อมูลได้หลากหลายวิธี โดยไม่ต้องมีการย้ายข้อมูล (รวมถึง business intelligence (BI) dashboarding, การทำงานเกี่ยวกับ interactive SQL, big data processing, predictive analytics, และ ML)

Logical architecture ของ modern data lake centric analytics platforms (แพลตฟอร์มการวิเคราะห์ข้อมูลสมัยใหม่ ซึ่งมี data lake เป็นศูนย์กลาง)

แผนภาพต่อไปนี้ แสดงภาพ architecture ของ modern data lake centric analytics platforms

แพลตฟอร์มการวิเคราะห์ข้อมูลซึ่งมี data lake เป็นศูนย์กลาง มี 6 logical เลเยอร์ ในแต่ละเลเยอร์จะประกอบองค์ประกอบหลายอย่าง แบ่งส่วนการทำงาน (decoupling of tasks) และมีความยืดหยุ่น ทั้งหมดนี้ก็เพื่อเพิ่มความคล่องตัวในการรวมรวบแหล่งข้อมูลใหม่ได้อย่างรวดเร็ว รองรับการวิเคราะห์รูปแบบใหม่ และรับมือกับการเปลี่ยนแปลง ในลำดับถัดๆไปผมจะอธิบายในเรื่องหน้าที่การทำงาน, ความสามารถ, ของแต่ละ logical เลเยอร์

Ingestion layer (เลเยอร์การนำข้อมูลเข้า)

Ingestion layer มีหน้าที่นำข้อมูลเข้าไปใน data lake เลเยอร์นี้เพิ่มความสามารถในการเชื่อมต่อทั้ง internal และ external data sources ด้วย protocol จำนวนมาก เลเยอร์นี้สามารถรับ batch และข้อมูล streaming เข้าไปยัง storage layer ได้ อีกหนึ่งหน้าที่ของ ingestion layer คือการลำเลียงข้อมูลที่ได้รับไปยัง data storage layer (รวมถึง object store, databases และ data warehouses)

Storage layer (เลเยอร์การจัดเก็บข้อมูล)

Storage layer มีหน้าที่เก็บข้อมูลปริมาณมาก, ให้ในเรื่องของความคงทน, การ scale, ความปลอดภัย และความคุ้มค่าด้านราคา เลเยอร์นี้รองรับการจัดเก็บข้อมูลที่มีความหลากหลาย ทั้ง unstructured data และ sturcture data ที่มีหลาย format รวมถึงยังรองรับการเก็บข้อมูล โดยไม่ต้องคำนึงถึง schema หรือ format องค์ประกอบจากทุกเลเยอร์ สามารถทำงานร่วมกับเลเยอร์การจัดเก็บได้ง่าย และแบ่งหมวดหมู่เพื่อรองรับการทำงานของแต่ละหน่วยงานในองค์กร ดังนี้

  • Raw zone – เป็นพื้นที่จัดเก็บที่มาจาก ingestion layer land data พื้นที่นี้เป็นพื้นที่ชั่วคราวที่จะรับข้อมูลจากแหล่งข้อมูล โดยปกติแล้ว หน่วยงาน data engineering จะจัดการข้อมูลในพื้นที่นี้
  • Cleaned zone – หลังจากตรวจสอบคุณภาพของข้อมูลเบื้องต้นแล้ว จะย้ายข้อมูลจาก raw zone ไปที่ cleaned zone ในโซนนี้ ข้อมูลจะจัดเก็บใน original format การจัดเก็บข้อมูลถาวรจากทุก sources เพื่อ “replay” หรือย้อนดู downstream data processing ได้เมื่อเกิดข้อผิดพลาด หรือข้อมูลสูญหาย โดยทั่วไปหน่วยงาน data engineering และ data science จะจัดการกับข้อมูลในพื้นที่นี้
  • Curated zone – เป็นพื้นที่จัดเก็บข้อมูลพร้อมใช้งาน ซึ่งเข้ากับมาตรฐานในองค์กร และ data model ชุดข้อมูลจะถูก partitioned, cataloged, และเก็บ format ที่รองรับการใช้งานโดย consumption layer ได้อย่างมีประสิทธิภาพ และคุ้มค่าด้านราคา Processing เลเยอร์จะสร้างชุดข้อมูลใน curated zone หลังจากที่จัดระเรียบ, ปรับปรุง, ทำตามมาตรฐานและ เพิ่มคุณค่าให้กับข้อมูล ทุกหน่วยงานในองค์กรจะใช้ข้อมูลที่จัดเก็บในพื้นที่นี้เพื่อตัดสินใจในทางธุรกิจ

Cataloging and search layer (เลเยอร์การทำรายละเอียดของข้อมูล และการค้นหา)

Cataloging and search layer มีหน้าที่ในการจัดเก็บ metadata ทางธุรกิจและทางเทคนิคที่มาจาก storage layer และยังมีความสามารถในการติดตาม schema และการ granular partitioning ของชุดข้อมูล ที่อยู่ใน data lake รวมถึงยังรองรับกลไกการติดตาม version เพื่อเตรียมพร้อมสำหรับการเปลี่ยนแปลงของ metadata เมื่อจำนวนข้อมูลภายใน data lake มากขึ้น layer นี้ จะสามารถช่วยหาข้อมูลภายใน data lake ได้

Processing layer (เลเยอร์การทำแปลงข้อมูล)

Processing layer มีหน้าที่แปลงข้อมูลให้อยู่ในสภาพที่พร้อมใช้งานผ่านการ data validation, cleanup, normalization, transformation และ enrichment และยังมีหน้าที่ยกระดับความพร้อมใช้งานของข้อมูลภายใน landing, raw และ curated zones รวมถึงการลงทะเบียน metadata สำหรับ raw และ tranformed data ไปยัง cataloging layer ซึ่งเลเยอร์การทำ Processing ประกอบไปด้วย purpose-built data-processing components ที่ถูกสร้างขึ้นมาเพื่อให้เข้ากับ dataset characteristic และประมวลผลข้อมูลในทันที สามารถรับมือกับข้อมูลในประมาณมาก และรองรับ schema-on-read partitioned data และความหลากหลายของ data formats อีกทั้งยังมีความสามารถในการสร้างและควบคุม multi-step data processing pipelines ที่ใช้ purpose-built components ในแต่ละขั้นตอน

Consumption layer (เลเยอร์การใช้ข้อมูล)

Consumption layer มีเครื่องมือรองรับการ scale ที่มีประสิทธิภาพ ซึ่งช่วยรับข้อมูลเชิงลึกจำนวนมากใน data lake เลเยอร์นี้จะทำให้การวิเคราะห์ personas (ลักษณะกลุ่มคน) ทุกหน่วยงานเป็นไปในทิศทางเดียวกัน ผ่านเครื่องมือ purpose-built analytics ที่รองรับ batch analytics, BI dashboards, reporting และ ML โดยปกติแล้ว consumption layer จะทำงานร่วมกับพื้นที่จัดเก็บ data lake cataloging และ security layer ส่วนประกอบใน เลเยอร์การใช้ข้อมูลจะช่วยรองรับ schema-on-read ข้อมูล data structures และ formats จำนวนมาก รวมถึงการใช้ data partitioning เพื่อประสิทธิภาพและความคุ้มค่า

Security and governance layer (เลเยอร์ด้านความปลอดภัยและการระบบจัดการ)

Security and governance layer มีหน้าที่ป้องกันข้อมูลใน Storage layer และ Processing layer ในทุกเลเยอร์ เลเยอร์นี้มีกลไกที่เข้าถึงการควบคุม การเข้ารหัส การป้องกันเครือข่ายอินเตอร์เน็ต การตรวจสอบการใช้งาน และการตรวจสอบบัญชี เลเยอร์ด้านความปลอดภัย ยังตรวจสอบการเคลื่อนไหวของทุกๆส่วนประกอบ และสร้างประวัติการตรวจสอบแบบละเอียด

Serverless data lake centric analytics architecture (สถาปัตยกรรม data lake โดยที่ไม่ต้องจัดการ server)

ตามที่กล่าวไว้ใน architecture ของ AWS ที่ใช้ AWS serverless และ managed services ซึ่งจะมาช่วยแก้ไขปัญหาต่อไปนี้

  • ให้บริการและจัดการเรื่องการ scale, resilient (การกลับสู่สภาพเดิมเมื่อเกิดปัญหา), และความคุ้มค่าด้านราคา ของส่วนประกอบต่างๆ
  • การทำงานร่วมกันของแต่ละส่วนประกอบ

Reference architecture นี้ ทำให้ผู้ใช้สามารถโฟกัสเวลาไปที่การพัฒนา data และ analytics pipelines รวมถึงยังสามารถรับและค้นหาข้อมูลใหม่ได้อย่างรวดเร็ว AWS serverless และ managed components จะช่วยให้สามารถเข้าถึงข้อมูลได้ด้วยตัวเอง โดยมีผลลัพธ์ดังนี้

  • มีรูปแบบการใช้งานที่ง่าย
  • ไม่ต้องจัดการระบบในระบบโครงสร้างพื้นฐาน
  • รูปแบบราคาเป็นแบบ Pay-per-use ใช้ตามที่จ่ายจริง

แผนภาพดังต่อไปนี้จะแสดงภาพ architecture

Ingestion layer

Ingestion layer ใน architecture แบบ serverless จะประกอบไปด้วย purpose-built AWS ที่สร้างขึ้นเพื่อรับข้อมูลที่มาจากหลากหลายแหล่งข้อมูล ในแต่ละเซอร์วิสจะมีความสามารถในการทำ self-service data ingestion ไปยัง data lake landing zone และยังสามารถทำงานร่วมกับเซอร์วิส AWS อื่นๆใน storage และ security layers ได้ โดยแต่ละ purpose-built AWS services สามารถรองรับ การเชื่อมต่อ,​ รูปแบบของข้อมูล, โครงสร้างของข้อมูล และอัตราเร่งของการนำข้อมูลเข้า,​ รองรับข้อมูลแบบ streaming และไฟล์ที่หลากหลาย

Operational database sources

โดยปกติแล้ว แต่ละองค์กรจะเก็บ operational data ไว้ในฐานข้อมูลแบบ relational และ NoSQL โดย AWS Data Migration Service (AWS DMS) สามารถเชื่อมต่อเข้ากับระบบฐานข้อมูล RDBMS กับ NoSQL และรับข้อมูลไปยัง Amazon Simple Storage Service (Amazon S3) ใน landing zone ของ data lake AWS DMS จะช่วยให้ผู้ใช้สามารถรับ one-time import จาก source data เข้าไปใน data lake และสำเนาข้อมูลการเปลี่ยนแปลงที่เกิดขึ้นใน source database ได้ AWS DMS สามารถเข้ารหัส S3 objects ได้ โดยใช้ AWS Key Management Service (AWS KMS) ที่เก็บไว้ใน data lake ทั้งยังเป็นระบบเต็มรูปแบบที่ยืดหยุ่น ที่ให้ตัวเลือกหลากหลายในการทำสำเนาข้อมูล

AWS Lake Formation มีความสามารถในการ scale และเป็นรูปแบบ serverless มี blueprints เพื่อนำข้อมูลจาก AWS native หรือ แหล่งฐานข้อมูลแบบ on-premises ไปยัง landing zone ใน data lake และ Lake Formation blueprint ยังเป็นเทมเพลตที่มีไว้เพื่อสร้างการนำข้อมูลเข้าใน AWS Glue workflow โดยอิงจากค่า parameters เช่น source database, target Amazon S3 location, target dataset format, target dataset partitioning columns และ schedule blueprint-generated ใน AWS Glue workflow จะใช้การ optimized และ parallelizedใน data ingestion pipeline ซึ่งประกอบไปด้วย crawlers, parallel job และการเชื่อมต่อตามเงื่อนไข สำหรับข้อมูลเพิ่มเติม สามารถเข้าไปที่นี่ Integrating AWS Lake Formation with Amazon RDS for SQL Server

Streaming data sources

Ingestion layer จะใช้ Amazon Kinesis Data Firehose เพื่อรับข้อมูล streaming จากทั้ง internal และ external sources เพียงไม่กี่คลิก ผู้ใช้ก็จะสามารถกำหนด Kinesis Data Firehose API endpoint เพื่อส่ง streaming data เช่น clickstreams, application และ infrastructure logs และ monitoring metrics, และ IoT data เช่น การส่งสัญญาณจากอุปกรณ์ และการอ่านค่าเซนเซอร์ โดย Kinesis Data Firehose จะมีหน้าที่ดังนี้

  • Buffers การรับข้อมู, streaming
  • Batches, compresses, transforms และ encrypts stream
  • เก็บข้อมูล streaming เป็น S3 objects ที่ landing zone ใน data lake

Kinesis Data Firehose ทำงานร่วมกับ เลเยอร์ด้านความปลอดภัย และ เลเยอร์การจัดเก็บ ทั้งยังสามารถส่งข้อมูลไปที่ Amazon S3, Amazon Redshift และ Amazon OpenSearch Service เพื่อวิเคราะห์รูปแบบการใช้งานในทันที Kinesis Data Firehose เป็นระบบ serverless ที่ทำงานได้ด้วยตัวเอง และยังมีโมเดลค่าใช้จ่ายที่จ่ายเฉพาะปริมาณข้อมูลที่ส่งผ่านและประมวลผลในตอนใช้งาน ซึ่ง Kinesis Data Firehose จะขยายขนาดตามปริมาณข้อมูลที่รับมาได้โดยอัตโนมัติ

File sources

หลายๆแอปพลิเคชันได้เก็บ structured และ unstructured data ไว้ในไฟล์ที่ตั้งอยู่ใน Network Attached Storage (NAS) หลายๆองค์กรจะได้รับไฟล์ข้อมูลจาก partners และ third-party vendors การวิเคราะห์ข้อมูลจากไฟล์เหล่านี้จะช่วยเพิ่มความได้เปรียบทางด้านธุรกิจ

การแชร์ intertal file

AWS DataSync จะรับข้อมูลได้มากกว่า 100 เทระไบต์ และไฟล์กว่าล้านไฟล์จาก NFS และ SMB ผ่านการใช้งานเครื่องมือ NAS เพื่อเข้าสู่ data lakeใน landing zone โดย DataSync จะจัดการการเขียนสคริปต์งาน กำหนดเวลาและตรวจสอบการถ่ายโอน ตรวจสอบความสมบูรณ์ของข้อมูล รวมถึงจัดการการใช้งานเครือข่ายอินเทอร์เน็ต DataSync สามารถถ่ายโอนไฟล์แบบ one-time transfers, ตรวจสอบ และซิงค์การเปลี่ยนแปลงข้อมูลเข้าไปใน data lake ดังนั้น DataSync จึงเป็นระบบแบบเต็มรูปแบบที่พร้อมติดตั้งได้ภายในไม่กี่นาที

ไฟล์ข้อมูลของ partner

FTP เป็นวิธีทั่วไปที่ใช้ในการแลกเปลี่ยนไฟล์ข้อมูลกับ partners โดย service ที่เข้ามาช่วยจัดการตรงส่วนนี้คือ AWS Transfer Family เป็น serverless ที่มีขนาดพื้นที่เยอะและขยายขนาดได้ ซึ่งรองรับความปลอดภัยของ FTP endpoints และทำงานร่วมกับ Amazon S3 ทาง Partners กับผู้ผลิตจะส่งไฟล์โดยใช้ SFTP protocol และใช้ AWS Transfer Family จัดเก็บข้อมูลไว้ในรูปแบบ S3 objects ที่ landing zone ใน data lake นอกจากนี้ AWS Transfer Family ยังสามารถรองรับการเข้ารหัสโดยใช้ AWS KMS และวิธีระบุตัวตนทั่วไป เช่น AWS Identity and Access Management (IAM) และ Active Directory

Data APIs

องค์กรในปัจจุบันจะใช้ SaaS และ partner application เช่น Salesforce, Marketo และ Google Analytics เพื่อสนับสนุนการทำธุรกิจ การวิเคราะห์ SaaS และ partner data ด้วย intertal operational application data เป็นสิ่งจำเป็นสำหรับการวิเคราะห์ข้อมูลทางธุรกิจทุกรูปแบบ ทั้ง Partner และ SaaS applications มักมี API endpoints ไว้สำหรับแชร์ข้อมูล

SaaS APIs

Ingestion layer จะใช้ AWS AppFlow เพื่อรับข้อมูล SaaS application เข้าสู่ data lake เพียงแค่ไม่กี่คลิก ผู้ใช้จะสามารถติดตั้ง serverless data ingestion flows ได้ใน AppFlow Flow ของผู้ใช้งานจะสามารถเชื่อมต่อกับ SaaS application (เช่น SalesForce, Marketo และ Google Analytics) รับข้อมูล และจัดเก็บไว้ใน data lake ผู้ใช้สามารถกำหนดเวลาการรับข้อมูล AppFlow หรือเปิดใช้งานตามสถานการณ์ได้ใน SaaS application ข้อมูลที่รับมาสามารถนำไปตรวจสอบ, กรอง, รวบรวม และคัดแยก ก่อนจัดเก็บไว้ใน data lake ซึ่ง AppFlow จะทำงานร่วมกับระบบการระบุตัวตน สิทธิ์การเข้าใช้งาน และการเข้ารหัสใน security และ governance layer

Partner APIs 

เพื่อรับข้อมูลจาก partner และ third-party APIs องค์กรจะต้องสร้างหรือซื้อ custom applications ที่เชื่อมต่อกับ APIs ที่สามารถดึงข้อมูลและสร้าง S3 objects ใน landing zone ผ่านการใช้ AWS SDKs ได้ แอปพลิเคชันและ dependencies สามารถจัดเก็บได้ใน Docker containers และสร้างไว้ใน AWS Fargate ซึ่ง Fargate เป็น serverless compute engine สำหรับ Docker containers ที่ไม่จำเป็นต้องตรวจสอบ จัดการ และขยายขนาดเซิร์ฟเวอร์ Fargate ทำงานร่วมกับระบบความปลอดภัยและการตรวจสอบระบบของ AWS เพื่อการเข้ารหัส การเข้าใช้งาน ความปลอดภัยทางอินเทอร์เน็ต การบันทึกข้อมูล และการตรวจสอบคลังเก็บแอปพลิเคชัน

AWS Glue Python shell jobs เป็นทางเลือกในด้าน serverless เพื่อสร้างและกำหนดการรับข้อมูลที่สามารถทำงานร่วมกับ partner APIs โดยใช้ native open-source หรือ Python libraries ของ partner ซึ่ง AWS Glue มอบความสามารถมากกว่าที่กำหนดในคำสั่งเดียวของ Python shell jobs สามารถรวมเป็นระบบ workflow รับข้อมูล ที่ซับซ้อนขึ้นใน AWS Glue workflows

Third-party data sources

องค์กรของคุณจะมีแต้มต่อทางธุรกิจมากขึ้นโดยการรวม internal data กับ third-party datasets เช่น บันทึกข้อมูลประชากร, ข้อมูลสภาพอากาศ และข้อมูลพฤติกรรมผู้ใช้งาน ซึ่ง AWS Data Exchange จะให้บริการแบบ serverless เพื่อค้นหา ติดตาม และรับข้อมูลโดยตรงจาก third-pary เข้าสู่ S3 bucket ภายใน data lake landing zone ผู้ใช้สามารถรับข้อมูลทั้งหมดของ third-party เพื่อเช็คและตรวจสอบข้อมูล AWS Data Exchange เป็นระบบแบบ serverless ที่จะช่วยให้หาและรับข้อมูล third-party ได้เพียงไม่กี่คลิก

Storage layer

Amazon S3 เป็นฐาน storage layer สำหรับข้อมูลใน architecture ซึ่ง Amazon S3 ให้บริการการขยายข้อมูลแบบไม่จำกัดในงบประมาณที่ไม่แพงสำหรับ serverless data lake ข้อมูลจะถูกจัดเก็บเป็น S3 objects ที่รวบรวมไว้ใน landing raw และ curated zone buckets รวมถึง prefixes ซึ่ง Amazon S3 จะเข้ารหัสข้อมูลโดยใช้ key managed ใน AWS KMS, IAM policies จะควบคุม zone-level และ dataset-level สำหรับผู้ใช้งานและคนอื่นๆ นอกจากนี้ Amazon S3 ยังให้ availability ของ service ถึง 99.99% และระดับความคงทนของข้อมูลอยู่ที่ 99.999999999% อีกทั้งยังเสียค่าใช้จ่ายเฉพาะข้อมูลที่จัดเก็บไป เพื่อการลดค่าใช้จ่ายของผู้ใช้ Amazon S3ให้บริการตัวเลือกพื้นที่จัดเก็บแบบ archive tier ที่ชื่อว่า Amazon S3 Glacier และ S3 Glacier Deep Archive เพื่อความคุ้มค่าของราคา Amazom S3 ยังมีบริการแบบ life cycle policies และตัวเลือกการจัด tiering อันชาญฉลาดที่จะย้ายข้อมูลเก่าไปยัง colder tier ระบบ AWS ใน ingestion, cataloging, processing, และ consumption layers สามารถเขียนและอ่าน S3 object ยิ่งไปกว่านั้น ยังมีผู้ให้บริการรายอื่น รวมถึงสินค้าและบริการแบบโอเพนซอร์ส อีกมากมายที่มีความสามารถในการอ่านและเขียน S3 object

ข้อมูลจาก structure (รวมถึง unstructured data) และ format ต่างๆ สามารถเก็บเป็นรูปแบบของ S3 object โดยไม่ต้องคำนึงถึง schema การเก็บข้อมูลรูปแบบนี้จะเปิดใช้งาน services ใน ingestion layer เพื่อรองรับข้อมูลที่มาจากหลาย source เข้าสู่ data lake ใน source format เดิม หลังจากรับข้อมูลเข้า data lake component ใน processing layer จะคาดการณ์ schema ล่วงหน้าโดยอิงจาก S3 datasets และบันทึกข้อมูล cataloging layer การบริการใน processing และ comsumption layer สามารถใช้ schema-on-read เพื่อใช้ structure ในการอ่านข้อมูลจาก S3 object ชุดข้อมูลที่เก็บไว้ใน Amazon S3 มักจะมีการทำ partitioned เพื่อการคัดกรองแบ่งกลุ่มของข้อมูลที่มีประสิทธิภาพใน processing และ consumption layer

Cataloging and search layer

โดยปกติแล้ว data lake จะรองรับชุดข้อมูลจำนวนมาก ซึ่งชุดข้อมูลนั้นจะเปลี่ยนเป็น schema และ new data partitions โดย Central Data Catalog ที่จัดการ metadata สำหรับ datasets ทั้งหมดใน data lake เป็นสิ่งที่จำเป็นในการเริ่มต้นหาข้อมูลด้วยตัวเองใน data lake นอกเหนือจากนั้น การแยก metadata จาก data เข้าสู่ central schema จะทำให้ใช้งาน schema-on-read สำหรับ processing และ consumption layer components ได้

ใน architecture จะมี Lake Formation จะมี central catalog เพื่อจัดเก็บและจัดการ metadata สำหรับ dataset ที่อยู่ใน data lake ในแต่ละองค์กรจะจัดการทั้ง technical metadata (เช่น versioned table schemas, partitioning information, physical data location, และการอัพเดท timestamps) และคุณลักษณะทางธุรกิจ (เช่น data owner, data steward, column business definition, และ column information sensitivity) ของชุดข้อมูล ใน Lake Formation จะทำงานร่วมกับ AWS Glue, Amazon EMR และ Amazon Athena รวมถึงค้นหาและลงทะเบียนข้อมูล metadata เข้าไปใน Lake Formation catalog โดยอัตโนมัติ นอกเหนือจากนั้น Lake Formation ยังมี APIs ใน metadata registration และจัดการ metadata ผ่าน custom scripts และผลิตภัณฑ์จาก third-party ซึ่ง AWS Glue crawlers ใน processing layer สามารถติดตามการเปลี่ยนแปลงของ schemas และเพิ่ม partition ใหม่ๆ ของชุดข้อมูลใน data lake รวมถึงสร้างการ corresponding ของ metadata ใน Lake Foundation catalog

Lake Formation จะมี data lake administrator เพื่อใช้ดูแลส่วนกลางของ data lake เพื่อติดตั้ง granular table และ column-level permissions สำหรับ databases และ tables hosted ใน data lake หลังจากที่เข้าถึง Lake Formation ได้แล้ว users และ groups สามารถเข้าถึง authorized tables และ columns ผ่านการใช้บริการ processing และ consumption layer เช่น Athena, Amazon EMR, AWS Glue, และ Amazon Redshift Spectrum

Processing layer

Processing layer ใน architecture ประกอบไปด้วย 2 ส่วนประกอบคือ

  • Components ที่ใช้สำหรับสร้าง multi-step data processing pipelines
  • Components ที่ใช้ควบคุม data processing pipelines ตามกำหนดเวลา หรือ เริ่มใช้งานตามสถานการณ์ (เช่น การรับข้อมูลใหม่เข้าสู่ landing zone)

AWS Glue และ AWS Step Functions มี serverless component ไว้เพื่อสร้าง ควบคุม และใช้งาน pipelines ที่สามารถขยายขนาดตามปริมาณของข้อมูลในการประมวลผลได้อย่างง่ายดาย การสร้าง Multi-step workflows โดยใช้ AWS Glue และ Step Function จะสามารถ catalog, validate, clean, transform และพัฒนาชุดข้อมูล โดยส่งจาก landing ไป raw และ raw ไป curated zone ใน storage layer

AWS Glue เป็นเซอร์วิส ETL แบบ serverless ที่เสียค่าใช้จ่ายแค่ตอนใช้งาน เพื่อการสร้างและใช้งาน Python หรือ Spark jobs (เขียนใน Scala หรือ Python) โดยที่ไม่ต้องใช้งานหรือจัดการ clusters ซึ่ง AWS Glue จะสร้างโค้ดขึ้นมาเพื่อเร่งกระบวนการแปลงข้อมูลและการโหลดข้อมูลการประมวลผลโดยอัตโนมัติ AWS Glue ETL สร้างขึ้นโดยใช้ Apache Spark และบริการ data source connectors, data structures และ ETL transformations ที่ใช้กันเป็นปกติเพื่อ validate, clean, transform, และบีบอัดข้อมูลที่เก็บในโอเพนซอร์ส format เช่น CSV JSON Parquet และ Avro นอกจากนี้ AWS Glue ETL ยังมีความสามารถในการประมวลผลข้อมูลที่ partitioned ไปแล้ว

ยิ่งไปกว่านั้น ผู้ใช้สามารถใช้ AWS Glue เพื่อใช้งาน crawlers เพื่อ crawl ไปตาม folders ใน data lake ค้นหา datasets และ partition จัดทำ schema รวมถึงกำหนด tables ใน Lake Formation catalog ซึ่ง AWS Glue มี built-in classifiers ที่สามารถแยก data structures ที่เก็บอยู่ในโอเพนซอร์ส formats นอกจากนี้ AWS Glue ยังมีความสามารถ triggers และ workflow capabilities ที่สามารถนำไปสร้าง data processing pipelines ที่หลายขั้นตอนแบบครบวงจร ซึ่งประกอบด้วย job dependencies และขั้นตอนการทำงานแบบ parallel คุณยังสามารถกำหนดการทำงาน AWS Glue Jobs และ workflows ได้ด้วยตัวเอง โดย AWS Glue จะทำงานร่วมกับ AWS services ภายใน storage, catalog และ security layers

Step Functions เป็น serverless engine ที่สามารถนำไปสร้างและควบคุมตารางเวลา หรือใช้งานตาม event-driven data processing workflows ผู้ใช้สามารถใช้ Step Functions เพื่อสร้าง data processing pipelines ที่ซับซ้อนเพื่อคุมระบบการทำงานโดยใช้ AWS services เช่น AWS Glue, AWS Lambda, Amazon Elastic Container Service (Amazon ECS) และอย่างอื่นอีกมากมาย Step Functions ทำให้ workflows ที่ซับซ้อนนั้นง่ายต่อการเข้าใจขึ้น Engine นี้จะจัดการ state checkpoints และ restarts ของ workflow เพื่อให้แน่ใจว่าเป็นไปตามระบบ data pipeline ที่คาดหวังไว้ ความสามารถแบบ try/catch retry และ rollback ที่อยู่ใน engine จะจัดการกับข้อผิดพลาดและปัญหาได้โดยอัตโนมัติ

Consumption layer

Consumption layer ใน architecture ให้บริการการวิเคราะห์ตาม purpose-built แบบเต็มรูปแบบที่สามารถใช้งานร่วมกับ SQL, BI dashboarding, batch processing และ ML

Interactive SQL

Athena เป็นเซอร์วิส interactive query ที่สามารถใช้งาน ANSI SQL ที่ซับซ้อนและข้อมูลที่เก็บอยู่ใน Amazon S3 ไว้หลายเทระไบต์โดยที่ไม่ต้องโหลดข้อมูลเข้า database ก่อนได้ ซึ่ง Athena queries สามารถวิเคราะห์ structured semi-structed และ columnar data ที่เก็บไว้ใน open-source formats เช่น CSV, JSON, XML Avro, Parquet และ ORC Athenaใช้ข้อมูลตารางจาก Lake Formation เพื่อใช้งานร่วมกับ schema-on-read ในการอ่านอ่านข้อมูลจาก Amazon S3

เนื่องจาก Athena เป็นระบบแบบ serverless จึงไม่ต้องการ infrastructure เพื่อติดตั้งและใช้งาน ซึ่งเสียค่าใช้จ่ายเฉพาะจำนวนข้อมูลที่ queries ได้สแกนไป ซึ่ง Athena ให้ผลลัพธ์ที่รวดเร็ว และลดค่าใช้จ่ายได้โดยการลดจำนวนข้อมูลที่ต้องสแกนผ่านการใช้ dataset partitioning information ใน Lake Formation catalog ผู้ใช้สามารถใช้ queries โดยตรงผ่าน Athena console หรือใช้ผ่าน Athena JDBC หรือ ODBC endpoints

Athena ทำงานร่วมกับเซอร์วิสของ AWS ใน security และ monitoring layer เพื่อรองรับการระบุตัวตน การเข้าใช้งาน, การเข้ารหัส รวมถึงการบันและทึกและการตรวจสอบ และ Athena ยังรองรับการเข้าถึง table- และ column-level ที่กำหนดไว้ใน Lake Formation catalog

Data warehousing และการวิเคราะห์แบบ batch

Amazon Redshift เป็นเซอร์วิส data warehouse แบบเต็มรูปแบบที่สามารถรองรับและประมวลผลข้อมูลได้หลาย petabytes รวมถึงเรียกใช้ queries ที่มีประสิทธิภาพในรูปแบบ parallel โดย Amazon Redshift ใช้หลาย compute nodes ในการเรียกใช้ queries ที่มีค่า latency queries ต่ำ เพื่อใช้งาน interactive dashboards และการวิเคราะห์ batch จำนวนมาก เพื่อช่วยในการตัดสินใจทางธุรกิจ ผู้ใช้สามารถใช้ Amazon Redshift queries โดยตรงผ่านคอนโซล Amazon Redshift หรือใช้ผ่าน JDBC/ODBC endpoints ของ Amazon Redshift

Amazon Redshift มีความสามารถที่เรียกว่า Amazon Redshift Spectrum ซึ่งใช้งานได้ใน queries บนชุดข้อมูลแบบ structured และ semi-structured ใน Amazon S3 โดยไม่ต้องเพิ่มเข้าสู่ cluster ซึ่ง Amazon Redshift Spectrum จะสร้าง nodes ที่จำเป็นสำหรับ query ไว้เป็นจำนวนมาก สำหรับการสแกนข้อมูลหลาย exabytes เพื่อผลลัพธ์ที่รวดเร็ว โดยปกติแล้ว องค์กรจะเพิ่ม dimension และ fact data เข้าไปใน Amazon Redshift cluster และเก็บข้อมูลประวัติรูปแบบ structured, semi-structured และ unstructured ใน Amazon S3 ไว้มากกว่าหลาย exabytes ซึ่ง Amazon Redshift Spectrum สามารถเรียกใช้งาน queries ที่ซับซ้อนเพื่อรวมข้อมูลจาก cluster และ Amazon S3 เข้าด้วยกันใน query เดียว

Amazon Redshift จะทำงานร่วมกับ Amazon S3 ใน storage layer, Lake Formation catalog และเซอร์วิสของ AWS ใน security และ monitoring layer

Business intelligence

Amazon QuickSight คือเซอร์วิส serverless BI เพื่อสร้างและเผยแพร่ interactive dashboard จำนวนมากได้อย่างง่ายดาย ซึ่ง Quicksight จะเพิ่มความสามารถแดชบอร์ดด้วยข้อมูลเชิงลึกจาก ML เช่น forecasting, anomaly detection และ narrative highlight โดย QuickSight จะทำงานร่วมกับ Amazon SageMaker เพื่อใช้งานการตั้งค่า ML ตามข้อมูลเชิงลึกของแดชบอร์ด BI ผู้ใช้สามารถใช้งานแดชบอร์ด QuickSight จากอุปกรณ์ใดก็ได้ที่มีแอปพลิเคชัน QuickSight หรือ embedded แดชบอร์ดไว้ในเว็บแอปพลิเคชัน พอร์ทัล และเว็บไซต์ต่างๆ

QuickSight ช่วยเชื่อมต่อและรับข้อมูลจากคลาวด์และ on-premises data sources ซึ่งประกอบด้วยแอปพลิเคชัน SaaS เช่น Salesforce, Square, ServiceNow, Twitter, GitHub,  และ JIRA รวมถึง third-party databases เช่น Teradata, MySQL, Postgres  และ SQL Server ทั้งยังมีเซอร์วิสของ AWS เช่น Amazon Redshift, Athena, Amazon S3, Amazon Relational Database Service (Amazon RDS), กับ Amazon Aurora และ private VPC ผู้ใช้สามารถอัปโหลดสกุลไฟล์ได้หลายสกุล เช่น XLS CSV JSON และ Presto

เพื่อที่จะรับประสบการณ์ความสามารถแดชบอร์ดที่รวดเร็ว QuickSight มี in-memory caching และเอนจินสำหรับการคำนวนที่ชื่อว่า SPICE เอนจินนี้จะสำเนาข้อมูลให้เพียงพอสำหรับการรองรับผู้ใช้งานจำนวนมากในคราวเดียวกัน และมีการวิเคราะห์แบบ interactive ในขณะที่ป้องกัน underlying data infrastructure ไปด้วย โดย QuickSight จะขยายการรองรับจำนวนผู้ใช้ได้ถึงหมื่นกว่าคน และมีค่าบริการที่คุ้มค่าแบบ pay-per-session

QuickSight ช่วยจัดการผู้ใช้และเนื้อหาให้ปลอดภัยผ่านฟีเจอร์ความปลอดภัยที่ประกอบด้วย security features เช่น role-based access control, active directory integration, AWS CloudTrail auditing, single sign-on (IAM หรือ third-party), private VPC subnets, และ data backup

Predictive analytics และ ML

Amazon SageMaker เป็นเซอร์วิสแบบเต็มรูปแบบที่ให้ components ไว้ build, train และ deploy ใช้งาน ML models โดยใช้ interactive devolopment environment (IDE) ที่ชื่อว่า Amazon SageMaker Studio ภายใน Amazon SageMaker Studio ผู้ใช้สามารถอัปโหลดข้อมูล, สร้าง notebooks ใหม่, train และ ปรับแต่ง tune models ทำขั้นตอนซ้ำไปมาเพื่อปรับแต่งการทดลอง, เปรียบเทียบผลลัพธ์ และส่ง models ไปสู่ production โดยทั้งหมดนี้เกิดขึ้นได้ในที่เดียวผ่านการใช้ unified visual interface ซึ่ง Amazon SageMaker ยังให้การจัดการ Jupyter notebooks ที่เริ่มต้นใช้งานได้เลยภายในไม่กี่คลิก และ Amazon SageMaker notebooks มี elastic compute resource และ git integration มีระบบที่ง่ายต่อการแบ่งปัน, pre-configured ML algorithms และตัวอย่าง ML ที่พร้อมใช้งานจำนวนมาก รวมถึงยังมี AWS Marketplace ที่สามารถใช้งานหลายอัลกอริทึมที่เขียนมาแล้วได้อย่างง่ายดาย โดย Amazon SageMaker notebooks มาพร้อมกับ major deep learning frameworks อย่าง TensorFlow, PyTorch, Apache MXNet, Chainer, Keras, Gluon, Horovod, Scikit-learn และ Deep Graph Library

ML models ที่ถูก train ใน Amazon SageMaker managed compute instance ซึ่งมี Amazon Elastic Compute Cloud (Amazon EC2) Spot Instances ที่คุ้มค่า คุณสามารถจัดการรูปแบบการ train ที่หลากหลายพร้อมกันได้โดยใช้ Amazon SageMaker Experiments และยังสามารถสร้าง​ training job ได้โดยใช้อัลกอรึทึมภายในของ Amazon SageMaker หรืออัลกอริทึมของผู้ใช้เอง หรืออัลกอริทึมอื่นๆ จาก AWS Marketplace นอกจากนี้ยังมี Amazon SageMaker Debugger ทำให้เห็นภาพรวมของการ train รวมถึง Amazon SageMaker ยังสามารถปรับแต่งค่า hyperparameter สำหรับการฝึก ML ได้โดยอัตโนมัติ

ผู้ใช้สามารถใช้งานโมเดลของ Amazon SageMaker ใน production ได้เพียงไม่กี่คลิกและยังสามารถ scale โมเดลไปไว้ใน EC2 instances ได้อย่างเต็มรูปแบบ ผู้ใช้สามารถเลือกรูปแบบของ EC2 instance ได้หลากหลายรูปแบบและใช้งานกับระบบ GPU-powered inference acceleration ที่คุ้มค่า หลังจากการใช้งานโมเดล Amazon SageMaker จะช่วยตรวจสอบ key model metris เพื่อสรุปผลความแม่นยำและตรวจสอบการเปลี่ยนรูปแบบของข้อมูล

Amazon SageMaker จะทำงานร่วมกับเซอร์วิส AWS ใน storage และ security layers

Security และ governance layer

Components จากทุกเลเยอร์ของ architecture จะปกป้องข้อมูล ตัวตน และ resources ที่ประมวลผลโดยใช้ความสามารถที่มีจาก security และ governance layer

Authentication and authorization (การระบุตัวตนและการให้สิทธิ์เข้าใช้งาน)

IAM จะระบุตัวตนผู้ใช้งาน, กลุ่ม, role level และกำหนดการเข้าถึงการควบคุม resources แบบละเอียดผ่านการเซอร์วิส AWS ในทุกเลเยอร์ของ architecture ซึ่ง IAM จะรองรับ multi-factor authentication และ single sign-on ผ่านสารระบบและข้อมูลระบุตัวตนจากการร่วมมือของผู้ให้บริการ เช่น Google, Facebook และ Amazon

Lake Formationให้เซอร์วิสการศูนย์กลางการจัดการสิทธิ์ สำหรับ tables ที่จัดเก็บไว้ใน data lake หลังจากใช้งานใน Lake Formation นโยบายสิทธิ์การเข้าใช้งานของ databases และ tables จะถูกบังคับใช้โดยเซอร์วิส AWS อื่นๆ เช่น Athena, Amazon EMR, QuickSight และ Amazon Redshift Spectrum ภายใน Lake Formation ผู้ใช้สามารถให้สิทธิ์หรือยกเลิกระดับการเข้าใช้งาน database table หรือ column ของ IAM users groups หรือ roles ที่กำหนดไว้ใน account เดียวกันใน Lake Formation catalog หรือ account อื่น ของ AWS รูปแบบการให้สิทธิ์/ถอนคืนรูปแบบง่ายของ Lake Formation จะทำให้ทำงานง่ายกว่าเดิม เพราะการให้สิทธิ์แบบเดิมของ IAM พึ่งการรักษาความปลอดภัยแบบแยกส่วนของ S3 data objects และ metadata objects ภายใน AWS Glue Data Catalog

Encryption (การเข้ารหัส)

AWS KMS มีความสามารถในการสร้างและจัดการคีย์การเข้ารหัสแบบ symmetric และ Asymmetric ของผู้ใช้งาน service ของ AWS ในทุกเลเยอร์ของ architecture จะทำงานร่วมกับ AWS KMS เพื่อเข้ารหัสข้อมูลภายใน data lake ซึ่งรองรับการสร้างทั้งคีย์ใหม่ๆ และรับคีย์ที่มีอยู่จากผู้ใช้งาน การเข้าใช้งาน encryption keys จะได้รับการควบคุมผ่านการใช้ IAM และรับการตรวจสอบผ่าน audit trails ที่ละเอียดใน CloudTrail

Network protection (การป้องกันระบบเครือข่าย)

Architecture ของ AWS จะใช้ Amazon Virtual Private Cloud (Amazon VPC) เพื่อจัดเก็บ logically isolated section ของ AWS Cloud (หรือเรียกว่า VPC) ที่แยกข้อมูลมาจากอินเทอร์เน็ตและผู้ใช้งาน AWS คนอื่นๆ ซึ่ง AWS VPC ทำให้ผู้ใช้สามารถเลือก IP address range สร้าง subnets และกำหนด route tables กับ network gateways ได้ด้วยตัวเอง เซอร์วิส AWS จากเลเยอร์อื่นๆ ใน architecture จะให้ resource ไว้ใน VPC ส่วนบุคคล เพื่อป้องกันทุกข้อมูลที่เข้าออกของแหล่งทรัพยากร

Monitoring และการทำ logging

เซอร์วิส AWS ในทุกเลเยอร์ของ architecture จะเก็บบันทึกข้อมูลที่ละเอียดและ monitor ระบบเมทริกซ์ใน AWS CloudWatch ซึ่ง CloudWatch มีความสามารถในการวิเคราะห์ข้อมูล logs, นำเสนอ monitored metrics, กำหนด monitoring thresholds  และส่งการแจ้งเตือนเมื่อถึง threshold ที่กำหนด

ทุกเซอร์วิสใน architecture ของ AWS ยังได้เก็บ audit trails ของผู้ใช้งานและประวัติการใช้บริการ ไว้ใน CloudTrail ซึ่ง CloudTrail จะแสดงประวัติการใช้งาน account AWS รวมถึงประวัติจาก AWS Management Console, AWS SDKs, command line tools,  และเซอร์วิสอื่นๆของ AWS ซึ่งประวัติข้อมูลนี้ช่วยให้การวิเคราะห์ความปลอดภัย, resource change tracking  และการแก้ไขปัญหา ทำได้ง่ายขึ้น รวมถึง CloudTrail ยังสามารถตรวจจับประวัติที่ผิดปกติใน account AWS ด้วยความสามารถทั้งหมดนี้ช่วยให้การวิเคราะห์การทำงานและการแก้ไขปัญหานั้นง่ายขึ้นอย่างมาก

ข้อควรพิจารณาเพิ่มเติม

ในโพสต์นี้ AWS ได้พูดคุยเรื่องการ ingesting data จากหลายๆ แหล่งข้อมูลและจัดเก็บเป็น object ใน S3 ภายใน data lake และใช้ AWS Glue เพื่อประมวลผล ingested datasets จนเข้าสู่ consumable state ซึ่ง Architecture นี้ช่วยให้รูปแบบการใช้งานที่ต้องการค่า source-to-consumption latency แบบนาทีกับชั่วโมง สามารถใช้งานได้ สำหรับโพสต์ต่อไปในอนาคต AWS จะพัฒนา serverless analytics architecture เพื่อเพิ่ม speed layer สำหรับรูปแบบการใช้งานที่ต้องการค่า source-to-consumption latency แบบวินาที รวมถึงปรับปรุง layered logical architecture ที่นำเสนอไป

บทสรุป

ด้วยบริการการจัดการแบบ serverless ของ AWS ผู้ใช้สามารถสร้าง architecture ศูนย์รวมการวิเคราะห์ที่ทันสมัยและค่าใช้จ่ายไม่แพงได้ภายในไม่กี่อึดใจ Architecture อีกรูปแบบหนึ่งที่ขับเคลื่อนด้วย component นี้ จะช่วยให้ตอบโจทย์ความต้องการและแหล่งข้อมูลใหม่ๆต่อไป

AWS อยากชวนให้อ่านโพสต์ วิธีการใช้งานอย่างละเอียดและโค้ดเบื้องต้นสำหรับการสร้าง components ของ serverless data lake centric analytics architecture