🎞️ Videos → Data Architecture ในงาน Data Engineer ใครก็เริ่มได้ ไม่ต้องเป็น Senior

แนะนำตัวและหัวข้อ Data Architecture สำหรับ Data Engineer มือใหม่0:00

โอเค ตามชื่อเรื่องหัวข้อนะครับ Data Architecture เมื่อกี้เห็นแบบมีใครเป็นจูเนียร์บ้างไหมครับ จูเนียร์ (หัวเราะ) ใครเป็นซีเนียร์นะ ไม่ ไม่ พูดไม่ได้ โอเค จริงๆ ผมจะบอกว่าเซสชั่นนี้ครับพยายามที่จะแชร์ประสบการณ์สำหรับ Data Engineer

มือใหม่เนาะ ว่าเดี๋ยวเราเห็นคำว่า Architect เนี่ย จะเป็นแบบรุ่นพี่หรือเปล่านะในการดีไซน์นะครับ เดี๋ยวผมจะพยายามทำให้พาทุกคนไปเรียนรู้กับมัน แล้วก็กลับไปทำที่บริษัทได้นะครับ หวังว่าจะเป็นแบบนั้นเนาะ โอเคครับ ตามชื่อเรื่องนะครับ Data Architecture ในงานของ Data Engineer ใครก็เริ่มได้ ไม่จำเป็นต้องเป็นซีเนียร์เนาะ แนะนำตัวเองอีกรอบครับ ชื่อกานต์นะครับอยู่ที่ ODDS-TEAM หรือว่าเรียกสั้นๆ ว่า ODT นะครับ เอ่อ เพิ่งเปลี่ยนชื่อไตเติลเมื่อกี้นิดนึงนะครับ ตัดคำว่าโค้ชไปเป็นคำว่า enabler แทนเนาะ ลอกมาจาก เอ่อ Enabling team ใน Team Topology นะครับ เราเข้าไป enable ลูกค้าให้เขาสามารถที่จะทำงาน ให้เขาสามารถที่จะคิดเองได้อะไรประมาณนั้นนะครับผม โอเค จริงๆ ก็อยู่ในงานสายงาน data มาหลายปีแล้ว 10 กว่าปีนะครับ แต่ว่าช่วงแรกๆ ก็คือพยายามไปทำพวก data science พยายามไปทำ machine learning แล้วก็พบว่าโลกสวยฮะ (หัวเราะ) เข้าไปทำงานคือไม่เจอ data

ไม่เจอระบบเลยนะครับ แล้วก็พัฒนาระบบมาแล้วก็เริ่มชอบพวก engineer ทั้งหลายแหล่นะครับ แล้วก็คิดว่าถ้าเราสามารถที่จะทำ engineer หรือว่า data engineer ได้ดี คนที่จบสายงาน data scientist อ่ะ เขาควรจะได้ทำในสายงานที่เขาเรียนมาเนาะนะครับ ประมาณนั้น โอเค

ปัญหาโลกแตก: โลกนี้ต้องการ Data Architect มากกว่านี้!1:49

เริ่มเรื่องดีกว่า วันนี้มี 3 หัวข้อนะครับ ก็คือเดี๋ยวจะลองเล่าถึงปัญหาในปัจจุบันก่อนนะครับ ว่าปัญหาในเรื่องของ Architect เนี่ย มันมีปัญหาอะไรที่ผมอยากจะหยิบยกมาเล่าให้ฟังเนาะ แล้วก็การออกแบบ Data Architect นะครับ ว่ามันเป็นแบบไหน สุดท้ายก็ทิ้งทวนเป็นรีแคปเฉยๆ นะครับ เกริ่นเป็น background ก่อน อ่า จะได้เข้าใจ context ตรงกันเนาะ ภาพนี้ Data Engineer

ทุกคนเดี๋ยวจะต้องเจอกันนะครับ ใครไม่เคยเห็นก็เดี๋ยวเห็นไว้นะครับ เดี๋ยวคุณจะได้เห็นภาพนี้ตลอดเวลา เป็นภาพ Data Engineer Life Cycle นะครับ มาจากหนังสือ Fundamentals of Data Engineering นะครับ อ่า ปกติแล้วสายงาน Data Engineer เราจะเห็นแต่ด้านบนเนาะ มีการ generate data จาก source นะครับ เข้าไปทำพวก transformation ต่างๆ มี storage แล้วก็ไปออก dashboard ใช่มั้ย อันนี้เป็นภาพแบบเหนือน้ำ ทีนี้ภาพใต้น้ำเนี่ยครับ undercurrents เนี่ย เวลาใครถามผมอ่ะ ถ้าคุณอยากจะ outstanding ในสายงาน Data Engineer เนี่ย ให้คุณโฟกัสที่ undercurrents นะครับ อ่า แล้วคุณจะเฉิดฉายในสายงานนี้ เพราะว่าด้านบนเนี่ยจริงๆ คุณทำไปสักพักคุณก็ทำได้แล้ว แต่ด้านล่างเนี่ยมันต้องอาศัย practice อาศัยประสบการณ์ อาศัยการเรียนรู้เพิ่มเติมเนาะ วันนี้เลยหยิบตรงนี้มาเล่าครับ เรื่องของ Data Architect โอเคเนาะ เป็นพาร์ทนึงของ undercurrents นะครับ

ทีนี้คำว่า Architect ใครรู้ความหมายมันมั่ง (หัวเราะ) แปลว่าอะไรนะ

