ওপেন সোর্স ডেটাহাব: লিঙ্কডইনের মেটাডেটা অনুসন্ধান এবং আবিষ্কার প্ল্যাটফর্ম

ওপেন সোর্স ডেটাহাব: লিঙ্কডইনের মেটাডেটা অনুসন্ধান এবং আবিষ্কার প্ল্যাটফর্ম

ডেটা-চালিত সিদ্ধান্ত নেওয়ার জন্য প্রচুর পরিমাণে ডেটার উপর নির্ভর করে এমন কোনও সংস্থার জন্য আপনার প্রয়োজনীয় ডেটা দ্রুত খুঁজে পাওয়া অপরিহার্য। এটি শুধুমাত্র ডেটা ব্যবহারকারীদের উৎপাদনশীলতাকে প্রভাবিত করে না (বিশ্লেষক, মেশিন লার্নিং ডেভেলপার, ডেটা সায়েন্টিস্ট এবং ডেটা ইঞ্জিনিয়ার সহ), কিন্তু এটি একটি মানসম্পন্ন মেশিন লার্নিং (ML) পাইপলাইনের উপর নির্ভর করে এমন শেষ পণ্যগুলির উপরও সরাসরি প্রভাব ফেলে। উপরন্তু, মেশিন লার্নিং প্ল্যাটফর্মগুলি বাস্তবায়ন বা তৈরি করার প্রবণতা স্বাভাবিকভাবেই প্রশ্ন উত্থাপন করে: অভ্যন্তরীণভাবে বৈশিষ্ট্য, মডেল, মেট্রিক্স, ডেটাসেট ইত্যাদি আবিষ্কার করার জন্য আপনার পদ্ধতি কী?

এই নিবন্ধে আমরা কীভাবে একটি উন্মুক্ত লাইসেন্সের অধীনে একটি ডেটা উত্স প্রকাশ করেছি সে সম্পর্কে কথা বলব৷ ডেটাহাব আমাদের মেটাডেটা অনুসন্ধান এবং আবিষ্কার প্ল্যাটফর্মে, প্রকল্পের প্রথম দিন থেকে শুরু করে কোথায় কিভাবে. LinkedIn ওপেন সোর্স সংস্করণ থেকে আলাদাভাবে DataHub এর নিজস্ব সংস্করণ বজায় রাখে। আমরা কেন আমাদের দুটি পৃথক উন্নয়ন পরিবেশের প্রয়োজন তা ব্যাখ্যা করে শুরু করব, তারপরে ওপেন সোর্স WhereHows ব্যবহার করার প্রাথমিক পদ্ধতি নিয়ে আলোচনা করব এবং DataHub-এর আমাদের অভ্যন্তরীণ (উৎপাদন) সংস্করণের সাথে তুলনা করব GitHub. আমরা উভয় রিপোজিটরিকে সিঙ্কে রাখতে ওপেন সোর্স আপডেটগুলি পুশ এবং গ্রহণ করার জন্য আমাদের নতুন স্বয়ংক্রিয় সমাধান সম্পর্কে বিশদও ভাগ করব৷ পরিশেষে, আমরা ওপেন সোর্স ডেটাহাব ব্যবহার করে কিভাবে শুরু করতে হয় তার নির্দেশনা প্রদান করব এবং সংক্ষিপ্তভাবে এর আর্কিটেকচার নিয়ে আলোচনা করব।

যেখানে হাউস এখন একটি ডেটাহাব!

LinkedIn এর মেটাডেটা দল আগে উপস্থাপিত ডেটাহাব (WhereHows-এর উত্তরসূরি), LinkedIn-এর অনুসন্ধান এবং মেটাডেটা আবিষ্কারের প্ল্যাটফর্ম, এবং এটি খোলার পরিকল্পনা শেয়ার করেছে। এই ঘোষণার কিছুক্ষণ পরে, আমরা DataHub-এর একটি আলফা সংস্করণ প্রকাশ করেছি এবং সম্প্রদায়ের সাথে শেয়ার করেছি। তারপর থেকে, আমরা ক্রমাগত সংগ্রহস্থলে অবদান রেখেছি এবং সর্বাধিক অনুরোধ করা বৈশিষ্ট্যগুলি যুক্ত করতে এবং সমস্যাগুলি সমাধান করতে আগ্রহী ব্যবহারকারীদের সাথে কাজ করেছি। আমরা এখন আনুষ্ঠানিক প্রকাশ ঘোষণা করে খুশি GitHub এ DataHub.

