DataHub منبع باز: پلتفرم جستجو و کشف فراداده LinkedIn

DataHub منبع باز: پلتفرم جستجو و کشف فراداده LinkedIn

یافتن سریع داده های مورد نیاز برای هر شرکتی که برای تصمیم گیری های مبتنی بر داده به حجم زیادی از داده ها متکی است، ضروری است. این نه تنها بر بهره وری کاربران داده (از جمله تحلیلگران، توسعه دهندگان یادگیری ماشین، دانشمندان داده و مهندسان داده) تأثیر می گذارد، بلکه تأثیر مستقیمی بر محصولات نهایی دارد که به خط لوله یادگیری ماشینی با کیفیت (ML) وابسته هستند. علاوه بر این، گرایش به سمت پیاده‌سازی یا ساختن پلتفرم‌های یادگیری ماشینی طبیعتاً این سؤال را ایجاد می‌کند: روش شما برای کشف داخلی ویژگی‌ها، مدل‌ها، معیارها، مجموعه داده‌ها و غیره چیست.

در این مقاله در مورد نحوه انتشار منبع داده تحت مجوز باز صحبت خواهیم کرد DataHub در پلت فرم جستجو و کشف فراداده ما، از روزهای اولیه پروژه شروع می شود کجا چطور. لینکدین نسخه خود از DataHub را جدا از نسخه منبع باز نگهداری می کند. ما با توضیح اینکه چرا به دو محیط توسعه جداگانه نیاز داریم شروع می کنیم، سپس رویکردهای اولیه برای استفاده از منبع باز WhereHows را مورد بحث قرار می دهیم و نسخه داخلی (تولیدی) DataHub خود را با نسخه موجود مقایسه می کنیم. GitHub. همچنین جزئیات راه حل خودکار جدید خود را برای فشار دادن و دریافت به‌روزرسانی‌های منبع باز به اشتراک می‌گذاریم تا هر دو مخزن را با هم هماهنگ نگه داریم. در نهایت، دستورالعمل‌هایی در مورد نحوه شروع استفاده از DataHub منبع باز ارائه می‌دهیم و به طور خلاصه در مورد معماری آن صحبت می‌کنیم.

WhereHows اکنون یک DataHub است!

تیم ابرداده لینکدین قبلا ارائه شده بود DataHub (جانشین WhereHows)، پلت فرم جستجو و کشف ابرداده LinkedIn، و برنامه های مشترک برای باز کردن آن. مدت کوتاهی پس از این اعلامیه، نسخه آلفای DataHub را منتشر کردیم و آن را با جامعه به اشتراک گذاشتیم. از آن زمان، ما به طور مداوم به مخزن کمک کرده‌ایم و با کاربران علاقه‌مند برای افزودن بیشتر ویژگی‌های درخواستی و حل مشکلات کار کرده‌ایم. ما اکنون خوشحالیم که انتشار رسمی را اعلام کنیم DataHub در GitHub.

رویکردهای منبع باز

WhereHows، پورتال اصلی لینکدین برای یافتن داده ها و از کجا آمده است، به عنوان یک پروژه داخلی شروع شد. تیم فراداده آن را باز کرد کد منبع در سال 2016. از آن زمان، تیم همیشه دو پایگاه کد مختلف را حفظ کرده است - یکی برای منبع باز و دیگری برای استفاده داخلی لینکدین - زیرا همه ویژگی‌های محصول توسعه‌یافته برای موارد استفاده از لینکدین به طور کلی برای مخاطبان گسترده‌تر قابل اجرا نبودند. علاوه بر این، WhereHows دارای برخی وابستگی‌های داخلی (زیرساخت‌ها، کتابخانه‌ها و غیره) است که منبع باز نیستند. در سال‌های بعد، WhereHows تکرارها و چرخه‌های توسعه زیادی را پشت سر گذاشت و همگام نگه داشتن دو پایگاه کد را به چالش بزرگی تبدیل کرد. تیم فراداده رویکردهای مختلفی را در طول سال‌ها امتحان کرده است تا توسعه داخلی و منبع باز را همگام نگه دارد.

اول امتحان کنید: "ابتدا منبع باز"

ما در ابتدا از یک مدل توسعه "اول منبع باز" پیروی کردیم، که در آن بیشتر توسعه در یک مخزن منبع باز رخ می دهد و تغییرات برای استقرار داخلی ایجاد می شود. مشکل این رویکرد این است که کد همیشه قبل از بررسی کامل داخلی، ابتدا به GitHub فرستاده می شود. تا زمانی که تغییراتی از مخزن منبع باز ایجاد نشود و یک استقرار داخلی جدید ایجاد نشود، هیچ مشکلی در تولید پیدا نخواهیم کرد. در صورت استقرار ضعیف، تعیین مقصر نیز بسیار دشوار بود زیرا تغییرات در دسته انجام می شد.