แปลว่าสถาปัตยกรรม (หัวเราะ) ไม่ได้ช่วยอะไรเลย (หัวเราะ) คือมันเป็นคำที่นิยามยากครับ คำว่า Architect เนี่ย เวลาที่พูดถึง Architect เนี่ย บางคนก็จะให้นิยามแบบหนึ่ง บางคนให้นิยามแบบหนึ่ง บางคนก็ให้นิยามแบบหนึ่ง โอเคมั้ย อะ ทีนี้ผมยกนิยามของที่เขาคุยกันนะครับ เอ่อ ในสายงานของซอฟต์แวร์อาร์คิเทคเนาะ Martin Fowler นะครับ เขาให้คำนิยามคำว่าอาร์คิเทคประมาณนี้นะครับ มันคือ Share understanding… Share understanding that the expert developers have of the system design. เวลาที่เขาดีไซน์อะไรออกมานะครับ เขาจะต้อง share ความเข้าใจของเขาอะ สิ่งที่อยู่ในหัวของเขาอะ ออกมาให้คนอื่นเข้าใจด้วย โอเคไหม ไม่ว่าจะเป็นรูปแบบของภาพ รูปแบบของไดอะแกรม การเล่าเรื่องบอกต่อออกเป็นสไลด์ต่างๆ นะครับ มันคือการ share understanding ให้ทุกคนเข้าใจ ให้ทุกคนเห็นภาพตรงกัน เห็นไหม อันนี้คือความหมายของ architect ที่เดี๋ยวผมจะพูดวันนี้นะครับ

โยนถึงปัญหาก่อน

ปัญหามีอะไรบ้างนะ ปัญหาหลักๆ อันนึงนะครับ เป็นปัญหาระดับโลกเลยนะ คือ

เรามีอาร์คิเทคน้อยเกินไป

เห็นไหมครับ ปัญหาระดับโลกเลยนะครับ เรามีจำนวนคนที่เป็น Data Architect หรือว่าเป็น Software Architect เนี่ย น้อยเกินไป

เห็นไหม เพราะว่าอะไรครับ คือมันส่งผลหลายอย่างเลยเนาะ เรื่องของระบบของแต่ละองค์กร ทำไมเขาออกแบบมาเป็นแบบนี้ ทำไมมันล่มบ่อย นู่นนี่นั่น เออ มันเป็นปัญหาที่ว่าคนที่ไม่ได้เป็นอาร์คิเทคไปออกแบบอาร์คิเทค หรือว่าบางที business analyst ไปออกแบบอาร์คิเทคอย่างเงี้ยครับ เออ มันก็เลยดูไม่ค่อยจะตอบโจทย์เท่าไหร่ ทีนี้มันน้อยเกินไป มันอาจจะเป็นเพราะว่า คนที่เป็น Data Architect หรือว่าเป็น Software Architect ครับ ภาพจะเหมือนแบบเป็นลูกสิงโตอ่ะ ที่โดนถีบออกจากหน้าผา แล้วก็บอกว่าถ้ากูว่ายน้ำได้ แล้วกูปีนขึ้นมาได้จากหน้าผาขึ้นมาเจอแม่มันอะ นั่นแหละคืออาร์คิเทค โอเคไหม

ใครๆ ที่ทำงานสายอาร์คิเทคมักจะเป็นแบบนี้เนาะ กูโดนถีบลงไปตรงไหนไม่รู้แหละ แต่กูรอดขึ้นมาได้นี่แหละ กูเรียกตัวเองว่าอาร์คิเทค โอเคไหมครับ อ่ะ

มันน้อยจนมีคนเอาไปทำเสื้อบอกว่า

someone who solves a problem you didn’t not know you had in a way you don't understand ทำอะไรไม่รู้แหละ แต่มันเวิร์ค เราก็ไม่ได้เข้าใจ ทีนี้โดยเฉพาะเด็กจบใหม่นะครับ จูเนียร์นะครับ เดี๋ยวคุณลองกลับเข้าไปบริษัทนะ แล้วคุณลองถามคำถามนี้กับซีเนียร์นะครับว่า เอ้ย ไอ้ระบบแบบนี้เนี่ย แพลตฟอร์มแบบนี้เนี่ย คุณออกแบบมาได้ยังไง เขามักจะตอบคุณว่า เอ่อ ไม่รู้ มันต้องแบบนี้เว้ย แล้วมันเวิร์ค

เห็นไหม มันเวิร์คอ่ะ เออ แต่ก็ไม่รู้เหมือนกันว่ามันมีที่มาที่ไปแบบไหนนะครับ อันนี้คือปัญหาของอาร์คิเทคในปัจจุบันระดับโลก

มีวิธีฝึกฝนตัวเองให้เป็น Data Architect ไหม? มาดู 3 ขั้นตอนกัน6:57

ก็เลยตั้งคำถามว่า เฮ้ย มันจะมีแบบ proper way ไหม หรือ proper training framework ไหมที่เราจะสามารถ build up skill architect ไม่ว่าจะเป็น software architect หรือ data architect ขึ้นมา แล้วเราสามารถที่จะออกแบบ architect ให้กับองค์กรได้ มันมีไหมนะ เวย์นี้ จะบอกว่ามันมีครับ ผมเชื่อว่ามี แล้วว่าก็เลยวันนี้จะเอามาแชร์ให้ทุกคนฟัง เป็นเวย์ที่ผมใช้แล้วกัน แล้วมันเวิร์คกับผม มันอาจจะเวิร์คกับพวกคุณก็ได้นะครับ หรือไม่เวิร์คก็ได้นะครับ แต่ก็เป็นเวย์หนึ่ง ก็ลองเอาไปลองประยุกต์ใช้กันดูเนาะ นะครับ โอเค การออกแบบ Data Architect หรือออกแบบ Architect นะครับ ผมมีหยิบมา 3 อย่าง ที่เราลองไปทำได้เลยนะครับ

