การเลือก Feature หรือ Feature Selection เป็นอีกขั้นตอนหนึ่งในการสร้างโมเดล Machine Learning ซึ่งขั้นตอนนี้แม้จะเป็นขั้นตอนย่อยแต่ก็มีส่วนช่วยอย่างมากในการทำให้โมเดลของเรามีประสิทธิภาพมากขึ้นควรเลือก Feature แบบไหน?เราควรเลือก Feature ที่สามารถบอกความแตกต่างของสิ่งที่เราจะจำแนกได้ครับ That’s it! เรื่องนี้บางทีก็ง่ายครับ บางทีก็ยาก 😂 ดูตัวอย่างง่ายๆ กันดีกว่า ลองนึกถึงว่าถ้าเราต้องการสร้างโมเดลเพื่อจำแนกมอเตอร์ไซค์กับรถยนต์ Feature ที่เราควรเลือก.. “จำนวนล้อ” ครับ เพราะว่าจำนวนล้อเนี่ยเราสามารถแยกมอเตอร์ไซค์กับรถยนต์ได้น่าจะเกือบ 100% (ที่ไม่เต็มร้อย เพราะว่าอาจจะมีมอเตอร์ไซค์ที่มี 4 ล้อ) แล้ว Feature ที่เราไม่ควรเลือกก็อย่างเช่นพวก สีรถ อะไรแบบนี้ ลองนึกดูครับ ถ้ามีเพื่อนมาบอกเราว่า สิ่งของนั้นๆ มีสีแดง 🤦‍♂ เราจะบอกไม่ได้เลยว่ามันเป็นมอเตอร์ไซค์หรือรถยนต์เทคนิคในการเลือก Feature (หรือ Feature Selection)เทคนิค #1 ครับ ใช้ Domain Knowledge! นั่นก็คือ ใช้ความรู้ของมนุษย์นั่นเอง อย่างเรื่องจำแนกมอเตอร์ไซค์กับรถยนต์ เราจะเลือกใช้จำนวนล้อก่อนเลย ไม่ต้องมัวมานั่งดูข้อมูลเทคนิค #2 เราจะใช้ Count Plot ครับ เฉพาะกับข้อมูลที่เป็น Categorical นะครับ อย่างเช่น เพศ หรือ การศึกษาอะไรแบบนี้ เทียบกับ Label หรือ Class ที่เราจะจำแนกข้อมูล ทำอย่างไร? เราจะใช้ตัวอย่างข้อมูล Titanic กันข้อมูลของ Titanic เนี่ย เราต้องการที่จะทำนายกว่าคนประเภทไหนที่รอดชีวิตบ้าง ถ้าเราอยากรู้ว่า เพศ นี่เป็น Feature ที่เราควรเลือกหรือเปล่า เราจะเอามาทำ Count Plot ตามนี้ครับCount Plot ระหว่าง Sex กับ Survivedแบบนี้แปลว่าดีครับ เพราะอะไร? จาก Plot ที่เราได้จะเห็นว่าจำนวนที่ไม่รอดชีวิต มีจำนวนของเพศชายมีจำนวนมากกว่าเพศหญิง และจำนวนที่รอดชีวิตมีจำนวนเพศหญิงมากกว่าเพศชาย ดังนั้นเราควรเลือกเพศมาเป็นข้อมูลในการสร้างโมเดลของเราแล้วถ้าเราลองเลือก Feature อื่นมา Plot บ้างล่ะ? ลองเลือก Embarked ละกันCount Plot ระหว่าง Embarked กับ Survivedแบบนี้แปลว่า? เราอาจจะเลือกใช้ Embarked ในการสร้างโมเดลของเราหรือไม่เลือกก็ได้ครับ Feature นี้ไม่ชัดเจนเท่า Sex ถ้าเป็นผมก็อาจจะลองสร้างโมเดลทั้งแบบที่มี Embarked กับไม่มี Embarked ครับ แล้วเอามาเทียบผลลัพธ์กันเทคนิค #3 ใช้ Box Plot กับข้อมูลที่เป็น Continuous ครับ เรายังคงอยู่กับข้อมูล Titanic กัน ลองเลือก Age มา Plot ดูBox Plot ระหว่าง Age กับ Survivedถ้าเราเป็น Box เท่าๆ กันแบบนี้เลยแปลว่าอะไร? แปลว่าค่า Age นี่ใช้จำแนกว่าใครจะรอดหรือไม่รอดไม่ดีเท่าไหร่ครับ ลองมาดูอีกค่ากัน ค่า FareBox Plot ระหว่าง Fare กับ Survivedค่า Fare นี่แหละครับที่สามารถพอจะจำแนกได้ว่าใครรอดหรือไม่รอด จะเป็นได้ว่า Box ของแต่ละอันมีความต่างกัน แบบคนที่ไม่รอดจะมี Box ที่อยู่ต่ำกว่าแบบของคนที่รอด แต่! ตรงนี้ต้องระวังด้วยนะครับ สังเกตจุดดำๆ ด้านบนของ Box แต่ละอัน จุดดำๆ พวกนั้นเราเรียกว่า Outlier ครับ จริงๆ แล้วเราควรที่จะกำจัดสิ่งพวกนี้ออกก่อน บทความนี้อยากจะแค่เสนอเทคนิคในการเลือก Feature เฉยๆ นะครับ เรื่องตัด Outlier นี่ลองไปทำกันเองดูนะ 😙เป็นไงกันบ้างครับทั้ง 3 เทคนิคง่ายๆ ไม่ได้ออกแรงอะไรมากมาย แต่ก็เป็นส่วนช่วยให้โมเดลของเราประสิทธิภาพมากขึ้นมากกกกก แนะนำให้ใช้ทุกครั้งนะครับผมปล. โค้ดสั้นๆ อยู่ที่ Feature Selection Techniques เผื่ออยากเอาไปลองรันเล่น

