আমরা কীভাবে একটি অত্যন্ত দক্ষ এবং সস্তা ডেটালেক সংগঠিত করেছি এবং কেন

আমরা একটি আশ্চর্যজনক সময়ে বাস করি যখন আপনি দ্রুত এবং সহজে বেশ কিছু রেডিমেড ওপেন-সোর্স টুলসকে সংযুক্ত করতে পারেন, স্ট্যাকওভারফ্লো-এর পরামর্শ অনুযায়ী আপনার “চেতনা বন্ধ” করে সেগুলিকে সেট-আপ করতে পারেন, “একাধিক অক্ষর” না দেখে এবং লঞ্চ করতে পারেন। তাদের বাণিজ্যিক অপারেশন. এবং যখন আপনাকে আপডেট/প্রসারিত করার প্রয়োজন হয় বা কেউ দুর্ঘটনাক্রমে কয়েকটি মেশিন রিবুট করে - আপনি বুঝতে পারেন যে এক ধরণের আবেশী খারাপ স্বপ্ন শুরু হয়েছে, সবকিছুই নাটকীয়ভাবে স্বীকৃতির বাইরে জটিল হয়ে উঠেছে, পিছনে ফিরে যাওয়ার কোন সুযোগ নেই, ভবিষ্যত অস্পষ্ট এবং নিরাপদ, প্রোগ্রামিং এর পরিবর্তে, মৌমাছির বংশবৃদ্ধি করুন এবং পনির করুন।

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

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

কিছু সময় আগে, আমরা বুঝতে পেরেছিলাম যে কোম্পানিগুলির পণ্য এবং প্রযুক্তিগত বিশ্লেষণ উভয়েরই ফল প্রয়োজন (মেশিন লার্নিং আকারে কেকের উপর আইসিং উল্লেখ না করা) এবং প্রবণতা এবং ঝুঁকিগুলি বোঝার জন্য - আমাদের সংগ্রহ এবং বিশ্লেষণ করতে হবে আরও এবং আরও বেশি মেট্রিক্স।

Bitrix24 এ মৌলিক প্রযুক্তিগত বিশ্লেষণ

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

নাড়ির উপর আঙুল - উন্নত প্রযুক্তিগত বিশ্লেষণ

"যত তাড়াতাড়ি সম্ভব" সমস্যা সম্পর্কে তথ্য পাওয়ার আকাঙ্ক্ষা আমাদেরকে সহজ এবং বোধগম্য সরঞ্জামগুলির সাথে সক্রিয় পরীক্ষা-নিরীক্ষার দিকে নিয়ে যায় - pinba এবং xhprof.

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

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

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

• বিট্রিক্স২৪ ক্লায়েন্টের গত এক ঘণ্টায় p24 পোর্টালে কতগুলি পিএইচপি ত্রুটি ছিল এবং কোনটি? বুঝুন, ক্ষমা করুন এবং দ্রুত সংশোধন করুন।
• পূর্ববর্তী 24 ঘন্টায় জার্মানির পোর্টালে কতগুলি ভিডিও কল করা হয়েছিল, কোন মানের সাথে এবং চ্যানেল/নেটওয়ার্কের সাথে কোন অসুবিধা ছিল?
• সিস্টেম কার্যকারিতা (পিএইচপি-র জন্য আমাদের সি এক্সটেনশন), সর্বশেষ পরিষেবা আপডেটে উত্স থেকে সংকলিত এবং ক্লায়েন্টদের কাছে রোল আউট কতটা ভাল কাজ করে? সেখানে segfaults আছে?
• গ্রাহকের ডেটা কি পিএইচপি মেমরিতে ফিট করে? প্রসেসের জন্য বরাদ্দ করা মেমরি অতিক্রম করার বিষয়ে কোন ত্রুটি আছে: "মেমরির বাইরে"? খুঁজুন এবং নিরপেক্ষ.

এখানে একটি কংক্রিট উদাহরণ. পুঙ্খানুপুঙ্খ এবং বহু-স্তরের পরীক্ষা সত্ত্বেও, ক্লায়েন্ট, একটি খুব অ-মানক কেস এবং ক্ষতিগ্রস্থ ইনপুট ডেটা সহ, একটি বিরক্তিকর এবং অপ্রত্যাশিত ত্রুটি পেয়েছিল, একটি সাইরেন বেজে ওঠে এবং দ্রুত এটি ঠিক করার প্রক্রিয়া শুরু হয়:

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

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

মৌলিক ব্যবসা বিশ্লেষণ

সবাই জানে যে কোম্পানিগুলির ব্যবসায়িক বিশ্লেষণ প্রায়শই, হ্যাঁ, এক্সেলের অত্যন্ত সক্রিয় ব্যবহার দিয়ে শুরু হয়। কিন্তু মূল বিষয় হল এটি সেখানে শেষ হয় না। ক্লাউড-ভিত্তিক Google Analytics এছাড়াও আগুনে জ্বালানি যোগ করে - আপনি দ্রুত ভাল জিনিসগুলিতে অভ্যস্ত হতে শুরু করেন।

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

