🎞️ Videos → Demystifying Data Catalog

แนะนำตัวและที่มาของหัวข้อ Data Catalog0:00

ก็ครับ เอ่อ ผมแมนนะครับ ชื่อ Yothin Muangsommuk ครับ มาจาก LINE Thailand ครับ เป็น Data Engineer ต๊อกต๋อยอยู่ในบริษัทนั้นครับผม

ต้องบอกว่าตอนที่-- ตอนที่เป็นหัวข้อนี้เนี่ย ตอนก่อนจะเริ่มมาเป็นหัวข้อนี้ ตอนนั้นเนี่ยตอนคุยกับ คุณแก้วคุณกานต์เนาะ แล้วก็รู้สึกว่า เฮ้ย มันมีคอมโพเนนต์ตัวหนึ่งเว้ยที่ในเวลาเราทำ Data Platform เนี่ย คนไม่ค่อยพูดถึง อย่างน้อยก็ในคอนเท็กซ์ใน ในประเทศเราเนาะ คนไม่ค่อยพูดถึงแล้วรู้สึกว่า เฮ้ย มันก็สำคัญนะ เออ แต่คนกลับไปโฟกัสอีกจุดหนึ่ง จุดอื่นไรเงี้ย เดี๋ยวค่อยว่ากันในทอล์คครับ ก็เลยวันนี้คิดว่า เราจะมาทำให้ดูว่าไอ้ตัว Data Catalog เนี่ย จริงๆ แล้วเนี่ยมัน มันสำคัญยังไง แล้วก็ข้างในมันทำงานยังไงบ้างครับคร่าวๆ ครับ

Data Catalog คืออะไร? ทำไมถึงสำคัญ?0:52

คร่าวๆ วันนี้ก็จะมีอยู่ 4 section หลักๆ

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

จุดเริ่มต้นของ Catalog: จากห้องสมุดสู่ Data Warehouse1:33

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

ในนี้ทุกคนน่าจะรู้จักสิ่งที่เรียกว่าห้องสมุดเนาะ อ่านี่เป็นสิ่งที่ทุกคนคุ้นเคยกันใน ใน physical world ครับ ซึ่งห้องสมุดก็มีอะไร มี Data Data คืออะไร หนังสือถูกป่ะ อยู่ตามชั้นอยู่ตามอะไร ทีเนี้ยเราก็จะเกิดคำถามว่า โอเค ถ้าเราอยากจะไปหาหนังสือสักเล่มนึง สมมุติไปหา อ่า อะไรนะ Designing Data-Intensive Application ที่พี่กานต์พูดตะกี้ เราจะไปหาที่ชั้นไหนยังไงครับ ถ้าใครอายุเยอะหน่อย

อาจจะคุ้นเคยกับสิ่งนี้ อันนี้ อันนี้ขอเช็กคร่าวๆ มีใครไม่เคยเห็นสิ่งนี้ไหมครับ โอเค แปลว่าเราอาจจะอยู่กันคนละยุคกันจริงจริง (หัวเราะ) ครับ สิ่งนี้มันเป็นเหมือน Index Card Catalog ในห้องสมุดเนาะ คือก่อนที่มันจะเริ่มมีระบบคอมพิวเตอร์เข้ามาในชีวิตประจำวันของเราเยอะๆ เนี่ย การหาหนังสืออยู่ในห้องสมุดเนี่ย การที่เราจะเดินหาตามชั้น— สมมุติห้องสมุดมันใหญ่มากแล้วมันก็ใช้เวลาเยอะนะครับ มันก็เลยจะถูกย่อตัว Index Card ตัวนี้อยู่ที่มุมมุมหนึ่งในห้องสมุด อาจจะเป็นตู้ที่มันมีชั้น Stack อะไรอย่างเงี้ย แล้วก็จะมีตัวอักษรบอกว่าโอเคอะไรอยู่ตรงไหนนะครับซึ่งในตัว Index Card เนี่ยมันจะมี มันจะมีดีเทลคร่าวๆ ก็คือแบบว่า เฮ้ย มันเป็นหนังสืออะไร ใครเขียนนะ

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

อ่า ตัวนี้ซึ่งถามว่า พอเรามาดูอย่างงี้เนี่ยมันช่วยอะไร ถ้าเรามองแบบฟิสิคอลเนาะ มันช่วยให้เราประหยัดเวลาแทนที่เราจะต้องไปเดินหาแบบตามชั้น เฮ้ยชั้นนี้อยู่ที่ไหน หมวดไอทีอยู่ตรงไหน หมวด Data Engineering อยู่ตรงไหนเนี่ย เรามาดูตรงนี้ก่อน เราก็รู้ชั้น เราจะรู้ เราจะรู้มุม เราจะรู้ชั้น แล้วเราก็จะไปหยิบได้ถูกเล่ม อ่านี่คือ physical world ที่เราคุ้นเคยกันเนาะ

ยุค Cloud และปัญหาของ Data Lake/Swamp3:32

ทีนี้กลับมาที่ตัวงาน Data ของเราเนี่ย ในยุคแรกๆ เนี่ยตัวระบบ Data มันยังไม่ซับซ้อนครับ จริงๆ มันก็ซับซ้อนแหละ แต่ว่า สิ่งที่มันอยู่มันอยู่ในสิ่งที่เรียกว่า Data Warehouse เนาะ อ่าซึ่งแต่ก่อนมันก็จะเป็นซอฟต์แวร์ก้อนเดียว อ่าอาจจะสมมติว่ามันเป็นตัว RDBMS สักตัวหนึ่งที่มันใหญ่มากๆ นะครับ ซึ่งเราก็จะคุ้นเคยกับหน้าตัวหน้าการ Query เนาะ แล้วเราก็จะคุ้นเคยกับอินเตอร์เฟสว่าเอ้ยเราใช้ SQL ในการ Query ตัว Data ที่เรามีอยู่เนี่ยขึ้นมาได้ในตัว Data ที่เราจัดการอยู่นะครับ ซึ่งตัวคอมโพเนนต์ตัวนี้หรือ Data Warehouse ตัวนี้เนี่ย ความสะดวกสบายของมันน่ะก็คือเรารู้แค่ SQL

เรารู้ว่า Data เราอยู่ที่ไหน เราสามารถ Select จากตัวจุดที่เรารู้ได้เลย เราไม่จำเป็นต้องจำว่าเอ้ยอะไรมันอยู่ตรงไหนเนาะ เบื้องหลังจริงๆ ของ Warehouse เนี่ย ถ้าเราไปดู Architecture ของตัว RDBMS เนี่ย มันจะประกอบด้วยคอมโพเนนต์ยุบยับเนาะแต่จะมีคอมโพเนนต์ตัวนึงชื่อว่า Catalog Manager นะครับ หรืออีกชื่อหนึ่งถ้าจะไปดูตัว Architecture ของตัว Database System เราเรียกว่า Data Dictionary นะครับ ตัวนี้จะเป็นตัว Map ว่าตัวเนื้อไฟล์จริงๆ อ่ะ อ่าตัวนั้นน่ะมันมี Structure ของ Data เป็นยังไง ตัว Database ชื่ออะไร แล้วก็แต่ละคอลัมน์อ่ะมันเป็น Type ไหนอะไรอย่างเงี้ย จะถูก Define ไว้ในสิ่งที่เรียกว่า Data Dictionary ซึ่งอยู่ในสิ่งที่เรียกว่า Catalog Manager เนาะ อ่าอันนี้คือยุคที่เป็นตัว อ่า

ผมเรียกว่า Monolithic Data Warehouse ก็คือยังเป็นก้อนใหญ่ๆ ก้อนนึงอยู่ ทีนี้เนี่ยอย่างที่ทุกคนรู้กันอาจจะสักประมาณ— ตอนนี้ปี 2025 ใช่ไหม

