- Yelp ได้ทบทวนวิธีการโหลดข้อมูลเข้า Redshift ให้มีประสิทธิภาพมากขึ้น หลังจากความต้องการใช้ข้อมูลของผู้บริโภคเพิ่มขึ้นในช่วงหลัง
- บทความนี้อธิบายว่า DBT สามารถทำงานร่วมกับ Redshift Spectrum ได้อย่างราบรื่น เพื่ออ่านข้อมูลจาก Data Lake เข้าสู่ Redshift ช่วยลดเวลาในการรันลงอย่างมาก แก้ปัญหาคุณภาพข้อมูล และเพิ่มประสิทธิภาพการทำงานของนักพัฒนา
จุดเริ่มต้น
- วิธีการโหลดข้อมูลแบบแบตช์เข้า Redshift ใช้งานได้ผลดีมาหลายปี แต่ยังคงมองหาแนวทางปรับปรุงอย่างต่อเนื่อง
- โดยหลักแล้วใช้ Spark jobs เพื่ออ่านข้อมูลจาก S3 แล้วเผยแพร่ไปยัง data pipeline ภายในองค์กรที่อิง Kafka เพื่อนำข้อมูลเข้าสู่ทั้ง Data Lake และ Redshift
- อย่างไรก็ตาม เริ่มพบปัญหาหลายประการ:
- ประสิทธิภาพ: ชุดข้อมูลขนาดใหญ่ (มากกว่า 1 ล้านแถวต่อวัน) เริ่มเกิดความล่าช้า โดยสาเหตุหลักมาจากการสแกนทั้งตารางเพื่อป้องกันไม่ให้ primary key ซ้ำระหว่างการ upsert
- การเปลี่ยนแปลงสคีมา: ตารางส่วนใหญ่ใช้ Avro schema การเปลี่ยนสคีมาบางครั้งซับซ้อน เพราะต้องผ่านหลายขั้นตอนในการสร้างและลงทะเบียน Avro schema ใหม่
- แบ็กฟิล: การรองรับแบ็กฟิลสำหรับการแก้ไขข้อมูลยังไม่ดีนัก เพราะไม่มีวิธีง่าย ๆ ในการแก้ไขแถวแบบ in-place จึงมักต้องลบข้อมูลด้วยตนเองก่อนเขียนข้อมูลที่แก้ไขแล้วกลับไปทั้งพาร์ทิชัน
- คุณภาพข้อมูล: การเขียนข้อมูลไปยัง Data Lake และ Redshift แบบขนานกันทำให้มีความเสี่ยงที่ข้อมูลจะต่างกัน เช่น ความแตกต่างของชนิดข้อมูลระหว่าง data store ทั้งสองแห่ง
ปรับปรุงการโหลดเข้า Redshift ด้วย DBT
- เมื่อพิจารณาวิธีเคลื่อนย้ายข้อมูลให้มีประสิทธิภาพยิ่งขึ้น จึงเลือกใช้ AWS Redshift Spectrum ซึ่งเป็นเครื่องมือที่สร้างมาโดยเฉพาะเพื่อให้ Redshift สามารถ query ข้อมูลใน Data Lake ได้
- โดยทั่วไปตารางใน Data Lake มักมีสคีมาที่อัปเดตที่สุด จึงตัดสินใจใช้ Data Lake เป็นแหล่งข้อมูลสำหรับแบตช์ของ Redshift แทน S3 ซึ่งไม่เพียงช่วยลดความต่างของข้อมูล แต่ยังสอดคล้องกับแนวปฏิบัติที่ถือให้ Data Lake เป็นแหล่งข้อมูลจริงเพียงหนึ่งเดียว
- สำหรับการติดตั้งใช้งาน Spectrum ต้องการสคีมาที่กำหนดไว้ ซึ่งมีอยู่แล้วใน Glue สำหรับตาราง Data Lake ของเรา การตั้งค่าเพิ่มเติมที่ต้องทำมีเพียงเพิ่มตาราง Data Lake เป็น external tables เพื่อให้ Redshift เข้าถึงได้ผ่าน SQL query แบบง่าย ๆ
- ก่อนหน้านี้เริ่มนำ DBT มาใช้กับชุดข้อมูลอื่นอยู่แล้ว และมันก็ดูเหมาะอย่างยิ่งสำหรับการเก็บ Redshift Spectrum queries ใน pipeline ด้วย DBT เด่นด้าน data transformation และช่วยผลักดันการเขียน SQL แบบแยกเป็นโมดูลและควบคุมเวอร์ชันได้
- แทนที่ Spark jobs จะอ่านจาก S3 ไปยัง Redshift ตอนนี้ใช้ DBT เพื่อคัดลอกข้อมูลจาก Data Lake เข้า Redshift โดยตรง นอกจาก DBT จะให้ข้อดีเด่นอย่าง reproducibility, flexibility และ data lineage แล้ว ยังช่วยแก้ปัญหาหลายข้อที่กล่าวไว้ข้างต้นได้ด้วย
การเปลี่ยนสคีมาที่ง่ายขึ้น
- เพื่อทำให้การเปลี่ยนสคีมาง่ายขึ้น ได้ใช้ configuration argument
on_schema_change ของ DBT
- ตั้งค่าเป็น
append_new_columns เพื่อให้มั่นใจว่าคอลัมน์จะไม่ถูกลบออกหากข้อมูลขาเข้าไม่มีคอลัมน์นั้น
- นอกจากนี้ยังใช้ DBT contracts เป็นชั้นป้องกันลำดับที่สอง เพื่อตรวจสอบว่าข้อมูลที่กำลังเขียนตรงกับการตั้งค่าของโมเดล
แบ็กฟิลที่ต้องทำน้อยลงด้วยมือ
- แบ็กฟิลทำได้ง่ายขึ้นมากผ่าน DBT โดยใช้ configuration argument
pre_hook เพื่อระบุ query ที่จะให้รันก่อนโมเดลทันที
- วิธีนี้ช่วยให้สามารถลบข้อมูลของพาร์ทิชันที่จะเขียนได้อย่างอัตโนมัติมากขึ้น
- ตอนนี้สามารถรับประกัน idempotency ได้แล้ว จึงทำแบ็กฟิลได้โดยไม่ต้องกังวลว่าข้อมูลเก่าจะไม่ถูกลบออก
การกำจัดข้อมูลซ้ำ
- เพื่อจัดการกับแถวที่ซ้ำกัน ได้เพิ่มชั้น deduplication ใน SQL และตรวจสอบความถูกต้องด้วย DBT tests
- DBT มี unique column test แบบ built-in แต่ต้องสแกนทั้งตาราง จึงไม่เหมาะกับตารางขนาดใหญ่
- ทางเลือกคือใช้ฟังก์ชัน
expect_column_values_to_be_unique จากแพ็กเกจ dbt_expectations ซึ่งช่วยให้กำหนด row condition เพื่อสแกนเฉพาะแถวที่เพิ่งถูกเขียนล่าสุดได้
ประสิทธิภาพที่ดีขึ้น
- ผลลัพธ์ที่เห็นได้ชัดที่สุดคือการปรับปรุงประสิทธิภาพ โดยเฉพาะกับชุดข้อมูล Redshift ที่มีปัญหามากที่สุด:
- การเขียนข้อมูลเคยใช้เวลาประมาณ 2 ชั่วโมง แต่ตอนนี้โดยทั่วไปใช้เพียง 10 นาที
- ก่อนหน้านี้เคยมีความล่าช้าสูงสุดถึง 6 ชั่วโมงต่อเดือน แต่ตอนนี้ไม่มีความล่าช้าแล้ว ซึ่งช่วยลดภาระงานตอบสนอง incident ของทีม on-call ได้มาก
- การอัปเกรดสคีมาเดิมเป็นกระบวนการหลายขั้นตอนที่ยาวนาน ตอนนี้ปรับปรุงเหลือกระบวนการ 3 ขั้นตอนที่ใช้เวลาเพียงไม่กี่ชั่วโมง
ความสอดคล้องของข้อมูลที่ดีขึ้น
- การกำจัดการแตกแขนงของ data flow ทำให้มั่นใจมากขึ้นว่าข้อมูลจะไม่แตกต่างกันระหว่าง data store ต่าง ๆ
- ข้อมูลทั้งหมดที่เข้า Redshift ต้องผ่าน Data Lake ก่อน จึงช่วยรับประกันได้ดียิ่งขึ้นว่า Data Lake จะยังคงเป็นแหล่งข้อมูลจริงเพียงหนึ่งเดียว
บทสรุป
- หลังจากความสำเร็จของการย้ายระบบ ได้ขยายการเปลี่ยนแปลงนี้ไปยังชุดข้อมูลอื่นอีกประมาณ 12 ชุด และพบประโยชน์คล้ายกันโดยรวม
- ด้วยการใช้เครื่องมืออย่าง AWS Redshift Spectrum และ DBT ทำให้สามารถพัฒนาโครงสร้างพื้นฐานให้สอดรับกับความต้องการด้านข้อมูลที่เปลี่ยนแปลงไป และส่งมอบคุณค่าได้มากขึ้นแก่ผู้ใช้และผู้มีส่วนได้ส่วนเสีย
ยังไม่มีความคิดเห็น