ক্লিকহাউস থেকে অ্যাপাচি ডরিসে টেনসেন্ট মিউজিক ট্রানজিশন

এই নিবন্ধটি আমি এবং আমার সহকর্মী কাই দাই দ্বারা সহ-লিখিত। আমরা দুজনেই টেনসেন্ট মিউজিক (এনওয়াইএসই: টিএমই) এর ডেটা প্ল্যাটফর্ম প্রকৌশলী, একটি মিউজিক স্ট্রিমিং পরিষেবা প্রদানকারী যার 800 মিলিয়ন মাসিক সক্রিয় ব্যবহারকারী। এখানে নম্বর ড্রপ করা বড়াই নয়, তথ্যের সমুদ্রের ইঙ্গিত দেওয়া যা আমার দরিদ্র সহকর্মীরা এবং আমাকে প্রতিদিন মোকাবেলা করতে হয়।

আমরা কি জন্য ক্লিক হাউস ব্যবহার

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

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

আমরা আমাদের বেশিরভাগ ডেটা টেনসেন্ট ডেটা ওয়ারহাউস (TDW), একটি অফলাইন ডেটা প্ল্যাটফর্মে সংরক্ষণ এবং প্রক্রিয়া করেছি যেখানে আমরা বিভিন্ন ট্যাগ এবং মেট্রিক সিস্টেমে ডেটা রাখি এবং তারপর প্রতিটি বস্তুকে কেন্দ্র করে ফ্ল্যাট টেবিল তৈরি করি (গান, শিল্পী ইত্যাদি)।

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

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

ডেটা প্রসেসিং পাইপলাইনটি দেখতে এইরকম ছিল:

ক্লিকহাউসের সমস্যা

উপরের পাইপলাইনের সাথে কাজ করার সময়, আমরা কয়েকটি সমস্যার সম্মুখীন হয়েছি:

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

   
   

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

   
   

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

Apache Doris-এ রূপান্তর

Apache Doris , একটি রিয়েল-টাইম অ্যানালিটিকাল ডাটাবেস, কিছু বৈশিষ্ট্য নিয়ে গর্ব করে যা আমাদের সমস্যাগুলি সমাধান করার জন্য আমাদের যা প্রয়োজন ছিল:

1. আংশিক আপডেট : ডরিস বিভিন্ন ধরণের ডেটা মডেল সমর্থন করে, যার মধ্যে অ্যাগ্রিগেট মডেল কলামের রিয়েল-টাইম আংশিক আপডেট সমর্থন করে। এটির উপর ভিত্তি করে, আমরা সরাসরি ডরিসের মধ্যে কাঁচা ডেটা গ্রহণ করতে পারি এবং সেখানে ফ্ল্যাট টেবিল তৈরি করতে পারি। ইনজেশন এভাবে যায়: প্রথমত, কাফকাতে ডাটা লোড করতে আমরা স্পার্ক ব্যবহার করি; তারপর, ফ্লিঙ্কের মাধ্যমে ডরিস এবং ইলাস্টিকসার্চে যেকোন ক্রমবর্ধমান ডেটা আপডেট করা হবে। ইতিমধ্যে, ফ্লিঙ্ক ডেটা প্রাক-একত্রিত করবে যাতে ডরিস এবং ইলাস্টিকসার্চের উপর বোঝা ছেড়ে দেওয়া যায়।

   
   

2. স্টোরেজ খরচ : ডরিস হাইভ, আইসবার্গ, হুডি, মাইএসকিউএল, এবং ইলাস্টিকসার্চ জুড়ে মাল্টি-টেবিল জয়েন কোয়েরি এবং ফেডারেটেড কোয়েরি সমর্থন করে। এটি আমাদেরকে বৃহৎ সমতল টেবিলগুলিকে ছোট আকারে বিভক্ত করতে এবং আপডেট ফ্রিকোয়েন্সি অনুসারে বিভাজন করতে দেয়। এটি করার সুবিধার মধ্যে রয়েছে স্টোরেজের বোঝা থেকে মুক্তি এবং কোয়েরি থ্রুপুট বৃদ্ধি।

   
   

