รื้อ ELT: เมื่อสิ่งที่ต้องการไม่ใช่ Silo แต่เป็น Graph
(jack-vanlightly.com)- ELT (Extract, Load, Transform) ถูกใช้เพื่อเชื่อม "ไซโล (Silo)" ระหว่างการวิเคราะห์ข้อมูลและการพัฒนาซอฟต์แวร์ภายในองค์กร แต่โครงสร้างแบบไซโลนี่เองคือรากของปัญหา
-
ELT เป็นเพียงสะพานเชื่อมระหว่างไซโลเท่านั้น โลกที่ไม่มีไซโลก็คือ "กราฟ (Graph)"
ข้อจำกัดของแนวคิดแบบ ELT
- ในโลกที่มีไซโลหนึ่งเป็นฝั่งซอฟต์แวร์ และอีกไซโลหนึ่งเป็นฝั่งการวิเคราะห์ข้อมูล ELT มีความหมายอย่างมาก
- ELT ทำงานโดยมีโครงสร้างแบบไซโลเป็นสมมติฐานตั้งต้น
- งาน "Extract" เกิดขึ้นในสถานการณ์ที่ทีมพัฒนาซอฟต์แวร์กับทีมวิเคราะห์ข้อมูลแยกจากกัน
- ทีมซอฟต์แวร์ไม่สนใจงานของทีมข้อมูล ขณะที่ทีมข้อมูลก็ใช้สิทธิ์เข้าถึงฐานข้อมูลดึงข้อมูลออกมาแบบตรง ๆ
- กว่าจะเริ่มนำหลักการวิศวกรรมอย่างคุณภาพข้อมูลและการทำแบบจำลองมาใช้ ก็เป็นช่วงหลังการดึงข้อมูลแล้ว ซึ่งช้าเกินไป
- กฎของ Conway ทำงานอยู่
- "การออกแบบของระบบที่องค์กรสร้างขึ้น จะมีลักษณะคล้ายกับโครงสร้างการสื่อสารขององค์กรนั้น"
- ด้วยกรอบคิดแบบไซโล ETL/ELT/Reverse ETL จึงไม่เหมาะกับการรับมือความซับซ้อนของสถาปัตยกรรมข้อมูลสมัยใหม่
- ตอนนี้ข้อมูลไม่ได้อยู่แค่ในระบบปฏิบัติการและระบบวิเคราะห์เท่านั้น แต่ขยายไปยังโดเมนข้อมูลที่สามซึ่งมี SaaS เป็นตัวแทน
- ข้อมูลไหลข้ามภูมิภาคและคลาวด์ รวมถึงระหว่างแบ็กเอนด์กับ SaaS
- ปัจจุบันมีแอปพลิเคชันมากกว่าเดิมถึง 100 เท่า องค์กรกำลังกลายเป็นซอฟต์แวร์มากขึ้น และเครือข่ายความสัมพันธ์ระหว่างระบบซอฟต์แวร์ก็ซับซ้อนขึ้นเรื่อย ๆ
ความจำเป็นของแนวคิดแบบกราฟ
- หากทีมซอฟต์แวร์และทีมข้อมูลทำงานร่วมกันอย่างสอดประสาน ก็สามารถเปลี่ยนจากโมเดลแบบ ELT ที่เน้นดึงและเก็บข้อมูล ไปเป็น โมเดลกราฟ ได้
- ลองจินตนาการถึงกราฟที่ประกอบด้วยโหนดซึ่ง "Consume" ข้อมูล
- แต่ละโหนดทั้งผลิตหรือบริโภคข้อมูล และก่อรูปเป็นเครือข่ายหรือกราฟขึ้นมาโดยธรรมชาติ
- ข้อดีของแนวคิดแบบกราฟ:
- การดึงข้อมูลลดลง และการบริโภคข้อมูลเพิ่มขึ้น
- มีการทำแบบจำลองข้อมูลมากขึ้นโดยยึดชุดข้อมูลคุณภาพสูงเป็นศูนย์กลาง
- งานทำความสะอาดข้อมูล การเก็บข้อมูลดิบ และการแก้ข้อผิดพลาดของไปป์ไลน์ลดลง
- ใช้การประมวลผลแบบค่อยเป็นค่อยไปและแหล่งข้อมูลแบบสตรีมมิงแทนกระบวนการแบบแบตช์
- การวิเคราะห์ไม่ได้จำกัดอยู่แค่เครื่องมือช่วยตัดสินใจเชิงกลยุทธ์ แต่ขยายไปสู่การใช้งานเชิงปฏิบัติการ
- ความร่วมมือและการปรับแนวทางระหว่างทีมเพิ่มขึ้น ไซโลลดลง
บทสรุป
- แนวคิดแบบ ELT เป็นผลลัพธ์ของกฎ Conway ที่สะท้อนการแยกขาดระหว่างทีมซอฟต์แวร์กับทีมข้อมูล
- ไม่จำเป็นต้องทิ้งเครื่องมือ ETL/ELT เดิมทั้งหมด แต่ควรโฟกัสที่ การบริโภคข้อมูลและการสร้างชุดข้อมูลอนุพันธ์ที่เชื่อถือได้
- ในความเป็นจริง Shift Left ยังอยู่ในขั้นที่เป็นเป้าหมายเชิงอุดมคติ และปัญหาการผสานรวมกับโครงสร้างพื้นฐานแบบเลกาซีก็ยังคงมีอยู่
- Shift Left : กลยุทธ์ในการผสานแนวปฏิบัติสำคัญเข้าไปตั้งแต่ช่วงต้นของวงจรชีวิตการพัฒนาซอฟต์แวร์ (SDLC)
- องค์กรที่ยอมรับแนวคิดแบบกราฟจะได้ประโยชน์สูงสุดในด้านการใช้ประโยชน์จากข้อมูล, AI ROI และผลลัพธ์ทางธุรกิจ
"ไม่มีการ Extract มีแต่ Consume เท่านั้น" – Data Yoda
5 ความคิดเห็น
พอได้อ่านหนังสือ Data Mesh แล้ว ก็มีหลายส่วนที่เข้าใจมากขึ้นครับ
ผมกำลังคิดไอเดียเกี่ยวกับการตัดสินใจบนพื้นฐานกราฟอย่างต่อเนื่องอยู่ และคิดว่าน่าจะดีถ้ามีคนที่มีแนวคิดแบบเดียวกันมารวมตัวกันได้
คำที่ใช้ในกรณีแบบนี้คือคำว่า ideation นี่เองครับ ได้เรียนรู้อีกอย่างหนึ่งแล้ว โดยส่วนตัวเป็นหัวข้อที่ผมสนใจมาก หากรวมตัวกันได้ก็คงจะดีมากครับ
มีใครช่วยอธิบายเพิ่มเติมได้ไหมครับ/คะ? วิธีที่ผู้เขียนพูดถึงหมายความว่าต้องบันทึกและจัดการชุดข้อมูลที่ถูกอนุมานจากกราฟทั้งหมดแยกกันใช่ไหม? ถ้าไม่ใช่ ก็ยังไม่ค่อยเข้าใจว่ามันต่างจาก ETL อย่างไร
เขาบอกว่าโครงสร้างที่แยกส่วนปฏิบัติการเดิมกับส่วนวิเคราะห์ออกจากกันมีปัญหาเชิงโครงสร้างแบบไซโล และเมื่อออกแบบ data architecture ไม่ควรพิจารณาสองส่วนนี้แยกจากกัน แต่ควรพิจารณาโดยแบ่งเป็นผู้สร้างข้อมูลกับผู้บริโภคข้อมูล
ตอนนี้เมื่อเส้นแบ่งระหว่างข้อมูลเชิงปฏิบัติการกับข้อมูลเชิงวิเคราะห์เริ่มพร่าเลือนลง จึงบอกว่าจำเป็นต้องใช้วิธีคิดแบบกราฟ (graph thinking, or the graph mindset)
ในความรู้สึกของผม แทนที่จะเป็นการแยก operational data กับ analytical data อย่างชัดเจน เขามองการแยกผู้บริโภคข้อมูลกับผู้สร้างข้อมูลในฐานะส่วนต่อเนื่องของ operational data และมองการเข้าถึงข้อมูลจากมุมมองของ data flow (แม้ว่าบทบาทอาจจะแยกจากกันก็ตาม)
ดูเหมือนว่าเขากำลังพูดในมุมมองของ data architecture ถึงการนำข้อมูลปฏิบัติการไปวิเคราะห์ แล้วส่งกลับไปยังการปฏิบัติการ และจากนั้นก็วนกลับไปสู่งานวิเคราะห์อีกครั้ง