ย้อนกลับไปประมาณปี 2010 เราเริ่มมีปัญหาการ Scaling อ่าเราเริ่มมีปัญหาการ Scaling ว่าโอเค ไอ้ก้อนใหญ่ๆ ก้อนนี้มันเริ่มเอาไม่อยู่แล้ว เพราะ Data ในยุคที่มันเป็นเว็บเนี่ย มันไหลมาเยอะมาก ไม่ว่าจะเป็นสมมติทำระบบบริษัทเอ็นเตอร์ไพรส์ใหญ่ๆ อย่างเงี้ย ทำระบบเซลล์ ทำหน้าเว็บขายของ ทำนู่นทำนี่ เราจะเริ่มมี Data ไหลเข้ามาในระบบเยอะๆ นะครับ ซึ่งตัว Monolithic Data Warehouse ก้อนโตๆ เนี่ย ไม่ว่าจะขยาย CPU ขยาย RAM ขยายฮาร์ดดิสก์ยังไงเนี่ย การที่มันระบบเป็นก้อนก้อนเดียวเนี่ย มันก็เริ่มเอาไม่อยู่แล้ว เพราะฉะนั้นมันเลยเกิดสิ่งที่ทุกคนอาจจะเริ่มคุ้นเคยกันดีในยุคนี้นะครับ ก็คือ Cloud

อ่า เริ่มมีการสเกลเป็น Distributed เป็น Cloud อย่างเงี้ย แล้วเกิดสิ่งที่เรียกว่า Cloud Data Platform ขึ้นนะครับ ซึ่งพอเรามองย้อนไปเนี่ย

เอ่อ ตะกี้เราคุ้นเคยกับ Structure ของตัว Data Warehouse เนาะ คนที่ทำงานกับ Data ก็เลยเริ่มคิด Structure ว่าเอ้ย เราจะทำยังไงดีนะที่เราจะทำการประมวลผล Data อยู่บน Cloud โดยใช้คอมโพเนนต์ที่มันทำให้เราใกล้เคียงกับสิ่งที่เราเคยทำได้มากที่สุดครับ มันก็เลยเกิดเป็น Building Block ตัวนี้ครับ ขึ้นมาเป็นตัว Cloud Data Platform อ่า ซึ่งสมมุติถ้าเราคิดถึงการที่เราจะทำงานกับ Data อย่างเงี้ย ในใจเราจะเริ่มคิดแล้ว เฮ้ย มันต้อง มันต้องมีคอมโพเนนต์อะไรบ้างนะ เอ่อ หลักๆ เนี่ย โดยส่วนใหญ่จากที่ประสบการณ์คุยกับหลายคนมา หรืออ่านในคอมมูนิตี้มาเนี่ย คนจะเริ่มโฟกัสกับ 2 อย่าง 2 อย่างแรกสุดเลยนะครับ ซึ่งจริงๆ มันก็สำคัญนะ เออ ก็คือเราโฟกัสกับตัวคอมพิวท์ อ่า ซึ่งคือ CPU กับ RAM เนาะ รีซอร์สต่างๆ ที่เราต้องใช้ในการประมวลผล อีกส่วนหนึ่งที่เราจะคิดก็คือตัว Storage อ่า เราจะคิดถึง 2 คอมโพเนนต์นี้ก่อนเสมอเลย ซึ่ง ซึ่งมันก็ไม่ผิดเนาะ แต่ว่าอีกจุดหนึ่งที่สำคัญก็คือ แล้วเราจะใช้ Data ตัวนั้นยังไง อ่า มันจะเกิดคำถามว่าเรามี CPU-- เรามีคอมพิวเตอร์เครื่องหนึ่งอ่ะ เอาไว้ประมวลผลแล้วอ่ะ แต่พอประมวลผลเสร็จแล้วอ่ะ เราจะเอาตัวประมวลผลตัวเนี้ยให้คนอื่นใช้ยังไงนะครับ ซึ่งอันนี้เป็นจุดที่ ที่ค่อนข้างจะสำคัญในจุดนี้ อ่า

โลกที่ไม่มี Data Catalog และการเกิดขึ้นของ Data Swamp7:06

แต่ก่อนอื่น ก่อนในยุคที่เป็น Cloud เนี่ย ก่อนที่จะไปถึงยุคที่มันมีแค็ตตาล็อกเนี่ย

อยากจะให้เห็นโลกก่อนว่าโลกที่มันไม่มีแค็ตตาล็อกเนี่ย หน้าตามันเป็นยังไง อ่า ทุกคนอาจจะรู้จักเทอมๆ นี้ อ่า ในยุคนี้น่าจะเป็น Common Word แล้วก็คือสิ่งที่เรียกว่า Data Lake เนาะ อ่า อย่างที่ อย่างที่เกริ่นไปตะกี้ก็คือในยุค Cloud เนี่ย เรามี Data เยอะมากเนาะ มันจะถูกฟีดดิ้งเข้ามาผ่านการ Inject เข้ามา ผ่านการซิงค์ Integrate เข้ามาเยอะมากอยู่ในสิ่งที่เรียกว่า Data Lake เสร็จแล้วเนี่ย Data มันกองอยู่ตรงเนี้ยเยอะมาก แล้วเราจะต้องใช้มัน อ่ะ ทีนี้เนี่ย การที่เราไม่มีวิธีการการจัดการมัน สมมุติเราเอามากองกันแล้ว เออ ทุกระบบ เดฟ รีพอร์ต อนาลิสต์อะไรอย่างเงี้ย เอามากองไว้ตรงนี้ ถ้าไม่มีการจัดการให้มันดีๆ สิ่งที่เกิดขึ้นก็คือ แทนที่เราจะได้วาดฝันว่า โอ้ เรามี Data เยอะมาก แล้วเราจะมี Data Warehouse ที่เราสามารถคิวรี่ แบบที่เราเคยทำได้ในสมัยที่เรามี Data Warehouse เป็นก้อนๆ เนี่ย มันจะเกิดการกรอง Data ออกมาเยอะ เป็น เขาเรียกว่าอะไร Garbage in ครับ ซึ่งเราก็จะเกิดคำถามว่า เอ๊ะ แล้วเราจะใช้ Data ตัวนี้ยังไงเนาะ เออ ซึ่งสถานะเนี้ย ในการที่เรามี Data Lake แล้วเราใช้งานมันไม่ได้อ่ะ สิ่งเนี้ยในทางเทคนิคเราเรียกว่า Data Swamp ครับ Data Swamp เนี่ย มันเป็นสเตจของตัว Data Lake ที่ เราเอาข้อมูลไปใช้ไม่ค่อยได้อ่ะ หรือใช้ยากอะไรอย่างเงี้ย เราไม่รู้ว่าเราจะหาข้อมูลตัวนั้นยังไงอ่ะ ยกตัวอย่างเช่น เฮ้ย ถ้าสมมติเราอยากได้ Log สมมติมี Traffic งานเข้า เราทำเว็บอีคอมเมิร์ซเนาะ สมมติ แล้วเราอยากรู้ว่า เฮ้ย มีคนเข้าเว็บไซต์เราเท่าไหร่ วันนี้เดือนนี้มียอดขายเท่าไหร่ เดือนนี้

จริงๆ เดฟก็เอา Data มากรองให้ Data Lake แล้วนะ แต่ว่า เราไม่มีวิธีการจัดการมัน เราก็จะไม่รู้จะใช้งาน Data ตัวนั้นยังไงอ่ะ เออ Data อยู่ตรงนั้นแหละ แต่เรายังไม่ได้ทำเอามาพาสเอามาทำนู่นนั่นนี่ในการจัดการให้มันเป็นระบบนะครับ ซึ่งอันเนี้ยเป็น sign ที่สำคัญมาก ในการที่สมมติถ้าเราอยู่ในยุค Cloud เนี่ย จะให้มองไว้ เพราะว่ามันจะช่วยป้องกันปัญหาที่ก่อนที่มันจะเริ่มโต เราสามารถหยุดมันได้ อ่านะครับ ซึ่ง