Message ที่ถูก Publish ใน MQTT จะไม่สามารถทราบได้ว่า Client ที่ Subscribe ไว้นั้น จะได้รับ Message หรือไม่ แต่ Client ที่เป็น Publisher นี้ รู้แน่นอนว่า Message ถูกส่งไปให้ Broker ได้ถูกรับเรียบร้อยแล้ว เช่นเดียวกัน Client ที่เป็น Subscriber เอง ก็ไม่สามารถจะรู้ได้ว่า Publisher จะส่ง Message มาให้เมื่อไหร่ (เพราะ Client จะไม่สามารถติดต่อกันได้โดยตรงค่ะ ต้องมี Broker มาคั่นกลาง) ซึ่งอาจจะแค่ไม่กี่วินาที หรือ อาจจะนานหลายชั่วโมง จึงมีการนำ Retained Message เข้ามาช่วยแก้ปัญหานี้ค่ะRetained Message ก็คือ MQTT Message นี่แหละค่ะ แต่ว่าจะถูก Publish มาพร้อมค่า retainFlag ที่ตั้งว่าไว้เป็น True ค่ะ ซึ่ง Broker จะทำการเก็บ payload และ QoS ของ Message สำหรับ Topic นี้ไว้ แล้วถ้ามี Client เข้ามาทำการ Subscribe ตรงกับ Topic ที่มี Retained Message เก็บไว้ Broker ก็จะส่ง Message นี้ ให้ Client โดยทันทีค่ะ ซึ่งในแต่ละ Topic นั้น Broker จะทำการเก็บ Retained Message ไว้แค่ค่าสุดท้ายค่าเดียวนะคะไม่เพียงแต่ Client ที่ทำการ Subscribe ใน Topic ที่ตรงกับ Retained Message ที่ Broker เก็บไว้นะคะ ถ้าหากว่า Client ทำการ Subscribe ใน Topic ที่มีเครื่องหมาย Wildcard (#) ร่วมใน Topic นั้นด้วย Client ก็จะได้รับ Retained Message ของ Topic นั้นเช่นกันค่ะตัวอย่างของการ RetainClient A ได้ทำการ Publish Retained Message ไปที่ Topic myhome/livingroom/temperature หลังจากนั้น Client B ได้เข้ามาทำการ Subscribe ที่ Topic myhome/# ทันทีที่ Subscribe เรียบร้อยแล้ว Client B จะได้รับ Retained Message (จาก Topic myhome/livingroom/temperature) ทันทีค่ะ ซึ่ง Client B สามารถรู้ได้ว่านี่คือ Retained Message โดยดูจาก retainFlag ที่ Broker ส่งมาให้ค่ะจะเห็นว่า ข้อดี ของ Retained Message ก็คือ การที่ Client สามารถรับรู้ได้ทันทีหลังจากที่ได้เข้ามาทำการ Subscribe ว่าตอนนี้ สถานะ ของ Topic นี้เป็นยังไง โดยที่ไม่ต้องรอให้ถึงจนกว่า Pusblisher จะทำการส่ง Message อีกครั้ง ซึ่ง Retained Message นี้ไม่จำเป็นว่าจะเป็น Message ล่าสุดที่ถูกส่งมานะคะ แต่ต้องเป็น Message ล่าสุดที่ถูกส่งมาพร้อมค่า retainFlag เป็น True ค่ะการลบค่าที่ระบบ Retain เอาไว้ถ้าหากว่าเราต้องการที่จะลบ Retained Message นี้ออก ก็ทำได้ง่ายๆเลยค่ะ เราแค่จัดการให้ Publisher ส่ง Message ที่ไม่มี payload (มี payload เป็น 0 Byte) พร้อมกับค่า retainFlag เท่ากับ True ค่ะ แค่นี้ Broker ก็จำทำการลบ Retained Message ของ Topic นั้นๆออกให้ค่ะ หลังจากนี้ Client ที่เข้ามาทำการ Subscribe ก็จะไม่ได้รับ Retained Message ค่ะการประยุกต์ใช้งานฟีเจอร์ RetainRetained Message เหมาะสมจะนำมาใช้เมื่อเราต้องการให้ Client ใหม่ ที่มา Subscribe ได้รับค่าอัพเดทล่าสุด อย่างเช่น เมื่อต้องการรู้ว่าอุปกรณ์นั้น Offline หรือ Online อยู่ค่ะ ถ้าหากไม่นำ Retained Message เข้ามาใช้ Client ก็จะต้องรอจนกว่าจะมีการ Publish อีกครั้งนึงค่ะ

การทำ Clustering Analysis คือการที่เราพยายามที่จะจัดกลุ่มของข้อมูลที่มีลักษณะคล้ายๆ กันให้อยู่กลุ่มเดียวกัน การทำแบบนี้ช่วยให้เรารู้สึกข้อมูลนั้นๆ มากขึ้น และยังสามารถช่วยให้เราตัดสินใจอะไรบางอย่างได้ดีขึ้นอีกด้วยลองนึกถึงตัวอย่างทางธุรกิจสักตัวอย่างหนึ่ง สมมุติว่าเราต้องการที่จะส่ง Campaign อีเมลไปให้กลุ่มลูกค้าที่ชื่นชอบและสนใจสินค้าที่เกี่ยวกับ Computer วิธีหนึ่งที่เราจะทำได้ก็คือเอาข้อมูลลูกค้ามาแล้วก็จัดกลุ่มเอง หรือ Filter เอง วิธีนี้ก็ดีในระดับหนึ่งครับ ถ้าเรารู้จักข้อมูลของเราดีพอ แล้วเราก็รู้ว่าเราต้องการอะไร แล้วถ้าในกรณีที่เราไม่รู้ล่ะ? การทำ Clustering จะช่วยเราในเรื่องนี้ แล้วเราก็จะเห็นด้วยว่าข้อมูลของเราแต่ละข้อมูลมีความสัมพันธ์กันอย่างไรบ้างอีกด้วย ซึ่งจริงๆ แล้วเหมือนกับเรากำลังทำ Exploratory Analysis นั่นเอง ;)เรามาทำความรู้จักกับเทคนิคหนึ่งในการทำ Clustering กัน เทคนิคนั้นชื่อ K-Means ครับ K-Means เนี่ย เราจัดอยู่ในการเรียนรู้แบบ Unsupervised Learning ครับผม เพราะว่าเราไม่ต้องบอก หรือไม่ต้อง Supervise ตัวอัลกอริธึมว่าคำตอบคืออะไรเราเริ่มมาทำความรู้จัก K-Means กันจากชื่อของมัน K-Means ครับ เราแปลแบบง่ายๆ กันคือ เราต้องกำหนด K หรือ จำนวนกลุ่มที่เราต้องแบ่งก่อน เสร็จแล้วจุดศูนย์กลาง (Centroid) ของกลุ่มนั้นๆ เราจะใช้ค่า Mean ส่วนขั้นตอนการทำงาน ผมลองวาดออกมาเป็นรูปด้านล่างนี้ครับรูปขั้นตอนการทำงานของ K-Meansสมมุติว่าเรามีข้อมูล 1 Dimension (1D) ตามนี้d = {2, 4, 10, 12, 3, 20, 30, 11, 25}และกำหนดค่า K เป็น 2ขั้นตอนแรก Initializeขั้นตอนนี้ทำแค่ครั้งเดียว เราจะกำหนดค่า Centroid เริ่มต้นมา 2 ค่า (เนื่องจากเรากำหนดค่า K เป็น 2) สมมุติว่าเรากำหนดว่า จุด Centroid แรก (m1) มีค่า 2 และจุด Centroid ที่ 2 (m2) มีค่า 4ขั้นตอนที่ 2 Assignเราจะดูข้อมูลแต่ละตัวใน {2, 4, 10, 12, 3, 20, 30, 11, 25} ว่าแต่ละค่ามีค่าใกล้เคียง หรือระยะห่างจากข้อมูลนั้นไปยังจุด m1 หรือ m2 ถ้าข้อมูลนั้นๆ ใกล้กับจุด m1 เราก็จะให้จุดนั้นอยู่กลุ่มเดียวกับ m1 ให้ทำแบบนี้จนครบทุกจุด ใน d (ถ้าสมมุติว่าได้ค่าระยะห่างเท่ากัน ก็ให้เลือกกลุ่มใดกลุ่มหนึ่งได้เลย)ขั้นตอนที่ 3 Update Centroidsหลังจากที่เรา Assign ทุกจุดแล้ว เราจะปรับค่า Centroid เพื่อให้ได้ Centroid ค่าใหม่ การปรับค่านี้เราก็จะหาค่าเฉลี่ย (Mean) กับข้อมูลทุกตัวในกลุ่มนั้นๆขั้นตอนที่ 4 Converge?ขั้นตอนนี้เป็นการเช็คเฉยๆ ว่าข้อมูลมีการย้ายกลุ่มหรือไม่ ถ้ามีการย้ายกลุ่มเกิดขึ้น เราก็จะย้อนกลับไปที่ขั้นตอนที่ 2 ทำไปเรื่อยๆ จนกว่าจะไม่มีการย้ายข้อมูลจะเห็นได้ว่าเรามีการทำซ้ำๆ เกิดขึ้นจนกว่าเราจะได้กลุ่มข้อมูลที่คงตัวครับ :D ลองดูตารางข้างล่างนี้ประกอบเนอะจะเห็นได้ว่ารอบที่ 5 เรามี Centroid ปัจจุบันเป็นค่าเดียวกับ Centroid ใหม่ ตรงนี้แหละครับ ที่เราบอกได้ว่ามัน Converge และเราสามารถจบการทำงานได้เลย สุดท้ายเราจะได้กลุ่มแรก {2, 3, 4, 10, 12, 11} ที่มี Centroid มีค่าเท่ากับ 7กลุ่มที่ 2 {20, 30, 25} ที่มี Centroid มีค่าเท่ากับ 25ถ้าอยากเขียนโค้ด? จัดไปครับ ตามนี้เลยhttps://gist.github.com/zkan/77a8bf05b7b2105337d3f7b457e73efeผลที่ได้ก็ตามนี้ครับ*หมายเหตุ จากตัวอย่างข้างบนผมใช้ตัวเลขนะครับ จะได้คำนวณง่ายๆ แต่ในปัญหาจริงๆ ข้อมูลจะไม่ได้มาเป็นตัวเลขเสมอไป งานของเราก็คือเราต้อง Preprocess ข้อมูลพวกนี้ก่อน ให้มาอยู่ในรูปที่เราสามารถคำนวณได้นั่นเองครับ แล้วก็ข้อมูลจริงๆ ไม่ได้มีแค่ 1D มันจะมาเป็นหลายๆ D เสมอ :D เราก็ค่อยไปหาการคำนวณระยะห่างของข้อมูลให้เหมาะสมกับจำนวน D ครับ

