Open Source DataHub: แพลตฟอร์มการค้นหาและค้นพบข้อมูลเมตาของ LinkedIn

Open Source DataHub: แพลตฟอร์มการค้นหาและค้นพบข้อมูลเมตาของ LinkedIn

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

ในบทความนี้ เราจะพูดถึงวิธีที่เราเผยแพร่แหล่งข้อมูลภายใต้ใบอนุญาตแบบเปิด ดาต้าฮับ ในแพลตฟอร์มการค้นหาและค้นพบข้อมูลเมตาของเรา เริ่มตั้งแต่ช่วงแรกๆ ของโครงการ อยู่ไหน.. LinkedIn จะดูแลรักษา DataHub เวอร์ชันของตัวเองแยกจากเวอร์ชันโอเพ่นซอร์ส เราจะเริ่มต้นด้วยการอธิบายว่าทำไมเราถึงต้องการสภาพแวดล้อมการพัฒนาสองสภาพแวดล้อมที่แยกจากกัน จากนั้นอภิปรายแนวทางเบื้องต้นในการใช้ WhereHows แบบโอเพ่นซอร์ส และเปรียบเทียบ DataHub เวอร์ชันภายใน (ที่ใช้งานจริง) กับเวอร์ชันบน GitHub. นอกจากนี้เรายังจะแชร์รายละเอียดเกี่ยวกับโซลูชันอัตโนมัติใหม่ของเราสำหรับการพุชและรับการอัปเดตโอเพ่นซอร์สเพื่อให้ที่เก็บข้อมูลทั้งสองซิงค์กัน สุดท้ายนี้ เราจะให้คำแนะนำเกี่ยวกับวิธีเริ่มต้นใช้งาน DataHub แบบโอเพ่นซอร์ส และพูดคุยสั้นๆ เกี่ยวกับสถาปัตยกรรมของตัวมัน

WhereHows กลายเป็น DataHub แล้ว!

ทีมข้อมูลเมตาของ LinkedIn นำเสนอก่อนหน้านี้ ดาต้าฮับ (ผู้สืบทอดจาก WhereHows) แพลตฟอร์มการค้นหาและการค้นพบข้อมูลเมตาของ LinkedIn และแบ่งปันแผนการที่จะเปิด ไม่นานหลังจากการประกาศนี้ เราได้เผยแพร่ DataHub เวอร์ชันอัลฟ่าและแชร์กับชุมชน ตั้งแต่นั้นมา เราได้สนับสนุนพื้นที่เก็บข้อมูลอย่างต่อเนื่องและทำงานร่วมกับผู้ใช้ที่สนใจเพื่อเพิ่มคุณสมบัติที่ได้รับการร้องขอมากที่สุดและแก้ไขปัญหา ตอนนี้เรามีความยินดีที่จะประกาศการเปิดตัวอย่างเป็นทางการ DataHub บน GitHub.

แนวทางโอเพ่นซอร์ส

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

ลองครั้งแรก: "โอเพ่นซอร์สก่อน"

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

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

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

ความพยายามครั้งที่สอง: “ภายในก่อน”

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

ครั้งที่สามมันได้ผล!

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

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

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

โอเพ่นซอร์สอัตโนมัติการเผยแพร่

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

1. ซิงค์โค้ด LinkedIn กับ/จากโอเพ่นซอร์สที่คล้ายกัน rsync.
2. การสร้างส่วนหัวใบอนุญาตคล้ายกับ อาปาเช่หนู.
3. สร้างบันทึกการคอมมิตแบบโอเพ่นซอร์สโดยอัตโนมัติจากบันทึกการคอมมิตภายใน
4. ป้องกันการเปลี่ยนแปลงภายในที่ทำลายการสร้างโอเพ่นซอร์สด้วย การทดสอบการพึ่งพา.

ส่วนย่อยต่อไปนี้จะเจาะลึกฟังก์ชันที่กล่าวมาข้างต้นซึ่งมีปัญหาที่น่าสนใจ

การซิงโครไนซ์ซอร์สโค้ด

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

รูปที่ 1: การซิงโครไนซ์ระหว่างที่เก็บข้อมูล LinkedIn ดาต้าฮับ และที่เก็บข้อมูลเดียว ดาต้าฮับ โอเพ่นซอร์ส

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

{
  "datahub-dao": [
    "${datahub-frontend}/datahub-dao"
  ],
  "gms/impl": [
    "${dataset-gms}/impl",
    "${user-gms}/impl"
  ],
  "metadata-dao": [
    "${metadata-models}/metadata-dao"
  ],
  "metadata-builders": [
    "${metadata-models}/metadata-builders"
  ]
}

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

{
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Foo.java":
"metadata-builders/src/main/java/com/linkedin/Foo.java",
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Bar.java":
"metadata-builders/src/main/java/com/linkedin/Bar.java",
  "${metadata-models}/metadata-builders/build.gradle": null,
}

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

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

การสร้างบันทึกการคอมมิต

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

metadata-models 29.0.0 -> 30.0.0
    Added aspect model foo
    Fixed issue bar

dataset-gms 2.3.0 -> 2.3.4
    Added rest.li API to serve foo aspect

MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0

การทดสอบการพึ่งพา

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

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

ความแตกต่างระหว่าง DataHub แบบโอเพ่นซอร์สและเวอร์ชันที่ใช้งานจริงของเรา

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

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

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

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

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

รายการความแตกต่างทั้งหมดระหว่างการใช้งานทั้งสองมีระบุไว้ในตารางด้านล่าง

