เดลต้า: แพลตฟอร์มการซิงโครไนซ์ข้อมูลและการเพิ่มคุณค่า

โดยคาดว่าจะมีการเปิดตัวกระแสใหม่ในอัตราดังกล่าว วิศวกรข้อมูล เราได้เตรียมแปลเนื้อหาที่น่าสนใจ

ทบทวน

เราจะพูดถึงรูปแบบที่ได้รับความนิยมพอสมควรโดยแอปพลิเคชันใช้ที่เก็บข้อมูลหลายแห่ง โดยที่แต่ละร้านใช้เพื่อวัตถุประสงค์ของตนเอง เช่น เพื่อจัดเก็บข้อมูลรูปแบบมาตรฐาน (MySQL เป็นต้น) ให้ความสามารถในการค้นหาขั้นสูง (ElasticSearch, ฯลฯ ) .) การแคช (Memcached ฯลฯ ) และอื่น ๆ โดยทั่วไป เมื่อใช้ที่เก็บข้อมูลหลายแห่ง หนึ่งในนั้นทำหน้าที่เป็นที่เก็บข้อมูลหลัก และอีกแห่งทำหน้าที่เป็นที่จัดเก็บอนุพันธ์ ปัญหาเดียวคือวิธีซิงโครไนซ์ที่เก็บข้อมูลเหล่านี้

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

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

โซลูชั่นที่มีอยู่

เข้าคู่

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

ปัญหา:

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

เปลี่ยนตารางบันทึก

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

ปัญหา:

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

ปัญหาอีกประการหนึ่งอยู่ที่การได้รับการเปลี่ยนแปลงสคีมาในระบบที่ไม่รองรับการเปลี่ยนแปลงสคีมาของทรานแซคชัน [1] [2] เช่น MySQL ดังนั้นรูปแบบของการเปลี่ยนแปลง (เช่น การเปลี่ยนแปลงสคีมา) และการบันทึกแบบทรานแซคชันในตารางบันทึกการเปลี่ยนแปลงจะไม่ทำงานเสมอไป

ธุรกรรมแบบกระจาย

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

ปัญหา:

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

สันดอน

เดลต้าได้รับการออกแบบเพื่อจัดการกับข้อจำกัดของโซลูชั่นการซิงโครไนซ์ข้อมูลที่มีอยู่ และยังช่วยให้สามารถเพิ่มประสิทธิภาพข้อมูลได้ทันที เป้าหมายของเราคือการแยกความซับซ้อนเหล่านี้ออกจากนักพัฒนาแอปพลิเคชัน เพื่อให้พวกเขาสามารถมุ่งเน้นไปที่การนำฟังก์ชันทางธุรกิจไปใช้อย่างเต็มที่ ต่อไปเราจะอธิบาย "Movie Search" ซึ่งเป็นกรณีการใช้งานจริงของ Delta ของ Netflix

Netflix ใช้สถาปัตยกรรมไมโครเซอร์วิสกันอย่างแพร่หลาย และไมโครเซอร์วิสแต่ละรายการมักจะให้บริการข้อมูลประเภทเดียว ข้อมูลพื้นฐานเกี่ยวกับภาพยนตร์มีอยู่ในไมโครเซอร์วิสที่เรียกว่าบริการภาพยนตร์ และข้อมูลที่เกี่ยวข้อง เช่น ข้อมูลเกี่ยวกับผู้ผลิต นักแสดง ผู้จำหน่าย และอื่นๆ ได้รับการจัดการโดยไมโครเซอร์วิสอื่นๆ อีกหลายรายการ (ได้แก่ Deal Service, Talent Service และ Vendor Service)
ผู้ใช้ทางธุรกิจที่ Netflix Studios มักจะต้องค้นหาตามเกณฑ์ภาพยนตร์ต่างๆ ซึ่งเป็นเหตุผลว่าทำไมการค้นหาข้อมูลที่เกี่ยวข้องกับภาพยนตร์ทั้งหมดจึงเป็นสิ่งสำคัญมากสำหรับพวกเขา

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

รูปที่ 1. ระบบโพลไปยังเดลต้า
หลังจากใช้เดลต้า ระบบถูกทำให้ง่ายขึ้นเป็นระบบที่ขับเคลื่อนด้วยเหตุการณ์ ดังแสดงในรูปต่อไปนี้ เหตุการณ์ CDC (Change-Data-Capture) จะถูกส่งไปยังหัวข้อ Keystone Kafka โดยใช้ Delta-Connector แอปพลิเคชัน Delta ที่สร้างขึ้นโดยใช้ Delta Stream Processing Framework (ตาม Flink) รับเหตุการณ์ CDC จากหัวข้อ เสริมคุณค่าด้วยการเรียกไมโครเซอร์วิสอื่นๆ และสุดท้ายก็ส่งข้อมูลที่ได้รับการเสริมประสิทธิภาพไปยังดัชนีการค้นหาใน Elasticsearch กระบวนการทั้งหมดเกิดขึ้นเกือบจะแบบเรียลไทม์ นั่นคือทันทีที่มีการเปลี่ยนแปลงในคลังข้อมูล ดัชนีการค้นหาจะได้รับการอัปเดต