บทความที่แล้วเราได้พูดถึงหนึ่งใน Feature สำคัญของ MQTT กันไปแล้วนะคะ ซึ่งก็คือ QoS หรือ Quality of Service ค่ะ และ ในช่วงท้ายๆของบทความ ได้พูดถึง Persistent Session แต่ยังไม่ได้อธิบายว่าคืออะไร บทความนี้ก็มาพูดถึงกันเลยค่ะถึงแม้ว่า MQTT (ตามคำนิยามแล้ว) ไม่ใช่ Message Queue แต่….. MQTT มีความสามารถที่จะทำ Message Queueing ได้ค่ะ ด้วยการใช้ Persistent Sessionหาก Client ต้องการรับ Message จาก Broker ตัว Client ต้องทำการเชื่อมต่อกับ Broker และ ทำการสร้าง Subscription ของ Topic ที่ตัว Client สนใจขึ้นมา ในระหว่างนี้ หากการเชื่อมต่อระหว่าง Client และ Broker มีปัญหาเกิดขึ้นทำให้การเชื่อมต่อมีข้อผิดพลาด และ ถ้าการเชื่อมต่อนั้นไม่ใช่แบบ Persistent Session จะทำให้ Client ไม่ได้รับ Message จาก Topic นั้นได้ ดังนั้น Client จำเป็นจะต้องทำการ Subscribe ใหม่อีกครั้งเมื่อมีการเชื่อมต่อกับ Broker ​ซึ่งการทำการเชื่อมต่อระหว่าง Broker และ Client ใหม่ซ้ำๆทุกครั้งที่มีปัญหาขาดการเชื่อมต่อย่อมทำให้เกิดปัญหา ยิ่งถ้าเรามีข้อจำกัดเรื่องอินเตอร์เนทอยู่ด้วยแล้วละก็ ปัญหาใหญ่แน่นอนค่ะ ดังนั้นเพื่อที่จะหลีกเลี่ยงปัญหานี้ ตัว Client จะต้องทำการเชื่อมต่อกับ Broker แบบ Persistent Session ค่ะการเชื่อมต่อแบบ Persistent Session นี้ จะช่วยเราเก็บข้อมูลทุกอย่างที่เกี่ยวข้องไว้บน Broker ค่ะ โดยจะใช้ ClientId เป็นตัวบ่งบอกว่า Session ไหนเป็นของ Client ตัวไหนข้อมูลต่างๆที่ Broker จะเก็บไว้ให้ Client ก็จะมีตามนี้เลยค่ะ (ถึงแม้ว่า Client จะ Offline ไป แต่เมื่อไหร่ที่ Client กลับมา Online ข้อมูลเหล่านี้ก็จะถูกจัดเตรียมให้ Client ทันทีเลยคะ)สถานะของ Session (ถึงแม้ว่าจะไม่มีการ Subscription)ข้อมูล Subscription ทุกอย่างของ ClientMessage (ที่ได้กำหนด QoS 1 หรือ 2) ต่างๆที่เกิดขึ้น และ Client ยังไม่ได้ทำการยืนยันMessage (ที่ได้กำหนด QoS 1 หรือ 2) ที่เกิดขึ้นใหม่ระหว่างที่ Client ได้ Offline ไปMessage (ที่ได้กำหนด QoS 2) ที่ได้รับจาก Client ที่ยังไม่ได้รับการตอบรับหาก Client ต้องการจะเชื่อมต่อแบบ Persistent Session กับ Broker ตัว Client สามารถทำได้โดยการกำหนดค่าของ cleanSession เพื่อบอกให้ Broker รู้ว่า Client ต้องการที่จะทำการเชื่อมต่อแบบไหน (Persistent Session หรือ Clean Session)ถ้าต้องการให้มีการเชื่อมต่อแบบ Clean Session ค่าของ cleanSession จะเป็น True ค่ะ ถ้าเกิดมีปัญหากับการเชื่อมต่อเกิดขึ้น ข้อมูลทุกอย่างก็จะหายไปค่ะ รวมไปถึง Message ที่ถูก Queue ไว้จาก Persistent Session ก่อนหน้านี้ก็จะหายไปด้วยค่ะตรงกันข้ามค่ะ ถ้าต้องการให้มีการเชื่อมต่อแบบ Persistent Session ค่าของ cleanSession จะถูกตั้งค่าให้เป็น False ตัว Broker ก็จะทำการสร้าง Persistent Session ให้ค่ะ ข้อมูลต่างๆ และ Message จะถูกเก็บไว้ให้โดย Broker จนกว่า Client จะขอทำการเชื่อมต่อแบบ Clean Session (ตั้งค่า cleanSession เป็น True) ค่ะ ถ้าเกิดว่ามีการขอเชื่อมต่อแบบ Persistent Session แต่ว่า ณ เวลานั้น Broker ได้ทำการเชื่อมต่อกับ Client เรียบร้อยแล้ว ในเคสนี้ Broker จะใช้ Session ที่เชื่อมต่ออยู่ และจะทำการส่ง Message ทั้งหมดที่เคย Queue ไว้ให้กับ Client ค่ะหลังจากที่การเชื่อมต่อแล้ว Client จะรู้ได้ยังไงว่า Broker ได้ทำการจัดเก็บข้อมูลต่างๆให้เราแล้ว …..Client สามารถรู้ได้จาก CONNACK Message จาก Broker ค่ะ ใน CONNACK จะมีข้อมูลเกี่ยวกับ sessionPresent ค่ะ ซึ่งก็จะบอกได้ว่า Session ที่ Client ได้ทำการเชื่อมต่อกับ Broker นั้นยังมีการเชื่อมต่ออยู่รึป่าว และยังสามารถใช้ได้อยู่รึป่าวMQTT CONNACK Messageไม่ใช่เฉพาะ Broker นะคะ ที่ต้องเก็บข้อมูลไว้ หากมีการเชื่อมต่อแบบ Persistent Session ตัว Client เองก็ต้องทำการเก็บข้อมูลไว้เหมือนกันค่ะ ซึ่งก็จะเก็บข้อมูลตามนี้ค่ะMessage (ที่ได้กำหนด QoS 1 หรือ 2) ต่างๆที่เกิดขึ้น และ Broker ยังไม่ได้ทำการยืนยันMessage (ที่ได้กำหนด QoS 2) ที่ได้รับจาก Broker ที่ยังไม่ได้รับการตอบรับการเลือกเชื่อมต่อกับ MQTT Brokerวิธีเลือกว่าจะทำการเชื่อมต่อ Client กับ Broker แบบไหนดี ระหว่าง Persistent Session กับ Clean Session ให้ลองพิจารณาตามนี้ค่ะจะเลือกใช้ Persistent Session เมื่อไหร่?เมื่อ Client ต้องการได้รับ Message ทั้งหมด จาก Topic ที่ได้ทำการ Subscribe ไว้ ไม่ว่า Client จะ Offline ไป Broker จะทำการ Queue ข้อความไว้ให้ และจะส่งให้ Client ทันทีที่กลับมา Onlineเมื่อ Client มีข้อจำกัดทางทรัพยากรที่มีผลกระทบต่อการเชื่อมต่อ แต่ต้องการให้ Broker เก็บ ข้อมูลการ Subscription ไว้ให้ และต้องการให้มีการกู้คืนเมื่อการเชื่อมต่อถูกรบกวนเมื่อ Client ต้องการที่จะ Publish ข้อความ (Qos 1 และ 2) หลังจากมีการกลับมาเชื่อมต่ออีกครั้งจะเลือกใช้ Clean Session เมื่อไหร่?ถ้าหาก Client (ที่เป็น Publisher) ต้องการแค่ Publish ข้อความClient (ที่เป็น Subscriber) ไม่ได้ต้องการที่จะ Subscribe และไม่ได้สนใจที่จะรับ Message ถ้าหากว่า Client เกิด Offline ไปBroker ไม่จำเป็นต้อทำการเก็บข้อมูลเกี่ยวกับ SessionBroker ไม่จำเป็นต้องพยายามส่ง Message (Qos 1 และ 2) อีกครั้ง เมื่อไม่สามารถส่ง Message ได้สำเร็จแล้ว Broker จะเก็บข้อมูลไว้ให้เรานานแค่ไหน?Broker จะทำการเก็บข้อมูลไว้จนกว่า Client จะกลับมา Online อีกครั้งและได้รับ Message ที่ไม่ได้รับในระหว่างที่ Offline ไปค่ะ ละถ้าเกิด Offline ไปเป็นเวลานานมากๆละ.. คำตอบก็คือ แล้วแต่เคสค่ะ โดยปกติแล้ว Memory ก็จะเต็มซะก่อน Message ที่ถูก Queue ไว้ก็จะถูกลบไปโดยปริยายค่ะหนักหัวต่ออีกนิดนะคะ แต่ก็ใกล้จะจบแล้วค่ะ ไว้คราวหน้าเราจะพูดถึงการเก็บข้อมูล หรือการ Retain ในระบบของ MQTT กันค่ะ แล้วพบกันนะคะ สวัสดีค่ะ

