ডেল্টা: ডেটা সিঙ্ক্রোনাইজেশন এবং সমৃদ্ধকরণ প্ল্যাটফর্ম

হারে একটি নতুন প্রবাহ চালু হওয়ার প্রত্যাশায় ডেটা ইঞ্জিনিয়ার আমরা আকর্ষণীয় উপাদানের একটি অনুবাদ প্রস্তুত করেছি।

ওভারভিউ

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

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

এই সমস্যাগুলি সমাধানের জন্য ডেল্টা তৈরি করা হয়েছিল। ডেল্টা শেষ পর্যন্ত ডেটা সিঙ্ক্রোনাইজেশন এবং সমৃদ্ধকরণের জন্য একটি সামঞ্জস্যপূর্ণ, ইভেন্ট-চালিত প্ল্যাটফর্ম প্রদান করে।

বিদ্যমান সমাধান

দুইবার প্রবেশ করানো

দুটি ডেটা স্টোরকে সিঙ্কে রাখতে, আপনি ডুয়াল রাইটিং ব্যবহার করতে পারেন, যা একটি স্টোরে লেখে এবং তারপরে অবিলম্বে অন্যটিতে লেখে। প্রথম রেকর্ডিং পুনরায় চেষ্টা করা যেতে পারে এবং দ্বিতীয়টি বাতিল করা যেতে পারে যদি প্রচেষ্টার সংখ্যা শেষ হওয়ার পরে প্রথমটি ব্যর্থ হয়। যাইহোক, দ্বিতীয় স্টোরে লেখা ব্যর্থ হলে দুটি ডেটা স্টোর সিঙ্কের বাইরে হয়ে যেতে পারে। এই সমস্যাটি সাধারণত একটি পুনরুদ্ধার পদ্ধতি তৈরি করে সমাধান করা হয় যা পর্যায়ক্রমে প্রথম সঞ্চয়স্থান থেকে দ্বিতীয়তে ডেটা পুনরায় স্থানান্তর করতে পারে, বা ডেটাতে পার্থক্য সনাক্ত করা হলেই তা করতে পারে।

সমস্যাগুলি হ'ল:

একটি পুনরুদ্ধার পদ্ধতি সম্পাদন করা একটি নির্দিষ্ট কাজ যা পুনরায় ব্যবহার করা যাবে না। উপরন্তু, পুনরুদ্ধার পদ্ধতিটি সঞ্চালিত না হওয়া পর্যন্ত স্টোরেজ অবস্থানের মধ্যে ডেটা সিঙ্কের বাইরে থাকে। সমাধানটি আরও জটিল হয়ে ওঠে যদি দুটির বেশি ডেটা স্টোর ব্যবহার করা হয়। অবশেষে, পুনরুদ্ধার পদ্ধতি মূল ডেটা উৎসে লোড যোগ করতে পারে।

লগ টেবিল পরিবর্তন করুন

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

সমস্যাগুলি হ'ল:

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

আরেকটি সমস্যা হল এমন সিস্টেমে স্কিমা পরিবর্তন করা যা লেনদেনমূলক স্কিমা পরিবর্তনগুলি সমর্থন করে না [1][2], যেমন MySQL। অতএব, পরিবর্তন করার প্যাটার্ন (উদাহরণস্বরূপ, একটি স্কিমা পরিবর্তন) এবং লেনদেনভাবে এটি পরিবর্তন লগ টেবিলে রেকর্ড করা সবসময় কাজ করবে না।

বিতরণ করা লেনদেন

বিতরণকৃত লেনদেনগুলি একাধিক ভিন্ন ভিন্ন ডেটা স্টোর জুড়ে একটি লেনদেনকে বিভক্ত করতে ব্যবহার করা যেতে পারে যাতে অপারেশনটি হয় ব্যবহৃত সমস্ত ডেটা স্টোরের জন্য প্রতিশ্রুতিবদ্ধ হয়, বা তাদের কোনওটির জন্য প্রতিশ্রুতিবদ্ধ নয়।

সমস্যাগুলি হ'ল:

ডিস্ট্রিবিউটেড লেনদেন ভিন্ন ভিন্ন ডেটা স্টোরের জন্য একটি খুব বড় সমস্যা। তাদের প্রকৃতির দ্বারা, তারা শুধুমাত্র জড়িত সিস্টেমের সর্বনিম্ন সাধারণ হর এর উপর নির্ভর করতে পারে। উদাহরণ স্বরূপ, প্রস্তুতি পর্বের সময় আবেদন প্রক্রিয়া ব্যর্থ হলে XA লেনদেন সম্পাদনকে অবরুদ্ধ করে। অতিরিক্তভাবে, XA অচলাবস্থা সনাক্তকরণ প্রদান করে না বা আশাবাদী সমবায় নিয়ন্ত্রণ স্কিম সমর্থন করে না। উপরন্তু, ইলাস্টিক সার্চের মত কিছু সিস্টেম XA বা অন্য কোন ভিন্ন ভিন্ন লেনদেন মডেল সমর্থন করে না। সুতরাং, বিভিন্ন ডেটা স্টোরেজ প্রযুক্তিতে লিখিত পারমাণবিকতা নিশ্চিত করা অ্যাপ্লিকেশনগুলির জন্য একটি খুব চ্যালেঞ্জিং কাজ [3]।