อย่างแรกถ้าเราอยากจะดีไซน์เรื่องของ Architect เนี่ย มันมีทฤษฎีหนึ่ง เรียกว่า Residuality Theory ครับ เดี๋ยวค่อยคุยกัน ชื่อมันอาจจะแปลกๆ นิดนึง แต่จริงๆ คอนเซ็ปต์มันเข้าใจง่าย โอเคมั้ย อย่างที่สอง เพื่อเป็นการแชร์ understanding ของเรานะครับ เราจะไม่พูดภาพ architect อยู่บนอากาศ โอเคไหมครับ ใครเคยเป็นบ้างแบบพูดถึงสิ่งๆ หนึ่ง พูดอยู่บนอากาศอย่างเงี้ย เฮ้ย แมวส้มตัวนั้นน่ารักจังเลย ทุกคนเห็นแมวส้มตัวเดียวกันไหม

ไม่น่านะ บางคนอาจจะนึกถึงการ์ฟิลด์ บางคนอาจจะนึกถึงแมวด้านล่างที่เพิ่งเจอมา โอเคไหมครับ เพราะฉะนั้นเนี่ย การที่จะทำให้ทุกคนเห็นภาพตรงกันเนี่ย มันจะต้อง visualize ออกมา somehow some way diagram ที่ผมจะเอามาแชร์ก็คือชื่อว่า C4 model นะครับ

และสุดท้ายเนี่ย

การที่เรามี knowledge แล้วเราจะส่งมอบต่อไปอ่ะ เราจะใช้ document ตัวหนึ่งที่ชื่อว่า ADR เนาะ เพื่อ persist knowledge เข้าไปในองค์กรนะครับ เข้าไปในทีม เดี๋ยวค่อยไปรู้จักกัน

Residuality Theory: สร้างบ้าน Data ให้แข็งแกร่ง9:02

อย่างแรกก่อน Residuality Theory นะครับชื่ออ่านยากนิดหนึ่ง

คนที่คิดนะครับชื่อว่า แบร์รี่ โอ'เลอรี่ มีงานวิจัยเลยนะ research เป็นเปเปอร์เลยนะ publish ออกไปที่ ScienceDirect ถ้าผมจำไม่ผิดนะครับ คือเขาสนใจเรื่องของ Complex System

แล้วก็ Software Engineering เขามองว่าเรื่องของ Complex System ถ้าเอามาผสมกับ Software Engineering เนี่ย มันจะช่วยให้เขาออกแบบระบบที่มัน Complex ได้ และอธิบายได้ด้วยว่ามันคืออะไร โอเคไหมครับ อ่ะมาดู concept แบบผมพยายามย่อยให้มันดูง่ายเนอะ

โอเคไหม ถ้าใครสงสัยเดี๋ยวคุยนอกรอบเลย ยกมือถามได้นะครับ อันนี้ยกนิยามมาก่อน The future of a system is a function of its residues. นะครับ Residues ก็คือ the leftovers of the system after the impact of a stressor. A stressor is anything that is previously unseen or unknown that impacts the system. อันนี้คือนิยาม แต่ว่าผมอยากจะเน้นสองคำนี้ครับ มาทำความรู้จักสองคำนี้กัน residue กับ stressor

โอเค ออกสู่โลก ออกจากโลก theory ก่อนนะ ออกมาในโลกแบบ practical นะครับ — ใครเคยดูการ์ตูนเรื่องนี้บ้าง

หมูสามตัวแล้วก็มีหมาป่าไปเป่าบ้าน ไม่เคยเลยหรอ ซวยละกู ใครเคยบ้างเป็นเพื่อนผมไหม โอเคมีคนพยักหน้า ขอบคุณมากครับไม่ได้รู้สึกว่าแก่อยู่คนเดียว ไม่เคยดูจริงหรอ กลับไปดูนะ ขอร้อง อะเรื่องมันมีอยู่ว่ามันมีหมูสามตัวครับ แล้วหมูแต่ละตัวมันสร้างบ้าน เห็นไหม รู้สึกหมูตัวแรกเนี่ยสร้างบ้านเป็นฟางนะครับ แล้วหมาป่าจะมากิน หมาป่าก็เป่าพ่วง หมูตัวแรกก็วิ่งหนีไปอยู่บ้านที่สอง บ้านที่สองเป็นไม้ หมาป่าก็เป่าพ่วงบ้านพัง แต่ว่าหมูบ้านที่สามเขาใช้อิฐก่อสร้างขึ้นมา ใช้เวลานานกว่าชาวบ้านนิดนึง แต่ว่าหมาป่าเป่ายังไงก็ไม่พัง เกี่ยวอะไรกับโลกของเรานะ เกี่ยวตรงที่ว่าไอ้หมาป่าเนี่ยครับ สำหรับผมแล้วมันคือ Stressor

Stressor คือคนที่จะมาอิมแพค กับระบบของเราโอเคไหม

เราสร้างระบบขึ้นมา เราสร้างบ้านขึ้นมาแล้วมันจะมี Stressor เข้ามาเป่าพ่วงพยายามทำให้ระบบเราพัง ถ้าในโลกความเป็นจริงของเราคือ requirement นั่นเองครับ requirement เข้ามาจะพยายามทำให้ระบบมันเกิดการเปลี่ยนแปลง แล้วระบบเราจะพัง เห็นไหม ส่วน Residual เนี่ย คือ The Left Over ใช่ไหมสิ่งที่เหลือรอดจาก Requirement นั้นมา เห็นไหมครับ อ้า Stressor กับ Residual นะครับ

อันนี้คือคอนเซ็ปต์หลักหลักของ Residuality Theory เนาะ เวลาที่มี Requirement เข้ามาแล้วก็ต้องทำบ้านให้มัน strong เนี่ยครับ เราจะพูดถึงสิ่งนี้ครับ Functional แล้วก็ Non-functional เห็นไหม เวลาที่เราออกแบบ architecture นะครับ การที่จะดีลกับ stressor ได้เราต้องคิดถึงสองอันนี้ หนึ่งคือ functional และสองคือ non functional การที่สร้างบ้านแล้วเปลี่ยนบ้านไปอีกอันหนึ่ง functional เนี่ยคือ business requirement ของเรา เขาจะอยากได้อะไรไปตอบโจทย์บิสเนสเห็นไหมครับ อ้า to solve the business problem ส่วน non functional เนี่ยคือหน้าที่ของเราแล้ว ที่จะต้องทำให้มั่นใจว่าระบบเนี่ยมัน support business goal ให้ได้เนาะสองอันนี้นะครับ functional และ non functional