บริษัท Pacifical ผู้จัดจำหน่ายเนื้อปลาทูน่า เป็นบริษัทขนาดใหญ่มีการร่วมทุนข้ามชาติระหว่าง 8 ประเทศ มีจุดประสงค์ในการจัดการการประมงปลาทูน่าโดยเฉพาะ เพื่อไม่ให้ปลาทูน่าถูกจับมากเกินไปจนเสียสมดุลย์ จัดสรรปันส่วนสิทธิ์ในการจับ แบ่งผลิตผลไปตามภูมิภาคต่างๆ และรวมไปถึงการจัดการทรัพยากรบุคคลในวงการของแต่ละประเทศปัจจุบัน Pacifical ได้มีการนำเอาเทคโนโลยีบล็อคเชนเข้ามาจัดการข้อมูลแหล่งที่มาของปลาทูน่าโดยเฉพาะ เพื่อความโปร่งใสและความสะดวกสบายแก่ลูกค้าปลายทาง โดยปกติแล้วถ้าเราต้องการทราบว่าปลาทูน่ากระป๋องยี่ห้อต่างๆ ที่เราซื้อมาจากห้างนั้นมีต้นตอถูกจับมาอย่างถูกต้องหรือไม่ จับมานานแล้วแค่ไหน ใครเป็นคนจับมีการใช้แรงงานเถื่อนหรือไม่ ฯลฯ เราอาจต้องใช้ความพยายามอย่างมากในการหาข้อมูลเหล่านี้และโดยที่ไม่สามารถรู้ได้เลยว่าข้อมูลเหล่านี้ถูกบิดเบือนเพื่อสร้างภาพแก่ยี่ห้อของปลากระป๋องนั้นๆหรือไม่เทคโนโลยีบล็อคเชนมีบทบาทสำคัญอย่างยิ่งในการแก้ปัญหาดังกล่าว กระบวนนี้บล็อคเชนจะถูกใช้เป็นฐานข้อมูลกลางที่ไม่ได้ขึ้นกับใคร และไม่มีใครหรือองค์กรใดเป็นผู้ครอบครอง โดยปลาทูน่ากระป๋องที่มาจากบริษัท Pacifical จะมี QR code ข้างกระป๋องทุกกระป๋อง เราสามารถดาวน์โหลดแอพและแสกน QR code เพื่อดูข้อมูลต่างๆที่ต้องการได้ทันที ข้อมูลของปลาที่อยู่ในกระป๋องนั้นๆ จะถูกตรวจสอบและเขียนข้อมูลนั้นๆลงบนบล็อคเชนโดยองค์กรอิสระ ข้อมูลดังกล่าวจึงแก้ไม่ได้ในภายหลังกระบวนการเขียนและอ่านข้อมูลผ่านบล็อคเชน โดยบริษัท Atato ผู้ให้บริการ ประยุกต์ใช้บล็อคเชนผู้บริโภคจำนวนมากในหลายประเทศเริ่มใส่ใจและให้ความสนใจกับแหล่งที่มาของผลผลิตต่างๆมากขึ้น โดยมองเรื่องราคาต่ำเป็นรอง ข้อมูลต่างๆเหล่านี้จะไม่มีน้ำหนักมากพอถ้าไม่ได้มาจากบล็อคเชน เนื่องจากมันสามารถถูกแก้ไขได้อย่างง่ายดายจากผู้ที่มีผลประโยชน์ บล็อคเชนเป็นฐานข้อมูลที่มีความโปร่งใส แก้ไม่ได้ และมีความปลอดภัยสูงที่สุด

ทำไมเราถึงต้องมาดูการจัดการ Missing Data (ข้อมูลที่หายไป) กันด้วยนะ? เกี่ยวอะไรกับ Machine Learning เหรอ?เรื่องนี้เกี่ยวข้องโดยตรงกับ Machine Learning เลยครับ โดยเฉพาะตอนที่เรากำลังที่จะสร้างโมเดล Machine Learning เพราะอะไรถึงเกี่ยวล่ะ? มาดูข้อมูลง่ายๆ กันครับ เช่น ถ้าเราต้องการที่จะสร้างโมเดลทำนายความสูงของคนจากอายุ เราก็อาจจะมีข้อมูลประมาณนี้แล้วเราก็อาจจะสร้างโมเดล Linear Regression กับข้อมูลชุดนี้ แล้วเอาโมเดลไปทำนายว่าอายุ 23 น่าจะมีความสูงเท่าไหร่ ก็ดูไม่มีปัญหาอะไรในโลกความเป็นจริงข้อมูลเราอาจจะมีไม่ครบ หรือเราทำแบบสอบถามไปแล้วเค้าไม่ตอบ หน้าตาข้อมูลก็จะมีประมาณนี้ข้อมูลความสูงที่อายุ 21 ของเราหายไป ซึ่งตรงนี้เราจะไม่สามารถสร้างโมเดลได้ครับ เนื่องจากสมการทางคณิตศาสตร์ของ Machine Learning โมเดล (รวมไปถึงสมการคณิตศาสตร์อื่นๆ) จะไม่มีการเอาค่าว่างๆ ไปคำนวณร่วมกับค่าเลขอื่นๆ ลองสมการง่ายๆ ดูก็ได้ครับ อ่ะ ไหนลองหาผลรวมของความสูงหน่อย? เราจะ.. 160 + ? + 175.5 + 173 เอ่อ.. คำนวณไม่ได้ นั่นแหละครับ Machine Learning ก็เหมือนกันวิธีแก้ Missing Data นี่มีหลายวิธี วิธีที่ง่ายที่สุดแบบแทบไม่ต้องใช้ความคิดเลยคือลบแถวที่มี Missing Dta นั้นทิ้งไปเลย! :joy: วิธีนี้ก็อาจจะทำให้ผลของโมเดลดีขึ้นก็ได้นะ อย่ามองข้ามๆแต่ว่าบทความนี้อยากจะพูดถึงวิธี Mean/Median/Mode Imputation Imputation ครับ ชื่อนี่อาจจะดูหรูหน่อย ถ้าเราเรียกแบบบ้านๆ ก็คือเราแทนค่า Missing Data ด้วยค่า Mean/Median/Mode นั่นเอง~ถ้าเราแทนค่าด้วย Mean เราจะได้ตามนี้ (160 + 175.5 + 173) / 3ถ้าเราแทนค่าด้วย Mode เราจะได้ตามนี้ (ในที่นี้แค่เลือกสักค่ามาแทนครับ เนื่องจากค่า 160, 175.5 และ 173 มีจำนวนเท่ากัน)ถ้าเราแทนค่าด้วย Median เราก็จะได้ตามนี้ (เรียงข้อมูลก่อน 160, 173, 175.5 เลือกค่ากลางคือ 173)เท่านี้เราจะได้ข้อมูลครบแล้วครับ พร้อมที่จะเอาไปสร้างโมเดลต่อไปแล้ววิธีไหนให้ผลดีที่สุด? จะตอบได้ก็ต่อเมื่อเราได้ลองสร้างโมเดลจากข้อมูลแต่ละแบบ แล้ววัดผลว่าแบบให้ผลดีที่สุดครับข้อควรระวัง ไม่ใช่ว่าถ้า Median Imputation ให้ผลดีที่สุด เราจะสามารถนำเอาวิธี Median Imputation ไปใช้กับข้อมูลอื่นได้เลยนะครับ ข้อมูลอื่นก็เป็นส่วนของข้อมูลอื่น เรายังคงต้องทดลองกับหลายๆ วิธีอยู่ดี ;)