ওপেন সোর্স অ্যাপ্রোচ

WhoHows, ডেটা খোঁজার জন্য LinkedIn এর মূল পোর্টাল এবং এটি কোথা থেকে আসে, একটি অভ্যন্তরীণ প্রকল্প হিসাবে শুরু হয়েছিল; মেটাডেটা দল এটি খুলেছে 2016 সালে সোর্স কোড. তারপর থেকে, দলটি সর্বদা দুটি ভিন্ন কোডবেস বজায় রেখেছে- একটি ওপেন সোর্সের জন্য এবং একটি লিঙ্কডইন-এর অভ্যন্তরীণ ব্যবহারের জন্য- কারণ লিঙ্কডইন ব্যবহারের ক্ষেত্রে তৈরি সমস্ত পণ্য বৈশিষ্ট্যগুলি সাধারণত বৃহত্তর দর্শকদের জন্য প্রযোজ্য ছিল না। অতিরিক্তভাবে, WhereHows-এর কিছু অভ্যন্তরীণ নির্ভরতা (অবকাঠামো, লাইব্রেরি, ইত্যাদি) রয়েছে যা ওপেন সোর্স নয়। পরবর্তী বছরগুলিতে, WhoHows অনেকগুলি পুনরাবৃত্তি এবং বিকাশ চক্রের মধ্য দিয়ে গেছে, দুটি কোডবেসকে সিঙ্কে রাখা একটি বড় চ্যালেঞ্জ করে তুলেছে। অভ্যন্তরীণ এবং ওপেন সোর্স ডেভেলপমেন্টকে সিঙ্কে রাখার চেষ্টা করার জন্য মেটাডেটা দল বছরের পর বছর ধরে বিভিন্ন পদ্ধতির চেষ্টা করেছে।

প্রথম চেষ্টা করুন: "প্রথমে ওপেন সোর্স"

আমরা প্রাথমিকভাবে একটি "ওপেন সোর্স ফার্স্ট" ডেভেলপমেন্ট মডেল অনুসরণ করেছি, যেখানে বেশিরভাগ ডেভেলপমেন্ট ওপেন সোর্স রিপোজিটরিতে ঘটে এবং অভ্যন্তরীণ স্থাপনার জন্য পরিবর্তন করা হয়। এই পদ্ধতির সমস্যা হল যে কোডটি সর্বদা প্রথমে GitHub-এ পুশ করা হয় আগে এটি সম্পূর্ণরূপে অভ্যন্তরীণভাবে পর্যালোচনা করা হয়। যতক্ষণ না ওপেন সোর্স রিপোজিটরি থেকে পরিবর্তন করা হয় এবং একটি নতুন অভ্যন্তরীণ স্থাপনা তৈরি না হয়, আমরা কোনো উৎপাদন সমস্যা খুঁজে পাব না। দুর্বল স্থাপনার ক্ষেত্রে, অপরাধী নির্ধারণ করাও খুব কঠিন ছিল কারণ ব্যাচে পরিবর্তন করা হয়েছিল।

অতিরিক্তভাবে, এই মডেলটি টিমের উৎপাদনশীলতা হ্রাস করে যখন নতুন বৈশিষ্ট্যগুলি তৈরি করে যার জন্য দ্রুত পুনরাবৃত্তির প্রয়োজন হয়, যেহেতু এটি সমস্ত পরিবর্তনগুলিকে প্রথমে একটি ওপেন সোর্স রিপোজিটরিতে পুশ করতে বাধ্য করে এবং তারপরে একটি অভ্যন্তরীণ সংগ্রহস্থলে ঠেলে দেয়৷ প্রক্রিয়াকরণের সময় কমাতে, প্রয়োজনীয় সংশোধন বা পরিবর্তন প্রথমে অভ্যন্তরীণ সংগ্রহস্থলে করা যেতে পারে, কিন্তু এই পরিবর্তনগুলিকে আবার ওপেন সোর্স রিপোজিটরিতে মার্জ করার সময় এটি একটি বিশাল সমস্যা হয়ে দাঁড়ায় কারণ দুটি সংগ্রহস্থল সিঙ্কের বাইরে ছিল।

