🎞️ Videos → Decoding Data Engineering — Myth vs Reality & What are Here to Stay

แนะนำตัว Panelists และหัวข้อสนทนา: Decoding Data Engineering0:00

เอ่อ สวัสดีค่ะ เจอ กันอีกครั้งนะคะ แก้วนะคะ ก็เดี๋ยวรับ หน้าที่เป็น โมเดอเรเตอร์ ให้กับ 2 คนนี้นะคะ ก็คือ เอ่อ หัวข้อเนี้ย คือหัวข้อ Decoding Data Engineering Myth versus Reality and What are Here to Stay คือ ความเชื่อกับความจริงเนาะ ก็ ก่อนอื่นให้

เอ่อ เราได้รับเกียรติจากคุณตั้วและคุณกานเนาะ ก็เดี๋ยวให้คุณตั้ว คุณกานเนี่ย แนะนำตัวให้ทุกคนรู้จักนิดนึงก่อนแล้วกันค่ะ ชั้นก่อนแล้วกันนะ โอเคครับ ผมดีเร็ก ยิ้มละไมนะฮะ เรียกว่าตั้วนะครับ ก็ อยู่ดูแลเรื่องของตัว infrastructure system จนมาจนรู้ตัวว่า ตลอดเวลาที่ทำมาก็คือมีเกี่ยวข้องกับพวก ลักษณะของพวก data platform แล้วก็ลักษณะของการจัดการ data มาโดยตลอด แต่ทั้งๆ ที่เติบโตมาทางสาย infrastructure ครับ ทั้ง system network security อะไรประมาณนี้ แล้วตอนนี้ก็มาดูแลเทคโนโลยีที่เป็น cloud มันเลยทำให้ ความคิดนั้นน่ะ เร็วขึ้น เพราะว่า cloud เอง การดีไซน์หรืออะไรพวกเนี้ยครับ มันสะดวก เราก็จะไปที่ประเด็นของพวก data แล้วก็ data platform ได้ ได้สะดวกขึ้น อันนี้คือ

บอกเล่าการเติบโตตัวเองสั้นๆ ประมาณนี้ก่อน แล้วก็ตอนนี้คือดูแลตัว Cloud Business ของ เอ็มเฟค ประมาณนี้ครับ เชิญคุณกาน อ่า สวัสดีค่ะ ก็กานนะคะ จริงๆ คือ พื้น background อ่ะค่ะ จะคล้ายๆ คุณตั้ว คือเป็นคน system infrastructure มาก่อนแล้วกัน แล้วก็ โชคดีได้มาจับงาน data ทุกภาคส่วนเลยก็เลย รู้เข้าใจว่าจริงๆ แล้วการที่เราจะทำงาน data ให้มันรอดเนี่ย เราต้องมีความเข้าใจ อ่า กายภาพของมัน คือด้าน infrastructure ด้วยเช่นกัน ก็ ตอนนี้ก็ปัจจุบันอยู่ เอ็มเฟค ค่ะ เป็น Cloud Optimization and Automation Consultant ค่ะ ก็จะมาดูในเรื่องของการที่ เราทำยังไงที่เรา อ่า ลด operation cost แล้วก็ optimize cost ของทุกสิ่งอย่างที่เราใช้ เพราะว่ามันไม่จบแค่ว่า อ่า cost ถูก แต่ว่า มันต้องดูต่อในระยะยาวด้วยว่าในการ operate ระยะ long term เนี่ย มันจะเป็นยังไงบ้าง ต้องใช้ resource ทุ่มขึ้นหรือเปล่า หรืออะไรประมาณนั้นค่ะ ดู long term ด้วยอีกทีนึง ประมาณนี้ โอเค

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

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

ประสบการณ์ตรงจากคุณตั้ว: ความผิดพลาดจาก Data Pipeline ในอดีต3:00

เอ่อ เป็นการทำ transform ใหญ่มากของระบบ finance ของไทย ประมาณ 20 ปี ก่อน ถามว่าเอาแล้ว ดีเร็ก นี่ทำงานมานานมั้ย ใช่ อายุเยอะแล้ว ครับ เอ่อ ในภาพเนี่ย ตอนนั้นที่ทำอ่ะครับ เป็น network system แล้วก็ในลักษณะของ infrastructure architect design ทั่วไปเลย มองง่ายๆ ผมเป็น IT architect มองแบบนี้ งานตอนนั้นเองเนี่ย มีความรู้สึกว่า เรากำลังทำอะไรอยู่นะ ลูกค้าอยากทรานส์ฟอร์ม ทุกอย่างเริ่มต้นที่ตัวเดต้าทั้งหมดเลยครับ เพราะว่าข้อมูลของลูกค้า พูดง่ายๆ คือของประชาชนน่ะ ที่ลูกค้าท่านเนี้ย หรือองค์กรเนี้ยดูแลเนี่ย สำคัญที่สุด ห้ามหาย

ตอนที่ไปทำ เราเข้าไปในฐานะที่เป็น Infra Architect ไปดูว่าอะไรมันเชื่อมโยงกันได้ แค่นี้ก็เกี่ยวข้องกับ Data Injection ในยุคนั้นแหละ แต่เราไม่เข้าใจ ตอนนั้นก็มองแค่ว่าไปดึง ข้อมูลมาจากแพลตฟอร์มต่างๆ Server Database ดู Utilization เพราะว่าเคยดึงมาแล้วเขาดาวน์ เรานี่แหละ ไปคนทำให้เกิด Incident นะครับ ตอนทำไม่เป็นไร ตอนเราจากไป มีปัญหาทุกทีเลย แต่ตอนนั้นคืออยู่ประมาณ 7 ปี ไม่ได้ไปไหนหรอกครับ เขาก็เรียกไปเคลียร์นี่แหละ จาก ถัดมา เราก็จะต้องไปคุยกับ Data Owner เพราะจะต้องทำ Data Cut

จริงๆ ตอนนั้นก็ไม่เข้าใจว่ามันคือ Data Architect ต้องดูว่า ระบบ A เนี่ย จะต้องทำ Data Cut เนี่ย 6:00 น. ก่อนเปิด branch นะ 6:01 น. เนี่ย ไม่ได้ แปลว่าจะต้องทำ Data Backup เนี่ย ให้แม่น จบที่ 6:00 น. 2 System B จะต้องไป Cut Next Day System A เนี่ย เอา 6:00 น. ของวันที่ 1 มองแบบนี้แล้วกัน แต่คือ System B เนี่ย ต้องไปเอา Next Day คือวันที่ 2 4:00 น. System C เนี่ย จะต้องรอจน Month End เท่านั้น ดังนั้นทุกอย่างผูกกันเนี่ย เลยรู้ว่า ต้องตัดสิ้นเดือน อ้าว แล้วเดือนนั้นกุมภามั้ย เดือนนั้นมี มีนา -คม หรือ -ยน ต้องดูให้ดี ตัดให้ตรง เราก็จะหา เห็น Data Dependency ก็เพิ่งเข้าใจว่าอันนั้นน่ะ คือการมอง Data Dependency การเตรียมทำ Data Pipeline ซึ่งตอนนั้นไม่มีความรู้นั้นเลย แต่ทำอยู่กับมือ พังมั้ยครับ ไม่ต้องห่วง ไอ้คนนี้แหละครับ ทำพัง ตอน Cut ครั้งแรก ครับ

เจ๊ง เพราะว่าผมเองเนี่ย ชะล่าใจ มันมีทั้งหมด Dependency เล็กสุดเนี่ยประมาณ 4 System System 1 2 3 เมื่อกี้ที่บอก เล่าคร่าวๆ อ่ะ เรียบร้อยและ System ที่ 4 ไม่มีเดทชัดเจน

