บทความ
ไม่ว่าจะ ข่าวสาร บทสัมภาษณ์ และ Digital Skill บนสื่อ
มีให้คุณได้อ่านบทความดี ๆ มากมายแล้วที่นี่
โดย: Laris
| IoT
มารู้จัก MQTT Protocol กันดีกว่า (ตอนที่ 5)
มาต่อกันกับอีก Feature นึง ของ MQTT ค่ะ ซึ่งก็คือ Last Will and Testament ค่ะเนื่องจาก MQTT มักจะถูกนิยมนำมาใช้ในเคสที่ Network ไม่มีความเสถียรสักเท่าไหร่ อย่างเช่น สัญญาณไม่แรงและแกว่งเป็นต้นค่ะ ในเคสที่สัญญาณไม่เสถียรแบบนี้ การเชื่อมต่อระหว่าง Broker และ Client ต้องมีปัญหาแน่นอนค่ะ บางครั้งการเชื่อมต่อก็อาจจะขาดหายไปดื้อๆแบบไม่ตั้งใจ ซึ่งอาจจะเกิดจากปัญหาที่ตัวสัญญาณเอง หรือ แบตเตอรีหมด และเป็นไปได้อีกหลายสาเหตุค่ะ การขาดหายของสัญญาณแบบนี้จะเรียกว่า Ungracefully Disconnect ค่ะ ไม่มีการแจ้งเตือนมาก่อนว่าจะ Disconnect ค่ะ เพราะปกติแล้ว ใน MQTT การจะ Disconnect (แบบมีมารยาท และ ตั้งใจที่จะตัดการเชื่อมต่อ) จะต้องมีการส่ง MQTT Disconnect Message ค่ะ เรียกอีกอย่างก็ Gracefully Disconnect ค่ะ ดังนั้น Broker จึงจำเป็นต้องทราบค่ะ ว่าการขาดหายของการเชื่อมต่อระหว่าง Broker และ Cleint นั้นเป็นการ Disconnect แบบไหน ตั้งใจ (Gracefully) หรือ ไม่ตั้งใจ (Ungracefully) เพื่อที่ Broker จะได้จัดการกับสถานการณ์ได้อย่างถูกต้องค่ะหากมีการเชื่อมต่อของ Client ตัวใดตัวนึงขาดหายไปแบบ Ungracefully ตัว Broker จะใช้ Last Will and Testament (LWT) แจ้งไปยัง Client อื่นๆที่เหลือ เพื่อบอกกล่าวว่า Client ตัวนี้ได้ Offline ไปแล้วค่ะClient แต่ละตัว สามารถฝาก Last Will Message ให้กับ Broker ได้ ในระหว่างที่เริ่มทำการ Connect กับ Broker ซึ่งตัว Last Will Message นี้ก็คือ MQTT Message ธรรมดาทั่วไปนี่แหละค่ะ ข้างในก็จะมี Topic, Retained Message Flag, QoS, และ Payload อย่างเช่นในรูป Fig 1 ข้างล่างค่ะFig 1. MQTT Connect MessageBroker จะรับฝาก Last Will Message ไว้จนกว่าจะมีการ Disconnect จาก Client นั้นๆค่ะ ซึ่งถ้าการ Disconnect เป็นแบบ Ungracefully ตัว Broker ก็จะทำการส่ง Last Will Message นี้ให้กับ Client ที่เหลือที่ได้ทำการ Subscribe ตรงกับ Topic ที่ระบุไว้ใน Last Will Message ค่ะ แล้วเคสไหนที่ Broker ถือว่าเปนการ Ungracefully Disconnect ลองมาดูกันค่ะ ว่ามีเคสไหนบ้างเมื่อ Broker เจอว่ามี Error เกิดขึ้นของ I/O หรือ Network เมื่อไม่มี Message ใดๆ จาก Client ส่งมาในช่วงเวลาที่กำหนด หรือ Keep Alive Period (Keep Alive คืออะไร? ในบทความถัดไป มาทำความรู้จักกันค่ะ….)เมื่อพบว่า Client ไม่มีการส่ง Disconnect Message มาให้ก่อนที่จะมีการปิดการเชื่อมต่อไปเมื่อ Broker เองเป็นคนตัดการปิดการเชื่อมต่อเนื่องจาก Error ของ MQTT Protocol เองแต่ถ้าหากมีการส่ง MQTT Disconnect Message — Gracefully Disconnect (Fig 2) ตัว Broker ก็จะลบ Last Will Message ที่เก็บไว้ให้ทิ้งค่ะFig 2. MQTT Disconnect Messageจะเห็นว่า LWT มีความบทบาทสำคัญในการแจ้งเตือน Client ตัวอื่นๆ โดยเฉพาะ Client ที่ได้ทำการ Subscribe ไว้กับ Client ตัวที่ได้ขาดการติดต่อไปแบบ Ungracefully DisconnectLWT มักจะถูกนำมาใช้คู่กับ Retained Message เพื่อทำการเก็บ State ล่าสุด(ของ Topic ใด Topic นึง) ของ Client ไว้ ถึงตรงนี้อาจจะยังนึกไม่ออกนะคะ ว่าจะเอา LWT และ Retained Message มาใช้เก็บ State ล่าสุดยังไง ลองมาดูตัวอย่างค่ะ…..Client1 เริ่มทำการเชื่อมต่อกับ Broker ด้วยการส่ง Connect Message ให้ Broker และ ใน Connect Message นี้ก็ระบุ payload ของ lastWillMessageไว้ว่า ‘Offline’ และ มีการเซท lastwillRetain ให้เป็น true และ มี lastWillTopic เป็น ‘client1/status’ (เลื่อนขึ้นไปดู ตัวอย่าง Connect Message ได้นะค่ะ — Fig 1)หลังจากทำการเชื่อมต่อเรียบร้อย Client ก็สามารถเริ่ม Publish ข้อความที่มี Payload ว่า ‘Online’ และ retaionFlag เซทเป็น true ไปที่ Topic ที่ตั้งไว้ตอนทำการเชื่อมต่อค่ะ (client1/status) ซึ่งในระหว่างนี้หากไม่มีการ Disconnect เกิดขึ้น Client ที่ได้ทำการเข้ามา Subscribe ใหม่ที่ Topic นี้ (client1/status) จะได้รับ Retained Message ที่มี Payload ว่า ‘Online’แต่หากว่าการเชื่อมต่อ ระหว่าง Client1 และ Broker มีการ Ungracefully Disconnect เกิดขึ้น Broker จะทำการ Publish LWT Message (ซึ่งมี Payload ว่า ‘Offline’) แทน Retained Message เดิม (ซึ่งมี Payload ว่า ‘Online’) นั่นหมายความว่าถ้ามี Client เข้ามา Subscribe หลังจากที่ Client1 ขาดการติดต่อไป จะได้รับ Message ที่มี Payload ว่า Offline ถึงตรงนี้แล้วพอจะนึกภาพออกแล้วใช่มั้ยคะ ว่าคู่บัดดี้ LWT Message และ Retained Message เข้ามาช่วยจัดการเกี่ยวกับ State ล่าสุดของ Topic ได้ยังไงในบทความถัดไป เราจะพูดถึงเรื่อง Keep Alive ค่ะ ซึ่งนี่ก็เป็น Feature เด่นอีกอย่างนึงของ MQTT ที่จะช่วยให้ Broker รู้ถึงสถานะของ Client ได้ค่ะ ว่า Online อยู่ หรือ Offline ไปแล้วอ้างอิงจาก MQTT Essentials Part 9: Last Will and Testament
โดย: Kan Ouivirach
| Machine Learning
มารู้จัก Mean Shift Clustering กัน
บทความก่อนหน้านี้เราพูดถึงวิธี Clustering กันไปแล้ววิธีหนึ่งคือ K-Means บทความนี้เรามารู้จักวิธี Clustering อีกวิธีหนึ่งที่ชื่อว่า Mean shift กันครับข้อแตกต่างระหว่าง Mean Shift กับ K-Meansที่เห็นได้ชัดๆ คือMean shift เป็น density-based clustering ส่วน k-means เป็น centroid-based clustering กล่าวคือ Mean shift จะใช้คอนเซปของ kernel density estimation (KDE) ในการหาตัวแทนกลุ่มของข้อมูล หรือ centroid ในขณะที่ k-means จะใช้ค่าเฉลี่ยระหว่างจุดกับ centroid ในการขยับ centroid ไปเรื่อยๆMean shift ไม่จำเป็นต้องรู้จำนวนกลุ่มของข้อมูลก่อน ส่วน k-means จำเป็นที่ต้องรู้ก่อน แต่ Mean shift ก็มีค่า parameter ที่เราต้องปรับเองตามการใช้งานครับ เค้าเรียกกันว่า kernel bandwidthหลักการทำงานของ Mean Shiftให้จุดทุกจุดเป็น cluster ของตัวมันเองก่อนเลย ถ้ามี 10 จุดข้อมูล ก็แปลว่าเรามี 10 clusters ก่อนเลยครับให้เราเลือก kernel ที่เหมาะสมกับข้อมูล ซึ่งโดยปกติแล้วจะเป็นฟังก์ชั่น Gaussian ครับ ตามสูตรของ Gaussian แล้ว เราจะได้ว่า kernel bandwidth ของเราคือ standard deviation นั่นเอง :Dคัดลอกจุดทุกจุดเก็บไว้ก่อนเป็น 2 ชุดข้อมูล แล้วนำจุดทุกจุดในชุดข้อมูลใดข้อมูลหนึ่ง ผมเรียกว่าเป็นข้อมูลชุดที่ 1 กับข้อมูลชุดที่ 2 ละกัน แล้วทำไมต้องแยกเป็น 2 ชุด? นี่เป็นเหตุผลทางด้านการเขียนโปรแกรมล้วนๆ ครับ :Pเสร็จแล้วเราจะมา estimate กับจุดทุกจุดในข้อมูลชุดที่ 2 โดยใช้ kernel ที่เราเลือกมากับจุดทุกจุดในข้อมูลชุดที่ 1 ครับ หรือพูดง่ายๆ ว่าเราใช้จุดทุกจุดในการอัพเดท cluster แต่ละ cluster ครับ ซึ่งจุดแต่ละจุดในข้อมูลชุดที่ 2 จะถูก estimate แล้วจะค่อยๆ เลื่อนเข้าสู่จุด convergence หรือจุดสูงสุดของ Gaussian (นึกภาพระฆังคว่ำ) แล้วเราอัพเดท cluster อย่างไรล่ะ? ขอยกไปอธิบายคร่าวๆ ต่อด้านล่างหลังจากที่ converge แล้ว ถ้าข้อมูลของเรามีการกระจายตัวหน้าตาแบบมี 3 ระฆังคว่ำ (หรือ 3 clusters) จุดข้อมูลของเราก็จะย้ายไปสู่จุดสูงสุดของ 3 ระฆังคว่ำนั้นโดยอัตโนมัติเองครับท้ายที่สุดคือการ assign จุดเหล่านั้นว่าควรจะอยู่ cluster ไหน ยังจำข้อมูลที่เราคัดลอกไว้ในข้อ 3 ได้ใช่ไหมครับ? เราก็เอาจุดเหล่านั้นมาทีละจุด เทียบระยะห่างระหว่างจุดสูงสุดของระฆังคว่ำที่เราได้มา จุดไหนใกล้ก็ assign จุดนั้นให้เข้าไปกับระฆังอันนั้นครับเป็นอันเสร็จสิ้น!สำหรับการ shift หรืออัพเดทค่า mean (เป็นเหตุผลที่เค้าเรียกว่า mean shift) ทำได้โดยใช้เทคนิค gradient ascent ครับ ซึ่งจริงๆ คือ gradient descent แต่แค่มีทิศตรงข้าม ลองดูสมการในรูป 1 ด้านล่างนี้ครับ เป็นรูปจากงานวิจัยของ Dorin Comaniciu กับ Peter Meerรูปพจน์ของ Mean Shiftสมการที่ 17 นี้เป็นพจน์ของ mean shift ครับ ซึ่งเราสามารถนำเอาส่วนที่ผมตีกรอบเส้นประสีแดงมาเป็นค่า mean ที่โดน shift แล้ว ส่วนฟังก์ชั่น g ในทีนี้ก็คือ kernel ของเรานั่นเอง ซึ่งในงานวิจัยนี้เค้าพิสูจน์ว่ามันเพียงพอสำหรับการ converge ลองตามไปอ่านกันดูนะครับ math เยอะสะใจดี >_<การเลือกค่า kernel bandwidth นั้นมีผลต่อจำนวน cluster ที่เราจะได้ ถ้าเราใช้ค่า bandwidth ที่ต่ำมากๆ เราอาจจะได้จำนวน cluster เท่ากับจำนวนจุดเลยก็ได้ แต่ถ้าเราเลือกค่าที่สูงเกินไป เราอาจจะได้แค่ 1 cluster ดังนั้นค่านี้ควรจะปรับให้เหมาะสมเองครับโดยการทดลองหรืออะไรก็แล้วแต่
โดย: Pii
| Blockchain
อนาคตอีเธอเรียมจากปากนายวิทาลิค
เมื่อไม่นานมานี้ผมมีโอกาสนั่งย่อยความเห็นเกี่ยวกับทิศทางและความเป็นไปได้ของอีเธอเรียมจากมุมมองของนายวิทาลิค บูเทอริน(Vitalik Buterin) ซึ่งเป็น 1 ในผู้ร่วมก่อตั้งบล็อคเชนอีเธอเรียมขึ้นมา สัมภาษณ์ในวันที่ 20 มีนาคม พ.ศ. 2562 ประเด็นต่างๆค่อนข้างน่าสนใจมากสำหรับคนที่ติดตามเทคโนโลยีและวงการบล็อคเชนอยู่ในขณะนี้ครับคำถาม: อีเธอเรียมกำลังถูกเหรียญสกุลอื่นๆไล่ตามขึ้นมาจริงหรือไม่?เขายอมรับตามตรงว่าปัจจุบันมีเหรียญหลายตัวที่น่าสนใจและดูมีศักยภาพ การพัฒนาอีเธอเรียมเองไม่สามารถจะเร่งรัดได้ตามต้องการทีเดียว โปรเจคต่างๆบนอีเธอเรียมยังมีไม่มากพอ การพัฒนาโปรเจคเหล่านี้จะดีขึ้นเรื่อยๆเมื่อมีตัวอย่างโปรเจคที่สำเร็จมากขึ้น เพื่อที่นักพัฒนาจะได้สามารถเรียนรู้วิธีการจากตัวอย่างเหล่านี้ ถ้าหากวันนึงอีเธอเรียมถูกแทนที่ด้วยบล็อคเชนอื่น เช่น Zcash หรือ Ethereum Classic วิทาลิคบอกว่าเป็นธรรมดาที่เทคโนโลยีจะต้องถูกเปลี่ยนไปตามความต้องการของผู้ใช้ แต่ว่าถ้าวันนั้นบล็อคเชนที่ขึ้นมาแทนอีเธอเรียมคือ Tron เขาคงจะหมดศรัทธาในวงการนี้เลยทีเดียวคำถาม: มีข่าวว่านักพัฒนาอีเธอเรียมได้ค่าแรงน้อยเกินไปจริงหรือไม่? เขาให้ความเห็นสั้นๆว่าองค์กรพัฒนาอีเธอเรียมยังควบคุมทุกอย่างได้อย่างไม่มีปัญหาอะไร และถ้าสมมุติว่าไม่มีใครบ่นเรื่องค่าจ้างเลยสักคนเดียว แสดงว่าองค์กรจ่ายค่าแรงให้มากเกินไปคำถาม: มูลค่าของเหรียญอีเธอเรียมมีผลกระทบใดต่อองค์กร หรือเหล่านักพัฒนาบ้างหรือไม่? เขาตอบตรงๆว่าในวงการนี้มีหลายโปรเจคที่ปั่นราคาขึ้นลงไปมามากมายในช่วงที่ผ่านมา ซึ่งสำหรับโปรเจคที่ตั้งใจพัฒนาเทคโนโลยีเพื่อตอบโจทย์คนใช้จริงๆ อย่างอีเธอเรียมนั้นไม่มีผลกระทบมากเท่าโปรเจคปั่น แต่สุดท้ายแล้วถ้ามูลค่ามันสูงโปรเจคต่างๆก็จะดำเนินไปได้ราบรื่นกว่าคำถาม: คิดยังไงกับพวกฟองสบู่โปรเจค ICO บนอีเธอเรียมทั้งหลายที่ผ่านมา? วิทาลิคบอกว่ายังไงโปรเจคพวกนี้ก็ต้องมีคนทำอยู่ดี ต่อให้ไม่ใช่บนอีเธอเรียม เขาเซ็งกับพวกประเภทที่มาขอถ่ายเซลฟี่กับเขา แล้วก็เอารูปเขาไปใช้ในฐานะ advisor ของโปรเจคเหล่านั้นมากกว่า คำถาม: การระดมทุนโปรเจคด้วยระบบอีเธอเรียมถือว่าผิดกฎหมายหรือไม่?เขาตอบว่าองค์กรอีเธอเรียมมีทีมนักกฎหมายพร้อมอยู่แล้ว ไม่จำเป็นต้องกังวนในเรื่องนี้คำถาม: มีความเห็นเรื่องการทำลายธุรกิจผูกขาดด้วยบล็อคเชนว่าอย่างไร? เขาเล่าสั้นๆว่าบล็อคเชนจะทำให้บริษัทขนาดเล็กหลายบริษัทสามารถทำงานร่วมกันเพื่อโค่นบริษัทที่ผูกขาดขนาดใหญ่ได้ โดยที่บริษัทขนาดเล็กเหล่านั้นก็ไม่ได้มีสถานะเป็นบริษัทผูกขาดแต่อย่างใดสุดท้ายวิทาลิคให้ความเห็นว่าอีเธอเรียมต่างจากบิทคอยน์ที่มีคนวางกฎ กำหนดทิศทางที่เทคโนโลยีควรจะเป็น ควรดำเนินเดินไป บิทคอยน์เป็นเหมือนทฤษฎีหรืองานวิจัยดิบที่เมื่อพิสูจน์ได้ว่าทำได้ก็ปล่อยมันออกมาทั้งแบบนั้นเลย ทำให้มีปัญหาในเรื่องมุมมองและความเห็นต่างของนักพัฒนา
โดย: Kan Ouivirach
| Machine Learning
เทคนิคง่ายๆ ในการเลือก Feature สำหรับโมเดล Machine Learning
การเลือก 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 เผื่ออยากเอาไปลองรันเล่น
โดย: Laris
| IoT
มารู้จัก MQTT Protocol กันดีกว่า (ตอนที่ 4)
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 อีกครั้งนึงค่ะ
โดย: Kan Ouivirach
| Machine Learning
Clustering Analysis
การทำ 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 ครับ
โดย: Laris
| IoT
มารู้จัก MQTT Protocol กันดีกว่า (ตอนที่ 3)
บทความที่แล้วเราได้พูดถึงหนึ่งใน 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 กันค่ะ แล้วพบกันนะคะ สวัสดีค่ะ
โดย: Pii
| Blockchain
การตรวจสอบแหล่งน่านน้ำที่จับปลาทูน่าด้วยบล็อคเชน
บริษัท Pacifical ผู้จัดจำหน่ายเนื้อปลาทูน่า เป็นบริษัทขนาดใหญ่มีการร่วมทุนข้ามชาติระหว่าง 8 ประเทศ มีจุดประสงค์ในการจัดการการประมงปลาทูน่าโดยเฉพาะ เพื่อไม่ให้ปลาทูน่าถูกจับมากเกินไปจนเสียสมดุลย์ จัดสรรปันส่วนสิทธิ์ในการจับ แบ่งผลิตผลไปตามภูมิภาคต่างๆ และรวมไปถึงการจัดการทรัพยากรบุคคลในวงการของแต่ละประเทศปัจจุบัน Pacifical ได้มีการนำเอาเทคโนโลยีบล็อคเชนเข้ามาจัดการข้อมูลแหล่งที่มาของปลาทูน่าโดยเฉพาะ เพื่อความโปร่งใสและความสะดวกสบายแก่ลูกค้าปลายทาง โดยปกติแล้วถ้าเราต้องการทราบว่าปลาทูน่ากระป๋องยี่ห้อต่างๆ ที่เราซื้อมาจากห้างนั้นมีต้นตอถูกจับมาอย่างถูกต้องหรือไม่ จับมานานแล้วแค่ไหน ใครเป็นคนจับมีการใช้แรงงานเถื่อนหรือไม่ ฯลฯ เราอาจต้องใช้ความพยายามอย่างมากในการหาข้อมูลเหล่านี้และโดยที่ไม่สามารถรู้ได้เลยว่าข้อมูลเหล่านี้ถูกบิดเบือนเพื่อสร้างภาพแก่ยี่ห้อของปลากระป๋องนั้นๆหรือไม่เทคโนโลยีบล็อคเชนมีบทบาทสำคัญอย่างยิ่งในการแก้ปัญหาดังกล่าว กระบวนนี้บล็อคเชนจะถูกใช้เป็นฐานข้อมูลกลางที่ไม่ได้ขึ้นกับใคร และไม่มีใครหรือองค์กรใดเป็นผู้ครอบครอง โดยปลาทูน่ากระป๋องที่มาจากบริษัท Pacifical จะมี QR code ข้างกระป๋องทุกกระป๋อง เราสามารถดาวน์โหลดแอพและแสกน QR code เพื่อดูข้อมูลต่างๆที่ต้องการได้ทันที ข้อมูลของปลาที่อยู่ในกระป๋องนั้นๆ จะถูกตรวจสอบและเขียนข้อมูลนั้นๆลงบนบล็อคเชนโดยองค์กรอิสระ ข้อมูลดังกล่าวจึงแก้ไม่ได้ในภายหลังกระบวนการเขียนและอ่านข้อมูลผ่านบล็อคเชน โดยบริษัท Atato ผู้ให้บริการ ประยุกต์ใช้บล็อคเชนผู้บริโภคจำนวนมากในหลายประเทศเริ่มใส่ใจและให้ความสนใจกับแหล่งที่มาของผลผลิตต่างๆมากขึ้น โดยมองเรื่องราคาต่ำเป็นรอง ข้อมูลต่างๆเหล่านี้จะไม่มีน้ำหนักมากพอถ้าไม่ได้มาจากบล็อคเชน เนื่องจากมันสามารถถูกแก้ไขได้อย่างง่ายดายจากผู้ที่มีผลประโยชน์ บล็อคเชนเป็นฐานข้อมูลที่มีความโปร่งใส แก้ไม่ได้ และมีความปลอดภัยสูงที่สุด
โดย: Kan Ouivirach
| Machine Learning
การจัดการ Missing Data
ทำไมเราถึงต้องมาดูการจัดการ 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 ไปใช้กับข้อมูลอื่นได้เลยนะครับ ข้อมูลอื่นก็เป็นส่วนของข้อมูลอื่น เรายังคงต้องทดลองกับหลายๆ วิธีอยู่ดี ;)
โดย: Laris
| IoT
มารู้จัก MQTT Protocol กันดีกว่า (ตอนที่ 2)
หลังจากบทความที่ผ่านมา เราพูดถึง 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 จะมีการจัดการเรื่องนี้ให้เรายังไง คอยติดตามอ่านกันนะคะ สวัสดีค่ะ

พบบทสัมภาษณ์ได้ที่นี่เร็ว ๆ นี้

พบDigital Skill บนสื่อ ได้ที่นี่เร็ว ๆ นี้

หมวดหมู่

พบหมวดหมู่ ได้ที่นี่เร็ว ๆ นี้

พบหมวดหมู่ ได้ที่นี่เร็ว ๆ นี้

Tags

พบคำสำคัญ ได้ที่นี่เร็ว ๆ นี้

พบคำสำคัญ ได้ที่นี่เร็ว ๆ นี้

พบคำสำคัญ ได้ที่นี่เร็ว ๆ นี้