বেশ দীর্ঘ সময় ধরে, এই নমনীয় সমাধানটি অনেক সাহায্য করেছিল, কিন্তু ধীরে ধীরে বুঝতে শুরু হয়েছিল যে ক্লিকহাউস রাবার নয় এবং এভাবে উপহাস করা যায় না।

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

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

পাইথন ও বিশ্লেষকদের দাবি

আমাদের কোম্পানির অনেক ডেভেলপার আছে যারা PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash-এ প্রায় প্রতিদিন 10-20 বছর ধরে কোড লেখেন। এছাড়াও অনেক অভিজ্ঞ সিস্টেম অ্যাডমিনিস্ট্রেটর আছেন যারা একাধিক অবিশ্বাস্য বিপর্যয়ের সম্মুখীন হয়েছেন যা পরিসংখ্যানের আইনের সাথে খাপ খায় না (উদাহরণস্বরূপ, যখন একটি রাইড-10-এর বেশিরভাগ ডিস্ক একটি শক্তিশালী বজ্রপাতের দ্বারা ধ্বংস হয়ে যায়)। এই ধরনের পরিস্থিতিতে, একটি "পাইথন বিশ্লেষক" কি তা দীর্ঘ সময়ের জন্য পরিষ্কার ছিল না। পাইথন হল PHP-এর মতো, শুধুমাত্র নামটি একটু লম্বা এবং দোভাষীর সোর্স কোডে মন-পরিবর্তনকারী পদার্থের সামান্য কম চিহ্ন রয়েছে। যাইহোক, যত বেশি বিশ্লেষণমূলক প্রতিবেদন তৈরি করা হয়েছে, অভিজ্ঞ বিকাশকারীরা ক্রমবর্ধমানভাবে নম্পি, পান্ডাস, ম্যাটপ্লটলিব, সিবোর্নের মতো সরঞ্জামগুলিতে সংকীর্ণ বিশেষীকরণের গুরুত্ব বুঝতে শুরু করেছে।
নিষ্পত্তিমূলক ভূমিকা, সম্ভবত, "লজিস্টিক রিগ্রেশন" শব্দের সংমিশ্রণ থেকে কর্মীদের আকস্মিক অজ্ঞান হয়ে যাওয়া এবং হ্যাঁ, হ্যাঁ, পাইসপার্ক ব্যবহার করে বড় ডেটার উপর কার্যকর প্রতিবেদনের প্রদর্শন দ্বারা অভিনয় করা হয়েছিল।

Apache Spark, এর কার্যকরী দৃষ্টান্ত যার উপর রিলেশনাল বীজগণিত পুরোপুরি ফিট করে এবং এর ক্ষমতাগুলি MySQL-তে অভ্যস্ত বিকাশকারীদের উপর এমন একটি ছাপ ফেলে যে অভিজ্ঞ বিশ্লেষকদের সাথে র‌্যাঙ্ক শক্তিশালী করার প্রয়োজনীয়তা দিন দিন স্পষ্ট হয়ে ওঠে।

Apache Spark/Hadoop-এর আরও প্রচেষ্টা এবং যা স্ক্রিপ্ট অনুযায়ী পুরোপুরি যায় নি

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

ফলস্বরূপ, আমরা বেশ কিছু অভ্যন্তরীণ বিশ্লেষণাত্মক প্রকল্পকে "বেঁচে রেখেছি" যা সক্রিয়ভাবে Apache Spark (Spark Streaming, Spark SQL সহ) এবং Hadoop ইকোসিস্টেম (এবং আরও অনেক কিছু) ব্যবহার করে। সময়ের সাথে সাথে আমরা "এটি" বেশ ভালভাবে প্রস্তুত এবং নিরীক্ষণ করতে শিখেছি এবং ডেটার প্রকৃতির পরিবর্তন এবং অভিন্ন আরডিডি হ্যাশিংয়ের ভারসাম্যহীনতার কারণে "এটি" কার্যত হঠাৎ ক্র্যাশ হওয়া বন্ধ করে দিয়েছে, ইতিমধ্যে প্রস্তুত কিছু নেওয়ার ইচ্ছা। , আপডেট করা হয়েছে এবং মেঘের কোথাও প্রশাসিত হয়েছে শক্তিশালী এবং শক্তিশালী. এই সময়েই আমরা অ্যামাজন ওয়েব পরিষেবাগুলির রেডিমেড ক্লাউড সমাবেশ ব্যবহার করার চেষ্টা করেছি - EMR এবং, পরবর্তীকালে, এটি ব্যবহার করে সমস্যাগুলি সমাধান করার চেষ্টা করেছিল। EMR হল Apache Spark যা Amazon দ্বারা ইকোসিস্টেম থেকে অতিরিক্ত সফ্টওয়্যার দিয়ে প্রস্তুত করা হয়েছে, অনেকটা ক্লাউডেরা/হর্টনওয়ার্কস তৈরি করে।