সম্পূর্ণ বৈশিষ্ট্যযুক্ত কাস্টম ওয়েব অ্যাপ্লিকেশনগুলির তুলনায় ভাগ করা প্ল্যাটফর্ম, লাইব্রেরি বা অবকাঠামো প্রকল্পগুলির জন্য এই মডেলটি বাস্তবায়ন করা অনেক সহজ। অতিরিক্তভাবে, এই মডেলটি এমন প্রকল্পগুলির জন্য আদর্শ যা প্রথম দিন থেকে ওপেন সোর্স শুরু করে, তবে WhoHows সম্পূর্ণ অভ্যন্তরীণ ওয়েব অ্যাপ্লিকেশন হিসাবে তৈরি করা হয়েছিল। সমস্ত অভ্যন্তরীণ নির্ভরতাকে সম্পূর্ণরূপে বিমূর্ত করা সত্যিই কঠিন ছিল, তাই আমাদের অভ্যন্তরীণ কাঁটাটি রাখা দরকার ছিল, কিন্তু অভ্যন্তরীণ কাঁটা রাখা এবং বেশিরভাগ ওপেন সোর্স বিকাশ করা পুরোপুরি কার্যকর হয়নি।

দ্বিতীয় প্রচেষ্টা: "অভ্যন্তরীণ প্রথম"

**দ্বিতীয় প্রয়াস হিসেবে, আমরা একটি "অভ্যন্তরীণ প্রথম" উন্নয়ন মডেলে চলে এসেছি, যেখানে বেশিরভাগ উন্নয়ন অভ্যন্তরীণভাবে ঘটে এবং নিয়মিতভাবে ওপেন সোর্স কোডে পরিবর্তন করা হয়। যদিও এই মডেলটি আমাদের ব্যবহারের ক্ষেত্রে সবচেয়ে উপযুক্ত, তবে এর অন্তর্নিহিত সমস্যা রয়েছে। সরাসরি সমস্ত পার্থক্যকে ওপেন সোর্স রিপোজিটরিতে ঠেলে দেওয়া এবং পরে মার্জ দ্বন্দ্বগুলি সমাধান করার চেষ্টা করা একটি বিকল্প, তবে এটি সময়সাপেক্ষ। বেশিরভাগ ক্ষেত্রে বিকাশকারীরা তাদের কোড পর্যালোচনা করার সময় এটি না করার চেষ্টা করে। ফলস্বরূপ, এটি অনেক কম ঘন ঘন, ব্যাচে করা হবে, এবং এইভাবে পরবর্তীতে একত্রীকরণ বিরোধগুলি সমাধান করা আরও কঠিন করে তোলে।

তৃতীয়বার কাজ হলো!

উপরে উল্লিখিত দুটি ব্যর্থ প্রচেষ্টার ফলে WhoHows GitHub সংগ্রহস্থলটি দীর্ঘ সময়ের জন্য পুরানো হয়ে পড়েছিল। দলটি পণ্যের বৈশিষ্ট্য এবং স্থাপত্যের উন্নতি করতে থাকে, যাতে লিংকডইন-এর জন্য WhereHows-এর অভ্যন্তরীণ সংস্করণটি ওপেন সোর্স সংস্করণের চেয়ে আরও উন্নত হয়ে ওঠে। এমনকি এটির একটি নতুন নাম ছিল - DataHub। পূর্ববর্তী ব্যর্থ প্রচেষ্টার উপর ভিত্তি করে, দলটি একটি মাপযোগ্য, দীর্ঘমেয়াদী সমাধান বিকাশ করার সিদ্ধান্ত নিয়েছে।

যেকোন নতুন ওপেন সোর্স প্রকল্পের জন্য, LinkedIn-এর ওপেন সোর্স টিম একটি ডেভেলপমেন্ট মডেলের পরামর্শ দেয় এবং সমর্থন করে যেখানে প্রকল্পের মডিউলগুলি সম্পূর্ণরূপে ওপেন সোর্সে তৈরি করা হয়। ভার্সন করা আর্টিফ্যাক্টগুলিকে একটি পাবলিক রিপোজিটরিতে স্থাপন করা হয় এবং তারপর ব্যবহার করে অভ্যন্তরীণ লিঙ্কডইন আর্টিফ্যাক্টে আবার চেক করা হয় বহিরাগত লাইব্রেরি অনুরোধ (ELR). যারা ওপেন সোর্স ব্যবহার করেন তাদের জন্য এই ডেভেলপমেন্ট মডেল অনুসরণ করা শুধুমাত্র ভালো নয়, এর ফলে আরও মডুলার, এক্সটেনসিবল এবং প্লাগেবল আর্কিটেকচার তৈরি হয়।

