การหลบเลี่ยงปัญหาคอขวดของข้อมูล — data mesh ที่ Starship | โดย Taavi Pungas | เทคโนโลยีเอ็นเตอร์ไพรส์

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

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

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

เราพบว่ากระบวนทัศน์ของ data mesh เป็นวิธีที่ดีที่สุดในอนาคต ฉันจะอธิบายการใช้ Starship เกี่ยวกับ data mesh ด้านล่าง แต่ก่อนอื่น มาดูบทสรุปสั้น ๆ เกี่ยวกับแนวทางนี้และเหตุผลที่เราตัดสินใจเลือกใช้

ตาข่ายข้อมูลคืออะไร?

กรอบโครงข่ายข้อมูลคือ อธิบายครั้งแรก โดย Zhamak Dehghani กระบวนทัศน์อยู่ดังต่อไปนี้ แนวคิดหลัก: ผลิตภัณฑ์ข้อมูล โดเมนข้อมูล แพลตฟอร์มข้อมูล และการกำกับดูแลข้อมูล

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

ตาข่ายข้อมูลใน Starship

ข้อมูลทำงานใกล้ชิดกับคนที่ผลิตหรือบริโภคข้อมูล

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

ความหลากหลายของกรณีการใช้งานเป็นเหตุผลหลักที่ดึงดูดเราให้ใช้วิธี data mesh — เราต้องการดำเนินการข้อมูลให้ใกล้ชิดกับคนที่ผลิตหรือบริโภคข้อมูล ด้วยการปฏิบัติตามหลักการของ data mesh เราหวังว่าจะตอบสนองความต้องการด้านข้อมูลที่หลากหลายของทีมของเราในขณะที่ยังคงให้การกำกับดูแลจากส่วนกลางนั้นเบาพอสมควร

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

ผลิตภัณฑ์ข้อมูล

กำหนดว่าผลิตภัณฑ์ข้อมูลของคุณคืออะไร — แต่ละผลิตภัณฑ์มีเจ้าของ อินเทอร์เฟซ และผู้ใช้

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

ตัวอย่างง่ายๆ ของผลิตภัณฑ์ข้อมูลใน Starship อาจเป็นแดชบอร์ด BI สำหรับโอกาสในการขายของไซต์เพื่อติดตามปริมาณธุรกิจของไซต์ ตัวอย่างที่ละเอียดยิ่งขึ้นคือท่อส่งบริการตนเองสำหรับวิศวกรซอฟต์แวร์หุ่นยนต์เพื่อส่งข้อมูลการขับขี่ประเภทใดก็ได้จากหุ่นยนต์ไปยัง Data Lake ของเรา

ไม่ว่าในกรณีใด เราไม่ถือว่าคลังข้อมูลของเรา (จริงๆ แล้วเป็น Databricks lakehouse) เป็นผลิตภัณฑ์เดียว แต่เป็นแพลตฟอร์มที่รองรับผลิตภัณฑ์ที่เชื่อมต่อถึงกันจำนวนมาก ผลิตภัณฑ์ที่ละเอียดเหล่านี้มักเป็นของนักวิทยาศาสตร์ข้อมูล / วิศวกรที่สร้างและบำรุงรักษา ไม่ใช่ผู้จัดการผลิตภัณฑ์โดยเฉพาะ

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

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

โดเมนข้อมูล

จัดกลุ่มผลิตภัณฑ์ข้อมูลของคุณเป็นโดเมนที่สะท้อนถึงโครงสร้างองค์กรของบริษัท

ก่อนที่เราจะรู้จัก data mesh model เราเคยใช้รูปแบบของ . สำเร็จแล้ว นักวิทยาศาสตร์ข้อมูลฝังตัวเบาๆ สักพักในสตาร์ชิพ อย่างมีประสิทธิภาพ ทีมหลักบางทีมมีสมาชิกในทีมข้อมูลทำงานพาร์ทไทม์ ไม่ว่าจะมีความหมายอะไรในทีมใดทีมหนึ่งก็ตาม

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

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

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

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

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

แพลตฟอร์มข้อมูล

มอบอำนาจให้ผู้คนสร้างผลิตภัณฑ์ข้อมูลของคุณโดยกำหนดมาตรฐานโดยไม่ต้องรวมศูนย์