เผื่อใครไม่เคยรู้จักสองคำนี้นะครับ อันนี้ยกตัวอย่างคือ Functional เนี่ยมันเกี่ยวกับ capability นะครับ ความสามารถของระบบ อย่างเช่น ระบบเนี่ยสามารถที่จะให้ user login ด้วย email และ password ได้ เห็นไหมอันนี้คือ functional นะครับ ก็คือ system should do อะไรควรจะทำอะไรได้เนาะ ส่วน non-functional เนี่ยหน้าตาจะเป็นแบบนี้ครับ คือ quality คือ experience ที่ช่วย support business goal นะครับ ก็คืออย่างเช่น

system เนี่ยจะต้อง handle 1,000 login พร้อมกันเนี่ยภายใต้ 2 วิ

นี้เป็นต้น พวก non-functional ต่างๆ เนี่ยจะเป็นฝั่งของ engineer ฝั่งของ architect เป็นคนคิด เพื่อ support ตัว business requirement นั้นๆ นะครับ how a system should perform

อันนั้นเป็นเรื่องของการดีไซน์เห็นไหมครับ สมมุติผมยกตัวอย่างก่อน ผมยกตัวอย่างดีกว่าจะได้เห็นภาพมากขึ้น เวลาที่เราเข้าไปในองค์กรเราถามหาบิสเนสก่อน

business goal เป็นอะไรนะครับ อย่างเช่นว่าถ้าสมมุติเป็นสตาร์ทอัพใหม่ๆ เลย เราเข้าไปในองค์กรเราบอกว่าโอเคอยากจะได้ข้อมูล public data ขึ้นมา

โอเค business มีแค่นี้เนาะ เราก็มาดีไซน์ออกแบบ architecture ของเราครับ Architecture ของเราเนี่ย ให้ออกแบบให้มันมินิมัมที่สุดที่จะตอบโจทย์ business requirement นั้นให้ได้ก่อน โอเคไหมครับ เช่น โอเคงั้นเดี๋ยวผมใช้โค้ดตัวหนึ่งเขียนด้วย Python

ไป scrape หน้าเว็บแล้วเอาข้อมูลมาวางให้พี่เป็น Excel

คำถามครับ ตอบโจทย์ functional requirement ไหม ตอบ ถูกไหมครับ ที่เหลือเนี่ยเรามาคิดว่าโอเค non-functional เป็นแบบไหน เขาอยากจะได้ข้อมูลทุกวันไหม อ่า หรือว่าเขาอยากจะได้ข้อมูลที่มันแบบมหาศาลใหญ่มากๆ อันนี้เราต้องมาเขียนโค้ดเพื่อตอบโจทย์บิสเนสนั้นๆ ถูกไหม อันนี้ไออยากได้ public data นี่คือหนึ่ง stressor นะครับ ยิงเข้าหาตัว architecture ของเรา มันอาจจะมี stressor อีกแบบหนึ่งเข้ามาใน architecture ของเราครับ โอเคอยากได้ระบบ เอ่อ อยากได้ data ของระบบตรงนู้นเอาเข้ามาซ้อนทับกับ public data ที่เรามีอยู่ ถูกไหม ถามว่า architecture ตัวเดิมตอบโจทย์ไหมครับ ไม่ตอบโจทย์ใช่ไหม เพราะว่ามันเป็นแค่โค้ด Python แล้วก็ไปดึงข้อมูล public data เราก็โอเคทำไงนะ ออกแบบตัว architecture ของเราใหม่นะครับ ให้มันสามารถไปดึงข้อมูลจากอีกระบบหนึ่งมาได้ แปลว่าเราก็ต้องคิดพวก authentication อะไรต่างๆ เข้ามาไหม แต่ถ้ายิ่งพี่เขาบอกว่าโอเค เอ่อ อยากจะเห็นแดชบอร์ดทุกวันอ่ะ เราก็ต้องมาคิดเพิ่มและเราจะเติม schedule เข้าไปยังไง ถามคือ Schedule เนี่ย เราเติมเข้าไปแบบง่ายๆ ที่สุดนี่คืออะไรนะ Cron อย่างงี้ใช่ไหม ครอนเป็น Process ตัวหนึ่งที่เราสามารถที่จะ Schedule ได้นะครับ อ่ะ มันก็ Schedule ไป แล้วเราก็วนลูปแบบนี้ครับ จนกว่า Architecture หรือระบบของเราเนี่ยมันตอบโจทย์ Requirement ทั้งหมด อันนั้นคือ Architecture ที่ดี ขององค์กรเรา เห็นไหม อันนี้เป็นขั้นตอนในการออกแบบ Architecture นะครับ

C4 Model: สื่อสาร Architecture ให้เข้าใจง่ายเหมือนนกบิน16:40

โอเค เราออกแบบเสร็จแล้ว แล้วเอาไปคุยกับคนอื่น คนอื่นรู้เรื่องไหม ก็จะเจออีกปัญหาหนึ่งนะครับ เราจะทำไงให้ภาพในหัวของเราเนี่ย สื่อสารออกมาให้คนอื่นรู้เรื่องนะครับ ก็จะใช้ประโยชน์ของไดอะแกรมเป็นหลัก ไดอะแกรมมีหลักของมันเหมือนกัน C4 เนี่ย เป็นไดอะแกรมที่ผมชอบมาก เพราะว่าเวลาที่เราดูภาพ Architecture นะครับ ให้ทุกคนเนี่ย ทำตัวเสมือนเป็นนก เห็นไหม