যাইহোক, একটি পরিপক্ক ব্যাক-এন্ড অ্যাপ্লিকেশন যেমন DataHub এই অবস্থায় পৌঁছানোর জন্য একটি উল্লেখযোগ্য পরিমাণ সময় প্রয়োজন হবে। এটি সমস্ত অভ্যন্তরীণ নির্ভরতা সম্পূর্ণরূপে বিমূর্ত হওয়ার আগে ওপেন সোর্সিংয়ের সম্পূর্ণ কার্যকরী বাস্তবায়নের সম্ভাবনাকে বাদ দেয়। এই কারণেই আমরা এমন সরঞ্জামগুলি তৈরি করেছি যা আমাদেরকে ওপেন সোর্স অবদানগুলিকে দ্রুত এবং অনেক কম ব্যথা সহ করতে সাহায্য করে৷ এই সমাধানটি মেটাডেটা দল (DataHub বিকাশকারী) এবং ওপেন সোর্স সম্প্রদায় উভয়কেই উপকৃত করে। নিম্নলিখিত বিভাগগুলি এই নতুন পদ্ধতি নিয়ে আলোচনা করবে।

ওপেন সোর্স পাবলিশিং অটোমেশন

ওপেন সোর্স DataHub-এ মেটাডেটা দলের সর্বশেষ পদ্ধতি হল এমন একটি টুল তৈরি করা যা অভ্যন্তরীণ কোডবেস এবং ওপেন সোর্স রিপোজিটরিকে স্বয়ংক্রিয়ভাবে সিঙ্ক করে। এই টুলকিটের উচ্চ স্তরের বৈশিষ্ট্যগুলির মধ্যে রয়েছে:

1. ওপেন সোর্সে/থেকে লিঙ্কডইন কোড সিঙ্ক করুন, অনুরূপ rsync.
2. লাইসেন্স হেডার জেনারেশন, অনুরূপ অ্যাপাচি ইঁদুর.
3. অভ্যন্তরীণ কমিট লগগুলি থেকে স্বয়ংক্রিয়ভাবে ওপেন সোর্স কমিট লগ তৈরি করুন।
4. অভ্যন্তরীণ পরিবর্তনগুলি প্রতিরোধ করুন যা ওপেন সোর্স বিল্ডকে ভেঙে দেয় নির্ভরতা পরীক্ষা.

নিম্নলিখিত উপ-বিভাগগুলি উপরে উল্লিখিত ফাংশনগুলির মধ্যে অনুসন্ধান করবে যার আকর্ষণীয় সমস্যা রয়েছে।

সোর্স কোড সিঙ্ক্রোনাইজেশন

DataHub-এর ওপেন সোর্স সংস্করণের বিপরীতে, যা একটি একক GitHub সংগ্রহস্থল, DataHub-এর LinkedIn সংস্করণ হল একাধিক সংগ্রহস্থলের সংমিশ্রণ (যাকে অভ্যন্তরীণভাবে বলা হয়) বহু পণ্য) DataHub ইন্টারফেস, মেটাডেটা মডেল লাইব্রেরি, মেটাডেটা ওয়্যারহাউস ব্যাকএন্ড পরিষেবা এবং স্ট্রিমিং কাজগুলি লিঙ্কডইন-এ পৃথক সংগ্রহস্থলে থাকে। যাইহোক, ওপেন সোর্স ব্যবহারকারীদের জন্য এটি সহজ করার জন্য, DataHub-এর ওপেন সোর্স সংস্করণের জন্য আমাদের কাছে একটি একক সংগ্রহস্থল রয়েছে।

চিত্র 1: সংগ্রহস্থলগুলির মধ্যে সিঙ্ক্রোনাইজেশন লিঙ্কডইন ডেটাহাব এবং একটি একক সংগ্রহস্থল ডেটাহাব মুক্ত উৎস

