LLM-চালিত OLAP: Apache Doris-এর সাথে Tencent অভিজ্ঞতা

ছয় মাস আগে, আমরা কেন আমাদের ডেটা ম্যানেজমেন্ট সিস্টেমের জন্য OLAP ইঞ্জিন হিসাবে Apache Doris দিয়ে ClickHouse প্রতিস্থাপন করেছি সে সম্পর্কে লিখেছিলাম। তখন, আমরা এসকিউএল স্টেটমেন্টের স্বয়ংক্রিয়-প্রজন্মের সাথে লড়াই করছিলাম। যত দিন যাচ্ছে, আমরা আপনার জন্য রেফারেন্স হওয়ার মতো যথেষ্ট অগ্রগতি করেছি, তাই আমি আবার এখানে আছি।

আমাদের ডরিস-ভিত্তিক OLAP পরিষেবাগুলিকে শক্তিশালী করতে আমরা লার্জ ল্যাঙ্গুয়েজ মডেল (LLM) গ্রহণ করেছি।

এলএলএম + ওএলএপি

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

প্রতিটি এআই-সম্পর্কিত অভিজ্ঞতার মতো, আমরা কিছু ঘর্ষণ জুড়ে এসেছি:

1. LLM ডেটা জার্গন বোঝে না, যেমন "ক্ষেত্র", "সারি", "কলাম" এবং "টেবিল"। পরিবর্তে, তারা "কর্পোরেট আয়" এবং "DAU" এর মতো ব্যবসায়িক পদগুলিকে পুরোপুরি অনুবাদ করতে পারে, যা মূলত ক্ষেত্র/সারি/কলামগুলি সম্পর্কে। এর অর্থ হল এটি শুধুমাত্র তখনই ভাল কাজ করতে পারে যদি বিশ্লেষকরা তাদের প্রশ্ন টাইপ করার সময় তাদের প্রয়োজনীয় মেট্রিক উল্লেখ করার জন্য সঠিক সঠিক শব্দটি ব্যবহার করেন।

   
   

2. আমরা যে LLM ব্যবহার করছি তা অনুমানে ধীর। সাড়া দিতে 10 সেকেন্ডের বেশি সময় লাগে। যেহেতু এটি টোকেন দ্বারা ফি চার্জ করে, খরচ-কার্যকারিতা একটি সমস্যা হয়ে ওঠে।

   
   

3. যদিও এলএলএম পাবলিক ডেটাসেটের একটি বৃহৎ সংগ্রহে প্রশিক্ষিত, তবে এটি বিশেষ জ্ঞানের কম-অবহিত। আমাদের ক্ষেত্রে, এলএলএম ইন্ডি গানগুলির সাথে খুব অপরিচিত, তাই গানগুলি আমাদের ডাটাবেসে অন্তর্ভুক্ত করা হলেও, এলএলএম তাদের সঠিকভাবে সনাক্ত করতে সক্ষম হবে না।

   
   

4. কখনও কখনও আমাদের ইনপুট প্রশ্নগুলির জন্য পর্যাপ্ত এবং সর্বশেষ আইনি, রাজনৈতিক, আর্থিক এবং নিয়ন্ত্রক তথ্যের প্রয়োজন হয়, যা একটি প্রশিক্ষণ ডেটাসেট বা জ্ঞানের ভিত্তিতে অন্তর্ভুক্ত করা কঠিন। আরও বৈচিত্র্যপূর্ণ কাজগুলি সম্পাদন করার জন্য আমাদের LLM-কে আরও বিস্তৃত তথ্য ঘাঁটির সাথে সংযুক্ত করতে হবে।

   
   

আমরা একের পর এক এই সমস্যাগুলোকে ছিটকে দেই।

1. একটি শব্দার্থিক স্তর