บินขึ้นบินลงได้ แปลว่าเราสามารถที่จะดูภาพ Bird's eye view ได้ ลงมาที่ Architecture ของเรา ถ้าเราอยากจะดูภาพให้มัน Low level กว่า เราก็บินลงมา เห็นไหมครับ C4 เป็นไดอะแกรมตัวหนึ่งที่ตอบโจทย์ตรงนั้น สามารถดูเป็น level ได้ ซึ่งมันไปตรงกับคอนเซ็ปต์ของ Architecture Elevator นะครับ เขาบอกว่าเวลาที่คุณเป็น CEO ขององค์กรแล้วมันมีตึกสูงๆ อยู่อะ ถ้าคุณอยากจะรู้ว่าชั้นไหนมันมีปัญหาคุณทำไง

บางคนบอกว่าคุณก็สั่งลูกน้องไปดู ไม่ใช่นะ คุณก็ต้องลงไปดูด้วยตัวเองถูกไหมครับ คุณก็ต้องแบบลงมาที่-- กดลิฟต์ลงมาที่ชั้นนั้น แล้วคุณก็แก้ปัญหาที่ชั้นนั้น ถ้าคุณอยากเห็นภาพบนสุด คุณก็ขึ้นลิฟต์ขึ้นไปบนสุด โอเคไหม อ้า นี่ครับการมองภาพ Architecture เราควรจะมองได้หลายเลเวลประมาณนี้ เนาะ ตัวอย่าง ตัวอย่าง ภาพเลเวลบนสุดใน C4 โมเดลนะครับ ภาพแรกคือ Context

หรือว่าเรียกว่า C1 ภาพ Context เนี่ยเป็นภาพที่เราใช้สื่อสารกับทาง Business นะครับ ว่าระบบหรือว่า Data Platform ของเราเนี่ยมีใครมาใช้บ้าง และเราไปเชื่อมต่อกับ External System ตัวไหนบ้าง แค่นี้เลยครับ เห็นไหมนะ นี่คือกล่องสี่เหลี่ยม 2 กล่องนะครับ แค่นี้พอเพราะว่าเวลาที่เราวาดภาพ เราใช้ในการสื่อสาร การสื่อสารเนี่ยเราต้องดู Audience ด้วยนะว่าเราจะสื่อสารให้ใคร ภาพนี้ใช้สื่อสารกับฝั่ง Business นะครับ ถ้าเราที่จะเริ่มสื่อสารกับฝั่งของ Engineer เราเนี่ย เราก็จะบินลงมาอีกชั้นหนึ่งนะครับ มาอีกเลเวลหนึ่งก็คือ โอเค เดี๋ยวฉันจะสื่อสาร Logistic platform นะ เป็น Logistic data platform ของฝั่งของทีม Data ของเรา เราก็เจาะลึกลงไปที่ Logistic platform ครับ ปึ๊บ อ๋อ Logistic platform เนี่ยมีการไป Stream Data นะครับ จาก External System

เข้าไปที่ Kafka ไปที่ Lambda ไปที่ Snowflake แล้วไปออก Tableau อ่ะ อันนี้ก็คือภาพ C2 เราลงมาอีกเลเวลหนึ่ง จะมีภาพเทคโนโลยีอยู่ด้วย โอเคไหม ประมาณนี้นะครับ จริงมันมี 4 เลเวลลงไปถึง C4 นี่คือเลเวลของพวก Sequence Diagram Use case อะไรต่างๆ โอเคเนาะ เข้าใจว่าทุกคนน่าจะแบบพอวาดของพวกนี้เป็นอยู่แล้ว เห็นไหมครับ เออ สี่เหลี่ยมเอาเส้นมาเชื่อมต่อกัน

คำถามถัดไปครับ

กดไม่ไป คำถามถัดไปคือ แล้วเทคโนโลยีพวกนี้คิดมาได้ยังไงนะ ในฐานะที่เราเป็นมือใหม่ใช่ไหมครับจริงๆ เราคิดมาจาก Business เนาะ ว่า Business อยากได้แบบไหน สมมุติว่าในเคสนี้ External System เขาให้ Data เราเป็นสตรีมมาแบบ Real-time เราก็ต้องไปหาเทคโนโลยีละ เทคโนโลยีไหนที่มันสามารถรับข้อมูลเข้ามาแบบ Real-Time ได้ แล้วเข้าไปที่ฟังก์ชันไหน เอาฟังก์ชันไหนไปเก็บในตัว Data Warehouse ของเรายังไง ไปเก็บใน Database ของเราแบบไหน อ่า เราอาจจะวางคร่าวๆ ก่อน แล้วมาดูว่าเทคโนโลยีคือเราควรจะต้องใช้อะไรตอบโจทย์ดี โอเคไหม

เลือก Tech ยังไงดี? Technology Comparison & Decision Matrix ช่วยได้20:32

ก็จะโยงถึงขั้นตอนถัดไปครับ 2 อันนี้เป็นเทคนิคที่ผมใช้ในการเลือกเทคโนโลยีเบื้องต้นก่อนนะครับ ก็จะมี Technology comparison ต้องทำอยู่แล้ว แล้วก็มี Decision matrix สมมุติในเคสที่โอเคเราจะเลือกแล้วว่า ข้อมูลไหลลงมาเนี่ยมาลงใน Data Warehouse ตัวหนึ่ง โอเคไหมครับ Data Warehouse ตัวนั้นใช้อะไรดี? อ่า สมมุติว่าเฮ้ยเราไปเจอละมี ClickHouse กับมี TiDB เคยได้ยินชื่อไหม

