ডাটা সিলোস ব্রেকিং ডাউন: অ্যাপাচি ডরিস কীভাবে গ্রাহক ডেটা ইন্টিগ্রেশনকে স্ট্রীমলাইন করে

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

এই পোস্টে আমি যে বীমা কোম্পানীর কথা বলতে যাচ্ছি তার ঠিক এটাই ঘটে। 2023 সাল নাগাদ, তারা ইতিমধ্যে 500 মিলিয়ন গ্রাহকদের সেবা করেছে এবং 57 বিলিয়ন বীমা চুক্তি স্বাক্ষর করেছে। যখন তারা একটি গ্রাহক ডেটা প্ল্যাটফর্ম (সিডিপি) তৈরি করতে শুরু করে যাতে এই ধরনের ডেটার আকার মিটমাট করা যায়, তারা একাধিক উপাদান ব্যবহার করে।

সিডিপিতে ডেটা সাইলো

বেশিরভাগ ডেটা প্ল্যাটফর্মের মতো, তাদের CDP 1.0 এর একটি ব্যাচ প্রসেসিং পাইপলাইন এবং একটি রিয়েল-টাইম স্ট্রিমিং পাইপলাইন ছিল। অফলাইন ডেটা স্পার্ক জবসের মাধ্যমে ইমপালায় লোড করা হয়েছিল, যেখানে এটি ট্যাগ করা হয়েছিল এবং গোষ্ঠীতে বিভক্ত ছিল। এদিকে, স্পার্ক এটিকে OneID গণনার জন্য নেবুলাগ্রাফে পাঠিয়েছে (পরে এই পোস্টে বিস্তারিত)। অন্যদিকে, রিয়েল-টাইম ডেটা ফ্লিঙ্ক দ্বারা ট্যাগ করা হয়েছিল এবং তারপরে HBase-এ সংরক্ষণ করা হয়েছিল, জিজ্ঞাসা করার জন্য প্রস্তুত।

এটি সিডিপিতে একটি কম্পোনেন্ট-ভারী গণনা স্তরের দিকে পরিচালিত করে: ইমপালা, স্পার্ক, নেবুলাগ্রাফ এবং এইচবেস।

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

অ্যাপাচি ডরিস-ভিত্তিক সিডিপি

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

অফলাইন ডেটা গ্রহণ করতে, তারা স্ট্রিম লোড পদ্ধতি ব্যবহার করে। তাদের 30-থ্রেড ইনজেশন পরীক্ষা দেখায় যে এটি প্রতি সেকেন্ডে 300,000 এর বেশি আপসার্ট করতে পারে। রিয়েল-টাইম ডেটা লোড করতে, তারা Flink-Doris-Connector এবং স্ট্রিম লোডের সংমিশ্রণ ব্যবহার করে। এছাড়াও, রিয়েল-টাইম রিপোর্টিং-এ, যেখানে তাদের একাধিক বাহ্যিক ডেটা উত্স থেকে ডেটা বের করতে হবে, তারা ফেডারেটেড প্রশ্নের জন্য মাল্টি-ক্যাটালগ বৈশিষ্ট্যটি ব্যবহার করে।

এই CDP-তে গ্রাহক বিশ্লেষণমূলক কর্মপ্রবাহ এভাবে চলে। প্রথমত, তারা গ্রাহকের তথ্য বাছাই করে; তারপর তারা প্রতিটি গ্রাহকের সাথে ট্যাগ সংযুক্ত করে। ট্যাগগুলির উপর ভিত্তি করে, তারা আরও লক্ষ্যযুক্ত বিশ্লেষণ এবং অপারেশনের জন্য গ্রাহকদের গ্রুপে বিভক্ত করে।

এর পরে, আমি এই কাজের লোডগুলিকে অনুসন্ধান করব এবং আপনাকে দেখাব কিভাবে Apache Doris এগুলিকে ত্বরান্বিত করে৷

ওয়ানআইডি

যখন আপনার পণ্য এবং পরিষেবাগুলির জন্য আপনার কাছে বিভিন্ন ব্যবহারকারী নিবন্ধন সিস্টেম থাকে তখন কি আপনার সাথে এটি ঘটেছে? আপনি একটি পণ্য ওয়েবপেজ থেকে UserID A এর ইমেল এবং পরবর্তীতে অন্য একটি থেকে UserID B এর সামাজিক নিরাপত্তা নম্বর সংগ্রহ করতে পারেন। তারপর আপনি জানতে পারেন যে UserID A এবং UserID B আসলে একই ব্যক্তির অন্তর্গত কারণ তারা একই ফোন নম্বর দিয়ে যায়।

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