স্বয়ংক্রিয় বিল্ড, পুশ এবং টান ওয়ার্কফ্লো সমর্থন করতে, আমাদের নতুন টুল স্বয়ংক্রিয়ভাবে প্রতিটি সোর্স ফাইলের সাথে সম্পর্কিত একটি ফাইল-স্তরের ম্যাপিং তৈরি করে। যাইহোক, টুলকিটের প্রাথমিক কনফিগারেশন প্রয়োজন এবং ব্যবহারকারীদের অবশ্যই একটি উচ্চ-স্তরের মডিউল ম্যাপিং প্রদান করতে হবে যেমন নীচে দেখানো হয়েছে।

{
  "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 যার কীগুলি হল ওপেন সোর্স রিপোজিটরির টার্গেট মডিউল এবং মানগুলি লিঙ্কডইন রিপোজিটরিতে সোর্স মডিউলগুলির তালিকা৷ একটি ওপেন সোর্স রিপোজিটরির যেকোন টার্গেট মডিউল যেকোন সংখ্যক সোর্স মডিউল দ্বারা খাওয়ানো যেতে পারে। উত্স মডিউলগুলিতে সংগ্রহস্থলগুলির অভ্যন্তরীণ নামগুলি নির্দেশ করতে, ব্যবহার করুন স্ট্রিং ইন্টারপোলেশন ব্যাশ স্টাইলে। একটি মডিউল-স্তরের ম্যাপিং ফাইল ব্যবহার করে, সরঞ্জামগুলি সংশ্লিষ্ট ডিরেক্টরিতে সমস্ত ফাইল স্ক্যান করে একটি ফাইল-স্তরের ম্যাপিং ফাইল তৈরি করে।

{
  "${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 ম্যাপিং। ফাইল অ্যাসোসিয়েশনের এই স্বয়ংক্রিয় তৈরির সাথে সম্পর্কিত বেশ কয়েকটি নিয়ম রয়েছে:

• ওপেন সোর্সে একটি টার্গেট মডিউলের একাধিক সোর্স মডিউলের ক্ষেত্রে, দ্বন্দ্ব দেখা দিতে পারে, যেমন একই এফকিউসিএন, একাধিক সোর্স মডিউলে বিদ্যমান। একটি দ্বন্দ্ব সমাধানের কৌশল হিসাবে, আমাদের সরঞ্জামগুলি ডিফল্ট "শেষ এক জয়" বিকল্পে।
• "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 ওপেন সোর্স রিপোজিটরিতে অভ্যন্তরীণ পরিবর্তনগুলি ব্যাচ করি।

ওপেন সোর্স ডেটাহাব এবং আমাদের উত্পাদন সংস্করণের মধ্যে পার্থক্য

এই মুহুর্তে, আমরা DataHub সংগ্রহস্থলের দুটি সংস্করণ সিঙ্ক্রোনাইজ করার জন্য আমাদের সমাধান নিয়ে আলোচনা করেছি, কিন্তু আমরা এখনও কেন দুটি ভিন্ন উন্নয়ন স্ট্রীম প্রথম স্থানে প্রয়োজন তার কারণগুলি ব্যাখ্যা করিনি। এই বিভাগে, আমরা DataHub এর সর্বজনীন সংস্করণ এবং LinkedIn সার্ভারে উৎপাদন সংস্করণের মধ্যে পার্থক্যগুলি তালিকাভুক্ত করব এবং এই পার্থক্যগুলির কারণগুলি ব্যাখ্যা করব৷

বৈপরীত্যের একটি উৎস এই সত্য থেকে উদ্ভূত হয় যে আমাদের উৎপাদন সংস্করণে কোডের উপর নির্ভরতা রয়েছে যা এখনও ওপেন সোর্স নয়, যেমন LinkedIn's Offspring (LinkedIn-এর অভ্যন্তরীণ নির্ভরতা ইনজেকশন ফ্রেমওয়ার্ক)। অভ্যন্তরীণ কোডবেসে অফসপ্রিং ব্যাপকভাবে ব্যবহৃত হয় কারণ এটি গতিশীল কনফিগারেশন পরিচালনার জন্য পছন্দের পদ্ধতি। কিন্তু এটা ওপেন সোর্স নয়; তাই আমাদের ওপেন সোর্স DataHub-এর বিকল্প খুঁজতে হবে।

অন্যান্য কারণও আছে। যেহেতু আমরা LinkedIn এর প্রয়োজনের জন্য মেটাডেটা মডেলে এক্সটেনশন তৈরি করি, এই এক্সটেনশনগুলি সাধারণত LinkedIn-এর জন্য খুব নির্দিষ্ট এবং অন্য পরিবেশে সরাসরি প্রযোজ্য নাও হতে পারে। উদাহরণ স্বরূপ, অংশগ্রহণকারী আইডি এবং অন্যান্য ধরনের মেটাডেটার জন্য আমাদের কাছে খুব নির্দিষ্ট লেবেল রয়েছে। সুতরাং, আমরা এখন DataHub-এর ওপেন সোর্স মেটাডেটা মডেল থেকে এই এক্সটেনশনগুলিকে বাদ দিয়েছি। যেহেতু আমরা সম্প্রদায়ের সাথে যুক্ত হই এবং তাদের প্রয়োজনগুলি বুঝতে পারি, আমরা এই এক্সটেনশনগুলির সাধারণ ওপেন সোর্স সংস্করণগুলিতে কাজ করব যেখানে প্রয়োজন হবে৷

ওপেন সোর্স সম্প্রদায়ের জন্য ব্যবহারের সহজতা এবং সহজ অভিযোজন ডাটাহাবের দুটি সংস্করণের মধ্যে কিছু পার্থক্যকে অনুপ্রাণিত করেছে। স্ট্রিম প্রসেসিং অবকাঠামোর পার্থক্য এর একটি ভালো উদাহরণ। যদিও আমাদের অভ্যন্তরীণ সংস্করণ একটি পরিচালিত স্ট্রিম প্রক্রিয়াকরণ কাঠামো ব্যবহার করে, আমরা ওপেন সোর্স সংস্করণের জন্য অন্তর্নির্মিত (স্বতন্ত্র) স্ট্রিম প্রক্রিয়াকরণ ব্যবহার করা বেছে নিয়েছি কারণ এটি অন্য অবকাঠামো নির্ভরতা তৈরি করা এড়ায়।

পার্থক্যের আরেকটি উদাহরণ হল একাধিক GMS-এর পরিবর্তে একটি ওপেন সোর্স বাস্তবায়নে একটি একক GMS (জেনারালাইজড মেটাডেটা স্টোর) থাকা। GMA (জেনারালাইজড মেটাডেটা আর্কিটেকচার) হল DataHub-এর ব্যাক-এন্ড আর্কিটেকচারের নাম, এবং GMS হল GMA-এর প্রসঙ্গে মেটাডেটা স্টোর। GMA হল একটি অত্যন্ত নমনীয় আর্কিটেকচার যা আপনাকে প্রতিটি ডেটা কনস্ট্রাক্ট (যেমন ডেটাসেট, ব্যবহারকারী, ইত্যাদি) তার নিজস্ব মেটাডেটা স্টোরে বিতরণ করতে দেয়, বা একটি একক মেটাডেটা স্টোরে একাধিক ডেটা কনস্ট্রাক্ট সংরক্ষণ করতে দেয় যতক্ষণ না রেজিস্ট্রিতে ডেটা স্ট্রাকচার ম্যাপিং রয়েছে। GMS আপডেট করা হয়েছে। ব্যবহারের সহজতার জন্য, আমরা একটি একক GMS দৃষ্টান্ত বেছে নিয়েছি যা ওপেন সোর্স DataHub-এ সমস্ত বিভিন্ন ডেটা কনস্ট্রাক্ট সঞ্চয় করে।

দুটি বাস্তবায়নের মধ্যে পার্থক্যের একটি সম্পূর্ণ তালিকা নীচের টেবিলে দেওয়া হয়েছে।

পণ্যের বৈশিষ্ট্য
লিঙ্কডইন ডেটাহাব
ওপেন সোর্স ডেটাহাব

সমর্থিত ডেটা কনস্ট্রাক্ট
1) ডেটাসেট 2) ব্যবহারকারী 3) মেট্রিক্স 4) ML বৈশিষ্ট্য 5) চার্ট 6) ড্যাশবোর্ড
1) ডেটাসেট 2) ব্যবহারকারী