বিশ্লেষণের জন্য রাবার ফাইল স্টোরেজ একটি জরুরী প্রয়োজন

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

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

আমাজন S3 কি ডেটালেকের প্রার্থী?

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

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

Hadoop থেকে আপনার নিজের চপ প্রস্তুত না করে আপনি যদি পরিচিত এবং সুপরিচিত স্কেলেবল ক্লাউড স্টোরেজ Amazon S3-এ ফাইল সংরক্ষণ করেন?

এটা স্পষ্ট যে ব্যক্তিগত ডেটা "কম", কিন্তু আমরা যদি এটিকে সেখানে নিয়ে যাই এবং "কার্যকরভাবে চালাই" তবে অন্যান্য ডেটার কী হবে?

অ্যামাজন ওয়েব সার্ভিসের ক্লাস্টার-বিগডাটা-বিশ্লেষণ বাস্তুতন্ত্র - খুব সহজ কথায়

AWS-এর সাথে আমাদের অভিজ্ঞতার বিচার করে, Apache Hadoop/MapReduce সক্রিয়ভাবে বিভিন্ন সসের অধীনে দীর্ঘদিন ধরে ব্যবহার করা হয়েছে, উদাহরণস্বরূপ DataPipeline পরিষেবাতে (আমি আমার সহকর্মীদের ঈর্ষা করি, তারা কীভাবে এটি সঠিকভাবে প্রস্তুত করতে হয় তা শিখেছিল)। এখানে আমরা DynamoDB টেবিল থেকে বিভিন্ন পরিষেবা থেকে ব্যাকআপ সেট আপ করি:


এবং তারা বেশ কয়েক বছর ধরে ক্লকওয়ার্কের মতো এমবেডেড হ্যাডুপ/ম্যাপরিডুস ক্লাস্টারে নিয়মিত চলছে। "এটি সেট করুন এবং এটি ভুলে যান":

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

এবং হ্যাঁ, আপনি নিজের জন্য বা ক্লাউডের একজন বিশ্লেষকের জন্য একটি ল্যাপটপ নিতে পারেন এবং এটি একটি Hadoop/Spark ক্লাস্টারের সাথে সংযুক্ত করতে পারেন, গণনা করুন এবং তারপরে সবকিছু ঠিক করে নিন:

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

AWS আঠালো - স্টেরয়েডগুলিতে সুন্দরভাবে প্যাকেজ করা অ্যাপাচি স্পার্ক

দেখা গেল যে AWS এর "Hive/Pig/Spark" স্ট্যাকের নিজস্ব সংস্করণ রয়েছে৷ Hive এর ভূমিকা, i.e. DataLake-এ ফাইলের ক্যাটালগ এবং তাদের প্রকারগুলি "ডেটা ক্যাটালগ" পরিষেবা দ্বারা সঞ্চালিত হয়, যা Apache Hive ফর্ম্যাটের সাথে এর সামঞ্জস্য লুকিয়ে রাখে না। আপনার ফাইলগুলি কোথায় অবস্থিত এবং সেগুলি কী ফর্ম্যাটে রয়েছে সে সম্পর্কে আপনাকে এই পরিষেবাতে তথ্য যোগ করতে হবে৷ ডেটা শুধুমাত্র s3 তে নয়, ডাটাবেসেও থাকতে পারে, তবে এটি এই পোস্টের বিষয় নয়। এখানে আমাদের DataLake ডেটা ডিরেক্টরি কিভাবে সংগঠিত হয়:

ফাইল নিবন্ধিত হয়, মহান. ফাইলগুলি আপডেট করা থাকলে, আমরা ম্যানুয়ালি বা একটি সময়সূচীতে ক্রলারগুলি চালু করি, যা হ্রদ থেকে তাদের সম্পর্কে তথ্য আপডেট করবে এবং সেগুলি সংরক্ষণ করবে। তারপর হ্রদ থেকে ডেটা প্রক্রিয়া করা যেতে পারে এবং ফলাফলগুলি কোথাও আপলোড করা যেতে পারে। সহজ ক্ষেত্রে, আমরা s3 এও আপলোড করি। ডেটা প্রসেসিং যে কোনও জায়গায় করা যেতে পারে, তবে এটি পরামর্শ দেওয়া হচ্ছে যে আপনি AWS Glue API এর মাধ্যমে উন্নত ক্ষমতা ব্যবহার করে একটি Apache Spark ক্লাস্টারে প্রসেসিং কনফিগার করুন। প্রকৃতপক্ষে, আপনি pyspark লাইব্রেরি ব্যবহার করে ভাল পুরানো এবং পরিচিত পাইথন কোড নিতে পারেন এবং Hadoop-এর সাহসে খোঁড়াখুঁড়ি না করে এবং ডকার-মোকার কন্টেইনারগুলি টেনে না নিয়ে এবং নির্ভরতা দ্বন্দ্ব দূর না করে, কিছু ক্ষমতার একটি ক্লাস্টারের N নোডগুলিতে এটির এক্সিকিউশন কনফিগার করতে পারেন। .

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

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