3. রক্ষণাবেক্ষণের খরচ : ডরিস সাধারণ আর্কিটেকচারের এবং মাইএসকিউএল প্রোটোকলের সাথে সামঞ্জস্যপূর্ণ। ডোরিসকে মোতায়েন করার জন্য শুধুমাত্র দুটি প্রক্রিয়া (FE এবং BE) জড়িত থাকে যাতে অন্য সিস্টেমের উপর কোন নির্ভরতা থাকে না, এটি পরিচালনা এবং বজায় রাখা সহজ করে তোলে। এছাড়াও, ডরিস বহিরাগত ES ডেটা টেবিলের অনুসন্ধান সমর্থন করে। এটি সহজেই ES-তে মেটাডেটার সাথে ইন্টারফেস করতে পারে এবং ES থেকে টেবিল স্কিমাকে স্বয়ংক্রিয়ভাবে ম্যাপ করতে পারে যাতে আমরা জটিল সংযোগের সাথে ঝাঁপিয়ে না পড়ে ডরিসের মাধ্যমে ইলাস্টিকসার্চ ডেটাতে প্রশ্নগুলি পরিচালনা করতে পারি।

আরও কী, ডরিস একাধিক ডেটা ইনজেশন পদ্ধতি সমর্থন করে, যার মধ্যে রয়েছে HDFS এবং S3 এর মতো দূরবর্তী সঞ্চয়স্থান থেকে ব্যাচ আমদানি, MySQL binlog এবং Kafka থেকে ডেটা পড়া, এবং রিয়েল-টাইম ডেটা সিঙ্ক্রোনাইজেশন বা MySQL, Oracle এবং PostgreSQL থেকে ব্যাচ আমদানি। এটি একটি ধারাবাহিকতা প্রোটোকলের মাধ্যমে পরিষেবার প্রাপ্যতা এবং ডেটা নির্ভরযোগ্যতা নিশ্চিত করে এবং স্বয়ংক্রিয় ডিবাগিং করতে সক্ষম। এটি আমাদের অপারেটর এবং রক্ষণাবেক্ষণকারীদের জন্য দুর্দান্ত খবর।

পরিসংখ্যানগতভাবে বলতে গেলে, এই বৈশিষ্ট্যগুলি আমাদের স্টোরেজ খরচ 42% এবং উন্নয়ন খরচ 40% কমিয়েছে।

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

আমাদের প্রয়োজন মেটানোর জন্য আরও উন্নতি

একটি শব্দার্থিক স্তর প্রবর্তন করুন

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

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

কেন এই সাহায্য করবে?

ডেটা বিশ্লেষকদের জন্য, সমস্ত ট্যাগ এবং মেট্রিক্স শব্দার্থিক স্তরে তৈরি এবং ভাগ করা হবে যাতে কম বিভ্রান্তি এবং উচ্চতর দক্ষতা থাকবে।

ডেটা ব্যবহারকারীদের জন্য, তাদের আর তাদের নিজস্ব ডেটাসেট তৈরি করতে হবে না বা প্রতিটি পরিস্থিতির জন্য কোনটি প্রযোজ্য তা খুঁজে বের করতে হবে না তবে কেবল তাদের নির্দিষ্ট ট্যাগসেট এবং মেট্রিসেটে প্রশ্নগুলি পরিচালনা করতে পারে।

শব্দার্থিক স্তর আপগ্রেড করুন

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

এই জন্য, আমরা শব্দার্থিক স্তরটিকে আমাদের ডেটা ম্যানেজমেন্ট সিস্টেমের হৃদয়ে পরিণত করেছি:

এটা কিভাবে কাজ করে?

TDW-তে সমস্ত কম্পিউটিং লজিক্স একটি একক ট্যাগ বা মেট্রিক আকারে শব্দার্থিক স্তরে সংজ্ঞায়িত করা হবে।

শব্দার্থিক স্তরটি অ্যাপ্লিকেশনের দিক থেকে যুক্তির প্রশ্নগুলি গ্রহণ করে, সেই অনুযায়ী একটি ইঞ্জিন নির্বাচন করে এবং SQL তৈরি করে। তারপর এটি কার্যকর করার জন্য TDW-তে SQL কমান্ড পাঠায়। ইতিমধ্যে, এটি ডরিসকে কনফিগারেশন এবং ডেটা ইনজেশনের কাজগুলিও পাঠাতে পারে এবং কোন মেট্রিক্স এবং ট্যাগগুলিকে ত্বরান্বিত করা উচিত তা সিদ্ধান্ত নিতে পারে৷

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

Apache Doris কে ফুল প্লে দিন

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

আমরা কি চাই?

বর্তমানে, আমাদের কাছে 800+ ট্যাগ এবং 1300+ মেট্রিক্স TDW-তে 80+ সোর্স টেবিল থেকে প্রাপ্ত। TDW থেকে ডরিসে ডেটা আমদানি করার সময়, আমরা আশা করি যে:

• রিয়েল-টাইম প্রাপ্যতা : প্রথাগত T+1 অফলাইন ডেটা ইনজেশন ছাড়াও, আমাদের রিয়েল-টাইম ট্যাগিং প্রয়োজন।

  
  