Data Swamp เนี่ย เป็นสเตจที่ทุกคนก็ไม่อยากเจอเนาะ อ่า เพราะฉะนั้นมันก็เลยเกิดคอมโพเนนต์ขึ้นมาในยุคคลาวเหมือนกันอีกตัว ซึ่งก็คือสิ่งที่เราจะคุยกันวันนี้ก็คือ Data Lake เอ้ย Data Catalog ครับผม อ่า ในการจัดการว่าเราจะใช้ข้อมูลแต่ข้อมูลยังไง

ประเภทของ Data Catalog: Technical vs. Federated9:25

ทีนี้เนี่ย ผมพูดเร็วไปไหมนะ ไม่เร็วนะ โอเคครับ ทีนี้เนี่ย

ก่อนที่จะไปคุยกันเรื่อง Data Catalog ต่อเนี่ย อยากให้รู้จักกับประเภทของ Data Catalog ก่อนนะครับ โอเค คือถ้าเราเอาคำว่า Data Catalog ไปเสิร์ชใน Google

ตอนนี้ในปี 2024 ตอนนี้ปี 2025 เนาะ เราจะเจอว่า โอ้โห มันมี มันมี Tooling หลายชื่อ หลายตัวอยู่ในสารสนเทศในการทำตัว Cloud Data Platform เยอะมาก

เยอะไปหมด เยอะจนเรารู้สึกว่า เฮ้ย เราจะใช้ตัวไหนดีวะ เออ ซึ่งตัว Data Catalog เนี่ย ถ้าเรามามองประเภทมันจริงๆ มันสามารถแบ่งกลุ่มได้เป็น 2 ประเภทใหญ่ๆ นะครับ ก่อนอื่น ไอ้คำ Catalog อันที่ผมเล่าไปแล้วเนาะ ก็คือมันเป็นคำที่โหลมากครับ เราพูดกับบุคคลที่ 1 บุคคลที่ 2 บุคคลที่ 3 ทุกคนอาจจะเข้าใจว่า Catalog ไม่เหมือนกันเลยก็ได้ อ่า เพราะฉะนั้นนั่นคือสาเหตุว่าทำไมเราต้องมาคุยกันว่ามันมีประเภทอะไรบ้างนะครับ ประเภทแรกเราเรียกว่า Technical Catalog นะครับ Technical Catalog เนี่ย หน้าที่หลักของมันก็คือทำการ Track ตัว Table Metadata นะครับว่า Table เรามีหน้าตาเป็นยังไง เอ่อ มีสกีม่าเป็นยังไง มี Database อะไรบ้าง แล้วมันจัด Hierarchy กันยังไง อยู่ตรงโลเคชั่นไหนนะครับ ซึ่งหัวใจสำคัญมันก็คือเป็นตัว Source of Truth ของตัวเนื้อ Data ของเรา ว่ามันอยู่ที่ไหนนะ อ่านะครับ ตัวนี้เป็นตัวแรก

ซึ่ง ถ้าจากดูรูปใหญ่ตะกี้เนาะ มันสามารถแบ่งมาอยู่ในนี้ได้อีกหลายตัวมาก อีกกลุ่มนึงซึ่ง ผมว่าถ้าเราเสิร์ชด้วยคำว่า Data Catalog เราจะเจอสิ่งนี้มากกว่า สิ่งนั้นเราเรียกว่า Federated Catalog นะครับ Federated Catalog เนี่ย หรือในอีกชื่อนึงอาจจะเป็นชื่อ Business Catalog แต่ผมไม่ค่อยอยากเรียกว่า Business Catalog เนาะ Federated คืออะไร? Federated คือการที่เอามารวมรวมกันจากหลายๆ แหล่งนะครับ ตัว Federated Catalog เนี่ยจะทำการ Track ในเลเวลที่ Business มอง อ่า ตัว Technical Catalog อะ เราจะมองในมุมของของเครื่องมือเนาะ มองมุม Engineer ว่าเออเครื่องมือมันเชื่อมถึงกันยังไง แต่มุม Federated Catalog เนี่ย เราจะมองในมุมของ Business ว่าโอเคตัวฝั่ง Business เนี่ยเราจะมอง Data อะไร เราจะมองหาอะไร ซึ่งมันจะประกอบด้วยตัวความสามารถ Capability เนี่ย ในมุมอีกมุมหนึ่ง เช่น ตัว Data Governance ในการจัดการ Access Control หรือว่าตัว Document และการสืบค้นเพื่อให้มันง่ายขึ้นนะครับ อ่า ซึ่งต้องบอกว่าวันนี้เนี่ย

ด้วยความที่เรื่อง Data Catalog มันใหญ่มากเนาะ วันนี้เราจะโฟกัสที่ Technical Catalog

การทำงานของ Data Catalog: Hive Metastore12:04

นะครับ ด้วยเวลาที่เรามีจำกัดอีก 18 นาที อ่ะ ทีนี้เนี่ยถ้ามาดูว่าตัว Catalog

เนี่ยมันทำงานยังไง อ่ะ อ่า ตะกี้เราเห็นก้อนคอมโพเนนต์เล็กๆ ตะกี้เนาะ ในภาพของตัว Data Platform ต้องย้อนกลับไปเลยว่า จุดเริ่มต้นมันน่ะ ในยุคที่มันเริ่มออกมาเป็นตัว Distributed เนี่ย อ่า มันเกิดสิ่งที่เรียกว่า Hive Metastore ขึ้นนะครับ Hive Metastore เกิดขึ้นตอนไหน ต้องบอกว่าในยุคนี้มีใคร เอ่อ ไม่รู้จัก Hadoop ไหมครับ

ติ๊กต็อก ติ๊กต็อก แปลว่ารู้จักกันทุกคน อ่านะครับ Hadoop เนี่ยมันเกิดมาตอนประมาณช่วงปี 2010 กว่าๆ เนาะ เออมันเกิดปัญหาว่าตอนนั้นคำคำที่บูมมากก็คือคำว่า Big Data ตอนนั้นเนี่ยมันเกิดปัญหาว่าโอเคคอมพิวเตอร์เครื่องนึง— ไอ้ที่เราเกริ่นกันก่อนหน้านี้ว่า Data Warehouse ก้อนก้อนหนึ่งมันเริ่มมันเริ่มไม่ไหวละ แล้วคอมพิวเตอร์มันแพงมาก ตัว CPU อะไรมันแพงมากในการที่จะสเกลขึ้นมาเป็นระบบระบบหนึ่ง ก็เลยเกิดเฟรมเวิร์คขึ้นมาครอบคลุมก็คือตัว Hadoop เนาะ ซึ่งมันทำให้เราใช้คอมพิวเตอร์เครื่องถูกๆ เนี่ยในการกระจายโหลดของการประมวลผลเนี่ยไปอยู่หลายๆ ตัวได้นะครับ ตัว Hadoop เนี่ยมันจะมี Stack คร่าวๆ ก็คือ มันจะมีตัว HDFS อยู่ข้างล่างเนาะ อันนี้ไม่แน่ใจเห็นเมาส์ผมไหม ก็คือมี HDFS เป็นตัว เป็นตัวสตอเรจเนาะ ถ้าเราเทียบกับภาพคลาวด์ตะกี้ แล้วก็มีตัว Yarn เป็นตัวจัดการรีซอร์ส แล้วก็จะมีตัว MapReduce ที่เป็นเฟรมเวิร์คเนี่ย ไว้คอยเขียนโปรแกรมในการเอาไปประมวลผลบน Hadoop นะครับ ทีเนี้ยในยุคแรกๆ ของ Hadoop เนี่ย มันเกิดปัญหาว่า ตัว MapReduce API ของมันเนี่ยมันเขียนยาก

