ไปป์ไลน์ข้อมูลเคยมีลำดับขั้นตอนที่เคร่งครัด ได้แก่ ดึงข้อมูลจากระบบต้นทาง แปลงข้อมูลให้อยู่ในรูปแบบที่สะอาดและมีโครงสร้าง จากนั้นจึงโหลดผลลัพธ์ที่เสร็จสมบูรณ์เข้าสู่ฐานข้อมูล ลำดับขั้นตอนดังกล่าว (การสกัด การแปลง การโหลด หรือ ETL) ก็เป็นขั้นตอนที่สมเหตุสมผลในยุคที่พื้นที่จัดเก็บข้อมูลมีราคาแพง และระบบปลายทางยังไม่มีประสิทธิภาพมากพอที่จะทำการประมวลผลหนักๆ ได้

แต่คลังข้อมูลบนระบบคลาวด์ได้เปลี่ยนสิ่งเหล่านั้นไปทั้งหมด และ ELT (การสกัด การโหลด การแปลง) ก็ได้กลายมาเป็นรูปแบบที่ทีมวิเคราะห์ข้อมูลจำนวนมากเลือกใช้เป็นค่าเริ่มต้นในปัจจุบัน แม้ว่า ETL แบบเดิมๆ จะยังคงครองส่วนแบ่งการตลาดอยู่เกือบ 40% แต่ก็กำลังสูญเสียความนิยมอย่างรวดเร็วให้แก่ไปป์ไลน์ข้อมูลประเภทอื่นๆ อย่างเช่น ELT

ด้านล่างนี้ เราจะอธิบายว่า ELT คืออะไร มีวิธีการทำงานอย่างไร และเหมาะหรือไม่เหมาะกับการทำงานแบบใดบ้าง

ประเด็นสำคัญ

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

• คลังข้อมูลระบบคลาวด์นั้นเหมาะสมกับ ELT เป็นอย่างยิ่ง เนื่องจากแยกพื้นที่เก็บข้อมูลออกจากการประมวลผล เติบโตได้อย่างยืดหยุ่น และช่วยให้นักวิเคราะห์เขียนตรรกะการแปลงข้อมูลด้วยภาษา Structured Query Language (SQL) ได้

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

ELT คืออะไร และมีวิธีการทำงานอย่างไร

ELT (การสกัด การโหลด การแปลง) คือรูปแบบการผสานรวมข้อมูลที่สร้างขึ้นจาก 3 ขั้นตอน ได้แก่ การสกัดข้อมูลจากระบบต้นทาง การโหลดข้อมูลดิบเข้าสู่ระบบปลายทางส่วนกลาง จากนั้นจึงทำการแปลงข้อมูลภายในระบบปลายทางดังกล่าวเพื่อนำไปใช้ในการวิเคราะห์ การทำรายงาน หรือการทำแมชชีนเลิร์นนิง

ในทางปฏิบัติ เวิร์กโฟลว์ ELT ทั่วไปมีหลักการทำงานดังนี้

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

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

• แปลง: ตรรกะการแปลงข้อมูลจะทำงานอยู่ภายในคลังข้อมูล โดยเครื่องมือที่ใช้ฐานข้อมูล SQL อย่างเช่น data build tool (dbt) จะช่วยให้ทีมต่างๆ สามารถควบคุมเวอร์ชันของโมเดลเหล่านั้น ทำการทดสอบ และสร้างชุดข้อมูลต่อยอดจากชั้นข้อมูลดิบได้

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

ELT ต่างจาก ETL อย่างไรในทางปฏิบัติ

ความแตกต่างทางสถาปัตยกรรมหลักระหว่าง ETL และ ELT คือสถานที่ที่เกิดการแปลงข้อมูล โดยในกระบวนการ ETL จะเกิดขึ้นภายนอกระบบปลายทาง ส่วนในกระบวนการ ELT จะเกิดขึ้นภายในระบบปลายทาง

ความแตกต่างที่สำคัญที่สุดระหว่าง ETL กับ ELT มีดังนี้

• ความพร้อมใช้งานของข้อมูล: ในไปป์ไลน์ ETL ข้อมูลจะไม่สามารถนำมาสืบค้นได้จนกว่าจะผ่านการแปลงและโหลดเข้าสู่ระบบแล้ว ในขณะที่รูปแบบ ELT ข้อมูลดิบจะถูกนำเข้ามาก่อน ดังนั้น นักวิเคราะห์จึงสามารถดำเนินการกับข้อมูลนั้นได้ในระหว่างที่ทำการแปลงข้อมูลแยกต่างหาก

