Data ingestion เป็นขั้นตอนแรกในไปป์ไลน์ข้อมูลทุกประเภท ซึ่งหมายถึงกระบวนการเก็บข้อมูลจากระบบต้นทางและย้ายไปยังคลังเก็บข้อมูล Data Lake หรือแพลตฟอร์มการวิเคราะห์เพื่อทำการค้นหา

เมื่อ Data ingestion ล้มเหลว แดชบอร์ดจะไม่อัปเดต การกระทบยอดอาจพัง และโมเดลแมชชีนเลิร์นนิงจะได้รับการฝึกด้วยข้อมูลที่ไม่สมบูรณ์ ยิ่งไปกว่านั้น ข้อมูลที่ไม่ดียังอาจส่งผลต่อผลกำไรของคุณด้วย องค์กรกว่า 25% รายงานว่าตนสูญเสียรายได้ 5 ล้านดอลลาร์สหรัฐขึ้นไปต่อปีเนื่องจากข้อมูลมีคุณภาพต่ำ

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

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

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

• Ingestion ที่น่าเชื่อถือขึ้นอยู่กับ 2 สิ่ง คือ ความสมบูรณ์ของข้อมูล (เช่น ข้อมูลที่ควรมีก็ต้องมีอยู่ครบถ้วน) และความตรงต่อเวลา (เช่น ข้อมูลมาถึงก่อนที่บุคคลแรกจะใช้งาน)

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

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

ในบริบทของการชำระเงิน Data ingestion อาจรวมถึงการเก็บข้อมูลจากแหล่งที่มาที่หลากหลาย ซึ่งได้แก่ ระบบบันทึกการขาย (POS) เว็บไซต์อีคอมเมิร์ซ และเกตเวย์การชำระเงิน

Data ingestion ประเภทหลักๆ มีอะไรบ้าง

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

โดยคุณควรพิจารณาวิธีหลักๆ ดังนี้

Batch ingestion

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

Streaming ingestion

Streaming ingestion จะประมวลผลเหตุการณ์เมื่อสร้างขึ้น ซึ่งจะลดความล่าช้าลงเหลือไม่กี่วินาทีหรือไม่ถึง โครงสร้างพื้นฐานจะมีความต้องการสูงกว่า โดยปกติคุณจะต้องทำงานกับระบบอย่าง Apache Kafka หรือระบบบนคลาวด์ที่เทียบเท่า และแอปพลิเคชันฝั่งผู้บริโภคจะต้องจัดการเหตุการณ์ที่ไม่เป็นไปตามลำดับรวมถึงการส่งมอบแบบอย่างน้อย 1 ครั้ง โดยทั่วไปวิธีนี้จะเหมาะสมเมื่อมูลค่าของข้อมูลต้องอาศัยสัญญาณการฉ้อโกง สินค้าคงคลังแบบสด และการปรับเปลี่ยนในแบบของตัวเองแบบเรียลไทม์

Change Data Capture

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

กรณีการใช้งาน Data ingestion ทั่วไปมีอะไรบ้าง

Data ingestion มีไว้เพื่อรองรับกระบวนการปลายน้ำบางอย่าง รูปแบบที่คุณเลือกจะขึ้นอยู่กับวิธีการนำข้อมูลไปใช้เป็นอย่างมาก

กรณีการใช้งาน Data ingestion ทั่วไปมีดังนี้

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

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

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

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

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

Data ingestion ควรมีลักษณะอย่างไร

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

Data ingestion ที่ดีจะต้องมีความสมบูรณ์ ข้อมูลที่ควรมีก็ต้องมีอยู่ครบถ้วน เลเยอร์ Ingestion ที่ออกแบบมาอย่างดีจะจัดการกับการลบข้อมูลที่ซ้ำซ้อน การเติมเต็มช่องว่าง และการตรวจจับระเบียนที่มาช้าก่อนที่จะกลายเป็นข้อผิดพลาดในการรายงาน

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

ความท้าทายหลักของ Data ingestion คืออะไร