เพราะว่า Data Owner เหลือแต่ The God ก็คือไม่เหลือใครแล้ว ไม่มีใครทำ Document เลย ทำไงฮะ ไปนั่งเฝ้าหน้า branch ครับ ไปอยู่กับ User พี่จะปิด branch กี่โมง โอ๊ย พี่ยังไม่เสร็จเลยลูก สามทุ่ม แล้วนะพี่ ครับ ตอนนั้นคือเกี่ยวข้องกับระบบเช็ค แปลว่าเช็คเนี่ย ปิดรับเช็คของทุกแบงค์เนี่ย ประมาณตอนนั้นนะครับ 18:00 น. 18:00 น. เอ่อ 15:00 น. เนี่ย ปิดรับประชาชน 18:00 น. ปิดรับ Corporate แล้วยังไง อ๋อ เดี๋ยวพี่จะเริ่ม Run 2:00 น. พี่ เช็คพี่ Run 2:00 น. หรอ ครับ Run 2:00 น. เช็คพี่เนี่ย Run 2:00 น. เนี่ย นับเป็นวันไหน วันนั้นคือคืนข้ามเดือน เพราะผมต้องทำตาม System C ที่บอกว่า End Month End เท่านั้น พอเลยเที่ยงคืน มันก็จะไม่ Month End แล้วสินะ มันจะเป็น New Month แล้วผมก็แบบชะล่าใจ พี่ งั้นพี่นับวันไหน เอ้ย นับ นับเมื่อวาน ก็คือแปลว่านับ Month End อยู่ Run 2:00 น. เสร็จ 6:00 น. เช็คหมื่นใบ Run อยู่ 4 branch ก็คือ 4 สาขา 4 4 ตึกอ่ะนะครับ Run เสร็จปุ๊บ ตอนนั้นยังใช้ Windows XP อยู่เลย Run เสร็จปุ๊บ ครับ

คิดดู เป็น Windows XP จริงๆ เอ่อ พอ Run เสร็จปุ๊บ เอาข้อมูลกลับมา ทำ Reconciliation เจ๊งครับ เพราะว่า System C บอกว่า ไม่ใช่ Month End แล้วไอ้ดิเรกคนนี้แหละครับ โกง ไปคุยกับ Data Owner ทั้ง 4 บอกว่าผมขอ Change Date ได้มั้ย ก็คือขอทำ

ทำเหมือนแบบ ทำ Virtual Date อ่ะครับ มันเลยมีไอเดีย Change Date นะวันนั้น ตอนนั้น ลอง Change Date ดู แล้วรันได้ ดิเรกชูมือได้เลย วันที่ทำว่าได้เนี่ย ทำ Data Dependency ทำ Data Pipeline เหมือน A เข้า B เข้า C คลีนอ่ะ cleansing เรียบร้อย เข้าแพลตฟอร์ม วันนั้นไม่เกิดเรื่องครับ ผ่านไปทั้งหมด 10 เดือน ก็คือ year end

ตอนแรกคือวันนั้นก็ดีใจเนาะ ไอ้วัน 10 วินาทีที่ศูนย์ของ 10 เดือนน่ะ ก็คือยังไม่ได้ คือวันที่คัทเรียบร้อยอะฮะ พอผ่านไป 10 เดือนมีข้อมูลนึงหาย ข้อมูลที่ system C ต้องการ แต่ผมไปเปลี่ยน date ไป change date เลยทำให้เกิด impact ของ year end อันนั้นก็เลยเป็นที่มาว่า ผมไม่มีความรู้ Data engineering มากพอ ในห้วงเวลานั้น ละเลยในความสำคัญของ date ที่เป็น timestamp ของ Data ทุกเรคคอร์ด แล้วคิดว่ามันได้ เพราะวันนั้นที่ทำอ่ะ สมมุติว่าเป็นเดือน 2 แล้วกัน มันได้อ่ะ มันจบ เดือน 3 reconciliation user มา review ทุกอย่างจบ audit ตรวจสอบเรียบร้อย ครบสมบูรณ์ Data owner sign off แต่อีก 10 เดือนถัดมา ก็คือประมาณพฤศจิกายนธันวาคม ทุกคนก็จะกำลังพักร้อนพักผ่อนเนาะ ช่วงกำลังไปเที่ยวเลย ดิเรกนี่แหละครับ ทำให้ทุกคนไม่ได้พักเลยฮะ แน่นอน มันมีทีมของผมแหละ แต่ผมเป็นคนตัดสินใจว่าให้ใช้วิธีนี้ นั่นเลยเป็นที่มาว่า ความรู้ system network security architect เนี่ย มีความจำเป็น แต่ทุกงานที่ผมแตะ เกี่ยวข้องกับตัว Data ทั้งสิ้นเลย นั่นเลยเป็นที่มาว่า ทำไมผมถึงอยากจะมาพูดถึง ความเชื่อที่ว่า เฮ้ย ผมไม่ได้ทำ Data platform ผมไม่รู้ไม่เกี่ยวไม่อยากยุ่งกับ Data เลย แต่ทุกวินาทีคือแตะกับตรงนั้น สรุป สรุปง่ายๆ เลยก็คือ ตอนนั้นที่พี่ทำอยู่อ่ะ พี่ไม่รู้เรื่องอะไรเลย ไม่รู้เรื่องอะไรเลย ใช่ แล้วก็ แล้วก็คิดว่าตัวเองอ่ะ รู้ทุกอย่างแล้ว ใช่ จนกระทั่งมันเกิด impact กับลูกค้า แล้วเพราะตอนนั้นเป็น เป็น consultant อ่า แล้ว ใช่ครับ แล้วพี่ก็ทำให้คนอื่นไม่ได้นอน ใช่ แล้วตอนนั้นยังอยู่ MFEC แล้วไม่ย้ายบริษัทด้วย ดูหน้าด้านนะ อ่า มันๆ ก็เลย มันก็เลยเป็นที่มาว่า เฮ้ย จริงๆ แล้วอ่ะ พี่ก็เลยอยากจะมาเล่าให้ทุกคนฟังว่า เฮ้ย จริงๆ แล้วมันควรจะเป็นยังไงเนาะ อืม พี่ พี่อย่าเพิ่งร้องไห้ คือมันเป็นของจริง คือกูไม่ร้องหรอก คนอื่นมันร้องไปเลย หมายถึงว่า ไอ้คนที่ผมทำให้ตื่นไม่ได้พักร้อนน่ะ ความเป็นจริงคือ พวกคุณมีโอกาสดีมากๆ ฮะ การเข้าใจ Data engineer เดี๋ยวเนี้ย หมายถึง เดี๋ยวเนี้ย มันดีมากเลย เพราะว่าทุกอย่างอ่ะ คือมัน relate บน Data ทั้งสิ้นเลย โลกใบนี้ขับเคลื่อนด้วย Data เมื่อก่อนบอกว่า Data ดั่งทอง ดิเรกตอนนั้นไม่ get ทำเละเทะ กลายเป็นไม่ใช่ทอง ไม่พูดแล้วกัน จริงๆ คือมันเป็นทอง จริงๆ มันเป็นของมีค่า แต่คือ ด้วยความไม่เข้าใจ ตอนนั้นมันเลยเป็นสภาพนี้ โอเค

ประสบการณ์คุณกานต์: Data และ Infra เป็นของคู่กัน9:45

เชิญ เชิญลูกพี่ครับ อ่า จริงๆ จะเหมือนกับที่พี่ดิเรกเจอค่ะ คือ คือถ้าเกิดรู้จักกานน่ะ จะบอกเสมอว่า ไม่อยากทำงาน Data ไม่ชอบงาน Data พี่เข้าใจ แต่ทุก แต่ว่าทุกครั้งที่ทำงานก็คือ หนีงาน Data ไม่พ้น มันจะตามมาหลอกหลอนค่ะ เพราะว่า Data กับ Infra เป็นของคู่กันค่ะ คือสร้าง Infra มาทันทีเนี่ย อย่างแย่ที่สุดน่ะ มันต้องมีการเก็บแล้วว่า เราสร้างอะไรไปมั่ง cost เท่าไหร่ ปั่น Data ให้บัญชี คุณจะหนีสิ่งนี้ไม่พ้นค่ะ อันนี้คือ ทำใจตัวเองอยู่นะ โอเค เพราะงั้นคือมันเลยกลับไปที่ว่า มันจะมีการที่มันปะทะกันระหว่าง infrastructure layer กับ user layer และ platform layer คือทุกเส้นทางเนี่ย ถ้าเกิดเราบอกว่า layer ลึกสุดน่ะ มันคือ infrastructure hardware networking ขั้นต่อมามันจะเป็น platform หรือ tool หรือ database อะไรก็แล้วแต่ที่ Developer เป็นคนใช้ ฝั่งตรงนี้ไปอาจจะเป็น user ซึ่งทั้งหมดเนี้ย เราควรที่จะมอง เป็นเส้นเดียวกันให้ได้ เพื่อที่เราจะรู้ว่า ปัญหาเวลาเกิดขึ้นน่ะ มันเป็นที่ส่วนใคร เพราะเวลาปัญหามันเกิด ขึ้นจริงเนี่ย มันจะ อาละวาดตรงไหนเราไม่รู้ แต่เราต้องใช้ skill ที่เรามีในการดูว่า ในเส้นทางของมันทั้งหมดเนี่ย มันไปอาละวาดอยู่ส่วนไหนจะได้แก้กันถูก แล้วบางที มันอาละวาดสองส่วนพร้อมกัน ต้องชี้ให้ออกว่า ตรงนี้ผลจากฝั่งนี้ ตรงนี้ผลจากฝั่งนู้น แก้คนนู้นที แก้ตรงนี้ที ประกอบกันจะไม่พังอย่างเงี้ยเป็นต้น ขอเติม ไอ้ที่การบอกครับว่า