หลังจากบทความที่ผ่านมา เราพูดถึง MQTT Basics ซึ่งผู้เขียนเองได้พูดถึงการ Publish และ การ Subscribe เบื้องต้นClient, Broker, and Connection EstablishmentMQTT Publish, Subscribe, and Unsubscribeและ MQTT Topicsบทความนี้เราจะพูดก็คือ QoS หรือ Quality of Service ค่ะQoS คืออะไร? QoS คือ ข้อตกลงระหว่างผู้ส่ง และ ผู้รับ Message ซึ่งกำหนดไว้เพื่อเป็นการการันตีว่า Message นั้น สามารถถูกส่งไปถึงผู้รับแน่นอน ซึ่งใน MQTT จะมีอยู่ 3 ระดับค่ะAt most once (0)At least once (1)Exactly once (2)ในการกำหนดค่า QoS ใน MQTT เราจะพิจารณาการรับส่ง Message เป็น 2 ส่วนนะคะ คือส่วนที่ 1 : Message ที่ถูกส่งจาก Publisher ไป Brokerส่วนที่ 2 : Message ที่ถูกส่งจาก Broker ไป Subscriberสาเหตุที่เราต้องพิจารณาเป็น 2 ส่วน เพราะว่า ถึงแม้ ว่าจะเป็นการส่ง Message ที่มี Content เดียวกัน แต่ว่าผู้ส่งและผู้รับในส่วนที่ 1 และ ส่วนที่ 2 แตกต่างกันนะคะเวลาที่ Publisher ต้องการส่ง Message ให้กับ Broker ตัว Publisher จะเป็นฝ่ายกำหนดค่า QoS ให้กับ Message นั้นๆ แต่ตรงกันข้ามเวลา Broker จะส่งต่อ Message ให้กับ Subscriber เนี่ย จะใช้ค่า QoS ที่ถูกกำหนดโดย Subscriber ค่ะแล้วถ้าเกิดค่า QoS ระหว่างส่วนที่ 1 และ ส่วนที่ 2 ต่างกันแล้วเราจะต้องใช้ค่าไหน? ถ้าหากค่า QoS จากส่วนที่ 2 มีค่าต่ำกว่าค่า QoS ในส่วนที่ 1 ตัว Broker จะใช้ค่า QoS ที่ต่ำกว่า ซึ่งก็คือค่า QoS จากส่วนที่ 2 ค่ะจะเห็นว่า QoS นั้นมีความสำคัญกับ MQTT ไม่น้อยเลย นั่นเพราะว่า QoS ถือว่าเป็น Key Feature นึงของ MQTT Protocol ค่ะ QoS ให้อิสระกับ Client (Publisher/Subscriber) ในการกำหนดค่า เพื่อให้รองรับกับประสิทธิภาพของ Network และ ApplicationQoS ทำให้การรับส่ง Message เป็นไปอย่างราบรื่น ถึงแม้จะเจอข้อจำกัดทาง Network (Unreliable Network ) เพราะว่า MQTT สามารถจัดการเรื่อง Message Retransmission และ มีการการันตีว่า Message จะได้รับแน่นอนถึงตรงนี้เราลองมาดูกันค่ะว่าแต่ละเลเวลของ QoS มีความหมาย และ ทำงานอย่างไรในระบบของ MQTT Protocolระดับของ QoSQoS 0 — at most onceระดับ QoS ที่น้อยที่สุดคือ ศูนย์ (0) ค่ะ ซึ่งค่านี้จะไม่มีการการันตีการได้รับ Message เลย ( Best-Effort Delivery ) ในระดับ QoS นี้ Message จะไม่ถูกจัดเก็บเพื่อทำการ Retransmission ค่ะQoS 0 จะมักจะถูกเรียกว่า ‘Fire and Forget’ และจะมีเลเวลการการันตีการได้รับ Message ตาม TCP Protocol ใน Layer ด้านล่างค่ะ (เพราะ MQTT Protocol อยู่ใน Application Layer ตาม TCP/IP Network Model ค่ะ)QoS 0 จะมักจะถูกเรียกว่า ‘Fire and Forget’ และจะมีเลเวลการการันตีการได้รับ Message ตาม TCP Protocol ใน Layer ด้านล่างค่ะ (เพราะ MQTT Protocol อยู่ใน Application Layer ตาม TCP/IP Network Model ค่ะ)Qos 0 — at most onceQoS 1 — at least onceQoS 1 นั้น จะการันตีว่าผู้รับจะได้รับ Message อย่างน้อย 1 ครั้ง ซึ่งผู้ส่งจะจัดเก็บ Message นี้ไว้จนกระทั่ง ได้รับ PUBACK Packet จากผู้รับซึ่งถือเป็นการตอบรับว่าได้รับ Message นั้นๆแล้ว ซึ่งในเลเวลนี้เป็นไปได้ว่า จะมีการส่ง หรือ รับ Message ได้มากกว่า 1 ครั้งQos 1 — at least onceใน PUBACK Packet จะมีรายละเอียดเกี่ยวกับ Packet ID ค่ะ ซึ่งตัวผู้ส่งเองจะใช้ไอดีนี้ในการตรวจสอบว่าผู้รับได้รับ Message หรือยัง ถ้าหากว่า ผู้ส่ง ไม่ได้รับ PUBACK Packet ในระยะเวลาที่เหมาะสม ผู้ส่งจะเริ่มทำการส่ง Message อีกครั้งค่ะ (ผู้ส่งใน MQTT เป็นได้ทั้ง Publisher และ Broker นะคะ เพราะเราแบ่งการส่ง Message เป็น 2 ส่วน สามารถย้อนไปอ่านข้างบนได้ค่ะ)ในกรณีที่ ผู้รับ ได้รับ Message ที่มี QoS 1 และถ้าผู้รับคือ Broker หลังจากได้รับ Message แล้ว Broker จะส่งต่อ Message ให้ Subscriber ทุกตัว ที่ได้ Subscribe ไว้ และทำการส่ง PUBACK Packet กลับไปยัง Publisher ค่ะ ถ้าหากว่า Message ที่ได้มีการตอบรับด้วย PUBACK Packet แล้วแต่มีการส่งซ้ำจากผู้ส่ง Message นั้นจะถูกเซทค่า DUP Flag ซึ่งเป็นค่านี้จะไม่ถูกนำไปใช้โดยผู้รับ (Broker/Subscriber) นั่นหมายความว่าไม่ว่า Message นั้น จะถูกตอบรับ ด้วย PUBACK Packet หรือไม่ เมื่อไหร่ที่ผู้รับได้รับ Message (ที่มี หรือ ไม่มี DUP Flag) ผู้รับก็จะทำการส่งกลับ PUBACK Packet ไปยังผู้ส่งทุกครั้งQoS 2 — exactly onceQoS 2 ถือว่าเป็นค่าสูงที่สุด ในระดับ QoS ใน MQTT ซึ่งการันตีว่าแต่ละ Message จะถูกส่ง และได้รับเพียงครั้งเดียวเท่านั้น ซึ่งถึงแม้ว่าการใช้ QoS 2 จะเป็นวิธีที่ให้ความมั่นใจได้ว่าผู้รับจะได้รับ Message และ ไม่มีการส่งซ้ำ(หากมีการได้รับ Message แล้ว) แต่ก็เป็นระดับ QoS ที่มีการทำงานช้าตามไปด้วย เพราะจำเป็นต้องใช้การส่งและรับ Request/Response อย่างน้อยถึง 2 ครั้ง (ซึ่งเท่ากับการทำ Handsharke 4 ครั้ง) ระหว่าง ผู้รับ และ ผู้ส่ง ใน QoS 2 ก็จะใช้ Packet ID ในการจัดการการรับส่ง Message เช่นเดียวกับใน QoS 1Qos 2 — exactly onceหลังจากที่ผู้รับ ได้รับ Message แล้ว ตัวผู้รับจะทำตอบกลับผู้ส่งด้วย PUBREC Packet ถ้าหากผู้ส่งไม่ได้รับ PUBREC Packet ผู้ส่งจะส่ง Message เดิมอีกครั้งด้วย DUP Flag จนกว่าจะได้รับ PUBREC Packetและทันทีที่ผู้รับได้รับ PUBREC Packet แล้ว ผู้ส่งจะทำการจัดเก็บ PUBREC Packet ไว้ และทำการส่ง PUBREL Packet กลับไปให้ผู้รับ และผู้รับก็จะทำการรีเซทState ทั้งหมด และจัดส่ง PUBCOMP Packet ไปให้ผู้ส่ง( ซึ่งผู้ส่งก็จะทำการรีเซท State เช่นกัน เมื่อได้รับ PUBCOMP Packet จากผู้รับ) ในระหว่างการรับส่ง Message นี้ ก่อนที่จะมีการตอบรับจากผู้ส่ง ด้วย PUBCOMP Packet ตัวผู้รับจะทำการจดจำ Packet ID ไว้ ซึ่งถือว่าเป็นกระบวนการที่สำคัญมากในการหลีกเลี่ยงการส่ง Message ซ้ำอีกครั้งหลังจากที่ผู้รับ ได้รับ PUBCOMP Packet แล้ว Packet ID นี้ก็จะถูกนำไปวนใช้ต่อไปค่ะ ซึ่งตามหลักการแล้วหากมีการนำตัวเลขนี้ไปวนใช้อีก Packet ID จะมีค่าได้ไม่เกิน 65535 ค่ะ แต่หากโชคไม่ดี เกิด Message หายระหว่างทาง ไม่มีการตอบรับจากผู้รับในช่วงเวลาที่กำหนด ผู้ส่งก็จะทำการจัดส่ง Message อีกครั้งค่ะถึงตรงนี้ อาจจะมีข้อสงสัยว่า…แล้วจะเลือกใช้ QoS ยังไงดี?การเลือกใช้ระดับของ QoSถ้าหากว่าเรามี Network ที่ค่อนข้าง Stable เช่น มีการใช้สายแลนเชื่อมต่อระหว่าง Publisher/Subscriber (มั่นใจว่าการเชื่อมต่อไม่หลุดง่ายๆแน่นอน) หรือ เรายอมรับได้กับ Message ที่หล่นหายไปบ้างระหว่างทาง ซึ่ง Message นั้นอาจจะไม่สำคัญมากเท่าไหร่ หรือ เราส่งถี่มากพอที่การสูญหายของ Message จะไม่มีผลกระทบมากมาย หรือ หากเราไม่ต้องการให้ Message ทำการ Queuing (Message Queuing มีผลเมื่อเลือกใช้ QoS 1 หรือ QoS 2 และมีการใช้ Persistent Session จะกลับมาอธิบาย Persistent Session ในบทความถัดไปนะคะ ) เลือกใช้ QoS 0 เลยค่ะแต่ถ้าหากว่าระบบของเรามีความจำเป็นที่ต้องได้รับทุก Message ที่ถูก Publish (ห้ามพลาดเลย) มีสองทางเลือกค่ะ คือ QoS 1 หรือ QoS2 หลังจากนั้นมาลองพิจารณาค่ะว่าหากเกิดการรับส่งซ้ำของ Message แล้วเนี้ย ระบบของเรารับได้มั้ย จะมีปัญหากับ Application ที่เราใช้รึป่าว หากไม่ติดปัญหาเรื่องการส่งซ้ำของ Message ได้ QoS 1 เป็นตัวเลือกที่เหมาะสมที่สุดค่ะ เพราะเมื่อเทียบกับ QoS 2 แล้ว QoS 1 ทำการรับส่งได้เร็วกว่ามากคะบทความถัดไป จะพูดคุยเพิ่มเติมเรื่อง Persistent Session ค่ะ ซึ่งสำคัญมาก หากอุปกรณ์ IoT ของเราเกิดอยู่ๆ Offline ไป แล้ว MQTT จะมีการจัดการเรื่องนี้ให้เรายังไง คอยติดตามอ่านกันนะคะ สวัสดีค่ะ