Ingestion ดูเหมือนเป็นเรื่องง่ายจนกว่าคุณจะต้องรันข้อมูลข้ามระบบต้นทางหลายๆ ระบบ ซึ่งความท้าทายเกี่ยวกับ Data ingestion ต่อไปนี้มักทำให้เกิดปัญหาอยู่เสมอ

ความปลอดภัยและการเปิดเผยข้อมูล

การย้ายข้อมูลที่ละเอียดอ่อน (เช่น ธุรกรรมทางการเงิน ข้อมูลส่วนตัวที่ใช้ระบุตัวตนได้ บันทึกการชำระเงิน) ผ่านโครงสร้างพื้นฐาน Ingestion จะสร้างความเสี่ยงในทุกๆ ขั้นตอน ทีมงานที่กำหนดเส้นทางข้อมูลการชำระเงินผ่านเครื่องมือเชื่อมต่อ Extract, Transform, Load (ETL) จากภายนอก ถือเป็นการเปิดโอกาสให้ผู้จัดจำหน่ายรายนั้นเข้าถึงประวัติธุรกรรมทั้งหมดได้ ซึ่งจะยอมรับได้หรือไม่นั้น ก็ขึ้นอยู่กับสัญญาของผู้จัดจำหน่าย การปฏิบัติตามข้อกำหนด และความเสี่ยงที่ยอมรับได้

การปรับขนาด

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

ความกระจัดกระจาย

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

ความล้มเหลวด้านคุณภาพ

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

Data ingestion แตกต่างจาก ETL และ ELT อย่างไร

Data ingestion, ETL และ ELT อธิบายถึงส่วนที่ทับซ้อนกันของไปป์ไลน์เดียวกัน แต่มีความหมายต่างกัน

• Data ingestion: คือการย้ายข้อมูลจากแหล่งที่มาไปยังระบบเป้าหมาย ซึ่งเป็นเรื่องของการส่งและการส่งมอบ โดยไม่ได้พิจารณาว่าข้อมูลมีการเปลี่ยนแปลงระหว่างการส่งหรือไม่
  
• Extract, transform, load (ETL): นี่คือสถาปัตยกรรมที่มีการสกัดข้อมูลจากแหล่งที่มา นำมาแปลงในระหว่างทาง (ในอดีตมักจะทำในเครื่องมือแปลงข้อมูลเฉพาะหรือเซิร์ฟเวอร์พักข้อมูล) และโหลดลงในปลายทางในรูปแบบสุดท้ายที่พร้อมสำหรับการสืบค้น การแปลงข้อมูลจะเกิดขึ้นก่อนที่ข้อมูลจะมาถึง
  
• Extract, load, transform (ELT): เป็นสถาปัตยกรรมแบบเดียวกันแต่สลับสองขั้นตอนสุดท้าย ข้อมูลดิบจะส่งไปยังคลังข้อมูลก่อน และการแปลงข้อมูลจะเกิดขึ้นที่นั่นโดยใช้ภาษาการสืบค้นที่มีโครงสร้าง (SQL) หรือเครื่องมือต่างๆ เช่น Data Build Tool (DBT) สิ่งนี้กลายเป็นเรื่องที่ทำได้จริงเนื่องจากคลังข้อมูลบนคลาวด์มีราคาถูกลงและทรงพลังมากพอที่จะเรียกใช้การแปลงข้อมูลจำนวนมากในขณะที่ขยายธุรกิจ และปัจจุบันถือเป็นรูปแบบหลักสำหรับสแต็กข้อมูลสมัยใหม่
  

ผู้ให้บริการชำระเงินช่วยเรื่อง Data ingestion ได้อย่างไร

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

Stripe Data Pipeline ช่วยเรื่อง Data ingestion ดังนี้

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

• ข้อมูลในอดีต: เมื่อเชื่อมต่อแล้ว คุณจะเข้าถึงประวัติ Stripe แบบเต็มได้ ไม่ใช่เพียงข้อมูลนับตั้งแต่วันที่เชื่อมต่อเป็นต้นไป

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

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