ที่สุดมันจะอะไรว่า ของผมเห็นไหม อะไรว่าช้า 10 เดือน แปลว่าตอนนั้นผมไม่เห็นไปข้างหน้าเลย มันเลยเป็นที่มาว่า เนี่ย มันเลยต้องเติมความรู้ เรื่องพวกนี้ แล้วก็มอง เพื่อมองความเสี่ยง ด้วย ครับ

Data Pipeline คืออะไร? ต้องคำนึงถึงอะไรบ้าง?11:30

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

ลอง ลองมีใครแบบ อยากตอบไหมว่า เอ้ย data pipeline คืออะไรนะ พี่ตั้วให้ 3,000 ล้อเล่น จริงปะครับ พี่ตั้วให้ 3,000 กูยกมือก่อนเลย ได้ โอเค โอเค สตาร์ทละ มีใครอยากลองไหม เออ ใน ในนี้ DE น่าจะครึ่งนึงนะ จริงๆ แล้วอ่ะ กดดัน โอเค ไม่เป็นไร อ่ะ พี่ตั้วอยากเฉลยไหมว่า เอ้ย จริงๆ แล้วอ่ะ data pipeline ที่เราทำ ทำกันอยู่เนี่ย จริงๆ มันคืออะไรกันแน่ โอเค ตอนที่ ผมเพิ่งมีความรู้แล้วกัน จากวันนั้นอ่ะนะ มันคือ การทำ data pipeline ในความ ใน ในความเข้าใจผม ที่คิดว่า เหมาะสมแล้วเนี่ย คือการทำในลักษณะที่ว่า รู้ว่าไปหยิบอะไรจากไหน แต่ก่อนไปหยิบอ่ะครับ ต้องเข้าใจก่อนว่าที่ ที่จะไปหยิบ คือ data source แล้วกัน มอง มอง เอ่อ เข้าใจคนดูแล หรือแม้กระทั่งเข้าใจระบบด้วยว่า

ที่จะไปแตะเขาเนี่ย เขาไหวใช่ไหม ไม่ใช่ utilization เขาปริ่ม 90% 95 แล้วไปแตะในวันหรือเวลาที่เขาแบบ ไม่พร้อมอ่ะ ขอ time period ขออะไรพวกนี้ด้วย data pipeline คือต้อง ต้อง care ตั้งแต่ ต้น ก็คือ empathy system อ่ะ ก็คือ เห็นใจระบบด้วย แน่นอนคือเรา empathy มนุษย์อยู่และ แต่คือเราควรที่จะเข้าใจตั้งแต่ ต้นทางว่าเราหยิบอะไร หยิบ อันนี้หมายถึง database เนาะ สมมุติว่า เรา DE อ่ะ เราจะต้องไปดึงข้อมูลจาก database ของ ใช่ application หรือ service อะไรอย่างนี้อยู่แล้ว ซึ่ง ซึ่งมันก็โดน ใช่ โดนใช้งานด้วย service หนักมากอยู่แล้วเนาะ แล้ว แล้วก็จะมีปาร์ตี้ ใช่ ถูก data pipeline ที่ไปดึงโคตรใหญ่เลย อะไรอย่างงี้ถูกไหม ก็ทำให้ utilization ของ database อ่ะ ใช่ มันปริ่ม อย่างที่พี่ตั้วบอกเนาะ ใช่ ขอบคุณมาก เพราะว่า เอ่อ ถ้าสมมุติ เอ่อ พอยต์ไปที่ database อ่า เออ ตัวเขาเองเนี่ยมีการ read write อยู่แล้ว IOPS ก็คือแบบ โอ๊ย กูแน่นละ เฮ้ย CPU ไม่ขึ้นไม่เป็นไรหรอก นี่ พอดิเรกก็เดินเข้าไป ก็คือไปหยิบมาเลยอย่างเงี้ยไม่ได้ แปลว่าต้องดูภาพรวมด้วย data pipeline ก็คือควรจะดูตั้งแต่ source ว่าเขาไหวไม่ไหวเท่าไหร่ ช่วงเวลาไหนที่เขา utilize ต่ำสุด เราไปหยิบตรงนั้นได้ไหม เพราะเวลาเราดึงมาทีเนี่ย แรกๆไม่ได้ดึงดิฟ

แทบจะ restore เลยมั้งพี่ ก็คือหมายถึงว่า กว่าเราจะมีการดึงแบบดิฟเนี่ย มันจะเป็นยุคนี้ยุคที่พวกคุณมีตอนนี้แล้วนะ

ความสำคัญของการสื่อสารและวางแผนใน Data Pipeline14:14

ขอเสริม ขอเสริมนิดนึงว่า มันจะมีความบันเทิงอย่างงี้ คือ ถ้าไอ้คนดึงดาต้า จากระบบ database ของแอป กับคนที่ดูแล database ของแอป ไม่ได้คุยกัน สิ่งที่เกิดขึ้นคือ database มันล่วงปุ๊บ ไอ้คนดูแอปก็จะงงว่า ช่วงนี้คนใช้เยอะเหรอวะ อือๆ แล้วถ้าเกิดไม่คุยกันเนี่ย หายก็หายไม่เจอค่ะ อืม ใช่ เป็นปัญหาต่อไปนะคะ โอเค เห็นด้วย ดังนั้น data pipeline ลำดับคือ ให้วางแผนลงเอกสารหรือกระดาษก่อน ทำเป็น manual ก่อน เรียกคนที่เกี่ยวข้องในทุกท่อน ไม่ว่าจะตั้งแต่ system admin ที่ดูแลระบบ Network admin เพราะบางที bandwidth เค้าเต็มอยู่แล้วครับ เพราะว่า network เนี่ยเป็นเหมือนถนน ชาวบ้านชาวเมืองก็ใช้มากกว่าแค่ตัว database server เมื่อครู่ด้วย มองว่าเอามาทำอะไร เพื่อ convince คนที่เป็น system admin Database เอ่อ Network admin หรือแม้กระทั่ง data owner อ่ะ ให้เห็นด้วยว่า ทำไปเพื่ออะไร ในมุมของการมาดึง data pipeline นี้ แล้วก็การทำ cleansing ต้องเห็นก่อนว่า เราทำไปเพื่ออะไรนะ เพราะไม่ใช่มาปุ๊บ data pipeline คือหยิบมาวางที่ destination มันไม่ใช่แค่นั้น หมายถึงว่าหยิบจาก source ไปวาง platform เนี่ย มัน มันทำแบบนั้นน่ะ มันเอา เอาตัวเองเป็นหลักเกินไป ดังนั้นคือควรจะมองด้วยว่าภาพใหญ่คืออะไร เพื่อไป พูดคุยให้กับทั้งคนที่ดูแลระบบ แล้วก็

เข้าใจตัวระบบว่าเค้าไหวแค่ไหน เราก็จะได้ทำซ้ำได้ อันนี้สำคัญ ตอนที่ผมทำในยุคก่อน ทำซ้ำไม่ได้นะครับ ไอ้เมื่อกี้ที่บอกว่า data cut น่ะ ทำได้ครั้งเดียว พอครั้งถัดไปปุ๊บ ก็ต้องมาคิดใหม่ ทำวางแผนใหม่ซึ่ง จริงๆไม่ต้องคิดใหม่ วางแผนใหม่ครับ มันทำซ้ำได้ แต่ความรู้ตอนนั้นไม่พอ ดังนั้นความรู้ เอ่อ การทำ data pipeline ควรทำซ้ำได้ tracking ได้ traceability ได้ และที่สำคัญ ทำให้มัน rerun ได้ด้วย เคยเหมือนกัน ทำ data pipeline ซะตายเลย ดูเท่มากเลย เฮ้ย ตั้ว rerun ดิ