• আংশিক আপডেট : প্রতিটি উৎস সারণী বিভিন্ন গতিতে নিজস্ব ETL টাস্কের মাধ্যমে ডেটা তৈরি করে এবং শুধুমাত্র ট্যাগ এবং মেট্রিক্সের অংশ জড়িত থাকে, তাই কলামগুলির আংশিক আপডেটের জন্য আমাদের সমর্থন প্রয়োজন।

  
  

• উচ্চ কর্মক্ষমতা : গ্রুপ টার্গেটিং, বিশ্লেষণ এবং রিপোর্টিং পরিস্থিতিতে আমাদের মাত্র কয়েক সেকেন্ডের প্রতিক্রিয়া সময় প্রয়োজন।

  
  

• কম খরচ : আমরা যতটা সম্ভব খরচ কমাতে আশা করি।

আমরা কি করি?

1. TDW এর পরিবর্তে ফ্লিঙ্কে ফ্ল্যাট টেবিল তৈরি করুন

   
   

TDW-তে ফ্ল্যাট টেবিল তৈরি করার কয়েকটি খারাপ দিক রয়েছে:

• উচ্চ স্টোরেজ খরচ : TDW-কে আলাদা 80+ সোর্স টেবিল ছাড়াও একটি অতিরিক্ত ফ্ল্যাট টেবিল বজায় রাখতে হবে। যে বিশাল অপ্রয়োজনীয়তা.

  
  

• কম রিয়েল-টাইমলাইনেস : সোর্স সারণিতে যেকোন বিলম্ব হলে তা বৃদ্ধি পাবে এবং পুরো ডেটা লিঙ্কটিকে পিছিয়ে দেবে।

  
  

• উচ্চ উন্নয়ন খরচ : বাস্তব-সময়োপযোগীতা অর্জনের জন্য অতিরিক্ত উন্নয়ন প্রচেষ্টা এবং সংস্থান প্রয়োজন।

বিপরীতে, ডরিসে ফ্ল্যাট টেবিল তৈরি করা অনেক সহজ এবং কম ব্যয়বহুল। প্রক্রিয়াটি নিম্নরূপ:

• অফলাইন পদ্ধতিতে কাফকাতে নতুন ডেটা আমদানি করতে স্পার্ক ব্যবহার করুন।
• কাফকা ডেটা ব্যবহার করতে ফ্লিঙ্ক ব্যবহার করুন।
• প্রাথমিক কী আইডির মাধ্যমে একটি ফ্ল্যাট টেবিল তৈরি করুন।
• ফ্ল্যাট টেবিলটি ডরিসে আমদানি করুন। নীচে দেখানো হিসাবে, ফ্লিঙ্ক ডাটাগুলির পাঁচটি লাইনকে একত্রিত করেছে, যার মধ্যে "ID"=1, ডরিসের একটি লাইনে, ডরিসের উপর ডেটা লেখার চাপ কমিয়েছে।

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

2. কলামগুলিকে স্মার্টলি নাম দিন

আমরা যেমন উল্লেখ করেছি, ডরিসের সামগ্রিক মডেল কলামগুলির আংশিক আপডেটের অনুমতি দেয়। এখানে আমরা আপনার রেফারেন্সের জন্য ডরিসের অন্যান্য ডেটা মডেলগুলির একটি সাধারণ ভূমিকা প্রদান করি:

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

ডুপ্লিকেট মডেল : এই মডেলটি সমস্ত আসল ডেটা সঞ্চয় করে ঠিক যেমনটি কোনো প্রাক-সমষ্টি বা অনুলিপি ছাড়াই।

ডেটা মডেল নির্ধারণ করার পরে, আমাদের কলামগুলি কীভাবে নাম দেওয়া যায় তা নিয়ে ভাবতে হয়েছিল। কলামের নাম হিসাবে ট্যাগ বা মেট্রিক্স ব্যবহার করা একটি পছন্দ ছিল না কারণ:

Ⅰ আমাদের অভ্যন্তরীণ ডেটা ব্যবহারকারীদের মেট্রিক্স বা ট্যাগের নাম পরিবর্তন করতে হতে পারে, কিন্তু ডরিস 1.1.3 কলামের নাম পরিবর্তন সমর্থন করে না।

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