ClickHouse เดี๋ยวมันจะดังขึ้นมาครับ ผมเชื่อเดี๋ยวมันจะมีชื่อเสียงมากนะครับ ClickHouse เนี่ย ส่วน TiDB นี่ PingCAP ซื้อไป (หัวเราะ) เข้าใจว่าเดี๋ยวจะมี session พูดเรื่อง ClickHouse ที่ FOSS Conference เมื่อกี้นะครับ Open source

อะ เทคโนโลยีเปรียบเทียบนะครับ Technology comparison เราก็แค่เอา 2 เทคโนโลยีเนี่ยมาดูว่าตามนะ ขอไอ้ Criteria เนี่ยครับ เราดูตาม Non-functional requirement ด้วยนะ เห็นไหม ตาม Non-functional requirement แต่ละข้อเนี่ยครับ 2 ระบบเนี่ยมันมีข้อแตกต่างกันยังไงบ้าง โอเคเนาะ เอ้อ ตัวหนังสือมันจะเล็กไปครับ คือเดี๋ยว เดี๋ยวผมส่งสไลด์ให้ทีมงาน

เสร็จแล้วพอเรา comparison เสร็จนะครับ มันก็ต้องโหวตใช่ไหม การโหวตถ้าจะให้ทุกคนเห็นภาพตรงกัน เราใช้ตัวเลขว่าเราให้เรทเท่าไหร่ โอเคไหมครับเรทก็อาจจะ gather ข้อมูลจากในทีม หรือเราอาจจะคิดเอง อะไรอย่างนี้เป็นต้นนะครับ ว่าโอเคอันนี้มันควรจะเป็นจาก 0 ถึง 10 เราให้ 10 อะไรอย่างเงี้ย เป็นต้น ครับผม เออ ใช่มั้ยเพราะว่าการให้เรทเนี่ยมันชัดเจน ไม่ใช่ว่าเฮ้ย ClickHouse มันดี ดียังไง หรือว่าการใช้ TiDB มันลำบาก มันลำบากยังไง มันไม่เห็นภาพตรงกัน แต่ถ้าบอกว่าเลขปุ๊บ ตอนนี้มีใครง่วงบ้างครับอย่าง เงี้ย ง่วงทุกคนเลย ถ้าผมเปลี่ยนใหม่ตอนนี้เลเวลความง่วงของคุณเนี่ยเท่าไหร่จาก 0 ถึง 5 อย่าง เงี้ย เราจะเข้าใจว่า โอ้ ทุกคน 5 หมดเลยว่ะ ง่วงหมด อย่าง เงี้ย เป็นต้นนะครับ อะ ใช้เลขในการสื่อสารแล้วก็ make decision ให้ recommendation แล้วก็เคาะตัดสินใจร่วมกันนะครับ ว่าโอเคเราจะไปเทคโนโลยีตัวนี้กัน โอเคไหม

ทีนี้ไม่มีช็อต ไม่มีช็อตคัตครับ ผมจะบอกเรื่องนี้ไม่มีช็อตคัต ถ้าคุณเป็นมือใหม่หรือคุณเป็นมือเก่านะ ผมแนะนำให้คุณต้องอ่านเล่มนี้แล้วกัน โอเคไหมครับ เล่มมันจะโคตรหนาอยู่ อยู่สักหน่อยแล้วนะ แต่ว่าเป็นเล่มที่ทำให้คุณเข้าใจเทคโนโลยีในโลกของ Data มากขึ้น โอเคไหม ไม่มีช็อตคัตนะครับ คุณไม่ได้อยู่ดีๆ แล้วคุณจะรู้เรื่องนะ โอเค คุณอ่านหนังสือด้วยนะครับ เราจะได้อ้างอิงจากหนังสือเล่มเดียวกันอันนี้

หลังจากที่เราเมคดีซิชั่นแล้ว เราออกแบบแล้วเราเมคดีซิชั่นเรื่องเทคโนโลยีแล้ว

ADR: จดบันทึกการตัดสินใจครั้งสำคัญไว้ อย่าให้ความรู้หายไปกับสายลม23:42

อีกอย่างหนึ่งสำคัญมากๆ ครับแล้วเรามักจะลืม คือถ้าเราไม่ได้เขียนมันลงไปนะครับ ผมจะถือว่าสิ่งนั้นมันไม่เกิดขึ้นจริงในโลกนี้

โอเคไหม แปลว่าเราจะต้องมีการ Record สิ่งๆ นี้ Record decision มันลงไปด้วยนะครับ ก็โยงถึงเรื่องของ Architectural Decision Record หรือว่า ADR ลักษณะมันเป็น Document ตัวหนึ่งนะครับ ตัวอย่างอยู่ทางขวามือ เราบอกว่า Title คืออะไร สเตตัสเป็นยังไง Context บริบท ณ เวลานี้เนี่ย ทำไมเราถึงเลือกเทคโนโลยีตัวนี้ ทำไมเราไม่เลือก Cloud ทำไมเราไม่เลือกตัวนั้นตัวโน้น นะครับ บริบทเป็นยังไง OK ไหม แล้วเราก็เมคดีซิชั่นอะไรเพื่อที่จะเลือกเทคโนโลยีตัวนั้น หรือว่าเลือกไดเรกชันนะครับ ทีนี้อาจจะมีคำถามว่าอะไรที่เราต้องเขียนบ้าง ไม่งั้นเราต้อง Record ทุกอย่างเลยหรือเปล่า ให้คิดแบบนี้ครับ อะไรที่มันเกี่ยวกับอาร์คิเทคเจอร์มันจะเป็นเรื่องที่เราเปลี่ยนยาก เห็นไหม difficult to change เช่น เปลี่ยนยี่ห้อดาต้าเบส เช่น เปลี่ยน programming language มีไหมวันหนึ่งเราใช้ Go เฮ้ย Go ไม่ ไม่เวิร์กแล้วไปใช้ Python สวิตช์แบบวันเดียวเลย มีไหม ใครทำได้บอกด้วยนะครับ (หัวเราะ) มาทำงานกับผมด้วย (หัวเราะ) โอเคเนาะ อะไรที่มันเปลี่ยนยากนะครับ อันนั้นน่ะเกี่ยวข้องกับอาร์คิเทคเจอร์ให้เรา Record ลงไปนะครับ โอเคเนาะ อยากจะย้ำแบบนี้นะครับ ใครเคยดูหนังเรื่องนี้ไหม แนะนำให้ไปดูเหมือนกันใน Netflix นะครับ The Last Kingdom คนนี้คืออัลเฟรดนะครับ เขาเป็นคิงของเวสเส็กที่พยายามจะรวมอังกฤษเข้าด้วยกัน