เอ่อ ครับผม ขอ Pipeline ที่ 2 เดี๋ยวทำ restore นี่ เป็นอย่างงี้ไปซะงั้น นั่นคือ ภาพของ data pipeline คือควรคิดให้จบ reuse ได้ แล้วก็สามารถ tracking ได้ ประมาณนี้ อ่า เสริมว่าจริงๆเมื่อกี้มันเป็นเรื่องของการ อ่า คุยกันข้ามกันเนาะว่า เราจะเอา data ไปใช้ยังไง ใช้แบบไหน ปัญหาที่เกิดขึ้นจริงคือ มันจะมีจริงๆ คือทีมต้นทางที่เค้าบอกว่า นี่ไง เราก็ให้ data คุณเป็น API ไปแล้ว แต่ไอ้คนต้องใช้อ่ะ ต้องขุด data ย้อนไประดับพระเจ้าเหาอ่ะค่ะ API เนี่ย ทำให้ได้นะ แต่ API server แหกก่อน Database หลังบ้านอ้วกก่อน คือถ้าเกิดเราคุยกันดีๆตรงนี้เนี่ย อาจจะ อลุ่มอล่วยเป็นว่า โอเค เดี๋ยวแบบคุณไปเจาะหลังบ้านเรา throughput เท่านี้ ขุดเอามาอะไรเงี้ย มันจะประหยัดทั้งเงินและ resource กว่าด้วยซ้ำ แต่ว่าจะไม่เกิดคอขวด ดีไม่ดีคือ restore ก้อนใหญ่มาก่อน แล้วค่อย ให้ data API ดึงดิฟมาประมาณนี้ ถูกต้อง เพราะปัญหาโลกแตกคือ คือ API มันก็ส่ง data ได้เหมือนกัน แต่ว่า มันไม่ได้เกิดมาเพื่อส่ง data ระดับเป็นรถบรรทุกอ่ะ มันจะส่งแบบระดับคันนึงสองคันอะไรเงี้ยประมาณนั้น แต่คือถ้าเกิดคุณจะขุด เป็นรถคอนเทนเนอร์ขนจากท่าเรืออะไรงี้ไปคือประมาณนั้น จะใช้ท่าอื่น เค้าเป็นข้อจำกัดของ HTTP protocol ที่อาจจะมี MTU จำกัด เท่านั้นเท่านี้ อ่า ถูกต้อง ไปๆๆ ไกลแล้ว กลับมาๆ อ่ะ เดี๋ยวๆ สรุปๆๆ ก็คือจริงๆ แล้วอ่ะ การทำ การทำ data pipeline อันนึงเนี่ย จริงๆ เราก็ต้องรู้นะว่า source ที่เราจะไปดึงอ่ะ มันคืออะไร มันอาจจะเป็น database ก็ได้ หรือเป็น API ก็ได้ เพราะฉะนั้นวิธีการดึงอ่ะ มันก็ไม่เหมือนกัน หลักๆ แล้วเราก็ต้อง เอ่อ ประเมินว่าเราควรจะดึงแบบไหนที่จะไม่กระทบกับ source system สุด แล้วเราก็ต้องรู้ด้วยว่า destination ของเราอ่ะ เราจะใช้เพื่ออะไร เพื่อที่เราจะได้ทำ transform ได้ถูกต้อง ถูกต้องเลยครับ อ่า ทำตรงนี้ แล้วก็ตรงระหว่างทางที่ทำ transform เนี่ย ตัว pipeline ของเราก็ควรจะ reusable ได้ ทำ backfill ได้ run ซ้ำได้

ไม่ใช่ว่า เพิ่ม pipeline ใหม่ไปเรื่อยๆ เพื่อ rerun อะไรแบบนี้เนาะ ครับ ใช่ครับ

เมื่อ Data Pipeline พัง: ใครรับผิดชอบ?18:08

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

แบบ อ่ะ ถ้าถ้าง่ายๆ ก็เจอจุดแดงใน Airflow อย่างเงี้ย หรือบางทีแดงก็ แดงแล้วนะ แต่ เราไม่รู้อ่ะ ว่ามันแดงอ่ะ แล้วจน user มา ทักว่า เอ๊ย ทำไมวันนี้ data ไม่มา report ที่ไม่ขึ้น dashboard ไม่ขึ้น ทำยังไง อ่า เงี้ย จริงๆ อ่ะ มันจะมีปัญหาหนึ่ง คือ data มันพังอ่ะ โอเค system รู้ วันนี้ฉันพัง แล้วประเด็นคือมีใครรู้กับ system บ้างว่ามันพัง ถ้าเราโชคดี engineer เค้าจะไปตั้ง alert เอาไว้ว่า ถ้า pipeline พัง ส่ง alert ใน Slack อะไรก็ว่ากันไป แต่อย่าประมาท stakeholder หรือเจ้าของ pipeline ที่ไม่อ่าน chat อันนี้ค่ะ เพราะเค้าจะกด mute มันไว้ค่ะ มีจริง เพราะงั้นคือ สุดท้ายมันคือแบบที่ว่า เนี่ย ระบบมีให้คุณแล้ว ทุกอย่างมีให้ดูสัญญาณชีพแล้ว คุณเข้าไปดู reaction มันหรือเปล่า จะกลับไปที่ว่าเป็น culture ของการ อ่า collaborate ร่วมกันด้วยว่า เราจะแก้ปัญหากันยังไง เพราะว่า ในการแก้ปัญหา เอาแบบง่ายที่สุดเลยคือ ปัญหาคุณไม่ใช่ปัญหาเรา แต่ในความเป็นจริงแล้วเนี่ย เราต้องควรจะช่วยกัน เพราะว่าบางทีแก้ที่เราไวกว่า แก้ที่คุณไวกว่า เรามาแค่มาดูกันว่า งานไหนแก้ที่ใคร เราคล่องตัวที่สุด

อย่าไปมองว่า เอ๊ย งานนี้ฉันทำเยอะ เธอทำน้อย สุดท้ายคือทุกคนมีงานเท่ากัน เราแค่ว่าทำยังไงให้เราแต่ละคนออกแรงน้อยที่สุด แล้วแก้ปัญหาไปด้วยกันได้ ขอเติมของการเมื่อกี้คือเข้า Slack แล้ว mute ใช่มั้ยครับ อันนี้คือเป็นระดับ Enterprise คือขึ้นจอเลยครับ ขึ้นจอมีขึ้นแดงนะฮะ admin เอ่อ operation lead shift นั้น กด accept done ให้เลย เพราะว่าเขามองว่าถ้าเกิดไม่มีเขียวแปลว่าตัว KPI เค้าดี

Use Case: ผลกระทบจากการมองข้ามรายละเอียดเล็กน้อย20:09

ความหมายตรงเนี้ยครับ คือจะบอกว่า ในภาพของการทำ data pipeline เสร็จแล้วเนี่ย จะต้องให้คนที่เกี่ยวข้องทั้งหมด ตั้งแต่ system คนดูแลระบบ คนดูแล network data owner คนนำไปใช้ หรือแม้กระทั่งคนดูแล data platform เนี่ย และรับหน้าที่ร่วมกันว่า เฮ้ย ถ้ามีจุดแดงแม้แต่นิดเดียวหรือมีปัญหาเนี่ย หน้าที่ของทุกคนนะ ผมขอลองเล่า use case นึง ของงานที่ผมทำอันนั้นแหละ ไอ้ เจ้า ยาวนานหลายปีนะฮะ เอาขึ้นแดชบอร์ดเรียบร้อย คราวนี้ทางฝั่งของ system เนี่ยเขาบอกว่า วันเนี้ยระบบเขาอะจะมี change นะครับ เขาจะขอดาวน์ไทม์ ช่วงนี้ ช่วงนี้ แจ้งแล้วล่วงหน้า เข้า change cab เรียบร้อย คือเข้า cab committee เรียบร้อย เสร็จ จากนั้น