علاوه بر این، این مدل هنگام توسعه ویژگی‌های جدید که نیاز به تکرار سریع داشتند، بهره‌وری تیم را کاهش داد، زیرا همه تغییرات را مجبور می‌کرد ابتدا به یک مخزن منبع باز و سپس به یک مخزن داخلی منتقل شوند. برای کاهش زمان پردازش، اصلاح یا تغییر مورد نیاز را می‌توان ابتدا در مخزن داخلی انجام داد، اما زمانی که نوبت به ادغام مجدد این تغییرات در مخزن منبع باز رسید، این مشکل بزرگ شد زیرا این دو مخزن هماهنگ نبودند.

اجرای این مدل برای پلتفرم‌های مشترک، کتابخانه‌ها یا پروژه‌های زیرساختی بسیار آسان‌تر از برنامه‌های کاربردی وب سفارشی با امکانات کامل است. علاوه بر این، این مدل برای پروژه هایی که از روز اول منبع باز شروع می شوند ایده آل است، اما WhereHows به عنوان یک برنامه وب کاملاً داخلی ساخته شده است. انتزاع کامل تمام وابستگی‌های داخلی واقعاً دشوار بود، بنابراین ما باید فورک داخلی را حفظ می‌کردیم، اما حفظ فورک داخلی و توسعه متن‌باز عمدتاً کارساز نبود.

تلاش دوم: "اول درونی"

**به عنوان تلاش دوم، ما به مدل توسعه "اولین داخلی" رفتیم، جایی که بیشتر توسعه در داخل انجام می شود و تغییرات به طور منظم در کد منبع باز انجام می شود. اگرچه این مدل برای موارد استفاده ما مناسب است، اما مشکلات ذاتی دارد. انتقال مستقیم همه تفاوت ها به مخزن منبع باز و سپس تلاش برای حل تعارضات ادغام بعداً یک گزینه است، اما زمان بر است. توسعه دهندگان در بیشتر موارد سعی می کنند هر بار که کد خود را بررسی می کنند این کار را انجام ندهند. در نتیجه، این کار به دفعات کمتر و به صورت دسته‌ای انجام می‌شود، و در نتیجه حل کردن تضادهای ادغام بعداً دشوارتر می‌شود.

بار سوم کار کرد!

دو تلاش ناموفق ذکر شده در بالا منجر به قدیمی ماندن مخزن WhereHows GitHub برای مدت طولانی شد. تیم به بهبود ویژگی‌ها و معماری محصول ادامه داد، به طوری که نسخه داخلی WhereHows برای لینکدین از نسخه منبع باز پیشرفته‌تر شد. حتی نام جدیدی داشت - DataHub. بر اساس تلاش‌های ناموفق قبلی، تیم تصمیم گرفت راه‌حلی مقیاس‌پذیر و بلندمدت ایجاد کند.

برای هر پروژه منبع باز جدید، تیم متن باز لینکدین یک مدل توسعه را توصیه می کند و از آن پشتیبانی می کند که در آن ماژول های پروژه به طور کامل به صورت متن باز توسعه می یابند. مصنوعات نسخه شده در یک مخزن عمومی مستقر می شوند و سپس با استفاده از آرتیفکت داخلی لینکدین بررسی می شوند. درخواست کتابخانه خارجی (ELR). پیروی از این مدل توسعه نه تنها برای کسانی که از منبع باز استفاده می کنند خوب است، بلکه منجر به معماری ماژولارتر، توسعه پذیرتر و قابل اتصال می شود.

با این حال، یک برنامه بک‌اند بالغ مانند DataHub به زمان قابل توجهی برای رسیدن به این وضعیت نیاز دارد. این همچنین از امکان منبع‌باز کردن یک پیاده‌سازی کاملاً کارآمد قبل از انتزاع کامل همه وابستگی‌های داخلی جلوگیری می‌کند. به همین دلیل است که ما ابزارهایی را توسعه داده‌ایم که به ما کمک می‌کنند مشارکت‌های منبع باز را سریع‌تر و با درد بسیار کمتر انجام دهیم. این راه حل به نفع تیم ابرداده (توسعه دهنده DataHub) و جامعه منبع باز است. بخش های بعدی این رویکرد جدید را مورد بحث قرار خواهند داد.

اتوماسیون انتشار متن باز

