Netflix เพิ่งเปิดตัว Unified Data Architecture (UDA) ซึ่งเป็นระบบที่ออกแบบมาเพื่อแก้ไขปัญหาการกระจัดกระจายของข้อมูลในสแต็กเทคโนโลยีขนาดใหญ่ของพวกเขา การประกาศนี้ได้จุดประกายการอภิปรายอย่างเข้มข้นในชุมชนเทคโนโลยีเกี่ยวกับว่าโมเดลข้อมูลสากลเป็นทางออกหรือปัญหาที่รอเกิดขึ้น
คำมั่นสัญญาและอันตรายของโมเดลข้อมูลสากล
UDA ของ Netflix มีเป้าหมายให้ทีมต่างๆ สามารถสร้างโมเดลครั้งเดียวแล้วนำไปใช้ได้ทุกที่ โดยการสร้างแหล่งข้อมูลเดียวที่เป็นความจริงสำหรับแนวคิดทางธุรกิจ เช่น ภาพยนตร์ นักแสดง และข้อมูลผู้ใช้ ระบบนี้จะสร้างสคีมาโดยอัตโนมัติสำหรับแพลตฟอร์มต่างๆ ตั้งแต่ GraphQL APIs ไปจนถึงตารางฐานข้อมูล เพื่อให้มั่นใจในความสอดคล้องกันทั่วทั้งสถาปัตยกรรมไมโครเซอร์วิสที่แผ่กิ่งก้านสาขาของ Netflix
อย่างไรก็ตาม ชุมชนเทคโนโลยีมีความเห็นแตกแยกว่าแนวทางนี้จะได้ผลในทางปฏิบัติหรือไม่ นักพัฒนาหลายคนชี้ให้เห็นถึงความขัดแย้งพื้นฐาน ในขณะที่โมเดลแบบรวมศูนย์สัญญาว่าจะให้ความสอดคล้อง แต่พวกเขายังสร้างคอขวดขององค์กรด้วย การเปลี่ยนแปลงใดๆ ต่อคำจำกัดความข้อมูลที่ใช้ร่วมกันจะต้องได้รับการอนุมัติจากหลายทีม ซึ่งอาจทำให้การพัฒนาช้าลงอย่างมีนัยสำคัญ
องค์ประกอบหลักของ UDA :
- Domain Models: จับภาพแนวคิดทางธุรกิจและความสัมพันธ์ต่างๆ
- Mappings: เชื่อมต่อ domain models กับการจัดเก็บข้อมูลทางกายภาพ (ฐานข้อมูล, APIs)
- Projections: สร้าง schemas สำหรับระบบต่างๆ ( GraphQL , Avro , SQL )
- Knowledge Graph: แสดงความสัมพันธ์ระหว่างแนวคิดข้อมูลต่างๆ
- Upper: Metamodel สำหรับการขยายความสามารถ (รายละเอียดยังไม่เปิดเผยต่อสาธารณะ)
บทเรียนจากความพยายามในอดีต
การอภิปรายเผยให้เห็นว่า Netflix ไม่ใช่บริษัทแรกที่พยายามใช้แนวทางนี้ นักพัฒนาได้แบ่งปันประสบการณ์กับระบบที่คล้ายกันที่ Uber (เรียกว่า Dragon) และองค์กรขนาดใหญ่อื่นๆ ความพยายามเหล่านี้ส่วนใหญ่ล้มเหลวโดยสิ้นเชิงหรือประสบความสำเร็จเฉพาะในกรณีการใช้งานที่จำกัดและเฉพาะเจาะจงเท่านั้น
ข้อมูลเชิงลึกที่สำคัญจากชุมชนมุ่งเน้นไปที่ธรรมชาติของแนวคิดทางธุรกิจเอง ภาพยนตร์มีความหมายที่แตกต่างกันสำหรับทีมการเงินของ Netflix (สัญญา) ทีมโครงสร้างพื้นฐาน (ไฟล์) และลูกค้า (เนื้อหาความบันเทิง) การพยายามบังคับให้บริบทที่แตกต่างกันเหล่านี้เข้าไปในคำจำกัดความสากลเดียวมักจะสร้างปัญหามากกว่าแก้ปัญหา
ความพยายามที่คล้ายคลึงกันในอุตสาหกรรม:
- ** Uber Dragon **: ระบบรวมสคีมา (ไม่เคยเปิดเป็นโอเพนซอร์ส)
- ** LinkedIn Hydra **: การต่อยอดแนวคิดของ Dragon (โอเพนซอร์ส)
- ** SAP **: แนวทางสคีมาแบบคงที่ที่ต้องการให้ลูกค้าปรับตัว
- ** Epic EMR **: ระบบการดูแลสุขภาพที่มีความท้าทายในการสร้างแบบจำลองสากลที่คล้ายคลึงกัน
ภาวะที่กลืนไม่เข้าคายไม่ออกของไมโครเซอร์วิส
นักวิจารณ์โต้แย้งว่า UDA เป็นการถอยหลังจากหลักการไมโครเซอร์วิส ซึ่งแต่ละเซอร์วิสควรเป็นเจ้าของข้อมูลของตัวเองอย่างอิสระ ความขัดแย้งคือ Netflix ช่วยทำให้สถาปัตยกรรมไมโครเซอร์วิสเป็นที่นิยม แต่ UDA ดูเหมือนจะขัดแย้งกับปรัชญานั้นด้วยการรวมศูนย์คำจำกัดความข้อมูล
นักพัฒนาบางคนตั้งคำถามว่า Netflix ได้สร้างปัญหาที่ไม่จำเป็นต้องแก้ไขหรือไม่ พวกเขาชี้ให้เห็นว่า GraphQL ได้รับการออกแบบมาเพื่อให้มุมมองข้อมูลแบบรวมศูนย์โดยไม่ต้องใช้สคีมาสากล การมีคำจำกัดความ Movie หลายแบบอาจเป็นคุณสมบัติ ไม่ใช่ข้อบกพร่อง
ความท้าทายในการนำไปใช้ทางเทคนิค
นอกเหนือจากข้อกังวลเชิงปรัชญาแล้ว ชุมชนยังระบุความท้าทายเชิงปฏิบัติกับแนวทางของ UDA การจัดการเวอร์ชันจะซับซ้อนเมื่อการเปลี่ยนแปลงสคีมาเดียวส่งผลต่อเซอร์วิสหลายสิบตัว การจัดการข้อผิดพลาดยังไม่ชัดเจน หากระบบหนึ่งตีความสคีมาสากลผิด UDA จะตรวจจับและแก้ไขปัญหาเหล่านี้ได้อย่างไร
ระบบนี้พึ่งพาเทคโนโลยี RDF และ semantic web อย่างมากซึ่งเป็นที่นิยมในช่วงกลางทศวรรษ 2000 แต่ไม่เคยได้รับการยอมรับอย่างแพร่หลาย แม้ว่าเครื่องมือเหล่านี้จะมีประสิทธิภาพ แต่ก็เพิ่มความซับซ้อนที่หลายองค์กรต้องดิ้นรนเพื่อรักษาไว้ในระยะยาว
รากฐานทางเทคนิค:
- สร้างบนพื้นฐาน RDF (Resource Description Framework)
- ใช้เทคโนโลยี semantic web ( SPARQL , OWL )
- ผสานรวมกับ Apollo Federation สำหรับ GraphQL
- รองรับการสร้าง schema อัตโนมัติในหลายรูปแบบ
- ใช้ประโยชน์จาก knowledge graph สำหรับการค้นหาข้อมูลและการติดตามแหล่งที่มา
การแลกเปลี่ยนด้านการกำกับดูแล
ข้อกังวลที่สำคัญที่สุดที่ถูกยกขึ้นมาอาจเป็นเรื่องขององค์กรมากกว่าเทคนิค โมเดลข้อมูลสากลต้องการโครงสร้างการกำกับดูแลที่แข็งแกร่งเพื่อป้องกันความวุ่นวาย ซึ่งหมายถึงคณะกรรมการ กระบวนการอนุมัติ และค่าใช้จ่ายในการประสานงานที่อาจทำให้นวัตกรรมช้าลง
นี่เป็นปัญหาทางธุรกิจโดยพื้นฐาน มากกว่าจะเป็นปัญหาทางเทคนิค แต่มีผลกระทบต่อความเร็วในการพัฒนา ดังนั้นจึงเป็นปัญหาทางเทคนิคในลำดับรอง
สถาปนิกของ Netflix ยอมรับข้อกังวลเหล่านี้ แต่โต้แย้งว่า UDA ได้รับการออกแบบมาให้อยู่ร่วมกับระบบที่มีอยู่แทนที่จะแทนที่ทั้งหมดในองค์กร พวกเขาเน้นย้ำว่าการยอมรับจะเป็นแบบสมัครใจ ไม่ใช่บังคับทั่วทั้งองค์กร
มองไปข้างหน้า
การถกเถียงนี้เน้นให้เห็นถึงความท้าทายที่กว้างขึ้นที่บริษัทเทคโนโลยีขนาดใหญ่ต้องเผชิญ นั่นคือจะรักษาความสอดคล้องและลดการทำซ้ำโดยไม่ขัดขวางนวัตกรรมได้อย่างไร UDA ของ Netflix เป็นตัวแทนของแนวทางหนึ่ง แต่ปฏิกิริยาที่หลากหลายจากชุมชนบ่งบอกว่าไม่มีทางออกสากลสำหรับปัญหาสากลนี้
ความสำเร็จของ UDA อาจขึ้นอยู่กับความสามารถของ Netflix ในการจัดการการเปลี่ยนแปลงขององค์กรที่จำเป็นมากกว่าข้อดีทางเทคนิค ประวัติการเปลี่ยนแปลงสถาปัตยกรรมขนาดใหญ่ของบริษัทให้ความน่าเชื่อถือแก่พวกเขา แต่ประวัติศาสตร์ของความพยายามที่คล้ายกันแนะนำว่าควรใช้ความระมัดระวัง
การอภิปรายยังคงดำเนินต่อไปในขณะที่บริษัทอื่นๆ เฝ้าดูการทดลองของ Netflix ด้วยความสนใจ โดยรู้ว่าพวกเขาเผชิญกับความท้าทายที่คล้ายกันในสถาปัตยกรรมข้อมูลของตัวเอง
อ้างอิง: Model Once, Represent Everywhere: UDA (Unified Data Architecture) at Netflix