9 คะแนน โดย xguru 2024-12-05 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • 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 ความคิดเห็น

 
udopeanut 2024-12-18

พอได้อ่านหนังสือ Data Mesh แล้ว ก็มีหลายส่วนที่เข้าใจมากขึ้นครับ

 
softer 2024-12-05

ผมกำลังคิดไอเดียเกี่ยวกับการตัดสินใจบนพื้นฐานกราฟอย่างต่อเนื่องอยู่ และคิดว่าน่าจะดีถ้ามีคนที่มีแนวคิดแบบเดียวกันมารวมตัวกันได้

 
kimsk 2024-12-06

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

 
jwseo 2024-12-05

มีใครช่วยอธิบายเพิ่มเติมได้ไหมครับ/คะ? วิธีที่ผู้เขียนพูดถึงหมายความว่าต้องบันทึกและจัดการชุดข้อมูลที่ถูกอนุมานจากกราฟทั้งหมดแยกกันใช่ไหม? ถ้าไม่ใช่ ก็ยังไม่ค่อยเข้าใจว่ามันต่างจาก ETL อย่างไร

 
rlaehdus2003 2024-12-05

เขาบอกว่าโครงสร้างที่แยกส่วนปฏิบัติการเดิมกับส่วนวิเคราะห์ออกจากกันมีปัญหาเชิงโครงสร้างแบบไซโล และเมื่อออกแบบ data architecture ไม่ควรพิจารณาสองส่วนนี้แยกจากกัน แต่ควรพิจารณาโดยแบ่งเป็นผู้สร้างข้อมูลกับผู้บริโภคข้อมูล

ตอนนี้เมื่อเส้นแบ่งระหว่างข้อมูลเชิงปฏิบัติการกับข้อมูลเชิงวิเคราะห์เริ่มพร่าเลือนลง จึงบอกว่าจำเป็นต้องใช้วิธีคิดแบบกราฟ (graph thinking, or the graph mindset)

ในความรู้สึกของผม แทนที่จะเป็นการแยก operational data กับ analytical data อย่างชัดเจน เขามองการแยกผู้บริโภคข้อมูลกับผู้สร้างข้อมูลในฐานะส่วนต่อเนื่องของ operational data และมองการเข้าถึงข้อมูลจากมุมมองของ data flow (แม้ว่าบทบาทอาจจะแยกจากกันก็ตาม)

ดูเหมือนว่าเขากำลังพูดในมุมมองของ data architecture ถึงการนำข้อมูลปฏิบัติการไปวิเคราะห์ แล้วส่งกลับไปยังการปฏิบัติการ และจากนั้นก็วนกลับไปสู่งานวิเคราะห์อีกครั้ง