ไม่ได้มาอัปเดต หรือคิดว่าทางฝั่งของคุณดูแล data platform ไม่ต้องเข้า cab นั้นก็คือไม่ต้องเข้าตัว advisor เอ่อ cab advisory board ก็เลยไม่ได้เชิญ แล้วไม่ได้มาอัปเดต operation team ใหญ่ด้วย ไม่ได้มาอัปเดตทีม monitor อะครับ แต่บอกทีม monitor แค่ว่า เดี๋ยววันเนี้ย จะมี change ทำ upgrade system database ตัวนี้นะ ช่วงเวลาเนี้ย ถ้าเกิดเจอแดงอะ ให้ ignore ได้เลย แม่เจ้า ครับ มันสนุกตรงนั้นแหละ จินตนาการที่เกิดขึ้นเป็นตามนั้นในหัวเลยครับ ก็คือ ตอนทำ change data ถูกดึงแล้วถูก interrupt วันนั้นไม่มี data ก้อนนั้น แปลว่าเมื่อกี้ที่ยกตัวอย่าง A B C ที่ เงื่อนไข A B C D เนี่ยมันต้องร้อยกันน่ะ หายไป แล้วช่วงนั้นเป็น quarterly คือมันเป็น quarter end น่ะ ก็คือมันปิดเดือน 3 เดือน 6 เดือน 9 ความหมายคือว่า รีพอร์ตของคิวนั้นไม่มีไปเลยครับ ดังนั้น

วิธีการทำก็คือ จะต้องไป next Q ต้องคุยกับ audit ต้องต่อรองกับ BOT หรืออะไรก็ตาม เพื่อขอให้ เกิดเหตุการณ์นั้น business impact เยอะมาก ถอยกลับมาที่ operation operation กด ignore เขียว green แล้วก็ mark ไปแค่ว่ามี change copy change number แปะ จบ เช้าวันถัดมา user ไม่ได้รีพอร์ต เหมือนที่เมื่อกี้คุณแก้วบอกเลย ร้องไห้เลยครับ เพราะว่า user เองจะต้องเอาอันนั้นไปชี้แจง audit มันเป็นเรื่องของการทำ ธุรกรรมการฟอกเงิน ประจำ quarter

ว่ามีบริษัทไหน เพราะที่สุดคือ บริษัทที่เป็น corporate ทั้งหมดจะต้องเอารีพอร์ตเนี้ย ที่เป็นรีพอร์ตของแต่ละบริษัทอะ เอาไป declare audit ของตัวเอง ว่าเขาเนี่ยไม่ได้ฟอกเงินนะ รูปแบบของ transaction ที่วิ่งเข้าวิ่งออก โปร่งใสแบบนี้ มีใครแบบนี้ ปปง. ไม่ต้องมาลง ลงหมดเลย ก็คือ คือ หนึ่งเดียวที่ change กด ignore ดังนั้นคือในลักษณะของการที่ ทำ data pipeline อะไรพวกนี้เสร็จแล้วเนี่ย ต้องมอง operation ด้วย แล้วก็จะต้องหาวิธีการว่า operation จะเกิด incident เอ้ย โทษที จะเกิดเคสแปลกๆ แบบเนี้ย ได้มากน้อยแค่ไหน อันนี้เป็นแค่เคสหนึ่ง คือ คือ สรุปคือแค่กด จุดเขียวอันเดียว ปปง. ลงเลย ใช่ ปปง. ลงของทุก corporate นะครับ เพราะว่า corporate เนี่ยปกติ 6:00 น. เนี่ยจะต้องได้รีพอร์ตชิ้นนี้ เออ ที่เป็นรีพอร์ตไม่กี่หน้าครับ แต่คือบอก transaction ที่มีความเสี่ยงหรือไม่มีความเสี่ยง โอเค 5 บริษัท 6 บริษัทอะครับ ธนาคารก็แบบ ต้องรับผิดชอบร่วม คือ คือ มันฟังดู critical มากเลยนะ ที่แบบว่า การที่เราทำ data pipeline แค่อันเดียวอะ แต่มันทำให้ไปโยงไปถึงกฎหมาย และฉิบหายได้กันขนาดนั้น ใช่ ถูกต้องเลยฮะ เพราะ คือเท่าที่แก้วฟังก็คือเพราะว่าแบบ เหมือนกับว่า เรา เราเหมือนแบ่งส่วนการทำงานอะ เหมือน data ก็ อ้าว คุณรับผิดชอบ data คุณก็ คุณก็ทำ ใช่ อะไรอย่างเงี้ย โดยที่เราไม่ได้สื่อสาร ผ่านทีมด้วยกันเนาะ ว่าจริงๆ แล้วการที่คุณทำแบบเนี้ย การที่ data อันเนี้ยมันหายไปอะ มันมีผลกระทบ อะไรกับ business หรือ impact อะไร ซึ่งในกรณีเนี้ยมันไปถึงกฎหมาย compliance อะไรอย่างงี้ด้วย

ความสำคัญของ Documentation และ Feedback24:00

เพราะฉะนั้นจริง ๆ อ่ะ แก้ว่าประเด็นมันคือแบบว่าเหมือนเวลา เราคืองาน data แบบว่าทุกคนอาจจะชอบมั้งว่า เอ้ย ทีม data ชื่อคือเอาเป็นว่า ตำแหน่งไหนอ่ะมี data นำหน้าคุณรับผิดชอบอ่ะ อืม แต่ว่าจริง ๆ แล้วอ่ะมันไม่ใช่ มันคือการทำ maintenance operation ระหว่างทีมกันด้วยอย่างงี้ เกี่ยวๆ กันหมด ใช่เลยครับ อืม คือตรงเนี้ยมันจะมีความ บันเทิงตรงที่ว่าส่วนมากอ่ะค่ะ คนที่ขึ้น pipeline อ่ะ ขึ้นจริงนะ แต่อาจจะ ไม่ได้อยู่นานจนถึงมัน run จริง ๆ แล้วมันอาละวาด ในเดือน 3 เดือน 4 หรือ 1 ปีให้หลังก็ว่ากันไป เพราะงั้นคือ อืม มันมีการที่เราขาด feedback long term จากระบบอยู่ ซึ่งเป็นจุดที่สำคัญเพราะว่า ถ้าเราไม่เคยเจอสิ่งเนี้ยแบบย้อนกลับ เราก็จะไม่รู้เลยว่า เราต้องเขียนหรือ plan โครงสร้าง pipeline ยังไงให้มัน plan ความ ship หายที่เกิดขึ้นในอนาคต ซึ่งเป็นปัญหาใหญ่มาก เพราะว่าทุกวันนี้คือ คือเหมือนทำก็ทำไปอ่ะ แล้วคนทำก็ออกไป แล้วคนทำมาต่อก็แบบ ยังไงลึกล่ะ แล้วเรื่องนี้ยังไง doc หรืออะไรทิ้งไว้ พออะไรเงี้ย ก็กลายเป็นว่ามีแต่พระเจ้าที่รู้สินะ เดี๋ยวมันจะเข้าอีก เรื่อง เรื่อง doc นี่มาหลาย session แล้วนะ ตั้งแต่ แต่ session แรกจนถึงตอนนี้ก็คือเขียน doc กันด้วยนะ อะไรอย่างงี้

โอเค คือ คือเท่าที่ฟังมามันแบบว่า ตั้งแต่คำถามแรกจน จนถึงเมื่อกี้อ่ะ มันมีทั้งแบบ หลายจุดมาก ๆ เนาะ แบบของการทำ data pipeline แค่อันเดียว มันมีแบบต้องมีความรู้ infra มีความรู้ architect ต้องคุยข้ามทีม ต้องทำนู่นทำนี่ ปัญหา

Data Engineer ต้องรู้ทุกอย่าง? End-to-End Data Engineer คืออะไร?25:32

มันเยอะขนาดเนี้ย มัน pipeline ทุกจุดเลยอ่ะ มันแตกตรงไหนก็ได้ถูกไหม ใช่ครับ แล้ว คนที่ทำ data engineer มันไม่ได้ต้องรู้ทุกอย่างเลยเหรอ หรือว่าแบบ หรือ หรือมันจะมีคำ ๆ นึงที่แบบชอบโผล่ขึ้นมาก็คือแบบว่า เอ้ย เราต้องเป็น end-to-end data engineer หรือเปล่านะ พี่ตั้วกับ กานต์คิดว่ายังไงบ้างคะ งั้นเดี๋ยวผม ผมขอแชร์ก่อน จากเมื่อครู่อ่ะครับ วิธีการแก้เป็นแบบนี้ ที่สุดต้องเห็น end-to-end จริง ๆ แต่ไม่ใช่ 1 คน อันนี้คือขอร้องเลย ต้องเป็นกลุ่มคน ส่ง ownership ของ system