ডেটাসেটের জন্য সমর্থিত মেটাডেটা উৎস
1) আমব্রি 2) কাউচবেস 3) ডালিডস 4) এসপ্রেসো 5) এইচডিএফএস 6) হাইভ 7) কাফকা 8) মঙ্গোডিবি 9) মাইএসকিউএল 10) ওরাকল 11) পিনট 12) প্রেস্টো 12) সমুদ্রের 13) টেরাডাটা 13) ভেক্টর 14) ভেনিস
হাইভ কাফকা RDBMS

পাব-সাব
লিঙ্কডইন কাফকা
সঙ্গম কাফকা

স্ট্রিম প্রসেসিং
Managed
এমবেডেড (স্বতন্ত্র)

নির্ভরতা ইনজেকশন এবং গতিশীল কনফিগারেশন
লিঙ্কডইন সন্তানসন্ততি
বসন্ত

টুলিং তৈরি করুন
Ligradle (LinkedIn এর অভ্যন্তরীণ Gradle র‍্যাপার)
গ্রেডলিউ

সিআই/সিডি
CRT (লিঙ্কডইনের অভ্যন্তরীণ CI/CD)
TravisCI এবং ডকার হাব

মেটাডেটা স্টোর
বিতরণ করা একাধিক GMS: 1) ডেটাসেট GMS 2) ব্যবহারকারী GMS 3) মেট্রিক GMS 4) বৈশিষ্ট্য GMS 5) চার্ট/ড্যাশবোর্ড GMS
একক GMS এর জন্য: 1) ডেটাসেট 2) ব্যবহারকারী

