open source ด้าน data observability (2022)

หมายเหตุ ผู้อ่านสามารถดู table of contents ของ Data Engineering from Noob to Newbie ได้ที่ http://bit.ly/2P7isEw

refer: https://www.kdnuggets.com/2020/02/observability-data-engineering.html

โดยปกติในตลาด oss (open source software) หากไม่มีบริษัทใหญ่หรือ community ที่แข็งแรงมาช่วย support ก็อาจจะหยุดพัฒนาและหลุดหายจากตลาดได้ทุกเมื่อ หรือในทางกลับกัน oss ที่พัฒนาไปอย่างช้าๆและดูเหมือนจะมี feature ด้อยกว่าคู่แข่งในตลาด อาจจะได้รับแรงพลักดันใหม่และกลับมาโดดเด่นในตลาดได้ อย่างเช่นกรณีของ datahub ที่หากย้อยกลับไปก่อนประมาณปี 2019–2020 ตัว datahub ซึ่งเป็น oss ด้าน data discovery ของ linkedin ที่มี ui ที่แข็งและการใช้งานที่ยากเพราะแค่ docker-compose up ยังมี error ตามมาไม่รู้เท่าไร ทำให้ในยุคนั้นหากถามผมว่าตัวเลือกด้าน data discovery ในตลาด oss มีอะไรน่าจะสนใจบ้างผมคงตอบได้ว่า Amundsen ของ Lyft และ Atlas ของ Apache คือตัวเลือกที่ดีที่สุดในตลาดในเวลานั้น แต่หลังจาก Acryl Data ได้เข้ามามีส่วนร่วมในการพลักดันและเปลี่ยนโฉม datahub ไปอย่างมาก ทำให้ทุกวันนี้สามารถบอกได้เลยว่า datahub คือเบอร์ 1 ในตลาดอย่างไม่ต้องสงสัย จากกรณีเรื่องตลาด oss ของ data discovery ข้างต้นทำให้เกิดความตั้งใจของบทความนี้ที่จะหยิบยกผู้เล่นต่างๆในตลาด oss ด้าน data observability มารีวิวกันว่า ณ ช่วงเวลานึง มีตัวเลือกหรือการเปลี่ยนแปลงที่น่าสนใจเกิดขึ้นกับตลาดหรือไม่

Data Observability เป็น 1 ใน data governance concepts ซึ่งมี tool ที่เป็นตัวเลือกในตลาดแบบ enterprise(เสียตัง) อยู่หลายเจ้าด้วยกัน แต่ในตลาด oss นั้นกลับหาตัวเลือกที่มี features แบบครบเครื่องลำบากที่สุด ซึ่งคำว่าครบเครื่องในความหมายของผมนั้นประกอบไปด้วย features ดังนี้

• monitor: ในการที่จะให้ dataops มั่นใจได้ว่า data ที่วิ่งอยู่ใน data pipeline นั้นยังอยู่เป็นอย่างที่ควรจะเป็น อาจจะต้องมี UI หรือ status บ้างอย่างที่แสดงถึง health ของ data ที่วิ่งใน pipeline
• anomaly detection: การตรวจพบความผิดปกติที่เกิดขึ้นกับ metric ที่สนใจได้ ซึ่งส่วนใหญ่ที่พบก็จะใช้เทคนิค outlier detection ที่อิงจากการคำนวน z-score ตัวอย่างเช่นถ้า metric ที่เรากำลัง monitor คือยอดขายของบริษัท และเมื่อใดก็ตามที่คำนวน z-score ได้มากกว่า x standard deviation ก็จะบันทึกว่ามีความผิดปกติเกิดขึ้นในรายการยอดขาย
• root cause analysis: จริงอยู่ที่หลังจากเราทำการ monitor และ anomaly detection ได้ ก็จะส่งผลให้ dataops พบความผิดปกติของ data pipeline แทบจะทันทีที่ event นั้นเกิดขึ้น แต่การที่สามารถระบุได้ว่าความผิดปกติที่เกิดขึ้น เกิดขึ้นกับ dimension อะไรได้ จะยิ่งส่งผลดีต่อ SLAs ใน metric ของ Time-to-detection รวมถึงการตอบสนองต่อความผิดปกติเหล่านั้นได้แม่นยำมากขึ้น ตัวอย่างเช่นหากเกิดความผิดปกติกับยอดขายของบริษัทแล้วเรามี root cause analysis feature ระบบสามารถตอบได้ว่าความผิดปกติที่เกิดนั้นเกิดขึ้นที่ dimension ใดเช่น สาขาใด และสินค้าอะไร
• alert channel: ช่องทางการส่ง alert เมื่อระบบตรวจพบ anomaly activity
• setup: การใช้งานในสมัยนี้อย่างตํ่าๆก็ควรมี Dockerfile จัดเตรียมไว้ให้ หรือดีหน่อยก็คงต้องมาเป็น helm chart สำหรับติดตั้งลง k8s