آخرین رویکرد تیم Metadata برای DataHub منبع باز، توسعه ابزاری است که به طور خودکار پایگاه کد داخلی و مخزن منبع باز را همگام‌سازی می‌کند. ویژگی های سطح بالای این جعبه ابزار عبارتند از:

1. همگام سازی کد لینکدین با/از منبع باز، مشابه rsync.
2. تولید هدر مجوز، مشابه موش آپاچی.
3. به طور خودکار گزارش های commit منبع باز را از گزارش های commit داخلی ایجاد کنید.
4. از تغییرات داخلی که ساخت‌های منبع باز را می‌شکنند، جلوگیری کنید تست وابستگی.

زیر بخش های زیر به توابع ذکر شده در بالا که دارای مشکلات جالبی هستند می پردازد.

همگام سازی کد منبع

بر خلاف نسخه منبع باز DataHub که یک مخزن GitHub واحد است، نسخه LinkedIn DataHub ترکیبی از چندین مخزن (به صورت داخلی نامیده می شود) است. چند محصولی). رابط DataHub، کتابخانه مدل ابرداده، سرویس پشتیبان انبار ابرداده، و کارهای جریانی در مخازن جداگانه در لینکدین قرار دارند. با این حال، برای سهولت کار برای کاربران منبع باز، ما یک مخزن واحد برای نسخه منبع باز DataHub داریم.

شکل 1: همگام سازی بین مخازن لینک DataHub و یک مخزن واحد DataHub متن باز

برای پشتیبانی از گردش‌های کاری ساخت، فشار و کشش خودکار، ابزار جدید ما به‌طور خودکار یک نقشه‌برداری در سطح فایل مربوط به هر فایل منبع ایجاد می‌کند. با این حال، جعبه ابزار نیاز به پیکربندی اولیه دارد و کاربران باید نقشه‌برداری ماژول سطح بالا را مطابق شکل زیر ارائه دهند.