ปัจจุบันเริ่มมีผู้คนให้ความสนใจบล็อคเชนในแง่ของการนำเอาไปประยุกต์ใช้จริงกับธุรกิจต่างๆของตน ผู้คนเริ่มตระหนักถึงตัวตนและความเปลี่ยนแปลงที่จะเกิดขึ้นจากการมีอยู่ของบล็อคเชนมากขึ้นเรื่อยๆ จริงๆแล้วบล็อคเชนทำงานอย่างไร? ซื้อขายได้อย่างไร?กรณีทั่วไปไม่ใช้บล็อคเชนน้อง ก. มีการจดบันทึกรายรับรายจ่ายของตนเองลงในสมุด ก. น้อง ก. จึงเป็นผู้มีสิทธิ์ในบันทึกนั้นแต่เพียงผู้เดียว คือคนอื่นดูไม่ได้(ถ้าไม่ได้รับอนุญาต) สามารถแก้ไขข้อมูลบันทึกได้หากต้องการ เมื่อคุณพ่อคุณแม่ขอดูบันทึกดังกล่าว คุณพ่อคุณแม่จึงต้อง “เชื่อ” ข้อมูลของน้อง ก. โดยปริยาย แม้ว่าจะมีการเปลี่ยนแปลงข้อมูล ณ เวลาไหนก็ตาม ไม่มีใครสามารถรู้ได้นอกจากน้อง ก.กรณีบล็อคเชน(จำลอง)คราวนี้คุณพ่อคุณแม่บังคับให้ 3 พี่น้อง ก. ข. ค. จดบันทึกรายรับรายจ่ายของทั้ง 3 คน ลงไปในบันทึก 3 เล่ม ก. ข. ค. ตามลำดับ กล่าวคือน้อง ก. จดรายรับรายจ่ายทั้งตัวเองและพี่ทั้ง 2 ลงสมุด ก. พี่ ข. จดเหมือน น้อง ก. ลงสมุด ข. และพี่ ค. จดเหมือนน้องๆลงสมุด ค. โดยมีเงื่อนไขว่าทุกบรรทัดต้องจดเหมือนกัน เมื่อใครต้องการจะเขียนข้อมูลเพิ่ม ทุกคนที่เหลือต้องเขียนให้เหมือนกันสมมุติว่าเด็กๆปฏิบัติตามเงื่อนไขในการจดบันทึก สิ่งที่เกิดขึ้นคือคุณพ่อคุณแม่สามารถ “เชื่อ” ความถูกต้องของระบบการจดบันทึกนี้ได้ คราวนี้หากว่าน้อง ก. แอบเปลี่ยนข้อมูลการใช้เงินของตัวเองในสมุด ก. ข้อมูลนั้นก็จะไม่ตรงกันกับข้อมูลใน สมุด ข. และ ค. คุณพ่อคุณแม่ก็จะทราบทันทีว่ามีการปลอมแปลงข้อมูลเกิดขึ้นจากการเทียบดูสมุดแต่ละเล่มบล็อคเชนคือ การจดบันทึกซ้ำซ้อนลงไปในฐานข้อมูลหลายตัว(ปัจจุบัน บิทคอยน์และอีเธอเรียม แต่ละเหรียญมีฐานข้อมูลประมาณ 10,000 ตัว) ซึ่งมีอัลกอริทึ่มทางคณิตศาสตร์ในการรักษาเงื่อนไขในการบันทึกข้อมูลว่าทุก node ต้องมีข้อมูลชุดเดียวกันเป๊ะๆ ดังนั้น จึงไม่สามารถปลอมแปลง คัดลอก(ก๊อปปี้) ข้อมูลดังกล่าวไปแปะเพิ่มให้มากขึ้นได้แท้จริงแล้ว บิทคอยน์ ก็คือข้อมูลที่ถูกบันทึกอยู่ในสมุด ก. ข. ค. นั่นเอง เช่นว่าน้อง ก. มี 10 บิทคอยน์ พี่ ข. มี 20 บิทคอยน์ และพี่ ค. มี 30 บิทคอยน์ โดยเมื่อ ลุง ง. อยากมีบิทคอยน์บ้าง ก็ติดต่อขอซื้อบิทคอยน์จาก ผู้ที่ถืออยู่(พี่น้อง ก. ข. ค.) โดยน้อง ก. อาจจะขายให้ ลุง ง. ที่เหรียญละ 100 บาท เมื่อตกลงกันได้แล้ว น้อง ก. ก็ต้องทำการบันทึกเพิ่มลงไปว่า ตนเองเหลือ 8 เหรียญ ลุง ง. มี 2 เหรียญ เช่นเดียวกันกับ พี่ ข. และ พี่ ค. ลงไปในสมุดทั้ง 3 เล่มนั่นเองสรุปคือ บล็อคเชนเป็นฐานข้อมูลซ้ำซ้อน ที่มีผู้ถือครองอยู่ทั่วโลก ทำให้ไม่สามารถเปลี่ยนข้อมูลที่จดบันทึกไปแล้วได้ โอกาสถัดไปจะพูดถึงการรักษาความปลอดภัยกรณี 3 พี่น้อง เกิดโกง ลุง ง. ระบบจะป้องกันการโกงอย่างไรครับ