โดยเราจะนำ features ต่างๆข้างต้นมาทำการวิเคราะห์ร่วมกับ oss ด้าน data observability ในตลาดตอนนี้กัน (ช่วงที่เขียน 05/2022) ซึ่งผมจะเรียงลำดับตามลำดับที่ผมได้รู้จักกับ tool นั้นๆ

Data Observability OSS Market

ThirdEye (https://github.com/project-thirdeye/thirdeye)

refer: https://thirdeye.readthedocs.io/en/latest/quick_start.html

ในการเริ่มต้นความพยายามค้นหา oss ด้าน data observability ตั้งแต่ประมาณปี 2019–2020 ต้องบอกว่า ThirdEye เป็นตัวแรกเลยที่ได้ค้นพบ โดยในช่วงนั้นเท่าที่ผมทราบตัว thrideye จะอยู่ภายใต้ Apache Pinot ก่อนจะแยก git repo ออกมาอยู่เดียว โดยมีเอกสารอ้างอิงว่า LinkedIn เป็นผู้เริ่มต้นพัฒนา project นี้ขึ้นมา และบ้างท่านอาจจะพอเดาได้จาก logo ในหน้า ui จากรูปข้างต้น ซึ่งในช่วงแรกของ datahub ก็มี logo ของ LinkedIn ใส่อยู่ประมาณนี้เช่นกัน

ในส่วนการติดตั้งต้องบอกว่าเริ่มต้นได้ติดลบมากเพราะหลังจาก clone git มาแล้วลองติดตั้งตามขั้นตอนกลับเจอ error มากกว่าจะสามารถทำให้ application ทำงานได้ครั้งแรก ซึ่งก็ต้องขอบคุณบทความจาก Greg Simons สำหรับทุกขั้นตอนของการแก้ไขแต่ละปัญหา

หลังจากที่ application สามารถทำงานได้ และทดสอบการ load ตัวอย่างของ dataset ที่เค้าจัดเตรียมไว้ให้ซึ่งเป็น H2DB ก็ทำงานได้เป็นอย่างดี ทำให้พอเห็น feature ด้าน root cause analysis

ui ของการวิเคราะห์ pageview

จาก ui ของ root cause analysis ที่ได้จาก metric pageview นอกจากระบบจะระบุว่า pageview ที่ได้เป็นจำนวนเท่าไรในช่วงเวลาที่เราสนใจ ยังสามารถระบุได้ว่า dimension ที่เราสนใจนั้น value ใดที่ส่งผลต่อการเปลี่ยนแปลงดังกล่าว ซึ่งจากรูป dimension ที่ชื่อ device ที่มี value เป็น android และ dimension ที่ชื่อ country ที่มี value เป็น cn มีการเปลี่ยนแปลงของ pageview มากที่สุด

ในส่วนของ alert channel นั้นหลักๆยังคงทำได้แค่ส่ง email แต่ส่วนตัวไม่ได้ทดสอบเพราะนอกจากการทดสอบของ dataset ที่เค้าจัดเตรียมไว้ให้แล้ว ผมยังไม่สามารถ config ตัว data source ใหม่เพื่อทดลอง feature ต่างๆได้ และเมื่อลองดู community ของ git repo ที่ไม่มีการ update ใดๆมา 15 เดือนแล้ว(นับจาก 05/2022) ทำให้อนาคตของ thirdeye ดูยังไม่เหมาะกับการนำมาใช้งานอย่างยิ่ง

thirdeye git repo

— — — — — — — — — — — — — — — — — — — — — — — — — —

Popmon (https://github.com/ing-bank/popmon)

refer: https://github.com/ing-bank/popmon

Popmon น่าจะเป็นตัวเลือกที่ light weight ที่สุดเท่าที่มีในตลาด (หากไม่นับว่าใช้ pycaret ในงาน anomaly detection) ซึ่ง popmon จะไม่มี server เป็นของตัวเองแต่จะอาศัย data processing framework อย่าง pandas และ spark ในการอ่าน dataset จากนั้นก็จะใช้การคำนวนตามหลัก statistics เพื่อระบุผลลัพธ์ของการคำนวน metric ที่ผิดปกติ ซึ่งจะถูกแสดงผลออกมาในช่อง Traffic light ซึ่งสีแดงหมายถึง anomaly event นอกจากนี้ popmon ยังมี report ที่อ้างอิงหลัก statistics ของ dataset ให้ explore มาให้จำนวนนึง โดย report ทั้งหมดจะถูกสร้างขึ้นในรูปแบบของ HTML file

refer: https://crclz.com/popmon/reports/flight_delays_report.html

feature นึงที่ popmon ไม่มีให้แน่ๆหากเทียบกับ thirdeye นั้นคือ root cause analysis ซึ่งแม้ว่าเราจะพบว่ามีความผิดปกติเกิดใน data pipeline แต่ก็ต้องมา drill down เองว่ามันเกิดขึ้นกับ dimension ใด

ด้วยรูปแบบการแสดงผลของ popmon อยู่ในรูปแบบของ HTML file ที่ถูกสร้างจากการประมวลผล data แบบ batch ทำให้หากมีข้อมูลเข้ามาใหม่ เราก็จำเป็นต้องมา generate report ใหม่ทุกครั้ง และการย้อนดู report ย้อนหลังก็ทำได้อย่างลำบาก เช่นหากเราทำการสร้าง report แบบ daily ในทุกๆวันก็จำเป็นต้องเก็บ report เก่าๆแยก partition กันตามวันเพื่อสามารถดู report ย้อนหลังได้

ในด้านการส่ง alert นั้น เราจำเป็นต้องมา coding ในส่วนนี้เองโดยอ้างอิงจาก report ที่ทำการ generate ในทุกรอบว่า รอบนั้นๆมี anomaly event เกิดขึ้นหรือไม่ และด้วยการทำงานที่เน้น coding ตัว popmon มาพร้อมชุดติดตั้งแบบ pip install ของ python สามารถใช้งานได้สะดวกและราบรื่นดี หากเทียบกับ thirdeye ที่แค่ start ตาม tutorial ก็พังแล้ว

ส่วน community ของ popmon นั้นถือว่าดูดีทีเดียวหากจะเทียบกับของ thirdeye

popmon’s git repo

— — — — — — — — — — — — — — — — — — — — — — — — — —

Monosi (https://github.com/monosidev/monosi)

refer: https://github.com/monosidev/monosi

เป้าหมายของตัว project เค้าตั้งไว้น่าสนใจทีเดียวที่จะเป็น “Open Source Data Observability Platform” ที่นี้หลังจากไปส่องการติดตั้งที่เค้าจัดเตรียมไว้ให้ในรูปแบบของ build docker image และนี้คือสิ่งที่ได้หลังจาก follow steps นั้นคือ error สิครับ :D

refer: https://docs.monosi.dev/docs/user-guide/getting-started

error หลังจากใช้คำสั่ง make compose

แต่ error แค่นี้ก็ยังหยุดเราไม่ได้โดยเบื้องต้นคำสั่งดังกล่าวเป็นเรียก docker compose ซึ่งตัว file นั้นอยู่ที่ใน folder “deployment/docker” ซึ่งสิ่งที่เราต้องทำคือเรียก docker-compose up เองแทนที่จะใช้งานผ่านทาง make script ซึ่งหลังจากทุก services ทำงานแล้วจากนั้นเราก็สามารถเรียก ui ได้จาก http://localhost:3000 ซึ่ง web browser หลักของผมจะเป็น firefox แต่พอกด continue แล้ว ui เหมือนจะไปหน้าหลักและก็ย้อนกลับมาหน้า getting-started อีกครั้ง และเมื่อไปส่อง logs กลับเจอ error HTTP 304 ดังรูปด้านล่าง

monosi’s ui

error จากการใช้ firefox

solution ที่ผมใช้คือเปลี่ยน web browser เป็น chrome ซึ่งก็สามารถใช้งานได้ปกติไม่ติดปัญหาใด ในจุดนี้ขอหักคะแนน จากแฟน firefox

monosi’ ui

สิ่งต่อไปที่เราต้องทำคือการเพิ่ม data source เพื่อนำข้อมูลมาแสดงผลใน monitor โดย ณ ตอนนี้ทาง monsi ได้รองรับ DB อยู่ 4 เจ้าตามรูปด้านล่าง ซึ่งในครั้งนี้เราจะเลือกเป็น postgresql และ dataset ที่เราจะใช้กันนั้นมาจาก Kaggle

sample data

DB ที่ทาง monosi supported

หลังจาก add data source เรียบร้อยเราก็ต้องทำการทดสอบ connection ด้วยการกดปุ่ม test

test db conn

เมื่อเรามีการ connect data source ตัว monosi จะทำการทำ data profiling แบบ auto ในทุก columns และทุห table ซึ่งในมุมนี้ส่วนตัวไม่ค่อยชอบเท่าไร เพราะมันรก ui เป็นอย่างมาก ควรจะให้เราทำการ config เพื่อระบุ table รวมถึง metric และ dimension ของ table ที่เราจะทำการ monitor เอง

monitor’s ui

และเมื่อเราทำการเข้าไปดูภาย metric ก็พบว่าแทนที่เราจะสามารถเลือกช่วงเวลาได้ แต่ระบบกลับไม่รองรับ รวมถึงการทำคำนวณ metric ก็ไม่ได้ทำแบบย้อนหลังให้แม้เราจะจัดเตรียมข้อมูล transaction ไว้แล้วแบบ daily ของทั้งปี

metric ui

ในเรื่องการทำ alert นั้น monosi แจ้งว่ารองรับ 3 channels แต่ email นั้นอาจจะต้องรอไปก่อน

alert channel

ด้าน anomaly detection ตัว monosi กำหนดแบบตายตัวมาเลยว่าจะ alert เมื่อ z score เกิด 3 standard deviations ซึ่งทำให้ขาดความยืดหยุ่นไปอย่างมาก

anomaly detection’s doc

ส่วน feature ด้าน root cause analysis เท่าที่หาดูตาม doc ของ monosi ก็สรุปได้ว่ายังไม่มี feature ในด้านนี้กล่าวคือเราสามารถทำ anomaly detection ได้แต่หากจะหาสามารถของ alert อาจจะต้อง drill down เอง

refer: https://docs.monosi.dev/docs/user-guide/table-health

ในเรื่องของ community นั้นก็ยังถือว่ามีการ active ดีและในอนาคตดูเหมือนว่าทาง monosi อาจจะเปิดให้บริการในรูแบบ cloud ซึ่งก็ต้องดูทิศทางกันอีกทีว่าจะมีการจำกัด feature มากแค่ไหนใน oss version

monosi’s git repo

monosi cloud

— — — — — — — — — — — — — — — — — — — — — — — — — —

Chaos Genius (https://github.com/chaos-genius/chaos_genius)

chaos genius’ website

สิ่งแรกที่น่าสนใจสำหรับ Chaos Genius คือเค้าไม่ได้บอกว่าจะเป็น “Open Source Data Observability Platform” แต่เค้าใช้คำว่า “Open Source Business Observability Platform” ซึ่งสาเหตุผมว่ามองเพราะเค้ามี feature ด้าน root cause analysis ที่สามารถขยายขอบเขตการใช้ ไม่จำกัดอยู่เฉพาะกับ DataOps แต่สามารถนำไปใช้กับฝั่ง Business ได้ด้วย ซึ่งเราสามารถดูตัวอย่างการนำไปใช้ได้จาก Demo

ในด้านการใช้ก็ทำออกมาได้ดี docker-compose up ได้อย่างไม่มีปัญหาใดๆ แถมใช้ firefox กด continue (คะแนนมาละ :D )

หน้าแรกเมื่อเริ่มใช้งาน Chaos Genius

data source ที่เราสามารถเชื่อมต่อได้ดูมีความหลากหลายดี

data source

หลังจากเราทำการเพิ่ม data source เรียบร้อยแล้ว ขั้นตอนต่อไปก็คือการตั้ง KPI ซึ่งก็คือการตั้งแค่ monitoring ว่าเราต้องการจะ monitor table อะไร column ใดเป็น domension อันไหนเป็น metric

กำหนด KPI

เมื่อกำหนด KPI เรียบร้อยแล้วระบบจะเริ่มทำการวิเคราะห์ dataset ของเราแล้วจะแสดงออกมาเป็นส่วน monitor ที่ชื่อว่า deepdrills

ช่วงหลังจากเพิ่ม KPI

สถานะของ KPI

deepdrills ui

feature ด้าน anomaly detection นั้นเราจำเป็นต้อง setup เพิ่มเติม ซึ่ง algorithms ที่เราสามารถใช้เพื่อ detect ตัว anomaly event มีหลายเลือกหลากหลาย โดยสามารถดูรายละเอียดของ algorithms ตาม link นี้ได้เลยครับ

ตั้งค่า anomaly detection ของ KPI

anomaly detection’ui

จากรูปข้างต้นจะเป็นแสดงกราฟที่ระบบ detect พบว่ามี anomaly event ซึ่งจะแสดงเป็นเส้นสีแดง ส่วนพื้นที่สีเขียวจะแสดงช่วงของพื้นที่ที่ระบบกำหนดไว้ว่าเป็น normal area ที่ผลลัพธ์ของการคำนวน metric อยู่ได้แบบไม่ถูกตีค่าว่าเป็น anomaly event และหากเรา click ในจุดบนเส้นสีแดง ระบบจะแสดง dimension ที่มีผลต่อ anomaly event ดังกล่าวด้านล่างให้เลย

dimension ของ anomaly event

สิ่งนึงที่เราอาจจะสังเกตเห็นได้จากการใช้ Standard Deviation model เป็น algorithm คือพื้นที่สีเขียวมีความแข็งไม่ยืดหยุ่นตามกราฟที่มีโอกาสวิ่งขึ้นแบบ linear ตัวอย่างเช่นหากเราตั้ง KPI ไว้เป็นจำนวนยอดขาย แล้วในช่วงเวลานึงยอดขายแต่ละวันเราสูงขึ้นเรื่อยๆ จนมันเกิดขอบพื้นที่เขีนวด้านบน ก็อาจจะทำให้ระบบ detect ว่าเป็น anomaly event แต่ถ้าเราเปลี่ยน algorithm ไปเป็น Exponentially Weighted Moving Average โดยเราสามารถดูตัวอย่างของผลลัพธ์ได้จากรูปด้านล่าง ที่จะเห็นว่าพื้นที่สีเขียวมีการปรับ movment ตามกราฟที่ขึ้นลง ซึ่งหากกราฟไม่เหวี่ยงแรงจริงๆ ระบบก็จะไม่ detect ว่าเป็น anomaly event

dashboard หลังจากเปลี่ยนเป็น Exponentially Weighted Moving Average

ด้าน alert channel ตอนนี้ที่สามารถใช้งานได้จะเป็น slack และ email ส่วน webhook นั้นคาดว่าจะเปิดให้ใช้งานเร็วๆนี้

alert channel

ในส่วนของ community การ active อยู่ในเกณฑ์ดี แต่ก็เหมือนกับ monosi ที่ตัว chaos genius ก็มีแผนจะขาย service ในรูปแบบเสียตังเหมือนกัน ซึ่ง limitation แรกที่เจอในตัวฟรีคือ dashboard เราไม่สามารถสร้างเพิ่มได้ แต่ก็ยังไม่เป็นปัญหาในแง่การใช้งานแต่อย่างใด จะเป็นปัญหาก็เฉพาะการจัดระเบียนของ KPI เท่านั้น

chaos genius git repo

Conclusion

หากสอบถามผมในตอนนี้ใจยังไงก็คงไปทาง chaos genius แน่ๆ เพราะด้วย features ที่ครบเครื่องในแบบที่อยากได้และการเคลื่อนไหว community ที่ดี แต่ก็ยังแอบหวังลึกๆว่าสักวันจะมีใครมาปลุกชีพให้กับ thrideye ให้กลับมาอลังการในแบบเดียวกับที่เกิดขึ้นกับ datahub

สุดท้ายนี้ถ้าท่านใดมีข้อสงสัยหรือคำชี้แนะใดๆสามารถติดต่อได้ทุกช่องทางดังนี้Website: www.damageek.com, Facebook: www.facebook.com/damageek, Youtube: www.youtube.com/@DAMAGeek-Channel, Twitch: www.twitch.tv/damageek, X (twitter): www.x.com/dama_geek, Tiktok: www.tiktok.com/@damageek_channel

สำหรับคนที่สนใจ Data Engineer สามารถเข้ามาแชร์ข้อมูลกันที่ได้ที่ https://www.facebook.com/groups/dataengineerth

Refer:

Why You Need To Set SLAs For Your Data Pipelines

Apache Pinot ThirdEye —Quickstart helper