• ความเร็วในการปรับปรุง: การเปลี่ยนวิธีแปลงข้อมูลในไปป์ไลน์ ETL มักหมายถึงการต้องสร้างตัวไปป์ไลน์นั้นขึ้นใหม่ทั้งหมด แต่ในกระบวนการ ELT คุณเพียงแค่ทำการอัปเดตโมเดล SQL แล้วรันใหม่อีกครั้งกับข้อมูลที่มีอยู่ในคลังข้อมูลเรียบร้อยแล้ว

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

• การเก็บรักษาข้อมูลดิบ: โดยทั่วไปแล้ว ETL จะละทิ้งสถานะข้อมูลระหว่างทางเมื่อได้ผลลัพธ์ที่แปลงเสร็จสมบูรณ์ออกมาแล้ว แต่ ELT จะรักษาชั้นข้อมูลดิบไว้เป็นค่าเริ่มต้น ซึ่งหมายความว่าคุณสามารถประมวลผลข้อมูลย้อนหลังใหม่ได้เมื่อความต้องการเปลี่ยนไป

ทำไม ELT จึงเหมาะสำหรับคลังข้อมูลบนระบบคลาวด์ยุคใหม่

คุณสมบัติต่อไปนี้ทำให้ ELT เหมาะสำหรับคลังข้อมูลบนระบบคลาวด์อย่างยิ่ง ดังนี้

• แยกการจัดเก็บและประมวลผล: แพลตฟอร์มอย่างเช่น Snowflake และ BigQuery จะคิดค่าบริการแยกกันระหว่างการจัดเก็บข้อมูลและการสืบค้นข้อมูล คุณจึงสามารถนำข้อมูลดิบเข้ามาเก็บไว้มากเท่าใดก็ได้ตามต้องการ และงานแปลงข้อมูลจะใช้ทรัพยากรส่วนประมวลผลเฉพาะในตอนที่รันเท่านั้น

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

• การจัดเก็บข้อมูลแบบแนวตั้ง: คลังข้อมูลบนระบบคลาวด์จะจัดเก็บข้อมูลในรูปแบบแนวตั้ง ซึ่งช่วยให้การสืบค้นเพื่อการวิเคราะห์ (การรวมกลุ่มข้อมูล การกรองข้อมูล การเชื่อมโยงข้อมูลในชุดข้อมูลขนาดใหญ่) ทำได้รวดเร็วกว่าการจัดเก็บข้อมูลแบบแนวนอนอย่างเห็นได้ชัด

• รองรับ SQL: นักวิเคราะห์และวิศวกรวิเคราะห์ข้อมูลส่วนใหญ่มีความรู้ความเข้าใจในภาษา SQL อยู่แล้ว การรันขั้นตอนแปลงข้อมูลภายในคลังข้อมูลจึงหมายความว่า คนที่เข้าใจตรรกะทางธุรกิจจะสามารถเขียนและเป็นเจ้าของโมเดลการแปลงข้อมูลนั้นได้โดยตรง

เมื่อใดจึงควรใช้ ELT

ELT อาจไม่ใช่คำตอบที่เหมาะสำหรับทุกไปป์ไลน์ข้อมูล แต่ก็เหมาะสำหรับชุดเงื่อนไขที่เห็นได้ชัดเจนดังต่อไปนี้

ตัวอย่างสถานการณ์ที่ ELT มักจะทำงานได้ดีมีดังนี้

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

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

• กรณีการใช้งานปลายทางหลายกรณี: ข้อมูลดิบในคลังข้อมูลสามารถป้อนเข้าสู่แดชบอร์ดระบบอัจฉริยะทางธุรกิจ คลังข้อมูลฟีเจอร์สำหรับแมชชีนเลิร์นนิง และรายงานการดำเนินงานได้พร้อมกัน โดยคุณสร้างไปป์ไลน์เพียงชุดเดียวแล้วออกแบบโมเดลข้อมูลให้แตกต่างกันไปตามผู้ใช้งานแต่ละกลุ่ม

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

ELT จะไม่เหมาะสำหรับสถานการณ์ต่อไปนี้