সমস্যা নং 1 এর জন্য, আমরা LLM এবং OLAP ইঞ্জিনের মধ্যে একটি শব্দার্থিক স্তর প্রবর্তন করি। এই স্তরটি সংশ্লিষ্ট ডেটা ক্ষেত্রগুলিতে ব্যবসার শর্তাবলী অনুবাদ করে। এটি বিভিন্ন প্রাকৃতিক ভাষার শব্দ থেকে ডেটা ফিল্টারিং শর্ত সনাক্ত করতে পারে, তাদের জড়িত মেট্রিক্সের সাথে সম্পর্কিত করতে পারে এবং তারপর SQL বিবৃতি তৈরি করতে পারে।

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

2. এলএলএম পার্সিং নিয়ম

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

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

3. স্কিমা ম্যাপার এবং বাহ্যিক জ্ঞানের ভিত্তি

এলএলএমকে বিশেষ জ্ঞানের সাথে শক্তিশালী করতে, আমরা এলএলএম থেকে একটি স্কিমা ম্যাপার যুক্ত করেছি। স্কিমা ম্যাপার একটি বাহ্যিক জ্ঞান বেসে ইনপুট প্রশ্ন ম্যাপ করে, এবং তারপর এলএলএম পার্সিং করবে।

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

4. প্লাগইন

আমরা LLM-কে তথ্যের আরও ক্ষেত্রগুলিতে সংযোগ করতে প্লাগইনগুলি ব্যবহার করেছি, এবং আমাদের কাছে বিভিন্ন ধরণের প্লাগইনগুলির জন্য বিভিন্ন ইন্টিগ্রেশন পদ্ধতি রয়েছে:

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

  
  

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

আমরা উপরের চারটি অপ্টিমাইজেশন সম্পন্ন করার পরে, সুপারসনিক ফ্রেমওয়ার্ক তৈরি হয়।

সুপারসোনিক ফ্রেমওয়ার্ক

এখন আমাকে এই ফ্রেমওয়ার্কের মধ্য দিয়ে যেতে দিন:

• একজন বিশ্লেষক একটি প্রশ্ন ইনপুট.

  
  

• স্কিমা ম্যাপার একটি বাহ্যিক জ্ঞান বেসে প্রশ্নটি ম্যাপ করে।

  
  

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

  
  

• পূর্ব-নির্ধারিত নিয়মের উপর ভিত্তি করে, LLM প্রশ্নটির জটিলতার মাত্রা নির্ধারণ করে। যদি এটি একটি সাধারণ প্রশ্ন হয়, এটি সরাসরি OLAP ইঞ্জিনে যাবে; যদি এটি একটি জটিল প্রশ্ন হয়, তবে এটি শব্দার্থগতভাবে পার্স করা হবে এবং একটি DSL বিবৃতিতে রূপান্তরিত হবে।

  
  

• শব্দার্থিক স্তরে, ডিএসএল বিবৃতিটি তার ক্যোয়ারী দৃশ্যের উপর ভিত্তি করে বিভক্ত করা হবে। উদাহরণস্বরূপ, যদি এটি একটি মাল্টি-টেবিল জয়েন কোয়েরি হয়, তাহলে এই স্তরটি একাধিক একক-টেবিল ক্যোয়ারী SQL স্টেটমেন্ট তৈরি করবে।

• যদি প্রশ্নে বাহ্যিক জ্ঞান জড়িত থাকে, তাহলে LLM একটি তৃতীয় পক্ষের প্লাগইন কল করবে।

উদাহরণ:

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

OLAP আর্কিটেকচার

এই ফ্রেমওয়ার্কের OLAP অংশের জন্য, স্থাপত্য বিবর্তনের বেশ কয়েকটি রাউন্ডের পরে, আমাদের বর্তমান OLAP পাইপলাইনটি এরকম দেখাচ্ছে।

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

আমরা আমাদের আর্কিটেকচারাল অপ্টিমাইজেশান অভিজ্ঞতা থেকে আপনার জন্য দুটি প্রধান টেকওয়ে আঁকেছি।

1. লিঙ্ক স্ট্রীমলাইন

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

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

2. সমতল টেবিল বিভক্ত

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

অতএব, আমরা সমতল টেবিলগুলিকে মেট্রিক টেবিল এবং মাত্রা টেবিলে বিভক্ত করি। যেহেতু সেগুলি বিভিন্ন গতিতে আপডেট হয়, আমরা সেগুলিকে বিভিন্ন ডেটা মডেলে রাখি৷