รูปที่ 2 ไปป์ไลน์ข้อมูลโดยใช้ Delta
ในส่วนต่อไปนี้ เราจะอธิบายการทำงานของ Delta-Connector ซึ่งเชื่อมต่อกับพื้นที่จัดเก็บข้อมูลและเผยแพร่เหตุการณ์ CDC ไปยังเลเยอร์การขนส่ง ซึ่งเป็นโครงสร้างพื้นฐานการส่งข้อมูลแบบเรียลไทม์ที่กำหนดเส้นทางเหตุการณ์ CDC ไปยังหัวข้อ Kafka และในตอนท้ายสุด เราจะพูดถึงเฟรมเวิร์กการประมวลผลสตรีมเดลต้า ซึ่งนักพัฒนาแอปพลิเคชันสามารถใช้สำหรับการประมวลผลข้อมูลและตรรกะการเพิ่มคุณค่า

CDC (การเปลี่ยนแปลง-ข้อมูล-การจับ)

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

Delta-Connector รองรับคุณสมบัติเพิ่มเติมหลายประการ เช่น:

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

ปัจจุบันเรารองรับ MySQL และ Postgres รวมถึงการปรับใช้บน AWS RDS และ Aurora เรายังรองรับ Cassandra (มัลติมาสเตอร์) ด้วย คุณสามารถหารายละเอียดเพิ่มเติมเกี่ยวกับ Delta-Connector ได้ที่นี่ โพสต์บล็อก.

คาฟคาและชั้นการขนส่ง

เลเยอร์การขนส่งเหตุการณ์ของเดลต้าสร้างขึ้นจากบริการส่งข้อความของแพลตฟอร์ม หลักสำคัญ.

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

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

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

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

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

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

กรอบการประมวลผลสตรีม

เลเยอร์การประมวลผลของเดลต้าสร้างขึ้นบนแพลตฟอร์ม Netflix SPAaS ซึ่งให้การผสานรวม Apache Flink เข้ากับระบบนิเวศของ Netflix แพลตฟอร์มดังกล่าวมีอินเทอร์เฟซผู้ใช้ที่จัดการการปรับใช้งาน Flink และการจัดกลุ่มคลัสเตอร์ Flink ที่ด้านบนของแพลตฟอร์มการจัดการคอนเทนเนอร์ Titus ของเรา อินเทอร์เฟซยังจัดการการกำหนดค่างานและอนุญาตให้ผู้ใช้ทำการเปลี่ยนแปลงการกำหนดค่าแบบไดนามิกโดยไม่ต้องคอมไพล์งาน Flink ใหม่

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

รูปที่ 3 ตัวอย่างการเพิ่มคุณค่าบน DSL ในเดลต้า

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

กรอบการประมวลผลเดลต้าสตรีมประกอบด้วยโมดูลหลักสองโมดูล ได้แก่ โมดูล DSL และ API และโมดูลรันไทม์ โมดูล DSL และ API มี DSL และ UDF (ฟังก์ชันที่ผู้ใช้กำหนด) เพื่อให้ผู้ใช้สามารถเขียนตรรกะการประมวลผลของตนเองได้ (เช่น การกรองหรือการแปลง) โมดูลรันไทม์จัดให้มีการใช้งานตัวแยกวิเคราะห์ DSL ที่สร้างการแสดงขั้นตอนการประมวลผลภายในโมเดล DAG องค์ประกอบการดำเนินการตีความโมเดล DAG เพื่อเริ่มต้นคำสั่ง Flink จริง และเรียกใช้แอปพลิเคชัน Flink ในท้ายที่สุด สถาปัตยกรรมของกรอบงานแสดงไว้ในรูปต่อไปนี้

รูปที่ 4 สถาปัตยกรรมกรอบการประมวลผลเดลต้าสตรีม

วิธีนี้มีข้อดีหลายประการ:

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

การใช้ในการผลิต

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

รูปที่ 5 สถาปัตยกรรมระดับสูงของเดลต้า

บลาโกดาเรนนอสตี

เราขอขอบคุณบุคคลต่อไปนี้ที่มีส่วนร่วมในการสร้างและพัฒนา Delta ที่ Netflix: Allen Wang, Charles Zhao, Jaebin Yoon, Josh Snyder, Kasturi Chatterjee, Mark Cho, Olof Johansson, Piyush Goyal, Prashanth Ramdas, Raghuram Onti ศรีนิวาสัน, แซนดีพ กุปต้า, สตีเว่น วู, ทารังกา กาเมธิเก, หยุน หวาง และเจิ้นจง ซู

แหล่งที่มา

1. dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
2. dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
3. Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: การประมวลผลเหตุการณ์ออนไลน์ ชุมชน พลอากาศเอก 62(5): 43–49 (2019) ดอย: doi.org/10.1145/3312527

ลงทะเบียนเข้าร่วมสัมมนาผ่านเว็บฟรี: “เครื่องมือสร้างข้อมูลสำหรับ Amazon RedShift Storage”

ที่มา: will.com