• ট্যাগ এবং মেট্রিক্সের নমনীয় পুনঃনামকরণের জন্য, আমরা মেটাডেটা (নাম, বিশ্বব্যাপী অনন্য আইডি, স্থিতি, ইত্যাদি) সংরক্ষণ করতে MySQL টেবিল ব্যবহার করি। নামের কোনো পরিবর্তন শুধুমাত্র মেটাডেটাতেই ঘটবে কিন্তু ডরিসের টেবিল স্কিমাকে প্রভাবিত করবে না। উদাহরণস্বরূপ, যদি একটি song_name 4 এর একটি আইডি দেওয়া হয় তবে এটি ডরিসে a4 এর কলামের সাথে সংরক্ষণ করা হবে। তারপর যদি song_name একটি প্রশ্নের সাথে জড়িত থাকে তবে এটি এসকিউএল-এ a4 এ রূপান্তরিত হবে।

  
  

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

  
  

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

  
  

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

3. তারিখ লেখা অপ্টিমাইজ করুন

এখানে কিছু অনুশীলন রয়েছে যা আমাদের দৈনিক অফলাইন ডেটা ইনজেশনের সময়কে 75% কমিয়েছে এবং আমাদের CUMU কমপ্যাকশন স্কোর 600+ থেকে 100-এ নেমে এসেছে।

• ফ্লিঙ্ক প্রি-এগ্রিগেশন: উপরে উল্লিখিত হিসাবে।

  
  

• লেখার ব্যাচের স্বয়ংক্রিয় আকার: ফ্লিঙ্ক রিসোর্স ব্যবহার কমাতে, আমরা একটি কাফকা বিষয়ের ডেটাকে বিভিন্ন ডোরিস টেবিলে লিখতে সক্ষম করি এবং ডেটা পরিমাণের উপর ভিত্তি করে ব্যাচের আকারের স্বয়ংক্রিয় পরিবর্তন উপলব্ধি করি।

  
  

• ডরিস ডেটা লেখার অপ্টিমাইজেশান: ট্যাবলেট এবং বালতিগুলির আকারের পাশাপাশি প্রতিটি দৃশ্যের জন্য কমপ্যাকশন প্যারামিটারগুলিকে সূক্ষ্ম সুর করুন:

  
  

   max_XXXX_compaction_thread max_cumulative_compaction_num_singleton_deltas

  
  

• BE কমিট লজিকের অপ্টিমাইজেশন: BE তালিকার নিয়মিত ক্যাশিং পরিচালনা করুন, ব্যাচ দ্বারা BE নোড ব্যাচে তাদের প্রতিশ্রুতি দিন এবং সূক্ষ্ম লোড ব্যালেন্সিং গ্রানুলারিটি ব্যবহার করুন।

  
  

  

  
  

4. কোয়েরিতে Dori-on-ES ব্যবহার করুন

   আমাদের ডেটা প্রশ্নের প্রায় 60% গ্রুপ টার্গেটিং জড়িত। গ্রুপ টার্গেটিং হল ফিল্টার হিসাবে ট্যাগের সেট ব্যবহার করে আমাদের টার্গেট ডেটা খুঁজে বের করা। এটি আমাদের ডেটা প্রসেসিং আর্কিটেকচারের জন্য কয়েকটি প্রয়োজনীয়তা তৈরি করে:

   
   

• APP ব্যবহারকারীদের সাথে সম্পর্কিত গ্রুপ টার্গেটিং খুব জটিল যুক্তি জড়িত হতে পারে। তার মানে সিস্টেমটিকে এক সাথে ফিল্টার হিসাবে শত শত ট্যাগ সমর্থন করতে হবে।

  
  

• বেশিরভাগ গ্রুপ টার্গেটিং পরিস্থিতিতে শুধুমাত্র সর্বশেষ ট্যাগ ডেটা প্রয়োজন। যাইহোক, মেট্রিক প্রশ্নগুলিকে ঐতিহাসিক ডেটা সমর্থন করতে হবে।

  
  

• ডেটা ব্যবহারকারীদের গ্রুপ টার্গেটিংয়ের পরে মেট্রিক ডেটার আরও সমষ্টিগত বিশ্লেষণ করতে হতে পারে।

  
  

• গ্রুপ টার্গেট করার পরে ডেটা ব্যবহারকারীদের ট্যাগ এবং মেট্রিক্সে বিস্তারিত প্রশ্নগুলি সম্পাদন করতে হতে পারে।

  
  

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

 SELECT tag, agg(metric) FROM Doris WHERE id in (select id from Es where tagFilter) GROUP BY tag

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

I. যখন ডরিস BE ইলাস্টিকসার্চ (ডিফল্টভাবে এক সময়ে 1024 লাইন) থেকে ডেটা টেনে আনে, এক মিলিয়নেরও বেশি বস্তুর লক্ষ্য গোষ্ঠীর জন্য, নেটওয়ার্ক I/O ওভারহেড বিশাল হতে পারে।