เพราะว่าคนที่จะเขียนโปรแกรมกับ Hadoop ได้ถามว่าต้องเขียนยังไง ก็เขียนภาษา Java แล้วถามว่าคน Dev ที่เป็นอะไรนะ อะนาไลสต์ สมมติเราจะเขียน Java อย่างเงี้ย ในการเอาไปข้อมูลไปวิเคราะห์ เขียนเป็นโปรแกรม Java แล้วก็รู้สึกว่าโอ้โห ตอนแรกแม่งอยู่ใน Data Warehouse เขียน SQL กันสวยงาม มันต้องไปเขียน Java มานั่งทำโปรแกรม MapReduce อะไรอย่างเงี้ย มันเริ่มมีความเป็น software engineering จัดๆ ละ มันก็เริ่มไม่สะดวกนะครับ

ข้อจำกัดของ Hive Metastore และการกำเนิดของ Hive14:05

ในช่วงถัดมาเนี่ยฝั่ง Facebook ก็เลยบอกว่าโอเคมันเริ่มลำบากไปละ เราก็เลยสร้าง Hive ขึ้นมาครอบตัว MapReduce Framework ตัวนี้อีกทีนึง ซึ่งตัว Hive เนี่ยจะเป็นทำตัวเป็น Data Warehouse ที่อยู่บน Distributed Framework ซึ่งก็คือ Hadoop เนาะ ในการทำให้เราสามารถคิวรี่โดยใช้ท่าแบบทำเป็น SQL ที่เราเคยทำได้อยู่บน Hadoop

ถามว่าข้อดีคืออะไร ข้อดีคือเราได้พลังการประมวลผล ในระดับ Data ที่ใหญ่มากในระดับ Hadoop แต่เราก็ยังมีอินเทอร์เฟซที่เราใช้งานง่ายที่เป็น SQL อินเทอร์เฟซ ในการทำงานกับ Data นะครับ ซึ่งถ้าเราไปดูอาร์คิเทคเจอร์ของ Hive เนี่ย ถ้าคุณดูภาพตัว Data Warehouse ตะกี้เนาะ จะเห็นว่ามันแยกส่วนของของตัวที่เป็นรีซอร์ส อ่า ดิสก์กับตัวคอมพิวออกจากกันนะครับ แต่ว่าอันนี้อาจจะไม่ต้องลงดีเทลมาก แต่ว่าสิ่งที่อยากจะให้เห็นก็คือเราจะรู้ได้ไงว่า ตัว Data ตัวนั้นมันอยู่ที่ไหนนะครับ มันก็เลยมีคอมโพเนนต์คอมโพเนนต์หนึ่งซึ่งมันมีลูกศรชี้เข้าชี้ออกเยอะมาก สิ่งนั้นคือ Metastore ตัวนี้ วงกลมสีน้ำเงิน ตัวนี้เป็นคอมโพเนนต์ที่เกิดขึ้นมาในยุคนั้นนะครับ ซึ่ง ตัว Metastore เนี่ยทำหน้าที่หลักๆ เนี่ยก็คือจัดการตัว Abstraction อย่างที่ผมบอกก็คือแทนที่เราจะมานั่งนั่งเปิดไฟล์อ่านทำเขียนโปรแกรมกับตัว Hadoop อินเทอร์เฟซ HDFS อย่างเงี้ย สิ่งที่เราทำก็คือตัวเนี้ยมันจะจัดการสร้าง Abstraction ครอบความเป็น Table ใน MySQL อะไรอย่างเงี้ยขึ้นมาให้ เพื่อให้เราสามารถคิวรี่ได้ แล้วก็จัดการในการทำตัว Data Discovery ในการหาว่าเฮ้ยตัว Data เนี้ยมีอะไรบ้าง จัดเป็น Catalog เป็น Collection ไว้เพื่อให้เราสามารถสืบค้นได้นะครับ ตัวเนี้ย คือความสามารถของมันนะครับ ซึ่ง

ถ้าไปมองใน Stack ย้อนกลับมาเนาะ ใน Stack ใหญ่ๆ เนี่ย ตัวเนี้ย core จริงๆ มันมีแค่นั้นเลย ก็คือทำหน้าที่ในการเก็บว่าอะไรมันอยู่ตรงไหน แล้วจะเข้าถึงได้ยังไงนะครับ เสร็จแล้วเนี่ยพอมันโฟกัสมากๆ เนี่ย มันก็มีคนมาเชื่อมกับมันอยู่ใน ใน Stack รอบตัวมัน ยกตัวอย่างเช่น ตัว compute engine อย่างเช่น Spark หรือ Hive อะไรอย่างเงี้ย ซึ่งถ้าใครใช้ Spark ยุคนี้เนาะ ก็จะมีบางคนแบบว่า เฮ้ย ทำไมจะต้องเซ็ตตัว Hive Metastore อีกนะ เราไม่ได้ใช้ Hive นะ เพราะว่า Spark เนี่ยมันไม่รู้ว่าอะไรมันอยู่ตรงไหน อะ มันต้องมีคนคอยบอกว่าอะไรมันอยู่ตรงไหน ซึ่งก็คือตัว Hive Metastore หรือว่าตัว Presto เนี่ย ถ้าสมมติไปเก็บของไว้เนี่ย บางทีมันก็ไม่รู้ ก็ต้องพึ่งตัว Hive Metastore ในการแบบว่าบอกว่า เฮ้ย อะไรมันอยู่ตรงไหนนะครับ อะ

แต่ว่ามันก็ไม่ได้คิดแค่นั้นอย่างเดียว อย่างเช่น ความสามารถในการจัดการ access control อย่างเงี้ย เอ่อ ตัว Hive มันก็มีระดับนึง แต่ว่าคนที่จัดการจริงๆ ก็ extend อ่านความรู้ที่ได้จากตรง Hive Metastore เนี่ยไปอยู่ในฝั่ง Apache Ranger อะไรอย่างเงี้ย หรืออย่างเช่น เอาข้อมูลใน Metastore เนี่ยไปทำ Data Lineage เนี่ย ก็ไปอยู่ในฝั่งตัว Apache Atlas นะครับ อะ

เจาะลึกสถาปัตยกรรมและการทำงานของ Hive Metastore17:01

อันนี้คือภาพรวมคร่าวๆ เนาะ ซึ่งพอเรามาดูตัวก้อนของ Hive Metastore จริงๆ อะ จริงๆ คอมโพเนนต์มัน มันง่ายมากเนาะ ถ้าใคร ถ้าใครเคยเขียนเว็บมาบ้างเนาะ จะรู้จัก สิ่งที่เรียกว่า Three Tier Architecture เนาะ อ่า มันก็จะมีแบบเป็นดาต้าเบส เป็นแบ็คเอนด์ เป็นฟรอนต์เอนด์อะไรอย่างเงี้ยที่ ที่เราคุ้นเคยกันเนาะ ตัว Hive Metastore Program จริงๆ เนี่ยมันประกอบไปด้วยแค่ 3 ชั้นอย่างงี้เลยครับ ชั้นแรกเนี่ยก็คือตัว Metastore Service ตัวเนี้ย สีเหลืองๆ ตัวเนี้ย ซึ่งถูกเขียนในตัว Thrift Framework เนาะ

อ่า ซึ่งเป็น Interface อีกรูปแบบหนึ่ง ซึ่งสมัยนี้อาจจะหาคนเขียนได้ยากแล้วนะครับ เป็น Interface ไว้ให้คุยกับตัว component อื่นๆ นะครับ แล้วก็จะมีตัวฝั่ง database ซึ่งตัวเนี้ยจะเก็บตัว metadata อย่างที่บอกเราเก็บอะไร เราเก็บตัว table