network หรือจะตีว่าเป็น infra ก็ได้ ที่ดูแลพาร์ทนั้นน่ะครับ ที่เป็น data owner ที่เป็น change committee ที่เป็น data admin data admin เลยนะ หรือ data engineer ก็ได้แล้วแต่ เพื่อมาร่วมกันว่า เออ มีใครจะทำอะไรแล้วไม่บอกกันไหม บอกกันหน่อยสิ ตะโกนมาก็ได้ ไอ้ 4-5 คนเนี้ยมันนั่งด้วยกัน เฮ้ย ๆ เดี๋ยววันนี้คืนนี้ว่าง ๆ shutdown เครื่องอัพเกรดแรมดีกว่า เดี๋ยวมึงคุยกับกูก่อน ได้ยินแว่ว ๆ มันเป็นอย่างงี้จริง ๆ ครับ ดังนั้นคือในลักษณะของการที่จะเป็น data end ที่ ที่ เติบโตขึ้นน่ะ พวกคุณน่ะจะเจ็บปวดอย่างเมื่อครู่ที่ผมเล่านี่แหละ แล้วคุณจะค่อย ๆ เห็น แล้วคุณก็จะเห็นว่า โอเค คุณจะสามารถต้องเห็นภาพรวมก่อน relate ของ impact ว่าแต่ละคนทำงานแล้ว impact อะไร ดังนั้น ถ้าเกิดจะมองว่าอยากมี data engineer ที่ดูแลแบบ end-to-end จริง ๆ อ่ะ คุณเป็นคนที่มองภาพรวมได้ แต่ถ้าเกิดจะ end-to-end แบบ operate หรือใช้งานได้จริงแบบ proper อ่ะ เป็นกลุ่มคนเท่านั้น อันนี้คือตอนแก้ปัญหาครับ ก็เลยนัดคุยกันว่า ทุกคนไม่ว่าจะเกี่ยวข้องกับแคป เอ่อ โทษที change จะเกี่ยวข้องกับ change ใด หรือไม่เกี่ยว ขอให้เข้ามานั่งก่อน อย่างน้อยสัก 1 ปี เพื่อที่จะได้ให้เห็นทุก use case เท่าที่เป็นไปได้ แล้วก็ค่อยๆ จัดเป็นคอมมิตตีแยก ที่อาจจะเป็นลักษณะของ data platform คอมมิตตี ทำ data impact หรืออื่นๆ เพราะว่าไม่อย่างนั้นมันจะเกิดเหตุแบบเมื่อกี้ ทำ change นิดเดียวจริงๆ ครับ อัพเกรด database เวอร์ชั่นนิดเดียว กับเพิ่ม RAM เพิ่ม CPU ใน VMware แต่จริงๆ คือ impact เยอะมาก เพราะไม่มีคนเห็นภาพรวม หรือไม่มีคนเห็น end-to-end

การทำงานเป็นทีมและการแบ่งหน้าที่ความรับผิดชอบ27:47

เป็นการ อ่าค่ะ จริงๆ ตรงนี้มันจะกลับมาที่ว่า โดยธรรมชาติของคนเราเนี่ย ถ้าเราเก่งด้านนึงได้อ่ะ จะเป็นเรื่องดี แล้วถ้าเรา เก่งมากขึ้นกว่านี้ เราคงถนัด 2 อย่างพร้อมกัน แต่ในความเป็นจริงอ่ะค่ะ เรา ไม่สามารถ หรือทำได้ แต่มันจะยากมากในการที่เราจะถือหมวก 2 ใบ แล้วก็นั่ง process มันพร้อมกัน ว่าคือเหมือนอะไรวะ เหมือนคนนึงเป็นคนโจมตี คนนึงเป็นคนตั้งรับอ่ะ มันจะวางเกมยังไงให้มันคาน 2 ฝ่ายกันได้ อย่างๆ ไม่ ไม่บ้งอ่ะ ซึ่งมันยากมากในการที่เราจะสลับหมวกไปมา กลับกัน มันเลยไปที่ว่า ทำไมเราถึงต้องมีคอมมิตตีแต่ละคนแยก คือแต่ละคนอ่ะ ใส่หมวกแยก เค้าอาจจะมีสกิลคล้ายๆ กันก็ได้ แต่ว่า เค้าเลือก ยืนยันตรงว่า โอเค วันนี้ชั้นอยู่ฝั่งแพลตฟอร์ม วันนี้ชั้นอยู่ฝั่งคนใช้งาน วันนี้ ชั้นอยู่ฝั่ง infra สลับหมวกกัน มาช่วยกันคิดว่า พอเราคิดในมุมเนี้ย เราเจออะไรได้บ้าง แล้วเราจะแก้ปัญหากันยังไง ที่สำคัญจริงๆ มากกว่าคือ อ่า การที่เราไม่สามารถเห็น

ทุกอย่างพร้อมกันในขณะเดียวกันได้เนี่ย ไม่ใช่เรื่องผิด แค่ว่าเราควรจะรู้ว่า เราจะหาใครมาเติมเต็มส่วนตรงนี้ ในขณะเดียวกัน ถ้าเรามอง overview อ่ะ มันมองสลับกัน 3-4 อย่าง มันมองได้แหละ แต่ว่า พอเราต้องไปนั่งลงหน้างานทำงานจริงอ่ะ มันยากมากที่จะนึกสภาพนะ วันนึงปุ๊บ มาถึง เขียน infra VPC security แล้วต่อไปปุ๊บ อ่า ขึ้น database ขึ้นแพลตฟอร์ม deploy airflow ขึ้น Kubernetes วันต่อมาปุ๊บ ไปนั่งเขียน pipeline ลง Kubernetes วันต่อมาคือไปนั่ง debug infra กลับมาปุ๊บ debug pipeline ต่ออย่างเงี้ย มันจะสลับไปมาแบบ รถไฟเหาะมาก ซึ่งมันจะเบิร์นก่อน แล้วคนจะทำได้ไม่นานเพราะว่ามันสับเยอะเกิน เพราะงั้นคือ end-to-end ที่ว่าเนี่ย มีอยู่จริงไหม มีอยู่จริงและไม่มีอยู่จริง ในเคสที่ว่า ในบางบริบท มันจะเป็นได้ แต่ไม่ใช่ทุกบริบทที่เราจะ end-to-end ได้ แล้วไม่ เหนื่อยหรือตายไปก่อน ขอเติมว่าสุดท้าย เออใช่ เออ แค่ แค่ฟังเมื่อกี้ก็ เหนื่อยแล้วอ่ะ แค่ฟังนะ ยังไม่ได้ทำนะ แค่ แค่ฟังเมื่อกี้ เพราะว่าที่สุดแล้วเมื่อครู่ที่ทั้งตั๋วแล้วก็การบอกครับ มันจะมีของแลก

งานของพี่จะช้าลงนะ แต่จะไม่เกิดปัญหาปปง ลง พี่เลือกอะไร จริงๆ บาง บางอย่างมันต้องแลกจริงๆ ครับ แน่นอนมีคอมมิตตีมีอะไรพวกเนี้ย มันใช้เวลาในการคุย change บางทีจะผ่านยากขึ้น แปลว่าก่อนที่คุณจะมาเข้าแคปแล้วบังคับทำ change เนี่ย คุณก็ไปคุยกับแต่ละระดับ กับ owner ก่อน มัน มันจะทำให้ งานไม่ได้รกจนเละอ่ะ แต่ว่า โอเค บางที business user อยากเร็วอ่ะเนาะ อยากได้เมื่อวาน เดี๋ยว รู้ พี่อยากได้เมื่อวาน พี่ change date ป่ะล่ะ เออ ก็ทำวันนี้ แต่พี่ทำเป็นเดทพรุ่งนี้ เมื่อวานป่ะล่ะ มันไม่ได้ มันต้องมีการแลก ถ้าขอเสริมว่าจริงๆ อ่ะปัญหาโลกแตกคือ อยากได้ณ ตอนนั้นเมื่อวานไม่ใช่เรื่องผิด แค่ว่า มันต้อง balance กันระหว่าง อ่า บางช่วงคุณไปไวได้ แต่ว่าเราต้องเปิดเวลาให้ทีมมาสะสาง ซากตรงนี้นะ เพราะถ้าเกิดซากมันทับไปเรื่อยๆ อ่ะ กลายเป็นว่า custom pipeline to case ค่ะ อย่างเงี้ยมันจะไม่จบไม่สิ้นเลย เข้าใจละ แปลว่าล่กได้ ล่ก รีบได้ แล้วก็ต้องมี period ให้เขามาทำความสะอาดด้วย คือๆ การล่ก ไม่ใช่เรื่องผิด เพราะบางทีมันจำเป็นต้องล่ก เพื่อให้เห็น use case จริงๆ หน้า งาน แต่ถ้าเกิดว่า มันเป็นอย่างงี้สะสมไปเรื่อยๆ อ่ะ มันจะกลายเป็น อ่า ซากที่มันทับถมแล้วมันจะทำให้เดินคล่องตัวลำบากแล้วกัน เพราะงั้นคือเราควรจัดหาเวลามา เพื่อคลายปมเหล่านี้ให้มันเดินได้อย่าง smooth ที่สุดแล้วกัน มันต้องมีการลงทุนแน่ๆ แต่ว่าอันนี้คือเป็นเรื่องของ อ่า ไว คือเหมือน เหมือนจ่ายมากได้เร็ว แต่ว่า จ่ายช้า แต่ว่าได้นานๆ อย่างงั้นน่ะ อืม โอเค