ডকার পাত্রে মাইক্রোসার্ভিস

ডকশ্রমিক এর সাথে অ্যাপ্লিকেশন স্থাপনা এবং বিতরণকে সহজ করে ধারককরণ. DataHub-এর পরিষেবার প্রতিটি অংশই ওপেন সোর্স, যার মধ্যে রয়েছে অবকাঠামোগত উপাদান যেমন কাফকা, Elasticsearch, নিও 4 জে и মাইএসকিউএল, এর নিজস্ব ডকার ইমেজ আছে। ডকার পাত্রে অর্কেস্ট্রেট করতে আমরা ব্যবহার করি ডকার রচনা.

চিত্র 2: স্থাপত্য ডেটাহাব *মুক্ত উৎস**

আপনি উপরের ছবিতে DataHub এর উচ্চ-স্তরের আর্কিটেকচার দেখতে পারেন। অবকাঠামোগত উপাদানগুলি ছাড়াও, এতে চারটি ভিন্ন ডকার কন্টেইনার রয়েছে:

datahub-gms: মেটাডেটা স্টোরেজ পরিষেবা

ডেটাহাব-ফ্রন্টএন্ড: অ্যাপ্লিকেশন খেলা, DataHub ইন্টারফেস পরিবেশন করা।

datahub-mce-consumer: অ্যাপ্লিকেশন কাফকা প্রবাহ, যা মেটাডেটা পরিবর্তন ইভেন্ট (MCE) স্ট্রীম ব্যবহার করে এবং মেটাডেটা স্টোর আপডেট করে।

datahub-mae-ভোক্তা: অ্যাপ্লিকেশন কাফকা প্রবাহ, যা একটি মেটাডেটা অডিট ইভেন্ট স্ট্রিম (MAE) ব্যবহার করে এবং একটি অনুসন্ধান সূচক এবং গ্রাফ ডাটাবেস তৈরি করে।

ওপেন সোর্স রিপোজিটরি ডকুমেন্টেশন এবং মূল DataHub ব্লগ পোস্ট বিভিন্ন পরিষেবার ফাংশন সম্পর্কে আরও বিস্তারিত তথ্য রয়েছে।

DataHub-এ CI/CD ওপেন সোর্স