เราเก็บตัว field ว่าเอ๊ย มันมีอะไรเป็นแบบไหน เสร็จแล้วตัวสุดท้ายที่เรามาคุยกันเนี่ยก็คือตัว client ซึ่งเอาไว้ในการ interact กับตัว metastore service ซึ่งก็คุยผ่านตัว Thrift protocol อีกทีนึงนะครับ อะ ดูเข้าใจง่ายๆ นะครับ ทีนี้ถ้าเราเจาะลึกเข้าไปในตัวดาต้าเบสว่าตัว Hive Metastore เนี่ย สุดท้ายแล้วมันเก็บอะไรบ้างใน table มันมีบอกที่ทำเอาดาต้าเบสของ Hive เนี่ย มาแกะตัว Schema ให้ดูเป็นแผนผังอีกทีนึง เราจะเห็น table แบบยุบยับเต็มไปหมดเลย แต่ถ้าเราอ่านชื่อมันดีๆ เนี่ยจะเริ่มเห็นว่ามันคือองค์ประกอบที่ทำให้เรามีสิ่งที่เรียกว่าตัว table กับดาต้าเบสที่เราคุ้นเคยกันได้ ยกตัวอย่างเช่น พอเราแยกตัว metadata object ออกมาเนี่ย 3 กลุ่มหลักๆ ที่เราต้องใช้ในการ Query มีอะไรบ้าง เราอยากรู้เนาะว่าตัวดาต้าเบสมีดาต้าเบสอะไรบ้าง เราอยากรู้ว่า table เนี่ย ใน table หนึ่งเนี่ยมันมีคอลัมน์อะไรบ้าง ตัวดาต้าเบสไหนเป็นเจ้าของ Storage มันเป็นอะไร ก็คือตัว type ของ field เนาะ เสร็จแล้วตัว location ของไฟล์ของ table เหล่านั้นเนี่ยมันอยู่ที่ไหนนะครับ แล้วก็ส่วนสุดท้ายคือ partition อันนี้ต้องสืบย้อนกลับไปนิดนึงว่าความเป็นยุค Hadoop เนี่ย

เอ่อ ตัวไฟล์อ่ะมันยังอยู่ในระดับ Hierarchy อยู่ หมายความว่าเราเก็บตัวไฟล์เป็น เป็น Hierarchy ตัวดาต้าอะไรอย่างเงี้ย แล้วการที่เราจะ access ได้เนี่ย มันก็จะผ่านชั้นตัว folder folder folder ซ้อนเข้าไปนะครับ ก็เลยต้องมีสิ่งที่เรียกว่า partition ขึ้นมาด้วย เดี๋ยวตอนตัวอย่างอาจจะได้เห็นครับ

ตัวอย่างการทำงานของ Hive Metastore: Create & Read Table19:18

ทีนี้ตะกี้มันเป็น abstraction เนาะ เรามาดูตัวอย่างของจริงกันดีกว่า พอตอนสมมติเรา create table ตัวเนี้ย พอเราสั่ง create table อันนี้ทุกคนน่าจะคุ้นเคยตัว SQL ตัวนี้เนาะ เออ นะครับ ถ้าทำงาน data น่าจะคุ้นเคยกันอยู่แล้ว พอเราสั่ง create table ผ่านตัว Client มันเนี่ย Client เนี่ยจะไปสั่งให้ Metastore Service เนี่ยเก็บข้อมูลลงในตัว ดาต้าเบสแต่ละ table นะครับ ซึ่งตะกี้ก็อย่างที่เราบอกไปมันมีทั้งดาต้าเบส มีทั้งตัว table แล้วก็จะมีตัว partition เนาะ อะไรอย่างเงี้ย เก็บเป็น type ว่าโอเคมี field อะไรบ้างนะครับ ซึ่งตรงตัวไม่มีอะไร ตะกี้ผมพูดไปนิดนึงแล้วเรื่องการที่มันเก็บว่า โอเคมันเป็น

เป็นชั้นตัว folder ยังไงเนาะ อ่าซึ่งเป็นชั้นๆ อันนี้ก็เลยต้องเก็บข้อมูลลงในตัว Metastore

อาจจะงงนิดนึงตรงนี้ ทีนี้ตอน Read เนี่ย ถามว่าตอน Read Read ยังไง เนื่องจากความที่มันเก็บข้อมูลลงเป็น เป็น table directory แต่ละ table เนาะ ในตัวชั้น Storage ของมัน ทุกครั้งที่มันถาม Query ขึ้นมา สิ่งที่เกิดขึ้นก็คือตัว Query Engine น่ะ ไม่ว่าจะเป็นตัว Hive เป็น Spark อะไรอย่างเงี้ย จะวิ่งไปถาม Metastore ก่อนเสมอว่า เฮ้ย

เราอยากจะ Query ตัวเนี้ย สมมติในนี้มันเป็น Employee Tracker Coffee Log ตัวเนี้ย อยากถามว่าไอ้ table ตัวเนี้ย มันมี field อะไรบ้าง Field นั้นมี type เป็นอะไร Location ของไฟล์มันอยู่ที่ไหนนะ เสร็จแล้วถ้าสมมติเรา Query สมมติเราชอบ Query เป็น เป็น timestamp เนาะ ซึ่งหลายๆ ครั้งในงาน data เราแบ่งงานเป็น partition ตัวนี้ก็จะบอกอีกว่า folder มันอยู่ตรงไหน เสร็จแล้วพอเราได้ข้อมูลจากตรงนี้มามากอะ ได้ครบแล้วเนี่ย ตัว Query Engine เนี่ยก็จะวิ่งไปอ่านตัวไฟล์แต่ละ path ซึ่งอาจจะอยู่ในตัว Object Storage หรือว่าตัว อ่า HDFS ได้นะครับ อันนี้เป็นหลักการทำงานของมัน ซึ่ง อ่า

พอถึงจุดนี้ก็รู้สึกว่ามันฟังดูดีเนาะ มันฟังดูดีว่าเออมันก็ตรงไปตรงมา นี่แบบไปถาม ไปถามอะไรนะ ไปถามบรรณารักษ์ว่าอะไรอยู่ตรงไหน แล้วก็ ไปหยิบของ ได้ของกลับมานะครับ

ข้อจำกัดของ Hive Metastore ในยุคปัจจุบัน21:17

แต่มันมี limitation ในยุคนี้อยู่นะครับ Limitation ยุคนี้ก็คือ อย่างแรกตัว Interface ของ Metastore เองเนี่ย มันเขียนด้วย Thrift ถามว่าในยุคนี้มีใครเขียนโปรแกรมด้วย Thrift ไหมครับ ไม่มีเนาะ ทุกคนรู้จักแต่ HTTP ทุกคนรู้จักแต่ REST Protocol ทุกคนรู้จักอะไรอาจจะ อาจจะแรงขึ้นก็คือ gRPC อะไรอย่างเงี้ย เพราะฉะนั้น Thrift Interface ในยุคนี้เนี่ยมันค่อนข้างจะแบบ เริ่มจะหาคนดูแลยากและจะหาคน Extend ได้แล้ว อีกจุดหนึ่งที่อาจจะเป็น limitation ของตัว Hive Metastore คือ ทุกครั้งที่มัน query อ่ะ มันต้องไปถามตัว RDBMS

ทุกอย่าง ทุกอย่างยกเว้นตัว Data ทุกอย่างหมายถึงอะไร ตัว Column Definition Table อยู่ที่ไหน Location อยู่ตรงไหนอะไรอย่างเงี้ย มันต้องไปถามตรง RDBMS ตัว Database ที่มันเป็นตัวเก็บ Metadata โหลดหนักมาก ซึ่งถ้าสมมติเราต้อง query เยอะๆ หรือกับเราอยากสแกนด้วยว่า เฮ้ย ทั้งหมดเนี่ยมันมีเก็บข้อมูลอยู่เท่าไหร่เนี่ย ตัว Database ตัวเนี้ยไม่ว่าจะสเกลเท่าไหร่มันก็จะเริ่มเหนื่อยมากจนเริ่มจะเป็นคอขวดในระบบนะครับ แล้วก็จริงๆ แล้วตัว Thrift API เนี่ยมันสามารถต่อตรงได้ซึ่งอาจจะไม่ค่อยปลอดภัยเท่าไหร่เนาะอันนี้