Apache Doris-এর ফাংশনগুলিকে কাজে লাগিয়ে তারা এইভাবে নির্ণয় করে যে কোন নিবন্ধন তথ্য একই ব্যবহারকারীর অন্তর্গত।

ট্যাগিং পরিষেবা

এই CDP 500 মিলিয়ন গ্রাহকের তথ্য মিটমাট করে, যা 500 টিরও বেশি উত্স টেবিল থেকে আসে এবং মোট 2000 টিরও বেশি ট্যাগের সাথে সংযুক্ত।

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

1. অফলাইন ট্যাগ:

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

 set enable_unique_key_partial_update=true; insert into tb_label_result(one_id, labelxx) select one_id, label_value as labelxx from .....

2. রিয়েল-টাইম ট্যাগ:

আংশিক কলাম আপডেটগুলি রিয়েল-টাইম ট্যাগের জন্যও উপলব্ধ কারণ রিয়েল-টাইম ট্যাগগুলি বিভিন্ন গতিতে আপডেট করা হয়। partial_columns true সেট করার জন্য যা প্রয়োজন।

 curl --location-trusted -u root: -H "partial_columns:true" -H "column_separator:," -H "columns:id,balance,last_access_time" -T /tmp/test.csv http://127.0.0.1:48037/api/db1/user_profile/_stream_load

3. উচ্চ-সঙ্গতি বিন্দু প্রশ্ন:

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

• be.conf এ ডরিস ব্যাকএন্ড প্যারামিটার ফাইন-টিউন:

 disable_storage_row_cache = false storage_page_cache_limit=40%

• টেবিল তৈরির সময় টেবিলের প্যারামিটারগুলি সূক্ষ্ম-সুরিয়ে নিন:

 enable_unique_key_merge_on_write = true store_row_column = true light_schema_change = true

4. ট্যাগ গণনা (যোগদান):

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

গ্রাহক গ্রুপিং

CDP 2.0-এ গ্রাহক গ্রুপিং পাইপলাইনটি এভাবে চলে: Apache Doris গ্রাহক পরিষেবা থেকে SQL গ্রহণ করে, গণনা সম্পাদন করে, এবং SELECT INTO OUTFILE এর মাধ্যমে S3 অবজেক্ট স্টোরেজে ফলাফল সেট পাঠায়। কোম্পানিটি তার গ্রাহকদের 1 মিলিয়ন গ্রুপে বিভক্ত করেছে। গ্রাহক গ্রুপিং কাজটি ইমপালাতে 50 সেকেন্ড সময় নিত এখন ডরিসে মাত্র 10 সেকেন্ডের প্রয়োজন।

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

Apache Doris-এ, এটি BITMAP ফাংশন দ্বারা প্রয়োগ করা হয়: BITMAP_CONTAINS হল একটি গ্রাহক একটি নির্দিষ্ট গোষ্ঠীর অংশ কিনা তা পরীক্ষা করার একটি দ্রুত উপায় এবং BITMAP_OR , BITMAP_INTERSECT , এবং BITMAP_XOR ক্রস-বিশ্লেষণের জন্য পছন্দ৷

উপসংহার

CDP 1.0 থেকে CDP 2.0 পর্যন্ত, বীমা কোম্পানী Spark+Impala+HBase+NebulaGraph প্রতিস্থাপনের জন্য Apache Doris, একটি ইউনিফাইড ডেটা গুদাম গ্রহণ করে। এটি ডেটা সাইলোগুলি ভেঙে এবং ডেটা প্রসেসিং পাইপলাইনগুলিকে স্ট্রিমলাইন করে তাদের ডেটা প্রক্রিয়াকরণের দক্ষতা বাড়ায়। CDP 3.0-এ, তারা আরও বৈচিত্র্যময় এবং নমনীয় বিশ্লেষণের জন্য রিয়েল-টাইম ট্যাগ এবং অফলাইন ট্যাগগুলিকে একত্রিত করে তাদের গ্রাহকদের গ্রুপ করতে চায়। Apache Doris সম্প্রদায় এবং VeloDB টিম এই আপগ্রেডের সময় সহায়ক অংশীদার হতে থাকবে।

এছাড়াও এখানে প্রকাশিত.