สินค้า
LinkedInดาต้าฮับ
โอเพ่นซอร์สดาต้าฮับ

โครงสร้างข้อมูลที่รองรับ
1) ชุดข้อมูล 2) ผู้ใช้ 3) ตัวชี้วัด 4) คุณสมบัติ ML 5) แผนภูมิ 6) แดชบอร์ด
1) ชุดข้อมูล 2) ผู้ใช้

แหล่งที่มาของข้อมูลเมตาที่รองรับสำหรับชุดข้อมูล
1) แอมบรี 2) โซฟา 3) ดาลิดส์ 4) เอสเพรสโซ่ 5) HDFS 6) ไฮฟ์ 7) คาฟคา 8) MongoDB 9) MySQL 10) ออราเคิล 11) Pinot 12) เพรสโต 12) ท้องทะเล 13) เทราดาต้า 13) เวกเตอร์ 14) เวนิซ
ไฮฟ์คาฟคา RDBMS

ผับย่อย
LinkedIn คาฟคา
คาฟคามาบรรจบกัน

การประมวลผลสตรีม
การจัดการ
แบบฝัง (สแตนด์อโลน)

การพึ่งพาการฉีดและการกำหนดค่าแบบไดนามิก
LinkedIn ลูกหลาน
ฤดูใบไม้ผลิ

สร้างเครื่องมือ
Ligradle (เครื่องห่อ Gradle ภายในของ LinkedIn)
กราดลิว

CI / ซีดี
CRT (CI/CD ภายในของ LinkedIn)
ทราวิสซี และ ศูนย์กลางนักเทียบท่า

ที่เก็บข้อมูลเมตา
กระจาย GMS หลายรายการ: 1) ชุดข้อมูล GMS 2) GMS ผู้ใช้ 3) GMS เมตริก 4) คุณลักษณะ GMS 5) แผนภูมิ/แดชบอร์ด GMS
GMS เดียวสำหรับ: 1) ชุดข้อมูล 2) ผู้ใช้

ไมโครเซอร์วิสในคอนเทนเนอร์ Docker

นักเทียบท่า ลดความยุ่งยากในการใช้งานและการแจกจ่ายแอปพลิเคชันด้วย การบรรจุภาชนะ. ทุกส่วนของบริการใน DataHub นั้นเป็นโอเพ่นซอร์ส รวมถึงส่วนประกอบโครงสร้างพื้นฐาน เช่น Kafka ElasticSearch, neo4j и MySQLมีอิมเมจ Docker ของตัวเอง เพื่อจัดเตรียมคอนเทนเนอร์ Docker ที่เราใช้ Docker Compose.

รูปที่ 2: สถาปัตยกรรม ดาต้าฮับ *โอเพ่นซอร์ส**

คุณสามารถดูสถาปัตยกรรมระดับสูงของ DataHub ได้ในภาพด้านบน นอกจากส่วนประกอบโครงสร้างพื้นฐานแล้ว ยังมีคอนเทนเนอร์ Docker ที่แตกต่างกันสี่แบบ:

datahub-gms: บริการจัดเก็บข้อมูลเมตา

datahub-ส่วนหน้า: แอปพลิเคชัน เล่นซึ่งให้บริการอินเทอร์เฟซ DataHub

datahub-mce-consumer: แอปพลิเคชัน คาฟคาสตรีมซึ่งใช้สตรีมเหตุการณ์การเปลี่ยนแปลงข้อมูลเมตา (MCE) และอัปเดตที่เก็บข้อมูลเมตา

datahub-mae-consumer: แอปพลิเคชัน คาฟคาสตรีมซึ่งใช้สตรีมเหตุการณ์การตรวจสอบข้อมูลเมตา (MAE) และสร้างดัชนีการค้นหาและฐานข้อมูลกราฟ

เอกสารแหล่งเก็บข้อมูลโอเพ่นซอร์สและ โพสต์บล็อก DataHub ดั้งเดิม มีข้อมูลรายละเอียดเพิ่มเติมเกี่ยวกับการทำงานของบริการต่างๆ

CI/CD บน DataHub เป็นโอเพ่นซอร์ส

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

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

การใช้ดาต้าฮับ

การตั้งค่า DataHub ง่ายมากและประกอบด้วยสามขั้นตอนง่ายๆ:

1. โคลนพื้นที่เก็บข้อมูลโอเพ่นซอร์สและเรียกใช้คอนเทนเนอร์ Docker ทั้งหมดด้วย docker-compose โดยใช้สคริปต์ docker-compose ที่ให้มาเพื่อการเริ่มต้นอย่างรวดเร็ว
2. ดาวน์โหลดข้อมูลตัวอย่างที่ให้ไว้ในที่เก็บโดยใช้เครื่องมือบรรทัดคำสั่งที่ให้มาด้วย
3. เรียกดู DataHub ในเบราว์เซอร์ของคุณ

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

แผนสำหรับอนาคต

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

นอกจากนี้เรายังวางแผนที่จะจัดหาโซลูชันแบบครบวงจรสำหรับการปรับใช้ DataHub บนบริการคลาวด์สาธารณะ เช่น สีฟ้า, AWS หรือ Google Cloud. จากการประกาศล่าสุดเกี่ยวกับการโยกย้ายของ LinkedIn ไปยัง Azure สิ่งนี้จะสอดคล้องกับลำดับความสำคัญภายในของทีมเมตาดาต้า

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

ที่มา: will.com