Netflix และการกำเนิดของ Open Table Format: Iceberg22:26

ทีนี้เนี่ยพอเห็นว่าไอ้ Metadata เนี่ยมันเหนื่อยมากๆ เนาะ เออ Netflix ก็เลยบอกว่า โอเค เราจะไม่อยู่กับมันละ เราอยู่กับมันมานานพอละ เราจะแก้ปัญหามัน มันก็เลยเกิดสิ่งที่เรียกว่า open table format ซึ่งหนึ่งในตัวที่เกิดขึ้นมาใน Netflix ก็คือ Iceberg ครับ ในนี้มีใครไม่รู้จัก Iceberg ไหมครับ

โอเค แปลว่าส่วนใหญ่รู้จักนะครับ ไม่แปลกใจเพราะนี่มันงาน Data Engineer เนาะ เราไม่รู้จัก Iceberg ก็อาจจะแปลกๆ หน่อยครับ ในยุค Iceberg เนี่ยถ้าเราไปเสิร์ชตัว Architecture มันจริงๆ เนี่ย มันจะเริ่มต่างจาก Hive แล้ว พอเรามองดูเนี่ย ไอ้สิ่งที่มันชูโรงมาเป็นแถวแรกสุดเลยอะ คือสิ่งที่เรียกว่า Iceberg Catalog นะครับ ตามด้วยตัว Metadata Layer และตัว Data Layer นะครับ อ่า เดี๋ยวเรามาเจาะดูทีละตัวกัน ตัว Iceberg Catalog เนี่ย ถ้าเรามองดูเนาะ เฮ้ย มันก็เหมือน Hive Metastore เนาะ แต่ถ้าเราดูในอินดีเทลจริงๆ เนี่ย ตัวเนี้ยมันจะลดโหลดบางอย่าง

สิ่งที่มันเก็บเนี่ยมันจะเก็บแค่ Metadata pointer หมายความว่าอะไร หมายความว่าแทนที่จะเก็บตัว Table Definition ทั้งหมด อย่างเช่น Table เราเนี่ยมี DDL เอ่อ มีฟิลด์หน้าตาแบบไหน มีคอลัมน์อะไรบ้างอย่างเงี้ยเก็บใน Iceberg Catalog ไม่ — Iceberg Catalog บอกว่าเราเก็บแค่ Location ของมันนะครับ เสร็จแล้วพอเรารู้ Location ของตัว Metadata เนี่ยในเลเวลที่สองเนี่ย ตัว Metadata เก็บอะไร ตัว Metadata เก็บรายละเอียดของ Table ตรงนั้นทั้งหมด รายละเอียดนั้นมีอะไรบ้าง รายละเอียดนั้นคือ เรามีไฟล์เก็บ path อยู่ที่ไหน เรามี Schema หน้าตาเป็นยังไงบ้างอะไรอย่างเงี้ย ไอ้รายละเอียดที่เราเคยเก็บอยู่ในตัว Hive Metastore เนี่ย มันถูก offload ออกมาอยู่ในตัว Metadata Layer ซึ่ง อ่า

พอมัน offload ตรงนี้เนี่ย…

ความสามารถของการทำ Schema Evolution อย่างเงี้ย มันเกิดขึ้นได้ง่ายขึ้น แล้วคอขวดมันไม่ได้อยู่ที่ตัว Hive Metastore หรือตัว Database ของมันอีกแล้วนะครับ ส่วนสุดท้ายเนี่ยก็คือตัว Data File ซึ่งจะมีสิ่งที่เรียกว่า Manifest File เป็นตัวประกบไว้เนาะ ตัวเนี้ยก็จะเป็นตัวคอยบอกย่อยอีกทีนึงว่า ตัว Data File เราเนี่ย Type มันเป็นอะไร อ่า นะครับ

Iceberg Catalog และ REST Catalog Specification24:45

ซึ่งพอมาดูตัว Iceberg เนี่ย Iceberg จริงๆ แล้วตัว Catalog มีหลายตัว แต่ตัวหนึ่งที่ Iceberg ชูขึ้นมาก็คือสิ่งที่เรียกว่า Iceberg REST Catalog นะครับ Iceberg REST Catalog เนี่ยมันเป็นเหมือน standard ที่ Iceberg สร้างขึ้นมาว่าการจะทำ Catalog เนี่ยในการคุยกับตัว Iceberg Table เนี่ย มันต้องคุยกันด้วย อ่า ฟอร์แมตอะไรบ้างนะครับ ซึ่งคอมโพเนนต์ ถ้าเราคุ้นเคยกับภาพตัว Hive Metastore ตะกี้เนาะ หน้าตามันก็จะมาแนวเดียวกันเลยก็คือ ตัว Iceberg Catalog ซึ่งตะกี้เราพูดถึงว่า Thrift มันมีปัญหาเนาะใน Hive Metastore Iceberg บอกว่า Iceberg เราไม่ใช้ Thrift เราจะใช้อะไรที่คนเขาเอาไว้ implement ง่ายๆ เพราะฉะนั้นก็เลยเกิดสิ่งที่เรียกว่า REST Catalog Specification ขึ้นมานะครับ แล้วก็คุยกันผ่านตัว HTTP Service ที่ทุกคนอาจจะเข้าใจกันอยู่แล้ว

อะ แล้วก็ยังมีมรดกตกทอดออกมาอยู่ก็คือ เราจะต้องเก็บข้อมูลบางอย่างอยู่ในตัว Database ของตัว Iceberg REST Catalog ซึ่งเดี๋ยวเราไปลงดีเทลต่อไปนะครับ แล้วก็มีตัว Client ที่คุยกันผ่านตัว REST Interface ไปที่ Iceberg REST Catalog เนาะ อ่า ตะกี้เราพูดถึงอันนี้ไปนิดนึงแล้วก็คือ แทนที่เราจะเป็นสเปคของ Thrift ซึ่งค่อนข้างจะแบบล็อก vendor มากแล้วเราไม่รู้ว่าเฮ้ยข้างในมันมีอะไรมีอะไรบ้างนะ ตัว Iceberg บอกว่า Iceberg เราทำ REST Catalog specification ให้ แล้วก็ถ้าใครอยากทำตัว Connector เอ้ยทำตัว Catalog เนี่ยก็ implement ตามนี้เลยนะครับ ซึ่งถ้าใครเป็นโปรแกรมเมอร์แล้วอ่าน Specification เป็นก็จะรู้ว่าโอเคมันมีแค่ input output ที่เราแค่ต้องเสิร์ฟออกมาตาม specification ส่วนเราจะเป็น implement ด้วยภาษาอะไร เป็น Python เป็น Rust เป็นอะไรก็แล้วแต่ ก็แค่ทำตามนี้ก็พอนะครับ อีกจุดหนึ่งที่น่าสนใจของตัว

Iceberg Catalog ก็คือตัว Metadata Object อย่างที่บอก ถ้าเราย้อนกลับไปดูภาพ ภาพแรกตรงนี้เนาะ Iceberg Catalog เนี่ย ตรงนี้มันบอกว่าเราเก็บแค่ Metadata Pointer หมายความว่ายังไง พอเราไปดูตัวสกีมาจริงๆ ที่ตัวดาต้าเบสของตัว Iceberg Catalog มันเก็บไว้อะ สิ่งที่มันสนใจมันสนใจแค่ 2 อย่างเองก็คือ มันมี namespace อะไรบ้าง Namespace เนี่ยในภาษาที่เราเข้าใจกันก็คือดาต้าเบสเนาะ อ่า อีกตัวหนึ่งที่เราสนใจเนี่ยก็คือตัว Iceberg Table ก็คือตัว Table จริงๆ ซึ่งตัว Table เนี้ย เราสนใจแค่ว่ามันอยู่กับ namespace ไหน อ่า ชื่ออะไร แล้วสิ่งที่สนใจจริงๆ คือ Metadata file มันน่ะอยู่ที่ไหนนะครับ ซึ่งอาจจะเป็น path ใน HDFS, path ใน S3, path ใน Google Storage อะไรอย่างเงี้ยก็ว่าไปนะครับ