เขาบอกไว้ว่า do not underestimate the power of written word ครับ when a man dies if nothing is written he is soon forgotten

ในเรื่องเขามีปัญหากับพระเอกครับ แล้วเขาบอกพระเอกว่าเขาจะไม่เขียนชื่อพระเอกลงในประวัติศาสตร์ ลงใน เอ่อ สิ่งที่เขาเขียน

พระเอกคนนั้นก็หายจากประวัติศาสตร์โลกนี้ไป โอเคไหม

เพราะฉะนั้นเนี่ยเวลาที่เราเมคดีซิชั่นนะครับ ให้เรา Record เป็นเอกสารไว้ด้วย ไม่งั้นเดี๋ยวมันจะเกิดเหตุการณ์ว่าอะไรนะ จำรูป senior รูปแรกๆ ได้ไหม ไม่รู้ว่ะมันมาได้ไงแต่มันเวิร์ค โอเคไหม อะเราจะได้เข้าใจบริบทของบริษัทด้วยว่าทำไมเขาเลือก Hadoop วะ แม่งเก่าไปแล้ว เดี๋ยวนี้เขาไป Cloud หมดแล้วอะไรอย่างเงี้ย นะครับ เออ โอเคไหม เราก็ต้องเข้าใจบริบทของเขาด้วย ซึ่งเอกสารพวกนี้ครับจะช่วยให้เราเข้าใจบริบทของเขา โอเคไหมครับ อะ ต้องเขียนเนอะ ต้องเขียน.

สรุปส่งท้าย: ทุกคนเป็น Data Architect ได้!26:44

โอเค ช่วงสุดท้ายสรุปนิดนึงครับ รีแคปนิดนึง.

ก็ปัญหาทุกวันนี้ยังคงมีอยู่นะครับ เรามี less— แบบจำนวนอาร์คิเทคเจอร์เนี่ยที่น้อยมาก และผมคาดหวังว่าเดี๋ยวทุกคนจบจากนี้ไปนะครับคุณจะมีสกิล architecture ในเร็ววันนี้ โอเคไหม คือสำหรับผมอะ ผมไม่ได้รู้สึกว่าเฮ้ยคนเป็น architecture นี่มันต้องเป็นยากนะ ผมรู้สึกว่าทุกคนน่ะควรจะมีสกิล Data architecture อยู่ โอเคไหมครับ เออ Data architecture skill มันไม่ควรอยู่ที่คนใดคนหนึ่งแล้วสั่งพวกเราให้ทำตาม OK ไหม มันควรจะเป็นดีซิชั่นแล้วก็มาจากทีมนะครับ เพราะว่าทีมเนี่ยจะรู้ดีที่สุดว่าเราจะต้องใช้เทคโนโลยีอะไร อะไรที่เหมาะสม อะไรที่มันควรใช้ ไม่ใช่ Consultant สักคนนึงเดินมาบอกเราว่า เฮ้ยพวกคุณไป Google เลย เฮ้ยพวกคุณ AWS อะไรอย่างเงี้ย ไม่ใช่นะครับมันควรจะมาจากทีม เพราะฉะนั้นทุกคนควรจะมีสกิลเรื่องในเรื่อง architecture นะครับ อะซึ่งเฟรมเวิร์คที่ผมใช้นะครับ Residuality theory นะครับ C4 Model แล้วก็ ADR นะครับ เป็น Practice เบื้องต้นแล้วกัน 3 อย่างนะครับที่จะช่วยให้เราแบบเรียนรู้เรื่องของ architecture ได้นะครับแล้วก็ออกแบบได้ดีขึ้น.

ซึ่งที่หยิบมา 3 อย่างเนี่ยจริงๆ เรื่อง architecture เนี่ยมันโคตรกว้างเลยนะครับ เอ้อ แต่ว่าถ้าคุณเรียนรู้ Just Enough เนี่ย To be Dangerous เนี่ยครับ ผมคิดว่าทุกคนสามารถที่จะก้าวไปเป็นแบบเฉิดฉายในองค์กร คุณแบบก้าวกระโดดไปเป็นซีเนียร์ในองค์กรได้ ออกแบบระบบซิสเท็มได้พวกนั้น นะครับ โอเค.ทิ้งท้ายครับ

Software แล้วก็ Data architecture นะครับ Without ดีไซน์เนี่ย ถ้าเราไม่ได้ดีไซน์มาดีๆ นะ มันเหมือนซิตี้ที่ไม่ได้แพลนนิ่งนะครับ ซิตี้ไหนไม่รู้นะครับ คุณคิดกันเอาเองนะครับ (หัวเราะ) โอเคเนาะ ซิตี้ที่ไม่ได้แพลนนิ่งนะครับ แล้วก็ผมเชื่อว่า Data Architecture— Data Engineer ทุกคนเนี่ยครับ สามารถที่จะมาสเตอร์สกิล Data Architecture ได้นะครับ โดยที่คุณไม่จำเป็นต้องเป็นซีเนียร์ครับผม ประมาณนี้ โอเค ขอบคุณครับ

ช่วงถาม-ตอบ29:07