{
  "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 از یک فایل منبع لینکدین به یک فایل در مخزن منبع باز است. چندین قانون مرتبط با این ایجاد خودکار پیوندهای فایل وجود دارد:

• در مورد چندین ماژول منبع برای یک ماژول هدف در منبع باز، ممکن است تداخل ایجاد شود، به عنوان مثال یکسان FQCN، در بیش از یک ماژول منبع وجود دارد. به عنوان یک استراتژی حل تعارض، ابزارهای ما به‌طور پیش‌فرض گزینه «آخرین برنده» را انتخاب می‌کنند.
• "null" به این معنی است که فایل منبع بخشی از مخزن منبع باز نیست.
• پس از هر ارسال یا استخراج منبع باز، این نقشه به طور خودکار به روز می شود و یک عکس فوری ایجاد می شود. این برای شناسایی اضافه‌ها و حذف‌های کد منبع از زمان آخرین اقدام ضروری است.

ایجاد commit log

گزارش‌های commit برای commit‌های منبع باز نیز به‌طور خودکار با ادغام گزارش‌های commit مخازن داخلی تولید می‌شوند. در زیر یک نمونه گزارش commit برای نشان دادن ساختار گزارش commit تولید شده توسط ابزار ما وجود دارد. یک commit به وضوح نشان می دهد که کدام نسخه از مخازن منبع در آن commit بسته بندی شده اند و خلاصه ای از گزارش commit را ارائه می دهد. این یکی را بررسی کنید مرتکب شدن با استفاده از یک مثال واقعی از commit log تولید شده توسط جعبه ابزار ما.

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 چند محصولی نیست و نمی تواند وابستگی مستقیم به هر چند محصولی باشد، اما با کمک یک بسته بندی چند محصولی که کد منبع منبع باز DataHub را واکشی می کند، همچنان می توانیم از این تست وابستگی استفاده کنیم. بنابراین، هر تغییری (که ممکن است بعداً در معرض آن قرار گیرد) در هر یک از چند محصولی که مخزن منبع باز DataHub را تغذیه می کند، یک رویداد ساخت را در چند محصول پوسته ایجاد می کند. بنابراین، هر تغییری که در ساخت یک محصول لفاف شکست خورده باشد، در آزمایشات قبل از اجرای محصول اصلی شکست خورده و برگردانده می شود.

این یک مکانیسم مفید است که به جلوگیری از هرگونه تعهد داخلی که ساختار منبع باز را شکسته و آن را در زمان ارتکاب شناسایی می کند، جلوگیری می کند. بدون این، تعیین اینکه کدام commit داخلی باعث شکست ساخت مخزن منبع باز شده است بسیار دشوار خواهد بود، زیرا ما تغییرات داخلی را به مخزن منبع باز DataHub اضافه می کنیم.

تفاوت بین DataHub منبع باز و نسخه تولیدی ما

تا این مرحله، ما راه حل خود را برای همگام سازی دو نسخه از مخازن DataHub مورد بحث قرار داده ایم، اما هنوز دلایلی را بیان نکرده ایم که چرا در وهله اول به دو جریان توسعه متفاوت نیاز داریم. در این قسمت تفاوت های نسخه عمومی DataHub و نسخه تولیدی در سرورهای لینکدین را لیست می کنیم و دلایل این تفاوت ها را توضیح می دهیم.

یکی از منابع اختلاف از این واقعیت ناشی می شود که نسخه تولیدی ما به کدهایی که هنوز منبع باز نیستند، مانند LinkedIn's Offspring (چارچوب تزریق وابستگی داخلی LinkedIn) وابستگی دارد. Offspring به طور گسترده در پایگاه های کد داخلی استفاده می شود زیرا روش ترجیحی برای مدیریت پیکربندی پویا است. اما منبع باز نیست. بنابراین ما باید جایگزین های منبع باز برای DataHub منبع باز پیدا کنیم.

دلایل دیگری نیز وجود دارد. همانطور که ما برای نیازهای لینکدین افزونه هایی را برای مدل ابرداده ایجاد می کنیم، این افزونه ها معمولاً برای لینکدین بسیار خاص هستند و ممکن است مستقیماً برای محیط های دیگر اعمال نشوند. به عنوان مثال، ما برچسب‌های بسیار خاصی برای شناسه‌های شرکت‌کننده و انواع دیگر فراداده‌های منطبق داریم. بنابراین، ما اکنون این افزونه ها را از مدل ابرداده منبع باز DataHub حذف کرده ایم. همانطور که با جامعه درگیر هستیم و نیازهای آن‌ها را درک می‌کنیم، در صورت نیاز روی نسخه‌های منبع باز رایج این افزونه‌ها کار خواهیم کرد.

سهولت استفاده و انطباق آسان تر برای جامعه منبع باز نیز الهام بخش برخی از تفاوت های بین دو نسخه DataHub است. تفاوت در زیرساخت های پردازش جریان نمونه خوبی از این موضوع است. اگرچه نسخه داخلی ما از یک چارچوب پردازش جریان مدیریت شده استفاده می کند، ما ترجیح دادیم از پردازش جریان داخلی (مستقل) برای نسخه منبع باز استفاده کنیم زیرا از ایجاد وابستگی زیرساخت دیگری جلوگیری می کند.

مثال دیگری از تفاوت داشتن یک GMS (فروشگاه فراداده عمومی) در یک پیاده سازی متن باز به جای چندین GMS است. GMA (Generalized Metadata Architecture) نام معماری Back-end برای DataHub است و GMS ذخیره ابرداده در زمینه GMA است. GMA یک معماری بسیار منعطف است که به شما امکان می‌دهد هر ساختار داده (مانند مجموعه داده‌ها، کاربران و غیره) را در فروشگاه ابرداده خودش توزیع کنید، یا ساختارهای داده‌های متعدد را در یک فروشگاه ابرداده ذخیره کنید تا زمانی که رجیستری حاوی نگاشت ساختار داده در GMS به روز شده است. برای سهولت استفاده، ما یک نمونه GMS را انتخاب کردیم که تمام ساختارهای مختلف داده را در DataHub منبع باز ذخیره می کند.

لیست کاملی از تفاوت های بین دو پیاده سازی در جدول زیر آورده شده است.

ویژگی های محصول
LinkedIn DataHub
DataHub منبع باز

ساختارهای داده پشتیبانی شده
1) مجموعه داده ها 2) کاربران 3) معیارها 4) ویژگی های ML 5) نمودارها 6) داشبوردها
1) مجموعه داده ها 2) کاربران

منابع فراداده پشتیبانی شده برای مجموعه داده ها
1) آمبری 2) کاناپه 3) دالیدها 4) بیان 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) Pinot 12) Presto 12) باش 13) Teradata 13) بردار 14) ونیز
کندو کافکا RDBMS

میخانه-زیر
لینکدین کافکا
کافکای همرو

پردازش جریان
مدیریت
تعبیه شده (مستقل)

تزریق وابستگی و پیکربندی پویا
فرزندان لینکدین
بهار

ساخت ابزار
Ligradle (پوشش Gradle داخلی LinkedIn)
گردللو

CI / CD
CRT (CI/CD داخلی LinkedIn)
TravisCI و مرکز داکر

