บทความนี้มีเนื้อหาดัดแปลงมาจากบทความภาษาญี่ปุ่นของ Classmethod, Inc. ในหัวข้อ「AWS IoT 再入門ブログリレー AWS IoT Analytics編 | DevelopersIO」 หากผู้อ่านสนใจอ่านเนื้อหาต้นฉบับสามารถอ่านได้ที่ลิ้งค์ "บทความต้นฉบับ" ด้านล่าง เนื้อหาในบทความนี้การอัพเดทเนื้อหาบางอย่างเพื่อให้เข้าใจง่ายขึ้นทำให้แตกต่างจากต้นฉบับในบางจุด
ภาพรวม
สวัสดีครับ ต้าครับ
ในบทความนี้เราจะมาแนะนำเกี่ยวกับบริการ "AWS IoT Analytics" ที่ทำหน้าที่ รวบรวม, ปรับเปลี่ยน, ใช้งาน ข้อมูล IoT กันครับ
บทนำ
เมื่อเราใช้งาน IoT จะมีหลายๆสิ่งที่เราต้องการให้เกิดขึ้นเช่น "การมองเห็นได้ว่าหน้างานมีการเปลี่ยนแปลงอย่างไร", "การวิเคราะห์ข้อมูลหน้างาน", "การตรวจสอบสิ่งผิดปกติ"
โดยการที่จะทำสิ่งเหล่านี้ได้ เราจำเป็นต้องทำการ collect, process, store, analyze, และ visualize ข้อมูล IoT ไว้อย่างเหมาะสม เตรียมเอาไว้ครับ
โดย "AWS IoT Analytics" ที่เราจะแนะนำต่อจากนี้ จะเป็นบริการที่จะ Support กระบวนการเหล่านี้แบบ Full management Service
อ้างอิง: What is AWS IoT Analytics? - AWS IoT Analytics
ก่อนอื่นที่เราจะเข้าไปยังเนื้อหา ผมจะขอแนะนำเกี่ยวกับคำศัพท์ที่จะได้เจอใน "AWS IoT Analytics" กันก่อนนะครับ
| หน้าที่ | สิ่งที่ควรรู้ | |
|---|---|---|
| Channel | - ทางเข้าของข้อมูล | - ข้อมูลดิลก่อนที่จะได้รับการประมวลผลจะถูกเก็บไว้ใน S3 - วิธีการนำข้อมูลเข้า channel มีอยู่ 2 รูแปบบด้วยกัน |
| Pipeline | - จัดเก็บใน Datastore เพื่อประมวลผลข้อมูลที่ถูกย้ายเข้ามายัง Channel | - ทำการเชื่อมต่อ 1 Datastore กับ 1 Channel - เมื่อทำการเปลี่ยนเนื้อหาที่ถูกประมวลผล สามารถกำหนด "ระยะเวลา" เพื่อประมวลผลอีกรอบได้(←สะดวกมาก!) |
| Datastore | - ผลลัพท์การประมวลผลของ pipeline | - ไฟล์จะถูกบันทึกลงใน S3 - สามารถใช้ 1 Datastore เชื่อมต่อกับ Pipeline หลายจำนวนได้ - สามารถสร้าง Dataset หลายจำนวนจาก 1 Datasotre ได้ |
| Dataset | - ข้อมูลของ Datastore ที่ผ่านการประมวลผล - มีอยู่ 2 รูปแบบคือ "SQL Dataset" กับ "Container Dataset" - สามารถตั้ง schedule ให้ประมวลผลตามกำหนดการณ์ที่เราตั้งได้ |
- ใน "SQL Dataset" จะอัพเดท Dataset ตาม SQL ที่ระบุ - "SQL Dataset" มีรูปแบบที่ไม่รองรับอยู่ - ผลลัพท์ quary ของ "SQL Dataset" สามารถส่งไปยัง S3 หรือ IoT Events ได้ - "Container Dataset" สามารถประมวลผลได้ตามที่ต้องการ |
collect
การที่เราจะย้ายข้อมูลเข้าไปใน "channel" ได้ เราจำเป็นต้องรวบรวมข้อมูลก่อน
ข้อมูลที่ถูกย้ายเข้าไปใน "channel" จะถูกควบคุมดูแลด้วย "S3 Bucket ที่ AWS ควบคุมดูแล" หรือ "S3 Bucket ที่เราควบคุมดูแลด้วยตนเอง"
แต่ไม่ว่าก็เป็นแบบไหนก็คิดค่าบริการในราคาที่เท่ากันครับ
- ข้อมูลดิบ: จัดเก็บไว้ใน Amazon S3 และเรียกเก็บค่าบริการตามมาตรฐานราคา S3
อ้างอิง: ราคา AWS IoT Analytics
โดยวิธีที่จะย้ายข้อมูลเข้าไปยัง "Channel" มีอยู่ 2 วิธี คือ "AWS IoT rule actions" และ "การ PUT BatchPutMessageAPI"
เมื่อทำการเรียบเรียงข้อดีและข้อเสีย จะได้ตามด้านล่างนี้ครับ
ในกรณีของ"การ PUT BatchPutMessageAPI" จะเป็นเคสของ Device ที่ installed "IoT Analytics Greengrass connector" หรือ เคสที่ใช้ Lambda ทำงาน
| ขอดี | ขอเสีย | วิธีใช้ | |
|---|---|---|---|
| AWS IoT rule actions | มีการผ่าน IoT Core ทำให้สามารถแผยแผ่ข้อมูลที่เหมือนกันไปยัง Service อื่นได้ง่าย | มีค่าใช้จ่ายในส่วนที่ดำเนินการ "AWS IoT Rule Action" | ตอนที่อยากเชื่อมต่อข้อมูล IoT กับ AWS Service อื่น |
| BatchPutMessage API | ไม่จำเป็นต้องใช้ "AWS IoT Rule Action" ซึ่งจะช่วยลดค่าใช้จ่ายได้ | แผยแผ่ข้อมูลที่เหมือนกันไปยัง Service อื่นได้ยากกว่า | จะยังไงก็ได้ขอให้ได้เก็บข้อมูลไว้ก่อน |
เราสามารถตรวจสอบ channel ผ่าน AWS Management Console ได้ด้วยครับว่ามี Message เข้ามาเยอะแค่ไหน
Processing
ข้อมูลที่ถูกย้ายใส่ channel จะถูกประมวลผลแบบ near-real time ที่ pipeline
สำหรับ pipeline จะมีจุดเด่นอยู่ 2 อย่างตามที่เขียนด้านล่างนี้
| จุดเด่น | รายละเอียด |
|---|---|
| Diverse processing methods | - ทำการคำนวณแบบพื้นฐาน จำพวก "ทำการ filtering ข้อมูลที่ไม่จำเป็น" หรือ "ทำการเพิ่ม attribute ที่ถูกคำนวณตาม attribute value" - สามารถดึงข้อมูลจาก Device(Shadow, registry) จาก IoT Core - สามารถใช้งานข้อมูลภายนอกโดยเปิดการใช้งาน Lambda function ได้ |
| Easy to recount | - ระบุระยะเวลาข้อมูลที่ถูกบันทึกอยู่ใน channel แล้วสามารถคำนวณอีกรอบได้ - สะดวกตอนที่ทำการปรับเปลี่ยนเนื้อหาการประมวลผลเนื้อหาใน pipeline |
โปรดทราบว่าในกรณีที่การประมวลผลจำเป็นต้องใช้ "ข้อมูลภายนอก" อาจเกิดปัญหาที่ขึ้นอยู่กับข้อมูลภายนอกได้
และจะเกิดค่าใช้จ่ายตามปริมาณข้อมูลที่ประมวลผล
นั่นทำให้เมื่อเราตั้งค่า Pipeline เราจำเป็นต้องระมัดระวังเรื่อง "การประมวลผลข้อมูลที่ไม่จำเป็น" หรือ "การประมวลผลข้อมูลที่ซ้อนกัน"
ซึ่งหัวข้อเหล่านี้สามารถดูได้ในหัวข้อ "การตั้งค่า Dataflow ของ AWS IoT Analytics" ด้านล่างนี้
Store
ข้อมูลที่ประมวลผลด้วย pipeline จะถูกบันทึกใน Datastore(ในสถานะ partitioned โดย processing time ใน S3)
[Dataset] ที่มีการเพิ่มการประมวลผลใน [Datastore] ก็สามารบันทึกลงใน S3 ได้
เมื่อสร้าง [Dataset] จาก [Datastore] ข้อมูลของ[Datastore]จะไม่สามารถใช้คำสั่ง Join หรือ With ได้ โปรดระวังเมื่อทำการสร้าง Datastore
SQL expressions in AWS IoT Analytics
ส่วนเรื่องราคาสามารถตรวจสอบได้จากลิ้งค์ด้านล่างนี้ครับ
（ภาพด้านล่างเป็นของ Region Tokyo）
อ้างอิง: ราคา AWS IoT Analytics
Analyze
จะทำการ Analyze processing ข้อมูลที่ถูกบันทึกใน [Datastore]
และผลลัพท์ของ Analyze ที่เป็น [dataset] ทำการส่งไปยัง S3 และ export metadata ด้วย Glue จะให้สามารถรวม Data lake กับ data ได้
การดึง [dataset] ผ่าน API ยกตัวอย่างเช่น SageMaker บน notebook instance ด้วย Jupyternotebook ก็สามารถอ้างอิง dataset ได้
การวิเคราะห์โดย [AWS IoT Analytics] จะมี 2 รูปแบบคือ [SQL Dataset] กับ [Container Dataset] โดยมีรายละเอียดตามด้านล่างนี้
SQL Dataset
ทำการดำเนินการ SQL กับ [Datastore] และส่งผลลัพท์ไปยัง S3
ถ้าจะให้เปรียบเทียบกับ RDBMS คือให้เรานึกถึง materialized view ครับ
โดยจุดเด่นของ SQL Dataset จะมีดังต่อไปนี้
- สามารถตั้งค่า schedule ได้
- สามารถควบคุมจัดการ Version ได้
- สามารถเพิ่ม Reproducibility กับ ผลลัพท์การวิเคราะห์ได้
- สามารถส่งผลลัพท์ไปยัง S3/IoT Event ได้
- การส่งไปยัง IoT Events จะทำให้สามารถสามารถ "Execute aggregation regularly & judge results using thresholds & execute subsequent processing" ได้
Container Dataset
สามารถใช้ Custom Container จัดการประมวลผลที่ซับซ้อนหรือชั้นสูงตามที่ต้องการได้ (ตัวอย่างเช่น การเปลี่ยนใหม่ Machine learning model)
สามารถดำเนินการได้หลังจากเปลี่ยน SQL Dataset ใหม่แล้ว หรือตาม schedule ที่กำหนดไว้
สามารถใช้งาน Container image ที่ลงทะเบียนไว้ใน ECR ได้
Visualize
เราสามารถ Visualize ข้อมูลของ Dataset โดยการใช้ Quicksight ได้
(อย่าลืมปรับเวลาในการอัพเดทของ [Dataset] กับ [SPICE ของ Quicksight])
และด้วยการ อัพเดท Container Dataset เป็นประจำ จะทำให้เราสามารถตรวจสอบ HTML View ที่สร้างขึ้น ใน AWS Console ได้
โดยสามารถดูรายละเอียดเพิ่มเติมได้ที่ลิ้งค์ด้านล่างนี้
Visualizing AWS IoT Analytics data - AWS IoT Analytics
การตั้งค่า Dataflow ของ AWS IoT Analytics
สำหรับท่านต้องการเข้าใจเพิ่มเติมเกี่ยวกับการตั้งค่า Dataflow ของ AWS IoT AnalyticsDesigning แนะนำให้อ่านบทความต่อไปนี้ Designing dataflows for multi-schema messages in AWS IoT Analytics | The Internet of Things on AWS – Official Blog
โดยจะขอสรุปสั้นๆไว้ตามที่เขียนไว้ด้านล่างนี้
สำหรับแต่ละส่วนประกอบเทคนิคของ "AWS IoT Analytics" แนะนำให้จำ 3 สิ่งด้านล่างนี้ไว้
1 Channel สามารถส่งข้อความไปยัง pipeline หลายจำนวนได้
pipeline จะผูกกับ 1 channel และ 1 datastore
1 Datastore สามารถสร้างได้หลาย dataset แต่ว่าตอนที่สร้าง dataset ไม่สาามารถอ้างอิงหลาย Datastore ได้
นอกจากนี้โปรดทราบว่า [AWS IoT Analytics] นั้นข้อมูลที่ถูกประมวลผลด้วย pipeline จะมีค่าใช้จ่ายเพิ่มขึ้นตามปริมาณ และ การประมวลผลซ้ำกันจะทำให้เกิดค่าใช้จ่ายที่ไม่จำเป็น
ความเกี่ยวข้องของ channel, pipeline, datastore จะมีอยู่ 4 รูปแบบตามด้านล่างนี้
| channel | pipeline | datastore | |
|---|---|---|---|
| Type1 | 1 | 1 | 1 |
| Type2 | N | N | 1 |
| Type3 | 1 | N | N |
| Type4 | 1 | N | 1 |
จาก flow ทั้ง 4 แบบด้านบน รูปแบบที่ง่ายที่สุดคือรูปแบบ [Type1]
หากต้องการสร้างโครงสร้าง [Type1] โครงสร้างด้านล่างนี้น่าจะเป็นโครงสร้างที่เป็นอุดมคติครับ
อ้างอิง: Designing dataflows for multi-schema messages in AWS IoT Analytics | The Internet of Things on AWS – Official Blog
แต่ว่าในกรณีที่ schema ของข้อมูล input มีความหลากหลาย(multi-schema) อาจจะทำให้เกิดความซับซ้อนของการประมวลผลเนื้อหาเกิดขึ้นได้
นอกจากนี้ หากเรามีหลาย schema แล้วทำแค่การเปลี่ยนแค่ข้อมูลจำเพาะ[แ]
เมื่อมีเพียง "schema เฉพาะ" ในหลาย schema เท่านั้นที่มีการเปลี่ยนแปลงข้อกำหนดอาจจะสามารถคำนวณอีกรอบได้ด้วย [pipeline]
ในกรณีนี้เองจะกลายเป็นการประมวลผลข้อมูลซ้ำ ซึ่งจะทำให้ค่าใช้จ่ายที่ไม่จำเป็นเกิดขึ้น
หากข้อมูลอินพุตมี schema ที่หลากหลายและเนื้อหาการประมวลผลมีแนวโน้มที่จะซับซ้อน ขอแนะนำให้ใช้ประเภท 2 ดังที่แสดงด้านล่าง
อ้างอิง: Designing dataflows for multi-schema messages in AWS IoT Analytics | The Internet of Things on AWS – Official Blog
ระบุข้อมูลเฉพาะที่จะประมวลผลในแต่ละ channel และดำเนินการประมวลผลเฉพาะสำหรับแต่ละ schema สำหรับแต่ละ pipeline
สาเหตุที่มีเพียง 1 datastore ก็เนื่องมาจาก "ไม่สามารถอ้างอิง datastore หลายแห่งได้เมื่อสร้าง dataset"
อย่างไรก็ตาม หากคุณสร้าง dataset ที่มีการกำหนดค่า "เมื่อคุณสแกน dataset ข้อมูลที่ไม่จำเป็นจะถูกสแกนทำให้ค่าใช้จ่ายสูงขึ้น (แม้ว่าจะป้อนข้อมูล ex.multi-schema ไว้ แต่จำเป็นต้องใช้เฉพาะข้อมูลของ schema ที่ระบุเท่านั้น)" เกิดขึ้นได้
จากมุมมองของการลดต้นทุนค่าใช้จ่ายให้ต่ำที่สุดเมื่อสแกนชุดข้อมูล ก็อาจคุ้มค่าที่จะพิจารณา Type3
อ้างอิง: Designing dataflows for multi-schema messages in AWS IoT Analytics | The Internet of Things on AWS – Official Blog
อย่างไรก็ตาม ในการกำหนดค่า Type3 มีปัญหาคือ "ข้อมูลเดียวกันจะถูกป้อนเข้าในแต่ละ pipeline ทำให้การประมวลผลจะถูกทำซ้ำ"
(จำเป็นต้องพิจารณาว่าสิ่งใดมีผลกระทบต่อต้นทุนมากกว่าระหว่างประมวลผลข้อมูล กับ การใช้ข้อมูล)
เพื่อจัดการกับปัญหานี้ แนะนำให้มีการกำหนดค่าที่ทำซ้ำประเภท 1 "channel:pipeline:datastore=N:N:N" จะมีประสิทธิภาพมากกว่า
(โดยการแบ่ง channel การประมวลผลจะไม่ซ้ำกันใน pipeline)
และสุดท้าย เรามาดูโครงสร้างของ Type4 กัน
การกำหนดค่านี้จะมีผลเมื่อคุณต้องการดำเนินการหลายกระบวนการในข้อความเดียว และทำให้ใช้งานง่ายขึ้นโดยการรวมไว้ใน datastore เดียว
อ้างอิง: Designing dataflows for multi-schema messages in AWS IoT Analytics | The Internet of Things on AWS – Official Blog
อย่างไรก็ตาม ในกรณีนี้ แต่ละ pipeline จะ "ดำเนินการประมวลผลซ้ำ" ซึ่งทำให้เกิดค่าใช้จ่ายที่ไม่จำเป็น เพื่อหลีกเลี่ยงปัญหานี้ เป็นความคิดที่ดีที่จะเตรียมหลาย channel เช่น การกำหนดค่า Type2 ที่เป็นโครงสร้างที่มีหลาย channel สำหรับการตั้งค่า Data flow ของแต่ละ type ก็มีเพียงเท่านี้
การแบ่งวิธีการใช้งานนอกจาก Data flow ของ "IoT Analytics" แล้ว "Kinesis" ก็ยังมีปัญหาคล้ายๆกันว่าจะเลือกใช้แบบไหนดี สามารดูได้จากลิ้งคืด้านล่างนี้ครับ
ซึ่งหากจะให้สรุปง่ายๆ การใช้งาน meta data ของ Device, การใช้ข้อมูลระยะยาว หรือหากคุณต้องการการ query ไม่ก็ model ที่มีความซับซ้อน ขอแนะนำให้ใช้ AWS IoT Analytics ครับ
สำหรับเคสที่ใช้ Kinesis กับ "AWS IoT Analytics" ก็ได้มีเขียนไว้ในบทความด้านล่างนี้แล้วด้วยครับ
AWS IoT Analytics FAQ Page
ทิ้งท้าย
ในหัวข้อต่างๆที่ผ่านมาผมได้เรียบเรียงภาพรวมของ "AWS IoT Analytics" กันไปแล้ว
โดยส่วนตัวแล้ว ผมชอบที่สามารถคำนวณใหม่ได้แม้ว่าจะเปลี่ยนคำจำกัดความของ "pipeline" แล้วก็ตาม
หากคุณสามารถออกแบบ channel, pipeline. datastore ได้อย่างเหมาะสม มันจะมีประโยชน์มาก ดังนั้น หากคุณกำลังคิดที่จะใช้ข้อมูล IoT นี่คือ Service ที่ผมคิดว่าน่าจะเป็นประโยชน์เมื่อนำไปใช้งานแน่นอนครับ
บทความอ้างอิง
- 【AWS Black Belt Online Seminar】AWS IoT Analytics Deep Dive - YouTube (Japanese)
- 20191030 AWS Black Belt Online Seminar AWS IoT Analytics Deep Dive | PPT (Japanese)
- Designing dataflows for multi-schema messages in AWS IoT Analytics | The Internet of Things on AWS – Official Blog (English)
- ราคา AWS IoT Analytics
- Amazon Timestream Pricing – Time Series Database – Amazon Web Services (English)
- What is AWS IoT Analytics? - AWS IoT Analytics (English)
- SQL expressions in AWS IoT Analytics - AWS IoT Analytics (English)
- AWS IoT Analytics FAQ Page (English)
บทความต้นฉบับ
AWS IoT 再入門ブログリレー AWS IoT Analytics編 | DevelopersIO (Japanese)
16