• মেট্রিক টেবিল : আমরা Apache Doris এর Aggregate Key মডেলে মেট্রিক ডেটা সাজাই, যার মানে SUM, MAX, MIN, ইত্যাদির মাধ্যমে নতুন ডেটা পুরানো ডেটার সাথে একত্রিত করা হবে।

  
  

• মাত্রা টেবিল : এই টেবিলগুলি Apache Doris-এর অনন্য কী মডেলে রয়েছে, যার মানে নতুন ডেটা রেকর্ড পুরানোটিকে প্রতিস্থাপন করবে। এটি আমাদের ক্যোয়ারী পরিস্থিতিতে কর্মক্ষমতা বৃদ্ধি করতে পারে।

  
  

আপনি জিজ্ঞাসা করতে পারেন, এটি কি প্রশ্নগুলিতে সমস্যা সৃষ্টি করে, যেহেতু বেশিরভাগ প্রশ্নের জন্য উভয় ধরণের টেবিলের ডেটা প্রয়োজন? চিন্তা করবেন না, আমরা ডরিসের রোলআপ বৈশিষ্ট্যের সাথে এটির সমাধান করব। বেস টেবিলের ভিত্তিতে, আমরা রোলআপ ভিউ তৈরি করতে প্রয়োজনীয় মাত্রা নির্বাচন করতে পারি, যা স্বয়ংক্রিয়ভাবে GROUP BY চালাবে। এটি প্রতিটি রোলআপ ভিউয়ের জন্য ট্যাগ সংজ্ঞায়িত করার প্রয়োজনীয়তা থেকে আমাদেরকে মুক্তি দেয় এবং মূলত কোয়েরির গতি বাড়ায়।

অন্যান্য কৌশল

অ্যাপাচি ডরিসের সাথে আমাদের অভিজ্ঞতায়, আমরা কিছু অন্যান্য কার্যকারিতাও সহজ খুঁজে পাই, তাই আমি সেগুলিও আপনার জন্য এখানে তালিকাভুক্ত করি:

1. বস্তুগত দৃশ্য

একটি ম্যাটেরিয়ালাইজড ভিউ হল একটি প্রাক-গণনা করা ডেটাসেট। যখন আপনাকে প্রায়শই নির্দিষ্ট মাত্রার ডেটা অ্যাক্সেস করতে হয় তখন এটি কোয়েরিগুলিকে ত্বরান্বিত করার একটি উপায়। এই পরিস্থিতিতে, আমরা মূলের উপর ভিত্তি করে উদ্ভূত ট্যাগ এবং মেট্রিক্স সংজ্ঞায়িত করি। উদাহরণস্বরূপ, আমরা মেট্রিক 1, মেট্রিক 2 এবং মেট্রিক 3: sum(m1+m2+m3) একত্রিত করে একটি প্রাপ্ত মেট্রিক তৈরি করি। তারপর, আমরা এটির জন্য একটি ম্যাটেরিয়ালাইজড ভিউ তৈরি করতে পারি। ডরিস রিলিজ সময়সূচী অনুসারে, সংস্করণ 2.1 মাল্টি-টেবিল ম্যাটেরিয়ালাইজড ভিউ সমর্থন করবে এবং আমরা এটির জন্য উন্মুখ।

2. ফ্লিঙ্ক-ডোরিস-সংযোজক

এটি ডেটা ইনজেশনের ক্ষেত্রে সঠিকভাবে-একবার গ্যারান্টির জন্য। ফ্লিঙ্ক-ডোরিস-সংযোজক একটি চেকপয়েন্ট মেকানিজম এবং দুই-পর্যায়ের প্রতিশ্রুতি প্রয়োগ করে এবং রিলেশনাল ডাটাবেস থেকে ডরিসে স্বয়ংক্রিয় ডেটা সিঙ্ক্রোনাইজেশনের অনুমতি দেয়।

3. কম্প্যাকশন

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

এরপর কি

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