فروشگاه های فراداده
GMS چندگانه توزیع شده: 1) GMS مجموعه داده 2) GMS کاربر 3) GMS متریک 4) GMS ویژگی 5) GMS نمودار/داشبورد
GMS واحد برای: 1) مجموعه داده ها 2) کاربران

میکروسرویس در ظروف داکر

کارگر بارانداز استقرار و توزیع برنامه را با ظرف سازی. هر بخش از سرویس در DataHub منبع باز است، از جمله اجزای زیرساخت مانند Kafka، ارزیابی جستجو, neo4j и خروجی، تصویر داکر خود را دارد. برای هماهنگ کردن کانتینرهای Docker ما استفاده کردیم داکور نوشتن.

شکل 2: معماری DataHub *متن باز**

معماری سطح بالای DataHub را در تصویر بالا مشاهده می کنید. علاوه بر اجزای زیرساخت، دارای چهار کانتینر Docker مختلف است:

datahub-gms: سرویس ذخیره سازی ابرداده

datahub-frontend: برنامه کاربردی بازی، رابط DataHub را ارائه می دهد.

datahub-mce-consumer: برنامه کاربردی جریان های کافکا، که از جریان رویداد تغییر ابرداده (MCE) استفاده می کند و ذخیره ابرداده را به روز می کند.

datahub-mae-consumer: برنامه کاربردی جریان های کافکا، که از جریان رویداد ممیزی ابرداده (MAE) استفاده می کند و یک فهرست جستجو و پایگاه داده نمودار ایجاد می کند.

اسناد مخزن منبع باز و پست وبلاگ اصلی DataHub حاوی اطلاعات دقیق تری در مورد عملکرد سرویس های مختلف است.

CI/CD در DataHub منبع باز است

مخزن منبع باز DataHub استفاده می کند TravisCI برای ادغام مداوم و مرکز داکر برای استقرار مداوم هر دو ادغام GitHub خوبی دارند و راه اندازی آن آسان است. برای اکثر زیرساخت های منبع باز توسعه یافته توسط جامعه یا شرکت های خصوصی (به عنوان مثال اتصال)، تصاویر Docker برای سهولت استفاده توسط جامعه ایجاد و در Docker Hub مستقر می شوند. هر تصویر Docker که در Docker Hub یافت می شود را می توان به راحتی با یک دستور ساده استفاده کرد داکر کشش.

با هر تعهد به مخزن منبع باز DataHub، تمام تصاویر Docker به طور خودکار ساخته شده و با برچسب "جدیدترین" در Docker Hub مستقر می شوند. اگر داکر هاب با تعدادی پیکربندی شده باشد نامگذاری شاخه های عبارات منظم، تمام برچسب ها در مخزن منبع باز نیز با نام تگ های مربوطه در Docker Hub منتشر می شوند.

با استفاده از DataHub

راه اندازی DataHub بسیار ساده است و شامل سه مرحله ساده است:

1. مخزن منبع باز را کلون کنید و همه کانتینرهای Docker را با docker-compose با استفاده از اسکریپت docker-compose ارائه شده برای شروع سریع اجرا کنید.
2. نمونه داده های ارائه شده در مخزن را با استفاده از ابزار خط فرمان که نیز ارائه شده است دانلود کنید.
3. DataHub را در مرورگر خود مرور کنید.

به طور فعال پیگیری می شود گیتتر چت همچنین برای سوالات سریع پیکربندی شده است. کاربران همچنین می توانند مشکلات را مستقیماً در مخزن GitHub ایجاد کنند. مهمتر از همه، ما از همه بازخوردها و پیشنهادات استقبال و قدردانی می کنیم!

برنامه های آینده

در حال حاضر، هر زیرساخت یا میکروسرویس برای DataHub منبع باز به عنوان یک ظرف Docker ساخته شده است و کل سیستم با استفاده از کامیون. با توجه به محبوبیت و گسترده بودن کوبرنیتس، ما همچنین می خواهیم در آینده نزدیک یک راه حل مبتنی بر Kubernetes ارائه دهیم.

ما همچنین قصد داریم یک راه حل کلید در دست برای استقرار DataHub در یک سرویس ابری عمومی مانند لاجوردی, AWS یا Google Cloud. با توجه به اطلاعیه اخیر مهاجرت لینکدین به Azure، این امر با اولویت های داخلی تیم ابرداده همخوانی دارد.

آخرین اما نه کم‌اهمیت، از همه پذیرندگان اولیه DataHub در جامعه منبع باز تشکر می‌کنیم که آلفاهای DataHub را رتبه‌بندی کرده‌اند و به ما در شناسایی مشکلات و بهبود اسناد کمک کردند.

منبع: www.habr.com