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

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

ด้านล่างนี้ เราจะอธิบายว่าแต่ละโมเดลทำงานอย่างไร เมื่อใดที่ ETL หรือ ELT จะสมเหตุสมผลกว่า และตัวเชื่อมต่อที่สร้างขึ้นโดยเฉพาะเหมาะสมกับแนวทางทั้งสองสำหรับแหล่งข้อมูลเฉพาะอย่างไร

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

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

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

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

ไปป์ไลน์ ETL กับ ELT แตกต่างกันอย่างไร

ETL ย่อมาจาก “Extract, Transform, Load” (ดึง แปลง โหลด) ในโมเดล ETL คุณจะดึงข้อมูลจากระบบต้นทาง รันข้อมูลผ่านเลเยอร์การแปลงที่ล้างข้อมูล จัดรูปแบบใหม่ และกรองข้อมูล จากนั้นจึงโหลดผลลัพธ์ที่ประมวลผลไปยังปลายทาง เช่น คลังข้อมูลหรือดาต้ามาร์ท

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

ELT ย่อมาจาก “Extract, Load, Transform” (ดึง โหลด แปลง) ซึ่งจะสลับขั้นตอนสองขั้นตอนสุดท้าย ข้อมูลดิบจะไปถึงปลายทางก่อน จากนั้นการแปลงข้อมูลจะทำงานภายในคลังข้อมูลโดยใช้ระบบประมวลผลของตัวเอง

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

ETL ทำงานอย่างไร

ไปป์ไลน์ ETL ทำงานในสามขั้นตอน โดยแต่ละขั้นตอนมีหน้าที่รับผิดชอบที่แตกต่างกัน

การทำงานของ ETL มีดังต่อไปนี้

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

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

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

ETL ยังคงเหมาะสมที่จะใช้ในสถานการณ์เฉพาะดังต่อไปนี้

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

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

• สภาพแวดล้อมเอดจ์: ระบบ Internet of Things (IoT) และระบบฝังตัวที่ส่งข้อมูลไปยังโครงสร้างพื้นฐานส่วนกลางมักจะไม่สามารถส่งเพย์โหลดดิบขนาดใหญ่ได้ ซึ่งทำให้การแปลงข้อมูลในพื้นที่ก่อนส่งข้อมูลกลายเป็นเรื่องจำเป็นในทางปฏิบัติ

• หนี้สินจากไปป์ไลน์รุ่นเก่า: องค์กรที่จัดตั้งมาอย่างยาวนานหลายแห่งมีไปป์ไลน์ ETL ที่รันอย่างเสถียรมานานหลายปี การสร้างไปป์ไลน์ใหม่ในรูปแบบ ELT มีความเสี่ยงที่อาจจะไม่คุ้มเสี่ยง

ELT ทำงานอย่างไร

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

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

ELT จึงเป็นตัวเลือกที่ชาญฉลาดด้วยเหตุผลต่อไปนี้

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

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

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

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

คุณจะเลือกใช้ระหว่าง ETL กับ ELT อย่างไร

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

สิ่งที่คุณต้องพิจารณามีดังต่อไปนี้

ปริมาณและความเร็วของข้อมูล

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

ไปป์ไลน์ที่มีปริมาณข้อมูลน้อยกว่าและมีตรรกะการแปลงข้อมูลที่เสถียรและชัดเจนอาจใช้ ETL ต่อไปได้โดยไม่เกิดปัญหามากนัก

ความเป็นเจ้าของการแปลงข้อมูล

หากการแปลงข้อมูลของคุณใช้ SQL และอยู่ภายใต้การดูแลของวิศวกรวิเคราะห์ข้อมูลที่ต้องปรับตัวอย่างอย่างรวดเร็ว การใช้ ELT ร่วมกับ dbt หรือเครื่องมือที่คล้ายกันน่าจะเหมาะสมกว่า

หากการแปลงข้อมูลของคุณเขียนโค้ดด้วย Python หรือ Java และอยู่ภายใต้การดูแลของทีมวิศวกรรมข้อมูล ETL อาจทำงานร่วมกับชุดเครื่องมือที่คุณมีอยู่ได้อย่างราบรื่น

การเข้าถึงข้อมูลดิบ

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

การกำกับดูแลและการปฏิบัติตามข้อกำหนด

หากต้องมีการปกปิดข้อมูลหรือทำให้ข้อมูลบางอย่างไม่สามารถระบุตัวตนได้ก่อนที่จะส่งไปยังปลายทางที่ใช้ร่วมกัน ETL จะช่วยให้คุณบังคับใช้ข้อกำหนดดังกล่าวผ่านสถาปัตยกรรมของระบบได้

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

ขั้นตอนการทำงานของทีม

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

ตัวเชื่อมต่อข้อมูลเหมาะสมกับไปป์ไลน์ ETL และ ELT อย่างไร

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

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

Stripe Data Pipeline จะจัดการปัญหานี้โดยตรง ดังต่อไปนี้

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

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

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

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