เปรียบเทียบการทำงานของ Hive Metastore และ Iceberg: Write & Read27:17

ทีนี้มาดูเทียบกันว่าจังหวะการเขียนเป็นยังไง จังหวะการเขียนสมมุติเราสร้าง create table คล้ายๆ กับตอนที่เราทำ Hive Metastore ตะกี้เนาะ พอมันเขียนเนี่ยสิ่งที่มันเซฟลงในตัวดาต้าเบส มันเซฟแค่ว่า โอเค เราเกิด DB Table หนึ่งนะ DB Table หนึ่งมีการมี Metadata file อ่ะอยู่ที่นี่ อยู่ที่อาจจะเป็น

S3 แล้วก็เป็น path something อะไรอย่างเงี้ย แล้วก็เป็นไฟล์ .json ที่เราอาจจะไป inspect ได้นะครับ เสร็จแล้วมันก็จะสร้างตัวโฟลเดอร์ขึ้นมาในตัว object storage จริงๆ แล้วก็เกิดตัว Metadata file ขึ้นมาเป็นเวอร์ชันแรกนะครับ ซึ่งตัว Iceberg Catalog มันพอยต์ไปอยู่นะครับ อ่านี่คือการ create table เนาะ ทีนี้จังหวะที่มัน read บ้างล่ะ จังหวะที่มัน read สมมติเรามีดาต้าแล้วเนี่ย สิ่งที่เกิดขึ้นตามจังหวะก็คือ โอเค ตัว Client เนี่ยวิ่งไปถามตัว Iceberg Catalog มันว่า Table นี้ อ่า Metadata file มันอยู่ที่ไหนนะ มันก็จะจิ้มไปว่าโอเคอยู่ที่ Metadata นะ เสร็จแล้วพอวิ่งไปที่ Metadata ปุ๊บ Metadata ก็จะบอกว่าตัว manifest file ของตัว Data file เราอยู่ที่ไหน มันก็จะวิ่งไปตามขั้น ถามว่า ภาพนี้มันดูเหมือนไม่มีอะไร แต่จริงๆ แล้วสิ่งที่เกิดขึ้นน่ะ ไอ้ตัวโหลดใน system ของ Iceberg Catalog ตรงนี้มันน้อยมาก สิ่งที่มันถามก็แค่ถามว่าอะไรมันอยู่ตรงไหน แบบจุดจุดเดียว รายละเอียดของ Table เช่น เรารู้ว่าคอลัมน์มันอยู่ที่ไหน Location ของตัว Data file อยู่ตรงไหนอย่างเงี้ย รวมถึงเวอร์ชันของดาต้ามันถูกออฟโหลดไปอยู่ข้างๆ ใน Metadata layer หมดเลยนะครับ นี่คือวิวัฒนาการที่เกิดจากยุค Hive Metastore ขึ้นมาเป็น Iceberg Catalog อ่า

ครับซึ่งตัว advantage เมื่อกี้ผมน่าจะเล่าไปหมดแล้ว ผมขอข้ามแล้วกันนะครับ ตึ๊งตึ๊ง

อนาคตของ Data Catalog: Format Agnostic, Single Node, Orchestrator Integrated28:59

พูดถึงอนาคตบ้างซึ่งตะกี้ทุกคนจะเริ่มเข้าใจแล้วว่าจริงๆ แล้ว ตัว Catalog เนี่ยมันก็เริ่มพอจะทำงานยังไงเนาะ อ่า ทีนี้เนี่ยพอ Catalog มันทำงานพื้นฐานได้ละ คนก็เริ่มแบบว่า โอ๊ย มันก็ไม่ได้ซับซ้อนขนาดนั้นนี่หว่า เราเริ่มจะมียูสเคสว่าเอามันไปใช้กับอะไรบ้างดีนะครับ ถ้าเราตามเทรนด์ ในตัว Data Engineering community มาสักพักเนาะ เราจะเริ่มเห็นว่าตัว Open Table Format เนี่ย มันค่อนข้างจะ dominate ช่วงนี้หนักมากนะครับ เราทุกคนต้องปรับตัวอยู่กับมันนะครับ เทรนด์แรกเกี่ยวกับ Data Catalog ที่อยากจะให้รู้ก็คือมันจะเริ่มเกิดสิ่งที่เรียกว่า Format Agnostic Catalog Format Agnostic คืออะไร อ่า ในช่วงที่เราดูตรงเนี้ย มันจะมีบางตัวที่บอกมันว่า

เค เราชอบทำงานกับไฟล์ format นี้ เราชอบทำงานกับไฟล์ format นี้ที่อยู่ใน Data Lakehouse แต่ทุกคนก็รู้ว่า หลาย need ในปัจจุบันมันก็มี requirement แต่ละทีมไม่เหมือนกันเนาะ ทีมนี้อยากได้ อ่า performance ดีๆ ในการ query ข้อมูล ทีมนี้อยากได้แค่แบบเป็นทำ monthly stat อะไรอย่างเงี้ย ซึ่งพอ requirement need มันไม่เหมือนกันเนี่ย มันก็เลยเกิด อ่า ตัว

Open Format ขึ้นมาหลายๆ ไฟล์นะครับ ซึ่งไอ้ Format Agnostic ตัวนี้มันเข้ามาแก้ปัญหาในจุดนี้ ก็คือแทนที่เราจะมี 1 Catalog ต่อ 1 ไฟล์ Open Format type เนี่ย เรามี Catalog ตัวนี้ที่มัน interop กับตัว ตัวไฟล์ type หลายหลายแบบได้เลยนะครับ ซึ่งเพื่อให้มั่นใจได้ว่าเรามี เรามีอะไรนะ ไฟล์ format ที่เหมาะสมกับแต่ละ use case แล้วก็ตัว specification ค่อนข้างจะเปิดกว้างเพื่อจะให้เรา extend มากยิ่งขึ้นนะครับ ซึ่งตัวอย่างของตัว อ่า Format Agnostic Catalog ตัวนี้ก็คือตัว Unity Catalog เนาะ ซึ่งตอนนี้ support หลากหลายมากกับตัวอย่างเช่น Apache Trino หรือว่าตัว XTable เองก็น่าจะกำลังคิดอยู่ตรงนี้อยู่ว่าเป็นตัว Catalog ที่ support ในการ inter interprocess ตัว Open Table Format นะครับอีกกลุ่มหนึ่งนะครับ

เทรนด์ Single Node Processing และผลกระทบต่อ Data Catalog31:00

เอ่อ ประมาณช่วงเดือนที่แล้วผม ผมไปเจอบทความความหนึ่งชื่อว่า Rise of Single Node Processing นะครับ มัน มันพูดถึงเทรนด์ในช่วงนี้ว่า เฮ้ยทำงาน Data Engineer เรา เราไม่ค่อยอยากจะ เขาเรียกอะไรนะ setup ตัว cluster ในการประมวลผลขึ้นมาเยอะแล้ว เพราะเทคโนโลยี compute engine เนี่ยมัน มันดีขึ้นมากแล้ว ยกตัวอย่างเช่น ไอ้ MacBook ตัวนี้ เอาจริงๆ มันก็แรงเนาะ ถูกไหม มัน มันไม่เหมือนคอมสมัยก่อนที่แบบแรม 4 GB ซีพียูแบบกระจึ๋งนึง อะไรอย่างเงี้ย แล้วเราประมวลผลดาต้า ไม่ได้ คอมสมัยนี้มันแรงพอที่เราจะทำอะไรในเครื่องได้แล้ว มันก็เลยเกิด tooling ที่ทำให้เราประมวลผลในเครื่องได้ที่เป็น Single Processor อย่างเช่นตัว DuckDB หรือตัว Apache Arrow หรือตัว Polars อย่างเงี้ย อ่า ซึ่งพอเกิด movement ตัวนี้ขึ้นมา สิ่งที่เกิดขึ้นคือ