ওপেন সোর্স ডেটাহাব রিপোজিটরি ব্যবহার করে TravisCI ক্রমাগত একীকরণের জন্য এবং ডকার হাব ক্রমাগত স্থাপনার জন্য। উভয়েরই ভাল গিটহাব ইন্টিগ্রেশন রয়েছে এবং সেট আপ করা সহজ। সম্প্রদায় বা প্রাইভেট কোম্পানী দ্বারা বিকশিত বেশিরভাগ ওপেন সোর্স অবকাঠামোর জন্য (যেমন মিলিয়া একীভূত), সম্প্রদায়ের দ্বারা ব্যবহারের সহজতার জন্য ডকার ইমেজ তৈরি এবং ডকার হাবে স্থাপন করা হয়। ডকার হাবে পাওয়া যেকোন ডকার ইমেজ একটি সাধারণ কমান্ড দিয়ে সহজেই ব্যবহার করা যেতে পারে ডকার টান.

DataHub ওপেন সোর্স রিপোজিটরির প্রতি প্রতিশ্রুতির সাথে, সমস্ত ডকার ইমেজ স্বয়ংক্রিয়ভাবে তৈরি করা হয় এবং "সর্বশেষ" ট্যাগ সহ ডকার হাবে স্থাপন করা হয়। যদি ডকার হাব কিছু দিয়ে কনফিগার করা হয় রেগুলার এক্সপ্রেশন শাখার নামকরণ, ওপেন সোর্স রিপোজিটরির সমস্ত ট্যাগ ডকার হাবে সংশ্লিষ্ট ট্যাগ নামের সাথে প্রকাশ করা হয়।

DataHub ব্যবহার করে

DataHub সেট আপ করা হচ্ছে খুবই সহজ এবং তিনটি সহজ ধাপ নিয়ে গঠিত:

1. ওপেন সোর্স রিপোজিটরি ক্লোন করুন এবং দ্রুত শুরু করার জন্য প্রদত্ত ডকার-কম্পোজ স্ক্রিপ্ট ব্যবহার করে ডকার-কম্পোজ সহ সমস্ত ডকার কন্টেইনার চালান।
2. এছাড়াও প্রদত্ত কমান্ড লাইন টুল ব্যবহার করে সংগ্রহস্থলে প্রদত্ত নমুনা ডেটা ডাউনলোড করুন।
3. আপনার ব্রাউজারে DataHub ব্রাউজ করুন।

সক্রিয়ভাবে ট্র্যাক করা হয়েছে৷ গিটার আড্ডা দ্রুত প্রশ্নের জন্যও কনফিগার করা হয়েছে। ব্যবহারকারীরা GitHub সংগ্রহস্থলে সরাসরি সমস্যা তৈরি করতে পারে। সবচেয়ে গুরুত্বপূর্ণ, আমরা সমস্ত প্রতিক্রিয়া এবং পরামর্শকে স্বাগত জানাই এবং প্রশংসা করি!

ভবিষ্যতের জন্য পরিকল্পনা

বর্তমানে, ওপেন সোর্স DataHub-এর জন্য প্রতিটি অবকাঠামো বা মাইক্রোসার্ভিস একটি ডকার কন্টেইনার হিসাবে তৈরি করা হয়েছে এবং পুরো সিস্টেমটি ব্যবহার করে সাজানো হয়েছে Docker-রচনা. জনপ্রিয়তা এবং ব্যাপকতা দেওয়া Kubernetes, আমরা নিকট ভবিষ্যতে একটি Kubernetes ভিত্তিক সমাধান প্রদান করতে চাই।

আমরা একটি পাবলিক ক্লাউড পরিষেবা যেমন ডেটাহাব স্থাপনের জন্য একটি টার্নকি সমাধান প্রদান করার পরিকল্পনা করি৷ নভোনীল, ডেস্কটপ AWS বা গুগল ক্লাউড. Azure-এ LinkedIn-এর স্থানান্তরের সাম্প্রতিক ঘোষণার পরিপ্রেক্ষিতে, এটি মেটাডেটা দলের অভ্যন্তরীণ অগ্রাধিকারের সাথে সারিবদ্ধ হবে।

সবশেষে কিন্তু অন্তত, ওপেন সোর্স কমিউনিটিতে DataHub-এর প্রাথমিক গ্রহণকারী সকলকে ধন্যবাদ যারা DataHub আলফাস রেট দিয়েছেন এবং সমস্যা চিহ্নিত করতে এবং ডকুমেন্টেশন উন্নত করতে আমাদের সাহায্য করেছেন।

উত্স: www.habr.com