การที่เราสร้างโมเดลๆ หนึ่งขึ้นมาทำนายผลนั้น การวัดประสิทธิภาพของโมเดลเป็นสิ่งที่สำคัญ และจำเป็นต้องทำเพื่อเราจะได้รู้ว่าโมเดลนั้นๆ ดีแค่ไหนก่อนที่เราจะทำไปใช้งานจริง บทความนี้เลยอยากจะเขียนถึงการวัดผลโดยใช้ปัญหาที่เรียกว่า Two-Class Prediction หรือ Binary Classification ซึ่งเป็นการวัดประสิทธิภาพที่เรานิยมใช้กัน ตัวอย่างของปัญหานี้ก็อย่างเช่น การตรวจจับสแปมหรือไม่ ถ้าเป็นก็ตอบ Yes ถ้าไม่เป็นก็ตอบ No เป็นต้นโดยเราจะบอกว่าผลลัพธ์ที่ได้ว่าเป็นคลาส Positive หรือ Negative มีได้ 4 แบบ คือTrue Positive (TP) หมายความว่า เราได้ผลลัพธ์จากการทำนายคือ p และค่าจริงๆ ก็คือ p ด้วยFalse Positive (FP) หมายความว่า เราได้ผลลัพธ์จากการทำนายคือ p แต่ว่าค่าจริงๆ แล้วคือ nTrue Negative (TN) หมายความว่า เราได้ผลลัพธ์จากการทำนายคือ n และค่าจริงๆ ก็คือ n ด้วยFalse Negative (FN) หมายความว่า เราได้ผลลัพธ์จากการทำนายคือ n แต่ว่าค่าจริงๆ แล้วคือ pค่า TN จะกลับกันกับ TP และ FN จะกลับกันกับ FP ตามลำดับอ่านแล้วอาจจะสับสน อย่าเพิ่งปิดบทความนี้ครับ >_< ใจเย็นๆ ขอผมยกตัวอย่างมาอธิบายเพิ่มเติมก่อนนะครับ จะได้เห็นภาพมากขึ้น สมมุติว่าเราต้องการจะทำนายว่า พฤติกรรมของคนๆ นี้ผิดปกติหรือไม่? หรืออีกนัยหนึ่งคือ เราต้องการที่จะตรวจจับพฤติกรรมที่ผิดปกติของคนๆ หนึ่งในที่นี้จะได้ว่า พฤติกรรมที่ผิดปกติคือคลาส Positive ส่วนพฤติกรรมปกติคือคลาส Negative จะได้ว่าTP คือ ระบบเราตรวจจับได้ว่าคนๆ นี้ผิดปกติ (p) และ คนๆ นี้ได้มีพฤติกรรมผิดปกติจริงๆ (p)FP คือ ระบบเราตรวจจับได้ว่าคนๆ นี้ผิดปกติ (p) แต่ว่า จริงๆ แล้ว เค้าไม่ได้ทำอะไรผิดเลย (n)TN คือ ระบบเราไม่ได้ตรวจจับอะไรเลย (n) และ คนๆ นี้ก็ไม่ได้ทำผิด (n)FN คือ ระบบเราไม่ได้ตรวจจับอะไรเลย (n) แต่ว่า คนๆ นี้ จริงๆ แล้วเค้ามีพฤติกรรมที่ผิดปกติ! (p)พอนึกออกรึเปล่าครับ? เอาอีกสักตัวอย่างเนอะ อย่างถ้าเราเขียนโมเดลระบบตรวจจับสแปมเมล ถ้าเจอสแปมเมลให้ลบทิ้งเลย (ระบบ Aggressive หน่อยๆ)ในที่นี้จะได้ว่า เมลที่เป็นสแปมคือคลาส Positive ส่วนเมลปกติคือคลาส NegativeTP คือ ระบบทำนายว่าเมลนี้เป็นสแปม (p) และ มันก็เป็นสแปมจริงๆ (p)FP คือ ระบบทำนายว่าเมลนี้เป็นสแปม (p) แต่ว่า จริงๆ แล้วเมลนี้เป็นเมลปกติ เช่น ข่าวสารทั่วไป เมลเกี่ยวกับงานต่างๆ (n)TN คือ ระบบทำนายว่าเมลนี้เป็นเมลปกติ (n) และ เมลนี้ก็ปกติจริงๆ (n)FN คือ ระบบทำนายว่าเมลนี้เป็นเมลปกติ (n) แต่ว่า จริงๆ แล้วมันเป็นสแปม! (p)ค่าที่ได้จาก 2 ตัวอย่างข้างต้นนี้ สามารถช่วยให้เราวิเคราะห์และนำไปพัฒนาโมเดลให้ดียิ่งขึ้นได้อีก จากตัวอย่างแรกจะเห็นได้ว่าค่า FN นั้นสำคัญมาก ถ้าค่า FN เราสูงไปแสดงว่า เราตรวจจับคนร้ายไม่ได้เลย และจากตัวอย่างที่สองจะเห็นได้ว่าค่า FP นั้นสำคัญ เนื่องจากเป็นระบบแนวโหดที่เวลาเจอสแปมแล้วจะลบทิ้งเลย ดังนั้นถ้าค่า FP สูง ระบบเราก็อาจจะลบเมลสำคัญๆ ของเราทิ้งไปนั่นเองที่เขียนมาด้านบนอาจจะจำยากหน่อย ว่าแบบไหนจะเรียก False Positive หรือแบบไหนเราจะเรียกว่า False Negative ผมวิธีจำง่ายๆ มาเสนอครับ ตามนี้เลยให้ดูก่อนว่าเป็น Positive หรือ Negative โดย Positive คือ โมเดลของเราทำนายว่ามันเป็น Positive (เป็นคนร้ายหรือเป็นสแปม)แล้วเราค่อยดูว่า True หรือ False ครับ ถ้า True คือ ที่ โมเดลของเราทำนายไปนั้น ถูกต้องแล้ว ถ้า False คือ โมเดลเราทำนายผิดเวลาเราตรวจหาอะไรก็ให้สิ่งนั้นเป็น Positive เช่น จะตรวจหาสแปม เราก็ให้สแปมเป็น Positive แล้วถ้าระบบเราทำนายว่าเป็นสแปมจริงๆ ก็แปลว่าเราได้ค่า True Positive ถ้าระบบเราทำนายว่าไม่ใช่สแปม แต่จริงๆ เป็นสแปม ก็แปลว่าเราได้ False Positive นั่นเองหวังว่าจะได้ประโยชน์กันนะครับ