ความเป็นแค็ตตาล็อกอะ แทนที่เราจะต้อง maintain เป็น component แยกอะ มันจะเริ่ม shift ไปหาฝั่งที่เป็น Processor มากขึ้น ก็คือให้มันอยู่ในเครื่องนี้เลย โดยการ pre-load ตัว อ่า แค็ตตาล็อกหรือ knowledge ในการ accessing ดาต้าเข้าไปนะครับ ซึ่งมันก็ช่วยลดความซับซ้อนในการ maintain component หลายๆ component ที่อยู่ใน Cloud Data Platform มากขึ้น แต่อย่างที่บอก พอเราออฟโหลดสิ่งเนี้ยเข้าไปอยู่ในฝั่ง User มากขึ้นเนี่ย การจัดการตัว access control หรือว่าแบบ security อะไรอย่างเงี้ย มันก็เริ่มมีความ challenge อยู่นะครับ ตัวนี้เป็นเทรนด์อีกเทรนด์หนึ่งที่กำลังมาของแค็ตตาล็อก

Orchestrator Integrated Catalog และตัวอย่าง Dagster/Airflow32:17

เทรนด์สุดท้ายที่อยากจะพูดถึงครับ ก็คือตัว Orchestrator Integrated นะครับ คือถ้าเรามองในมุม Data Platform เนาะ ทุกคนเนี่ยอยากทำงาน— ตะกี้พี่กานต์พูดถึงว่า ถ้าอยากให้มันทำงานซ้ำๆ มันก็ต้องมี Cron เนาะ แต่ถ้างานในดาต้าจริงๆ เราก็จะมี Orchestrator เนาะ Airflow หรือนู่นนั่นนี่ หรือที่เราใช้กันนะครับ ซึ่งตัว Orchestrator เนี่ยก็เริ่มมี movement เหมือนกัน แทนที่เราจะทำงานเป็น เป็น taskๆ แบบว่า ทำ A ไป B ไป C อะไรอย่างเงี้ย เราจะเริ่มทำงานกับดาต้าในมุมของสิ่งที่เรียกว่า Asset มากยิ่งขึ้นนะครับ ซึ่งทั้งๆ ที่ตัว Orchestrator มันรู้อยู่แล้วว่ามันจะคุยกับใครอะไรยังไงอ่ะ มันก็ยกระดับตัวเองขึ้นมาว่า เฮ้ย เรากุมความรู้ของแค็ตตาล็อกตัวนี้ไว้ด้วยนะ อยากรู้อะไรว่าอะไรมันเชื่อมกับอะไรตรงไหนเนี่ย มาดูที่เรานะครับ ถามว่าทำอย่างงี้แล้วมันดียังไง

ดาต้าแค็ตตาล็อกส่วนใหญ่เนี่ย มันจะแยก component ออกไปเป็นต่างหากตัวหนึ่งเนาะ แล้วต้องการที่จะทำให้มันมี value ขึ้นมา เราต้องทำการส่งดาต้าให้มัน อาจจะจะเป็นการ push model หรือ pull model ก็ได้ แต่การที่เรา move ตัวแค็ตตาล็อกตัวนี้มาอยู่ในตัว Orchestrator ซึ่งทุกคนต้องทำงานกับมันอยู่แล้วอ่ะ มันทำให้ความรู้อยู่ตรงเนี้ย แล้วการเกิดขึ้นของดาต้า ดาต้าควอลิตี้เป็นยังไงอย่างเงี้ย มันถูกจัดการอยู่ในตัว Orchestrator ทีเดียวเลยนะครับ ซึ่งมันก็ลดความซับซ้อนไว้อีกเนาะนะครับ ซึ่งถามว่าตัวเนี้ย ถามว่าเกิดขึ้นมากแค่ไหน เอ่อ

ผมไม่รู้ ผมไม่รู้ Orchestrator ตัวอื่นเนาะ แต่ตัวอย่าง Dagster หรืออย่างเช่นตัว Airflow ที่ทุกคนใช้กันเนี่ย Dagster ก็จะมีสิ่งที่เรียกว่า Asset เนาะ ตัว Airflow ก็จะมีสิ่งที่เรียกว่า Asset ตัวเนี้ยเป็นตัว drive ตัว movement นี้ขึ้นมาว่า โอเค เราย้ายแค็ตตาล็อกมาอยู่ที่ฝั่งของ Orchestrator นะครับ อ่ะ ทีนี้

จริงๆ ขอเกินเวลา ขออภัยนะครับ

บทสรุปและข้อคิดในการเลือกใช้ Data Catalog34:01

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

ว่ามันควรจะทำอะไรได้ ทำอะไรไม่ได้นะครับ แล้วก็สิ่งที่อยากจะฝากไว้อันสุดท้ายของทอล์คนี้คือ คือตัว Data Catalog เนี่ย

ถ้าสมมุติเราอยู่ในบริษัทเนาะ ลอง ลองคิดภาพตัวบริษัท บริษัทเนี่ย เวลาเราเข้าไปเนี่ย ให้มองดูว่าตัว Adoption ของดาต้าเราเป็นเลเวลไหน อะ บริษัทเราเป็น Brownfield หรือเปล่า ที่มีการทำ Governance หนักมาก มีทุกอย่างพร้อม มี Processing เรียบร้อยแล้ว หรือว่าเราเข้าไปเป็น Data Engineer คนแรกที่อยู่ในบริษัท แล้วเราไม่รู้ว่าจะทำอะไรยังไงขึ้นมา อะไรอย่างเงี้ยนะครับ ความรู้ที่เรามีในการทำแค็ตตาล็อกตัวเนี้ย ในวันนี้ที่ผมเล่าไปเนี่ย มัน serve สอง สองคน สองคน สองกลุ่มเนี้ยต่างกัน อ่า อย่างเช่นสมมุติเราอยู่ในโลกที่มัน Brownfield มากเนาะ เออ เรามี Governance หนักมาก เรามีนู่นนั่นนี่หนักมาก ถามว่าถ้าสมมุติ Governance เราเริ่มช้า หรือตัว Data Catalog ของ ของตัวหลักเรามันเริ่มโหลดมากๆ อย่างเงี้ย เราจะทำยังไงให้มันเร็วขึ้นในสภาวะที่องค์กรมันใหญ่มากๆ อย่างเงี้ย การที่เรารู้ว่าแค็ตตาล็อกมันทำงานยังไง หรือว่าเราจะเลือกใช้ สร้างมันยังไงอย่างเงี้ย ตัวเนี้ยจะทำให้มัน accelerate ยิ่งขึ้น หรืออย่างเช่นถ้าอยู่ใน Greenfield อย่างเงี้ย โอเค เราไม่รู้อะไรเลย เราเป็น Data Engineer คนแรกในบริษัท เราจะทำยังไง การที่เรารู้จักแค็ตตาล็อกเนี่ย มันทำให้รู้ว่า โอเค จุดเริ่มต้นที่ Data Citizen เลเวลแรก เลเวลแรกคือใครคือ Engineer ที่เราทำงานด้วยเนี่ย เขาจะใช้ดาต้ายังไงเนี่ย มันจะมีประโยชน์ยังไงบ้างนะครับ นอกจากที่เราจะรู้ว่าเราจะเลือก Compute Engine ยังไง เราจะเลือก Storage ตัวไหนนะครับ ตัวนี้ก็น่าจะหวังว่าจะช่วยให้ อ่า กลุ่มคนที่อยู่ในสองโลกนี้เนาะ

เข้าใจกับ Data Catalog มากยิ่งขึ้น ครับผม ประมาณนี้ครับ ขอบคุณครับ ขอเสียงปรบมือให้พี่แมนหน่อยค่ะ (เสียงปรบมือ) ขอบคุณพี่แมนมากๆ นะคะ