ব-দ্বীপ

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

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

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

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

চিত্র 2. ডেল্টা ব্যবহার করে ডেটা পাইপলাইন
নিম্নলিখিত বিভাগগুলিতে, আমরা ডেল্টা-সংযোগকারীর অপারেশন বর্ণনা করব, যা স্টোরেজের সাথে সংযোগ করে এবং পরিবহন স্তরে CDC ইভেন্টগুলি প্রকাশ করে, যা একটি রিয়েল-টাইম ডেটা ট্রান্সমিশন অবকাঠামো যা CDC ইভেন্টগুলিকে কাফকা বিষয়গুলিতে রুট করে। এবং একেবারে শেষে, আমরা ডেল্টা স্ট্রিম প্রসেসিং ফ্রেমওয়ার্ক সম্পর্কে কথা বলব, যেটি অ্যাপ্লিকেশন ডেভেলপাররা ডেটা প্রসেসিং এবং সমৃদ্ধকরণ যুক্তির জন্য ব্যবহার করতে পারে।

CDC (পরিবর্তন-ডেটা-ক্যাপচার)

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

ডেল্টা-সংযোগকারী বিভিন্ন অতিরিক্ত বৈশিষ্ট্য সমর্থন করে যেমন:

• কাফকার আগে কাস্টম আউটপুট ডেটা লেখার ক্ষমতা।
• সমস্ত টেবিল, একটি নির্দিষ্ট টেবিল, বা নির্দিষ্ট প্রাথমিক কীগুলির জন্য যে কোনো সময় ম্যানুয়াল ডাম্প সক্রিয় করার ক্ষমতা।
• ডাম্পগুলি খণ্ডে পুনরুদ্ধার করা যেতে পারে, তাই ব্যর্থতার ক্ষেত্রে আবার শুরু করার দরকার নেই।
• টেবিলে লক রাখার কোন প্রয়োজন নেই, যা ডাটাবেস লেখার ট্র্যাফিক আমাদের পরিষেবা দ্বারা কখনই অবরুদ্ধ না করা নিশ্চিত করার জন্য খুবই গুরুত্বপূর্ণ।
• AWS প্রাপ্যতা অঞ্চলে অপ্রয়োজনীয় দৃষ্টান্তের কারণে উচ্চ প্রাপ্যতা।

আমরা বর্তমানে AWS RDS এবং Aurora-তে স্থাপনা সহ MySQL এবং Postgres সমর্থন করি। আমরা ক্যাসান্দ্রাকেও সমর্থন করি (মাল্টি-মাস্টার)। আপনি এখানে ডেল্টা-সংযোগকারী সম্পর্কে আরও বিশদ জানতে পারেন ব্লগ পোস্ট.

কাফকা এবং পরিবহন স্তর

ডেল্টার ইভেন্ট ট্রান্সপোর্ট লেয়ারটি প্লাটফর্মের মেসেজিং সার্ভিসে তৈরি করা হয়েছে খিলানের মধ্যপ্রস্তর.

ঐতিহাসিকভাবে, Netflix-এ পোস্ট করা দীর্ঘায়ুর পরিবর্তে অ্যাক্সেসযোগ্যতার জন্য অপ্টিমাইজ করা হয়েছে (নীচে দেখুন)। পূর্ববর্তী নিবন্ধ) ট্রেড-অফটি বিভিন্ন প্রান্তের পরিস্থিতিতে সম্ভাব্য ব্রোকার ডেটার অসঙ্গতি ছিল। উদাহরণ স্বরূপ, অপরিচ্ছন্ন নেতা নির্বাচন প্রাপকের সম্ভাব্য ডুপ্লিকেট বা হারিয়ে যাওয়া ঘটনাগুলির জন্য দায়ী।

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

কিস্টোন কাফকা ক্লাস্টারে, অপরিচ্ছন্ন নেতা নির্বাচন সাধারণত প্রকাশকের অ্যাক্সেসযোগ্যতা নিশ্চিত করতে অন্তর্ভুক্ত করা হয়। এর ফলে বার্তা নষ্ট হতে পারে যদি একটি অসিঙ্ক্রোনাইজড রেপ্লিকা নেতা হিসেবে নির্বাচিত হয়। একটি নতুন উচ্চ প্রাপ্যতা কাফকা ক্লাস্টারের জন্য, বিকল্প অপরিচ্ছন্ন নেতা নির্বাচন বার্তা ক্ষতি রোধ করতে বন্ধ করা হয়েছে।