অর্কেস্ট্রেশন সম্পর্কে কি? যদি টাস্ক পড়ে এবং অদৃশ্য হয়ে যায়? হ্যাঁ, অ্যাপাচি পিগ স্টাইলে একটি সুন্দর পাইপলাইন তৈরি করার প্রস্তাব করা হয়েছে এবং আমরা সেগুলি চেষ্টাও করেছি, কিন্তু আপাতত আমরা পিএইচপি এবং জাভাস্ক্রিপ্টে আমাদের গভীরভাবে কাস্টমাইজড অর্কেস্ট্রেশন ব্যবহার করার সিদ্ধান্ত নিয়েছি (আমি বুঝতে পারছি, জ্ঞানীয় অসঙ্গতি আছে, কিন্তু এটি কাজ করে, বছর এবং ত্রুটি ছাড়া)।

হ্রদে সংরক্ষিত ফাইলের বিন্যাস হল কর্মক্ষমতার চাবিকাঠি

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

• ফাইলগুলির কলামগুলি আলাদাভাবে সংরক্ষণ করুন (যাতে আপনাকে কলামগুলিতে কী আছে তা বোঝার জন্য সমস্ত লাইন পড়তে হবে না)। এই জন্য আমরা কম্প্রেশন সঙ্গে parquet বিন্যাস গ্রহণ
• ভাষা, বছর, মাস, দিন, সপ্তাহের মতো ফোল্ডারে ফাইলগুলিকে ভাগ করা খুবই গুরুত্বপূর্ণ। যে ইঞ্জিনগুলি এই ধরণের শার্ডিং বোঝে তারা একটি সারিতে সমস্ত ডেটা সিফ্ট না করে শুধুমাত্র প্রয়োজনীয় ফোল্ডারগুলি দেখবে৷

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

AWS Athena - জ্যাক-ইন-দ্য-বক্স

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

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

এথেনার অনুরোধের মূল্যও আকর্ষণীয়। আমরা জন্য অর্থ প্রদান স্ক্যান করা ডেটার পরিমাণ. সেগুলো. প্রতি মিনিটে ক্লাস্টারে মেশিনের সংখ্যার জন্য নয়, কিন্তু... আসলে 100-500টি মেশিনে স্ক্যান করা ডেটার জন্য, শুধুমাত্র অনুরোধটি সম্পূর্ণ করার জন্য প্রয়োজনীয় ডেটা।

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

যাইহোক, আমরা কীভাবে s3 এ আমাদের ডেটা ভাগ করি তা এখানে:

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

কিন্তু আমরা আরও এগিয়ে গেলাম এবং উত্তরের জন্য মেঘের কাছে যেতে লাগলাম ODBC ড্রাইভারের মাধ্যমে: একজন বিশ্লেষক একটি পরিচিত কনসোলে একটি এসকিউএল ক্যোয়ারী লেখেন, যা 100-500টি মেশিনে "পয়সার জন্য" s3 এ ডেটা পাঠায় এবং সাধারণত কয়েক সেকেন্ডের মধ্যে একটি উত্তর ফেরত দেয়। আরামপ্রদ. এবং দ্রুত। আমি এখনো বিশ্বাস করতে পারছি না।

ফলস্বরূপ, একটি দক্ষ কলামার বিন্যাসে এবং ফোল্ডারগুলিতে ডেটার যুক্তিসঙ্গত সংযোজন সহ s3-এ ডেটা সংরক্ষণ করার সিদ্ধান্ত নেওয়ার পরে... আমরা ডেটালেক এবং একটি দ্রুত এবং সস্তা বিশ্লেষণাত্মক ইঞ্জিন পেয়েছি - বিনামূল্যে। এবং তিনি কোম্পানিতে খুব জনপ্রিয় হয়ে ওঠেন, কারণ... SQL বোঝে এবং ক্লাস্টার শুরু/বন্ধ/সেট আপ করার চেয়ে দ্রুত মাত্রার অর্ডার কাজ করে। "এবং যদি ফলাফল একই হয় তবে কেন বেশি অর্থ প্রদান করবেন?"

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

তথ্যও

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

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

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

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

উত্স: www.habr.com