• ข้อจำกัดด้านกฎระเบียบของข้อมูลดิบ: สภาพแวดล้อมข้อมูลบางประเภท เช่น ข้อมูลด้านการรักษาพยาบาลและข้อมูลทางการเงิน มีข้อห้ามในการนำเข้าข้อมูลที่ละเอียดอ่อนก่อนที่จะทำการพรางข้อมูลหรือคัดกรอง ในกรณีเหล่านั้น ขั้นตอนการแปลงข้อมูลจำเป็นต้องเกิดขึ้นที่ระบบต้นน้ำ

• โครงสร้างข้อมูลปลายทางที่ปรับเปลี่ยนยาก: หากระบบปลายทางของคุณไม่สามารถรองรับข้อมูลดิบหรือข้อมูลแบบกึ่งมีโครงสร้างได้ แนวทางของ ELT ในการโหลดข้อมูลเข้ามาก่อน จะสร้างปัญหามากกว่าที่จะช่วยแก้ไข

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

ความท้าทายที่มาพร้อมกับ ELT มีอะไรบ้าง

การจัดเก็บข้อมูลดิบไว้ในคลังข้อมูลเป็นสิ่งที่มีประสิทธิภาพ แต่อาจมาพร้อมกับความท้าทายด้านการกำกับดูแลและต้นทุน

ควรพิจารณาความท้าทายที่อาจเกิดขึ้นจาก ELT ดังต่อไปนี้

การควบคุมการเข้าออก

ตารางข้อมูลดิบมักจะมีข้อมูลที่ไม่ควรเปิดให้เข้าถึงได้เป็นการทั่วไป เช่น ข้อมูลส่วนตัวที่ใช้ระบุตัวตนได้ (PII), บันทึกทางการเงิน หรือข้อมูลระบุตัวตนภายในองค์กร ในกระบวนการ ETL ฟิลด์ที่ละเอียดอ่อนเหล่านี้สามารถถูกพรางข้อมูลหรือตัดทิ้งไปได้ก่อนที่ข้อมูลจะส่งไปถึงปลายทาง แต่ในกระบวนการ ELT ข้อมูลจะถูกนำเข้ามาก่อน ดังนั้น หากไม่มีระบบการรักษาความปลอดภัยระดับแถว การพรางข้อมูลระดับคอลัมน์ หรือการกำหนดบทบาทหน้าที่ในคลังข้อมูลอย่างรัดกุม นักวิเคราะห์ก็อาจจะสืบค้นฟิลด์ข้อมูลที่พวกเขาไม่ควรมีสิทธิ์เห็นได้

คุณภาพของข้อมูล

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

การจัดการต้นทุน

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

เวิร์กโฟลว์ ELT จัดการข้อมูลการชำระเงินอย่างไร

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

Stripe Data Pipeline เป็นตัวเลือกแบบเนทีฟที่สร้างขึ้นมาโดยตรงภายในแดชบอร์ด Stripe โดยระบบจะซิงค์ข้อมูลและรายงานของ Stripe ไปยัง Snowflake, Databricks, Amazon Redshift และแพลตฟอร์มอื่นๆ ได้ในไม่กี่คลิก โดยไม่ต้องเขียนโค้ด ไม่ต้องตั้งค่าตัวเชื่อมต่อ และไม่ต้องจัดการรหัสผ่านแยกต่างหาก ซึ่งการซิงค์ข้อมูลนี้จะทำงานโดยใช้โครงสร้างพื้นฐานของ Stripe เอง ดังนั้น จึงไม่มีระบบของบุคคลที่สามเข้ามาจัดการกับข้อมูลทางการเงินของคุณในระหว่างการส่งข้อมูล

รายละเอียดเฉพาะเจาะจงที่ควรทราบมีดังนี้

• ความครอบคลุมข้อมูลที่ผ่านมา: Stripe Data Pipeline มีข้อมูลย้อนหลังตั้งแต่ที่คุณเริ่มใช้บัญชี Stripe มากกว่าที่จะเริ่มจากจุดที่คุณเปิดใช้งานการซิงค์

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

• ความสมบูรณ์ของข้อมูล: นอกจากข้อมูลดิบของออบเจกต์แล้ว Stripe Data Pipeline ยังให้คุณเข้าถึงรายงานทางการเงินที่สร้างไว้ล่วงหน้าและชุดข้อมูลที่คัดสรรมาแล้วได้อีกด้วย ซึ่งสามารถเร่งการรายงานและลดงานการแปลงข้อมูลสำหรับกรณีการใช้งานทั่วไป เช่น รายรับตามแบบแผนล่วงหน้าต่อเดือน (MRR) และการวิเคราะห์การฉ้อโกงได้