২. ডেটা টেনে নেওয়ার পর, ডরিস BE-কে শাফেল/ব্রডকাস্টের মাধ্যমে স্থানীয় মেট্রিক টেবিলের সাথে জয়েন অপারেশন পরিচালনা করতে হবে, যার জন্য অনেক খরচ হতে পারে।

সুতরাং, আমরা নিম্নলিখিত অপ্টিমাইজেশানগুলি করি:

• একটি ক্যোয়ারী সেশন ভেরিয়েবল es_optimize যোগ করুন যা অপ্টিমাইজেশান সক্ষম করতে হবে কিনা তা নির্দিষ্ট করে।

  
  

• ES-তে ডেটা লেখার ক্ষেত্রে, প্রাথমিক কী আইডি হ্যাশ হওয়ার পরে বালতি নম্বর সংরক্ষণ করতে একটি BK কলাম যোগ করুন। অ্যালগরিদমটি ডরিস (CRC32) এর বাকেটিং অ্যালগরিদমের মতোই।

  
  

• Doris BE ব্যবহার করে একটি বাকেট জয়েন এক্সিকিউশন প্ল্যান তৈরি করুন, বালতি নম্বরটি BE ScanNode-এ পাঠান এবং ES-এ ঠেলে দিন।

  
  

• জিজ্ঞাসা করা ডেটা সংকুচিত করতে ES ব্যবহার করুন; একাধিক ডেটা আনয়নকে একটিতে পরিণত করুন এবং নেটওয়ার্ক I/O ওভারহেড হ্রাস করুন।

  
  

• নিশ্চিত করুন যে ডরিস BE শুধুমাত্র স্থানীয় মেট্রিক টেবিলের সাথে সম্পর্কিত বালতিগুলির ডেটা টেনে নেয় এবং ডরিস BE-এর মধ্যে ডেটা পরিবর্তন এড়াতে সরাসরি স্থানীয় জয়েন অপারেশন পরিচালনা করে।

  
  

  

  
  

  ফলস্বরূপ, আমরা বৃহৎ গোষ্ঠী টার্গেটিং এর জন্য ক্যোয়ারী রেসপন্স টাইম 60 সেকেন্ড থেকে কমিয়ে আশ্চর্যজনক 3.7 সেকেন্ড করে দেই। সম্প্রদায়ের তথ্য দেখায় যে ডরিস 2.0.0 সংস্করণ থেকে উল্টানো সূচী সমর্থন করতে যাচ্ছে, যা শীঘ্রই প্রকাশিত হবে৷ এই নতুন সংস্করণের সাহায্যে, আমরা পাঠ্যের ধরন, পাঠ্য, সংখ্যা এবং তারিখের সমতুল্যতা বা পরিসর ফিল্টারিংয়ের উপর সম্পূর্ণ-পাঠ্য অনুসন্ধান পরিচালনা করতে সক্ষম হব এবং ফিল্টারিংয়ে সুবিধাজনকভাবে AND, OR, NOT লজিককে একত্রিত করতে পারব কারণ ইনভার্টেড ইনডেক্সিং অ্যারে প্রকারগুলিকে সমর্থন করে৷ ডরিসের এই নতুন বৈশিষ্ট্যটি একই টাস্কে ইলাস্টিকসার্চের চেয়ে 3 ~ 5 গুণ ভাল পারফরম্যান্স সরবরাহ করবে বলে আশা করা হচ্ছে।

  
  

5. তথ্য ব্যবস্থাপনা পরিমার্জিত

ডোরিসের ঠান্ডা এবং গরম ডেটা আলাদা করার ক্ষমতা ডেটা প্রক্রিয়াকরণে আমাদের খরচ কমানোর কৌশলগুলির ভিত্তি প্রদান করে।

• Doris-এর TTL পদ্ধতির উপর ভিত্তি করে, আমরা শুধুমাত্র বর্তমান বছরের ডেটা Doris-এ সঞ্চয় করি এবং কম স্টোরেজ খরচের জন্য TDW-তে তার আগে ঐতিহাসিক ডেটা রাখি।

  
  

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

  
  

ডরিস হট ডেটাকে ঠান্ডা ডেটাতে পরিণত করতে সমর্থন করে তাই আমরা কেবলমাত্র SSD-তে গত সাত দিনের ডেটা সঞ্চয় করি এবং কম ব্যয়বহুল স্টোরেজের জন্য তার চেয়ে পুরানো ডেটা HDD-এ স্থানান্তর করি।

উপসংহার

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