ขอเสียงปรบมือให้พี่กานต์หน่อยค่ะ (เสียงปรบมือ) ค่ะ แล้วก็ได้รู้แล้วนะคะว่าสกิล Data Architecture เนี่ยมันสำคัญยังไงกับงาน Data Engineer ของเรานะคะ ในตอนนี้จะถือว่าเป็นช่วง Q&A เนาะ หากใครมีคำถามสามารถยกมือถามตอนนี้ได้เลยค่ะ

โอเคครับ คือแสดงว่าจาก เอ่อ C4 Model เมื่อกี๊เนี่ย ผมสงสัยว่าถ้าเกิด อ่า สมมติมี… หลายๆ คนที่เราต้องไปพรีเซนต์ด้วย แล้วเขามีโดเมนแตกต่างกันอย่างเงี้ย เราต้องทำ Architecture visualize แยกออกไปตามจำนวนเท่านั้นเลยใช่ไหมครับ คำถามคือเรา เราจะสื่อสารใคร เราจำเป็นต้องทำภาพนั้นครับ สำหรับผมนะ เราจะจำเป็นต้องทำภาพนั้นเพื่อสื่อสารกับเขาให้เข้าใจ ทำเฉพาะที่จำเป็น นะครับ มันไม่มี แบบ ภาพรวมทีเดียวเลยใช่ไหมครับ แต่เราต้องดีไซน์ออกมาให้ตามเขาเท่านั้น ใช่ครับ ไม่มีภาพ— ไม่มีภาพเดียวเป็น Silver Bullet นะครับ เหมือนเวลาเราคุยกับเพื่อนเนาะ เราไม่ได้คุยกับเพื่อนคนนึงกับอีกคนนึงเหมือนกันถูกไหมครับ เราสื่อสารกันคนละแบบ ดังนั้นภาพ Architecture เนี่ยครับมันเป็นการแชร์ understanding ระหว่างผมกับพวกคุณ ผมกับน้องเขาอะไรอย่างเงี้ย ผมกับ เอ่อ น้องอีกคนนึง ดังนั้นผมต้องพูดคือพูดคุยกันคนละแบบ ไม่มีภาพเดียว ขอบคุณมากครับ ครับผม มีใครมีคำถามเพิ่มเติมไหมคะ? โอเค อยากถามว่า Data Architect อะครับ เอ่อ ในเชิงซอฟต์แวร์ครับ ก็คือ DevOps Engineer หรือเปล่า ต่างกันยังไงบ้างครับ DevOps Engineer ผมมองว่าความต่างในการโฟกัสนะครับสิ่งที่เขาโฟกัส เออ DevOps Engineer เนี่ย ลักษณะจะเป็น… เหมือนเราพยายามที่จะทำ automate เพื่อ deliver ของเนี่ยจากต้นทางไปยังปลายทางให้ได้สมูทที่สุด ได้เร็วที่สุดนะครับ จะโฟกัสแถวๆ นั้น โฟกัสระหว่างแบบ เหมือนเป็น culture ที่ออกแนว support การ deliver ให้กับทีม เราพัฒนาซอฟต์แวร์ตัวนึงเนี่ย จะเอาซอฟต์แวร์ตัวเนี้ยไปวางไว้บน Server ไป deploy ให้ลูกค้าใช้ยังไงอะครับ เขาจะทำ support ทั้งเส้น เนาะ อันเนี้ยสำหรับผมคือแนวๆ DevOps Engineer ครับ ส่วน Data Architect ก็เราวางออกแบบระบบนะครับ อย่างสมมติว่าถ้าเป็น Architecture ของ Data เนาะ เราออกแบบระบบขึ้นมาว่า ตัว Architecture ตัวเนี้ยเราจะตอบโจทย์เรื่องของการรับข้อมูลเข้ามายังไงได้บ้าง แล้วก็เอาข้อมูลเนี่ยออกไป produce ออกไปให้ฝั่งของ downstream หรือว่าผู้ใช้งาน Data เนี่ยยังไงได้บ้าง มากกว่าจะเป็นภาพแบบดีไซน์มากกว่า support ครับผม เอ่อ ประมาณว่า Data Architect กับ เอ่อ เมื่อกี้น่าจะผมพูดผิดน่าจะไม่ใช่ DevOps ครับ น่าจะเป็นประมาณ Solution Architect แบบนี้ครับ Cloud Architect น่าจะคล้ายๆ กันนะครับ อ้า Solution Architect สำหรับผมอะมันออกแนว Business ครับ อะเราไปทำความเข้าใจ สำหรับผมนะตามความเข้าใจผมนะ เราไปทำความเข้าใจกับทางฝั่งของ Business แล้วเราก็คิดโซลูชันให้เขา ครับ ประมาณนั้น โซลูชันเนี่ยมันอาจจะเป็นภาพ Architecture ที่เรามีอยู่แล้วว่า เฮ้ย ถ้า Business แบบนี้เราใช้ภาพ Architecture แบบนี้เพื่อทำเป็นโซลูชันให้กับอีกทีมนึง อย่างเงี้ยเป็นต้น ให้กับลูกค้าอีกเจ้านึงเป็นต้น ครับ เอ้อ มันจะมีความแตกต่างสำหรับผมแบบ Software Architect หรือว่า Data Architect เนี่ย จะอยู่เข้ามา Internal มากกว่า Solution Architect ครับ

ขอบคุณครับ

ค่ะก็ขอบคุณสำหรับคำถามทั้งหมดด้วยนะคะ ยังไงถ้าหากว่าท่านอื่นอื่นมีคำถามเนี่ยสามารถถามพี่กานต์ได้เลยนะคะ ก็ยังไงขอบคุณพี่กานต์มากนะคะที่มาแชร์ความรู้ในวันนี้ ขอเสียงปรบมือให้พี่กานต์หน่อยค่ะ (เสียงปรบมือ)