บทสรุป: สิ่งสำคัญของการเป็น Data Engineer ที่ดี31:15

วิธีแก้คือ ทำใหม่ ไม่ ไม่รู้เรื่องอะไรเลย ทำไม หมายถึงว่าคือกี่ปีนะคะ กี่ปีเสร็จนะคะ โอเค โอเค โอเค ก็เดี๋ยวจะเป็นคำถามสุดท้ายแล้ว เพราะเรา เราก็คุยกันมา เยอะพอสมควรและ ทีนี้ อยากให้กานต์กับพี่ตั้ว เอ่อ สรุปเนี่ย จริงๆ แล้วอ่ะ อะไรที่สำคัญกับการเป็น DE จริงๆ ณ ตอนเนี้ย แบบ ช่วยสรุปเป็น key takeaway สั้นๆ ให้ทุกคนหน่อย เพราะเราคุยกันมาเยอะมากเลย แบบ ไหลๆ ใช่ครับ ถ้าเป็นของผมเมื่อครู่ จากสาย system network security เรียกว่าสาย infra ละกัน แตะ network แตะ security แตะ system เนี่ย มี data อยู่ทั้งสิ้น ไม่ว่าจะเป็น system log หรืออะไรพวกเนี้ย หรือแม้กระทั่งตัว database system ภาพของผมอ่ะ ความหมายคือ ในทุกอาชีพอ่ะครับ ในทุกบทบาทหน้าที่อ่ะ ถ้าเกิดมาปุ๊บ คุณมีพื้นฐาน infra ก็สามารถเข้าใจว่า infra คิดยังไง แล้วไปเติมเต็มความรู้ทาง data ได้ ก็คือไปเติมความรู้ด้าน DE ว่าโอเค pipeline ที่แท้จริงเป็นยังไง หรือถ้าคุณไม่เคยมีพื้นฐาน infra เลย อย่างน้อยต้องเข้าใจว่างานพวกเขาคืออะไร เหมือนกับเข้าใจงานเขาอ่ะ เพราะมันต้องทำงานด้วยกัน เข้าใจภาษาเขาว่าต้องคุยยังไง มาปุ๊บ จะไปดึงข้อมูลพี่ โอเคครับพี่ งั้นคำถามผมง่ายมากเลย อยู่ที่ live พี่ตอนไหนสะดวกบ้าง ผมจะต้องดึง data ประมาณ 1 gigabyte ต่อชั่วโมง อันนี้สมมุตินะครับ หรือ 10 gigabyte ต่อชั่วโมง พี่พอมี room ให้ผมลองดึงมั้ย อ่ะ แล้วน้องดึงเท่าไหร่ เอา 100 กิ๊ก ผมใช้ประมาณเท่านี้ชั่วโมง bandwidth ใช้ประมาณเท่านี้

คำคุยของ data engineer ที่เป็นแบบเนี้ย system และ network จะชอบมากๆ ถัดมาก็บอก permission ผมเนี่ย ไม่ต้องขอเป็นสิทธิ์สูงก่อน ไม่ต้องให้ ขอสิทธิ์นี้เท่านั้น เล็กๆ system เอ้ย security ก็จะชอบและ เพราะไม่งั้นจะคุยยากมากเลย มาปุ๊บ พี่ผมขอดึง data พี่นะ ต้องการตอนนี้ data ใหญ่ๆ แล้วก็ เอ่อ ขอสิทธิ์สูง admin เลย เดี๋ยว ใครจะให้ admin กูยังต้องเบิกเลย อืม อยู่ใน strong room มึงมีมึงก็บ้าแล้ว เออ พี่แต่ผมมีแล้ว โอ้โห เส้นใหญ่ คราวนี้ก็จะไม่มีใครอยากคุยด้วย ดังนั้นคือเราต้อง empathize ที่คนดูแลระบบเนาะ แล้วก็ empathize system ด้วย เห็นใจพวกระบบด้วย ไม่ไหวแล้ว กู run 95% utilized ตลอด พี่ครับ system เขาไปอัพเกรดก่อน เดี๋ยว data pipeline เส้นนี้ยังไม่ทำ พวกเนี้ยจะทำให้คุณเติบโตเป็น data engineer ที่ เห็นภาพรวมได้ แล้วทำให้เกิด end-to-end ได้แท้ แท้จริง เพราะว่าทำกับกลุ่มคนเช่นกันครับ จริงๆ คีย์เวิร์ดคือ เห็นภาพรวมเนาะ จริงๆ ตรงเนี้ยมันยากเหมือนกันเพราะว่า เราก็จะอยู่ตั้งธงจากฝั่งที่เราเห็นและเรารู้จักมา แต่บางทีเนี่ยเราจะต้อง ขยับเอามานิดนึงแล้วก็ถอยไปดูว่า เอ้ย เพื่อนบ้านเราอ่ะทำงานกันยังไงบ้าง สุดท้ายคือมันเลยกลายเป็นที่ว่า คนที่พร้อมทำความเข้าใจ

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

ก็ ก็จริงๆ อ่ะ แบบว่า มันมี มันมี 2 ประเด็นแล้วกันที่แก้ว แก้วจับได้ก็คือ การ การที่เรามองภาพรวมเนาะ คือเราไม่ได้แค่โฟกัส อยู่ที่งาน Data Engineer อย่างเดียว เพราะว่าจริงๆ แล้วงาน Data Engineer มัน มัน มันเกี่ยวข้องกับเพื่อนบ้านกับทีมอื่นด้วยอ่ะ แบบว่า อาจจะ ถ้าจะบอกก็คือตั้งแต่ Infra Network หรือจะเป็น user ที่เป็น DS, DA, MLE ก็ได้ คือเราจริงๆ เราต้องมองเค้าด้วยเนาะ แล้วก็ ไปกราบเขาให้มาช่วยเรา อะไรประมาณ นี้ ด้วยภาษาเขา ใช่ ดู เห็นภาพรวมแล้วก็ คุยกับ คนอื่นๆ ให้มากขึ้น เข้าใจคนอื่นๆ ให้มากขึ้นแล้วกัน อืม ใช่ครับ

ช่วงถาม-ตอบ: เครื่องมือทดสอบ Pipeline และ KPI ของ DE ที่ดี35:52

ก็น่าจะมีเวลาเหลืออยู่สำหรับ เอ่อ Q&A ค่ะ มี

ใครมีคำถามอะไรอยากจะถามพี่ตั้วกับกานต์ไหมคะ อย่าถามว่าไซท์ไหน กูไหว้อ่ะ

แค่นี้ก็แบบ ครับ จ้ะ คำ คำถามก็คือ ถามว่า อยากถามในเรื่องของการ Test pipeline ว่ามี tool อะไรที่จะมาช่วยในการ test pipeline