เป้าหมายของแพลตฟอร์มข้อมูลใน Starship นั้นตรงไปตรงมา: ทำให้คนข้อมูลคนเดียว (โดยปกติคือนักวิทยาศาสตร์ข้อมูล) ดูแลโดเมนแบบ end-to-end ได้ กล่าวคือ เพื่อไม่ให้ทีมแพลตฟอร์มข้อมูลส่วนกลางทำงานทั้งวัน- งานวันนี้. ซึ่งจำเป็นต้องมีเครื่องมือที่ดีและมาตรฐานสำหรับผลิตภัณฑ์ข้อมูลแก่วิศวกรโดเมนและนักวิทยาศาสตร์ข้อมูล

หมายความว่าคุณต้องการทีมแพลตฟอร์มข้อมูลเต็มรูปแบบสำหรับแนวทาง data mesh หรือไม่? ไม่เชิง. ทีมแพลตฟอร์มข้อมูลของเราประกอบด้วยวิศวกรแพลตฟอร์มข้อมูลเพียงคนเดียว ซึ่งใช้เวลาครึ่งเดียวในการฝังตัวในโดเมน เหตุผลหลักที่ทำให้เราพึ่งพาวิศวกรรมแพลตฟอร์มข้อมูลได้ก็คือการเลือก Spark+Databricks เป็นแกนหลักของแพลตฟอร์มข้อมูลของเรา สถาปัตยกรรมคลังข้อมูลแบบเก่าของเราก่อนหน้านี้ทำให้วิศวกรรมข้อมูลมีค่าใช้จ่ายสูง เนื่องจากความหลากหลายของโดเมนข้อมูลของเรา

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

• Databricks+Spark เป็นสภาพแวดล้อมการทำงานและแพลตฟอร์มการคำนวณที่หลากหลาย
• ฟังก์ชันหนึ่งซับสำหรับการนำเข้าข้อมูล เช่น จากคอลเล็กชัน Mongo หรือหัวข้อ Kafka
• อินสแตนซ์ Airflow สำหรับการจัดกำหนดการไปป์ไลน์ข้อมูล
• เทมเพลตสำหรับการสร้างและปรับใช้โมเดลการคาดการณ์เป็นไมโครเซอร์วิส
• การติดตามต้นทุนของผลิตภัณฑ์ข้อมูล
• เครื่องมือ BI และการแสดงภาพ

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

การกำกับดูแลข้อมูล

ความเป็นเจ้าของส่วนบุคคลที่แข็งแกร่งสนับสนุนโดยลูปตอบรับ

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

คำตอบของเรา: ผ่านวัฒนธรรมของการเป็นเจ้าของ การอภิปราย และข้อเสนอแนะภายในทีม เรายืมอย่างเสรีจากปรัชญาการจัดการ ใน Netflix และปลูกฝังดังต่อไปนี้:

• ความรับผิดชอบส่วนบุคคลสำหรับผลลัพธ์ (ของผลิตภัณฑ์และโดเมนของตน);
• แสวงหาความคิดเห็นที่แตกต่างก่อนตัดสินใจ
• การขอความคิดเห็นและการตรวจสอบโค้ดทั้งในฐานะกลไกคุณภาพและโอกาสสำหรับการเติบโตส่วนบุคคล

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

หลักการเหล่านี้นำไปใช้นอกงาน “สร้าง” ของทีมข้อมูลของเราด้วย ซึ่งเป็นจุดสนใจของโพสต์ในบล็อกนี้ อย่างชัดเจน, ยังมีอีกมาก มากกว่าการจัดหาผลิตภัณฑ์ข้อมูลตามที่นักวิทยาศาสตร์ข้อมูลของเราสร้างมูลค่าให้กับบริษัท

ความคิดขั้นสุดท้ายเกี่ยวกับธรรมาภิบาล — เราจะพยายามย้ำเตือนถึงวิธีการทำงานของเรา ไม่มีทางใดที่ “ดีที่สุด” ในการทำสิ่งต่างๆ ได้เลย และเรารู้ว่าเราต้องปรับตัวเมื่อเวลาผ่านไป

คำพูดสุดท้าย

นี่ไง! เหล่านี้เป็นแนวคิด 4 แกนข้อมูลหลักที่ใช้ใน Starship อย่างที่คุณเห็น เราได้พบแนวทางของ data mesh ที่เหมาะสมกับเราในฐานะบริษัทที่มีการเติบโตอย่างรวดเร็ว หากบริบทของคุณฟังดูน่าสนใจ ฉันหวังว่าการอ่านเกี่ยวกับประสบการณ์ของเราจะเป็นประโยชน์

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

ติดต่อเราหากคุณมีคำถามหรือความคิดเห็น แล้วมาเรียนรู้จากกันและกัน!