আমরাও বাড়ালাম প্রতিলিপি ফ্যাক্টর 2 থেকে 3 এবং ন্যূনতম ইনসিঙ্ক প্রতিলিপি 1 থেকে 2. এই ক্লাস্টারে লেখা প্রকাশকদের অন্য সকলের কাছ থেকে অ্যাকস প্রয়োজন, নিশ্চিত করে যে 2টির মধ্যে 3টিতে প্রকাশকের দ্বারা পাঠানো সবচেয়ে সাম্প্রতিক বার্তা রয়েছে৷

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

ডেটা ডেলিভারি গ্যারান্টি আরও বাড়ানোর জন্য, আমরা ব্যবহার করি বার্তা ট্র্যাকিং সিস্টেম চরম পরিস্থিতিতে কোনো বার্তার ক্ষতি সনাক্ত করতে (উদাহরণস্বরূপ, পার্টিশন লিডারে ঘড়ি ডিসিঙ্ক্রোনাইজেশন)।

স্ট্রিম প্রসেসিং ফ্রেমওয়ার্ক

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

ডেল্টা Flink এবং SPaaS এর উপর ভিত্তি করে একটি স্ট্রিম প্রসেসিং ফ্রেমওয়ার্ক প্রদান করে যা ব্যবহার করে টীকা-ভিত্তিক ডিএসএল (ডোমেন নির্দিষ্ট ভাষা) বিমূর্ত প্রযুক্তিগত বিবরণ. উদাহরণস্বরূপ, বহিরাগত পরিষেবাগুলিকে কল করার মাধ্যমে ইভেন্টগুলিকে কোন ধাপে সমৃদ্ধ করা হবে তা নির্ধারণ করতে, ব্যবহারকারীদের নিম্নলিখিত ডিএসএল লিখতে হবে এবং ফ্রেমওয়ার্ক এটির উপর ভিত্তি করে একটি মডেল তৈরি করবে, যা ফ্লিঙ্ক দ্বারা কার্যকর করা হবে।

চিত্র 3. ডেল্টায় ডিএসএল সমৃদ্ধকরণের উদাহরণ

প্রসেসিং ফ্রেমওয়ার্ক শুধুমাত্র শেখার বক্ররেখাই কমায় না, সাধারণ স্ট্রিম প্রসেসিং বৈশিষ্ট্য যেমন ডিডপ্লিকেশন, স্কিমাটাইজেশন এবং সাধারণ অপারেশনাল সমস্যা সমাধানের জন্য নমনীয়তা এবং স্থিতিস্থাপকতা প্রদান করে।

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

চিত্র 4. ডেল্টা স্ট্রীম প্রসেসিং ফ্রেমওয়ার্ক আর্কিটেকচার

এই পদ্ধতির বেশ কয়েকটি সুবিধা রয়েছে:

• ব্যবহারকারীরা Flink বা SPaaS কাঠামোর সুনির্দিষ্ট বিষয়ে অনুসন্ধান না করেই তাদের ব্যবসায়িক যুক্তিতে ফোকাস করতে পারে।
• অপ্টিমাইজেশান এমনভাবে করা যেতে পারে যা ব্যবহারকারীদের কাছে স্বচ্ছ, এবং ব্যবহারকারী কোড (UDF) এ কোন পরিবর্তন না করেই ত্রুটিগুলি সংশোধন করা যেতে পারে।
• ডেল্টা অ্যাপ্লিকেশন অভিজ্ঞতা ব্যবহারকারীদের জন্য সরলীকৃত হয়েছে কারণ প্ল্যাটফর্মটি বাক্সের বাইরে নমনীয়তা এবং স্থিতিস্থাপকতা প্রদান করে এবং বিভিন্ন বিস্তারিত মেট্রিক্স সংগ্রহ করে যা সতর্কতার জন্য ব্যবহার করা যেতে পারে।

উৎপাদন ব্যবহার

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

চিত্র 5. ডেল্টার উচ্চ-স্তরের স্থাপত্য।

স্বীকৃতি

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

সূত্র

1. dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
2. dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
3. মার্টিন ক্লেপম্যান, অ্যালিস্টার আর. বেরেসফোর্ড, বোয়ার্জ স্বিংগেন: অনলাইন ইভেন্ট প্রসেসিং। কমুন ACM 62(5): 43–49 (2019)। DOI: doi.org/10.1145/3312527

একটি বিনামূল্যে ওয়েবিনার জন্য সাইন আপ করুন: "Amazon Redshift স্টোরেজের জন্য ডেটা বিল্ড টুল।"

উত্স: www.habr.com