อ๋อ ใครคือคนที่มาทำการ test pipeline หรือมี tool ไหนที่จะมาช่วยในการ test pipeline บ้างไหม โอเค แยกกันก่อน เรื่องคน คือ สุดท้ายอ่ะ มันจะกลับไปที่ว่า คนที่ทำ feature คือ pipeline อ่ะ ควรจะรู้สิ่งนั้นดีที่สุด เพราะงั้นตามหลักการ เค้าควรจะ design test ของตัวเองด้วยแล้วกัน Test ใช่ แต่ทีเนี้ยเรื่องเครื่องมืออ่ะ ล้านแปด มีตั้งแต่สำเร็จรูป GUI Framework เยอะแยะมากมาย เยอะๆ อืม เพราะงั้นคือ ลองไปดูว่า อ่ะ คือ ขั้นต้นน่ะ อาจจะลองไป explore framework ดูก่อน แล้วดูว่า อะไรที่ตอบโจทย์ของเรา เพราะว่าแต่ละ tool อ่ะ มันจะมี target use case ไม่เหมือนกัน ลองไปดูตรงนี้ก่อน แล้วที่สำคัญตรงนี้คือ อ่า

การเทสต์ Data Pipeline เนี่ยต้องแยกกับ 2 เลเยอร์ ระหว่างการเทสต์ว่าท่อ ทำงานปกติไหม กับการเทสต์กับ Data จริง อืม เพราะว่า งาน Data Pipeline เนี่ยมันจะมีเรื่องของ character data ด้วยที่ มันมีผลกับการเทสต์ เพราะฉะนั้นคือไปเทสต์ 2 อย่างนี้แยก เพราะว่าถ้าเกิดว่าเราเทสต์กับ Data จริงทุกครั้งใน CI อะไรเงี้ย คือ รอกัน 3 ชาติไม่จบหรอก แล้วมันจะเปลืองตังค์ด้วย เพราะฉะนั้นคือ ไปทำเทสต์เป็น 2 ชั้น คือ เทสต์ท่อปกติ แล้วก็เป็นเทสต์กับ Data จริง อันเนี้ย ดันจริงๆ เพราะว่าค่อยตกลงกันอีกทีนึง ขอบคุณมาก ขอเติมตรงนี้ มันเหมือนที่เราจะเทสต์ใน Unit Test ก่อน Data Pipeline ตอนเราเทสต์อาจจะทีละท่อน แต่พอเต็มลูปเนี่ย เราอาจจะเทสต์แบบ Data ที่มีก่อน เทสต์ Data จริงอ่ะ ให้ทำ ให้ทำตอน Deploy นั่นแหละ แล้วตกลงกันเลยว่าพี่ เดี๋ยวเรามีการเทสต์

Fail Case แล้วนะ ว่าสามารถ Rerun ได้หรือ Restore ได้ แล้วก็คือจะได้ไปเทสต์ Data จริง เพราะจะได้เห็นของจริงด้วย ครับ

ขอบคุณมากครับ สำหรับคำถาม มีคำถามอื่นๆ เพิ่มเติมไหมคะ เดี๋ยว เดี๋ยวแก้วทวนคำถามนิดนึงนะคะ ก็คือ เอ่อ คนถามเนี่ย บอกว่า เท่าที่เคยเจอมาเนี่ย การเป็น DE อ่ะ ส่วนใหญ่จะเป็น DE โดยอุบัติเหตุ accidentally become DE ก็แบบว่า เหมือน เหมือนแบบว่าไม่มีใครที่จะพร้อมอ่ะเป็น DE เขาก็เลยต้องจับ ตำแหน่งข้างเคียง เช่น อย่างนี้ก็คือ Software Engineer มาทำ DE เนาะ คำถามก็คือ ในมุมของพี่ตั้วอ่ะ แบบ การ การเป็น DE ที่ดีอ่ะ เอ่อ มัน มันอยู่ มัน เราจะวัดยังไงนะ หรือมี KPI อันไหนไหมที่จะบอกได้ว่า เอ้ย คนเนี้ย คือ DE ที่ดีแล้ว งั้นขอ พูดแค่พาร์ทเดียวก่อน เพราะจริงๆ DE มีหลาย หลายนิยามมาก แล้วเดี๋ยวค่อยไปที่ Networking กัน ขอ Section Networking นะ DE ที่ดีเนี่ย ในมุมตั้วเนี่ย ขอให้มีอยู่ 3 เรื่อง เป็นหัวใจสำคัญเลย จริงๆ Software Engineer หรืออะไรพวกเนี้ย 3 เรื่องเนี้ย สามารถ apply ได้ อันที่ 1 คือ มองความเสี่ยงไปข้างหน้าเท่าที่ประสบการณ์เรามีอ่ะ ให้ไกลที่สุด แต่ตอนนั้นผมมองไม่เห็นไอ้ 10 เดือนข้างหน้า แต่คือ นั่นแหละ ด้วยความประมาทด้วย เพื่อที่จะ ไปอันที่ 2 คือ รับ feedback ได้ทันที ด่าได้พี่ ว่าได้เลย แต่ขอ solution กันด้วย discuss กัน ว่าแก้ยังไง

อันที่ 3 มองภาพรวมได้มากขึ้นเรื่อยๆ เมื่อกี้คืออันแรกคือมองไปข้างหน้าเพื่อเห็นความเสี่ยง ได้มากขึ้น อันที่ 3 จะทำให้คุณมองเห็นภาพรวมได้มากขึ้นเรื่อยๆ 3 อย่างเนี้ย พื้นฐานคือ communication และความเข้าใจคนทีี่อยู่แวดล้อม ในสิ่งที่เราจะไปแตะนี่แหละ Surprise manager หรือ Surprise DE อ่ะ โดยอุบัติเหตุเนี่ย ปกติ 3 เรื่องเนี้ย เราไม่เคยมีประสบการณ์ใน DE อยู่แล้ว ความที่จะเป็น DE ที่ดีในพาร์ทที่ 1 เนี่ย จะเป็น จะเรียกว่าจะไม่มีทางวัดผลได้ แต่ถ้าเกิดคุณมีการสื่อสารได้ รับ feedback ได้ เห็นความเสี่ยงเผื่อเพื่อนได้เนี่ย นี่คือพื้นฐาน DE ที่ดีที่สุดเท่าที่ผมเห็นเลย เพราะมันจะทำให้ ทุกสายอาชีพเลยนะครับ System Network อะไรพวกเนี้ย หรือ DE เนี่ย ถ้ามีพื้นฐานเนี้ย ผมคิดว่าเป็น DE ที่ดีแล้ว เพราะมันจะเติบโตไปในสาย DE ที่โตขึ้นได้ แล้วก็จะสามารถ

คุยจน user เนี่ย ปรับพฤติกรรม ทำให้ Data ขาเข้าเนี่ย เป็นไปตามที่เราอยากได้ได้ เพราะบางทีคือ user เองไม่กล้าปรับพฤติกรรมตัวเอง เพราะเขา เขาก็เหนื่อยมากแล้ว แต่พอเราเข้าใจจนแบบ โห พี่ ถ้าทำแค่นี้พี่จบเลย เค้าจะสบายขึ้นด้วยซ้ำ นี่คือ DE ที่ดี ใน ในพาร์ทที่ 2 เพราะว่าเราไปแตะขาเข้าใช่มั้ยฮะ เราไปแนะนำจนขาเข้าเค้าทำงานได้ลีนขึ้น หรือแม้กระทั่งตัว database system ก็ได้ บอกพี่เราไม่แตะ master ตอนนี้เป็นคลาวด์ หรือไม่คลาวด์ก็ได้ ทำ replica ให้หน่อย หรือเอามาวางให้หน่อย อะไรประมาณนี้ DE ที่ดีก็คือ มีความเห็น เห็น เห็นภาพรวม แล้ว feedback ได้

ตรงนี้เป็นพาร์ทที่ 1 ที่ ถือว่า เติบโตแน่นอนครับ ขอบคุณมากครับ

สรุปและปิดท้าย41:02

โอเคค่ะ ก็ ขอบคุณสำหรับคำถามนะคะ แล้วก็หมดเวลาแล้วด้วย ก็ เอ่อ session นี้ขอขอบคุณพี่ตั้วกับกานต์มากนะคะ ที่มา discuss กันอย่างเมามัน แล้วก็แชร์ความรู้ให้กับทุกคน ก็สามารถเจอกับ พี่ตั้วกับกานต์ได้ต่อใน networking นะคะ ถ้าเกิดว่าใครมีคำถามอะไรที่สงสัย ถ้าอยากจะถามต่อเนี่ย ก็ เจอกันตอน networking ได้ค่ะ ขอบคุณมากครับ ขอบคุณค่ะ