ในการพัฒนาระบบทางด้าน IoT นั้นมีหลายโพรโตคอล (Protocol) ให้เราเลือกใช้ ซึ่งทางผู้เขียนเห็นว่า MQTT เป็นตัวเลือกที่ดีในการเริ่มต้นกับงาน หรือการเขียนโปรแกรมทางด้าน IoT ค่ะIntroducing MQTTMQTT เป็น Protocol ที่แรกเริ่มได้ถูกออกแบบเพื่อนำไปใช้ในการติดต่อระหว่างท่อน้ำมันและดาวเทียม ดังนั้น Protocol ตัวนี้จะต้องใช้พลังงาน และ Bandwidth น้อยที่สุด MQTT ถูกใช้โดย IBM เพียงผู้เดียว มาเกือบทศวรรษ หลังจากถูกคิดค้นออกแบบ หลังจากนั้น IBM ก็ได้ปล่อยตัว MQTT 3.1 ให้คนภายนอกได้ใช้กันปี 2014 MQTT 3.1.1 ได้รับการรับรองมาตรฐานโดย OASIS และ ISO และจากเดิมที่เคยเป็นเพียง acronym (MQTT — MQ Telemetry Transport) MQTTได้กลายมาเป็นชื่อของ Protocol ซึ่งถูกใช้อย่างแพร่หลายในโลกของ IoT และ M2M(Machine to Machine) เพราะมีข้อดีที่ว่ามีขนาดเล็ก สามารถส่งข้อมูลได้เกือบ Real-time โดยใช้ Bandwidth ต่ำ และมี Delivery Guarantee ถึงแม้จะใช้กับ Network ที่ไม่ค่อยสถียร และ ที่สำคัญ ไม่ยุ่งยากสำหรับ DevelopersPublish & Subscribe Basicspublish / subscribe หรือ ที่รู้จักกันว่า pub / sub ซึ่งเป็นอีก Architecture นึง ที่แตกต่างไปจาก Client-Server ที่เราๆรู้จักและใช้กันมานาน เพราะ Publisher หรือ Client ที่ใช้ส่งข้อความ และ Subscriber หรือ Client ที่ใช้รับข้อความ จะไม่คุยกันโดยตรง เหมือนเช่น Client และ Server แต่จะพูดคุยผ่าน Broker ซึ่ง Broker เองก็มีหน้าที่สำคัญในการ Filter ข้อความที่ได้รับจาก Publisher เพื่อจัดส่งต่อไปยัง Subscriber ที่สนใจจะรับข้อความนั้นได้อย่างถูกต้องการแยก Publisher และ Subscriber ไม่ให้คุยกันโดยตรง มีข้อดีหลายอย่าง Publisher และ Subscriber ไม่จำเป็นต้องรู้จักกัน ไม่จำเป็นต้องรู้ว่าใคร IP หรือ Port อะไร และไม่จำเป็นต้อง Online พร้อมกัน เพราะมี Broker เป็นตัวควบคุมดูแลอยู่ และทำให้การ Scale up ง่ายมากขึ้นBroker จะมีวิธีการ Filter ข้อความ หลากหลายแบบ เช่นSubject-Based Filtering ที่จะ Filter เอาแต่ข้อความที่มี Subject หรือ Topic เป็นส่วนหนึ่งข้อความนั้นๆ ซึ่งโดยทั่วไปตัว Topic จะอยู่ในรูปแบบของ String ที่มีโครงสร้างแบบขั้นเลเวล (Hierachical Structure)Content-Based Filtering ที่จะ Filter เอาแต่ข้อความที่มีContent ตามที่ได้ Subscribe ไว้ ซึ่งจะมีข้อเสียตรงที่เราจำเป็นต้องรู้ Content ของข้อความล่วงหน้า และ เป็นการยากที่จะ Encrypt ข้อความType-Based Filtering เมื่อ Object-Oriented Language ถูกนำมาใช้ ข้อความก็จะถูก Filter จาก Type หรือ Class ของข้อความซึ่งคุณสมบัติต่างๆใน โมเดล Publish /Subscribe ที่พูดถึงข้างต้นนี้ เราสามารถพบเจอได้ใน MQTT ใน MQTT Publisher และ Subscriber จะถูกแยกออกจากกัน เวลาที่ต้องการส่งหรือรับข้อความ ตัว Publisher/Subscriber ต้องการรู้เพียงแค่ Host/IP/Port ของตัว Broker เท่านั้นถึงแม้ว่าโดยปกติแล้ว MQTT จะรับส่งข้อมูลแบบเกือบ Real-Time​ (Near Real-Time) แต่ MQTT สามารถ Store ข้อความให้ Client ที่ Offline ได้ นอกจากนี้ โดยปติแล้ว MQTT ทำงานแบบ Asynchronous แต่ในบางกรณี MQTT ก็รองรับ Synchronous เช่นกัน ในด้านการ Filter ข้อความนั้น MQTT นั้นใช้วิธี Filter แบบ Subject-Basedเพื่อป้องกันปัญหาที่อาจจะเกิดขึ้นในระบบ Pub/Sub MQTT มีการใช้ QoS เพื่อใช้การันตีว่ามีการส่งข้อมูลเรียบร้อย ไม่ว่าจะส่งจาก Broker ไป Client หรือ จาก Client ไป Broker ซึ่งบางครั้งอาจจะเป็นไปได้ว่าไม่มี Clientไหน Subscribe ตัว Topic นี้เลย ดังนั้น ตัว Broker เองต้องมีวิธีที่จะจัดการกับเคสที่ว่าด้วยหลังจากทำความเข้าใจเบื้องต้นเกี่ยวกับระบบ Pub/Sub และ MQTT แล้ว จะเห็นได้ว่า MQTT นั้นมีความแตกต่างจาก Message QueueMessage Queue จะเก็บข้อความไว้จนกว่าจะถูกนำไปใช้โดย Client แต่ใน MQTT บาง Topic ก็ไม่มี Client ตัวไหนสนใจ Subscribe เลยข้อความใน Message Queue จะสามารถถูกนำไปใช้โดย Client รายเดียวเท่านั้น ซึ่งในขณะเดียวกัน MQTT ที่ไม่มีข้อจำกัดตรงนี้Queue ใน Message Queue ที่ถูกสร้างขึ้นและตั้งชื่อแล้วเท่านั้นถึงจะ Publish ได้ ซึ่งต่างจาก MQTT ที่สามารถสร้าง On the fly ได้Client, Broker and Connection Establishmentหลังจากที่พอเข้าใจคร่าวๆเกี่ยวกับ Pub/Subและ MQTT กันแล้ว เราลองมาทำความเข้าใจให้ละเอียดเกี่ยวกับ Client และ BrokerMQTT Client หมายถึง deviceใดๆก็ได้ที่ใช้ MQTT Library และมีการเชื่อมต่อกับ MQTT BrokerMQTT Broker ถือเป็นหัวใจสำคัญของระบบ Pub/Sub เลยทีเดียว หน้าที่สำคัญของ Broker ก็คือ การรับข้อความ และนำข้อความนั้นมา Filter เพื่อให้ทราบว่าจะต้องส่งต่อข้อความนั้นไปให้ Client ที่ Subscribe ไว้ตัวไหนบ้างเมื่อมี Client แล้ว มี Broker แล้ว สองตัวนี้จะต้องเชื่อมต่อกันเพื่อให้เกิด MQTT Connectionโดยเริ่มจากการส่ง CONNECT Message จาก Client ไป Broker หลังจากนั้น Broker จะตอบกลับด้วย CONNACK message และ Status Code ไปที่ Client การเชื่อมต่อจะถูกหยุดลงเมื่อ Client ส่งคำสั่ง Disconnect มาที่ BrokerMQTT Publish, Subscribe & UnsubscribeMQTT Client สามารถ Publish ข้อความได้ทันทีหลังจาก ทำการเชื่อมต่อกับ MQTT Broker ซึ่งในแต่ละข้อความนอกจากจะต้องมี Topic ที่ MQTT Broker สามารถนำไป Filter ได้แล้ว ยังมีส่วนของ Payload ที่มีข้อมูลที่ต้องการส่งหลากหลายรูปแบบ เช่น Text หรือ Image หรือ เกือบทุกรูปแบบที่สามารถอยู่ในรูปแบบของ Binaryได้และเมื่อ Client ต้องการรับข้อความใน Topic ที่สนใจ ซึ่งสามารถทำได้โดยการส่ง SUBSCRIBE Message ไปให้ Broker ซึ่ง ใน SUBSCRIBE Message นี้ก็จะมีลิส ของ Topic ที่ Client สนใจอยู่ และ Broker ทำการตอบรับด้วยการส่ง SUBACK MessageClient สามารถยกเลิกการรายการที่เคย Subscribe ไว้กับ Broker ด้วยการส่ง UNSUBSCRIBE Message และเช่นเคย Broker จะทำการตอบรับด้วยการส่ง UNSUBACK Message เพื่อเป็นการยืนยันกับ Client ว่าคำร้องขอยกเลิกได้ถูกคอนเฟิร์มแล้วMQTT TopicsMQTT Topic คือ UTF-8 String ที่ถูกใช้โดย Broker ในการ Filter ข้อความ ซึ่ง Topic สามารถมีได้หลายเลเวล แต่ละเลเวลจะถูกแบ่งด้วยเครื่องหมาย / (Slash) ในแต่ละ Topic ต้องมีอย่างน้อย 1 ตัวอักษรClient สามารถเลือกที่จะ Subscribe เฉพาะเจาะจง Topic หรือ สามารถ ใช้ Wildcard ในการเลือกรับหลายๆ Topic ซึ่งก็จะมีการใช้อยู่ 2 แบบ คือ แบบ Single Level และ แบบ Multi LevelSingle Level ( + ) Wildcard สามารถใช้แทนที่ Topic เพียง หนึ่ง เลเวล โดยใช้เครื่องหมาย + (Plus)Multi Level (#) Wildcard สามารใช้แทนได้มากกว่าหนึ่ง Topic ซึ่ง # (Sharp) จะต้องอยู่เป็นตัวอักษรสุดท้าย และต้องมี /(Slash) นำหน้าบทความนี้ก็อาจจะหนักหัวหน่อยนะคะ แต่รับรองคุ้มค่าที่จะรู้จักกับ MQTT ค่ะ แต่ยังมีความสามารถอีกหลายอย่างเลยที่เรายังไม่ได้พูดถึง เราจะค่อยๆเรียนรู้ไปด้วยกันนะคะ แล้วพบกันใหม่ในตอนหน้าค่ะ