چگونه یک DataLake بسیار کارآمد و ارزان را سازماندهی کردیم و چرا چنین است

ما در زمان شگفت انگیزی زندگی می کنیم که می توانید به سرعت و به راحتی چندین ابزار منبع باز آماده را به هم متصل کنید، آنها را با "آگاهی خاموش" خود طبق توصیه stackoverflow تنظیم کنید، بدون اینکه در "چند حروف" جستجو کنید، و راه اندازی کنید. آنها را وارد عملیات تجاری کنند. و هنگامی که نیاز به به روز رسانی/بسط دارید یا شخصی به طور تصادفی چند دستگاه را راه اندازی مجدد می کند - متوجه می شوید که نوعی رویای بد وسواس گونه شروع شده است، همه چیز به طرز چشمگیری پیچیده شده است که قابل تشخیص نیست، هیچ بازگشتی وجود ندارد، آینده مبهم و امن تر است. به جای برنامه نویسی، زنبورها را پرورش دهید و پنیر کنید.

بی جهت نیست که همکاران با تجربه تر، با سرهای پر از اشکال و در نتیجه خاکستری، به استقرار سریع بسته های "ظروف" در "مکعب" روی ده ها سرور به "زبان های مد روز" با پشتیبانی داخلی فکر می کنند. ورودی/خروجی غیرمسدود ناهمزمان، با ملایمت لبخند بزنید. و آن‌ها بی‌صدا به بازخوانی «man ps» ادامه می‌دهند، در کد منبع «nginx» تا زمانی که از چشم‌هایشان خون می‌آید، کاوش می‌کنند و تست‌های واحد را می‌نویسند، می‌نویسند، می‌نویسند. همکاران می دانند که جالب ترین چیز زمانی اتفاق می افتد که "همه اینها" یک روز در شب در شب سال نو به خطر بیفتد. و تنها با درک عمیق از ماهیت یونیکس، جدول وضعیت TCP/IP حفظ شده و الگوریتم های مرتب سازی-جستجوی اولیه به آنها کمک می شود. برای بازگرداندن سیستم به زندگی با صدای زنگ ها.

اوه بله، کمی حواسم پرت شد، اما امیدوارم توانسته باشم حالت انتظار را منتقل کنم.
امروز می‌خواهم تجربه‌مان را در راه‌اندازی یک پشته راحت و ارزان برای DataLake به اشتراک بگذارم، که اکثر وظایف تحلیلی شرکت را برای بخش‌های ساختاری کاملاً متفاوت حل می‌کند.

مدتی پیش، ما به این درک رسیدیم که شرکت ها به طور فزاینده ای به ثمرات محصول و تجزیه و تحلیل فنی نیاز دارند (بدون ذکر یخ روی کیک در قالب یادگیری ماشینی) و برای درک روندها و خطرات - ما نیاز به جمع آوری و تجزیه و تحلیل داریم. معیارهای بیشتر و بیشتر

تجزیه و تحلیل فنی پایه در Bitrix24

چندین سال پیش، همزمان با راه‌اندازی سرویس Bitrix24، ما به طور فعال زمان و منابعی را برای ایجاد یک پلتفرم تحلیلی ساده و قابل اعتماد سرمایه‌گذاری کردیم که به دیدن سریع مشکلات در زیرساخت و برنامه‌ریزی گام بعدی کمک می‌کرد. البته توصیه می شد از ابزارهای آماده استفاده کنید که تا حد امکان ساده و قابل فهم باشد. در نتیجه، nagios برای نظارت و munin برای تجزیه و تحلیل و تجسم انتخاب شد. اکنون ما هزاران چک در nagios، صدها نمودار در munin داریم و همکاران ما هر روز با موفقیت از آنها استفاده می کنند. معیارها واضح هستند، نمودارها واضح هستند، سیستم چندین سال است که به طور قابل اعتماد کار می کند و آزمایش ها و نمودارهای جدید مرتباً به آن اضافه می شود: وقتی یک سرویس جدید را به کار می گیریم، چندین آزمایش و نمودار اضافه می کنیم. موفق باشید.

Finger on the Pulse - تجزیه و تحلیل فنی پیشرفته

تمایل به دریافت اطلاعات در مورد مشکلات "در اسرع وقت" ما را به آزمایش های فعال با ابزارهای ساده و قابل درک - pinba و xhprof سوق داد.

Pinba آماری را در بسته‌های UDP درباره سرعت عملکرد بخش‌هایی از صفحات وب در PHP برای ما ارسال کرد و ما می‌توانیم به صورت آنلاین در حافظه MySQL (Pinba با موتور MySQL خود برای تجزیه و تحلیل سریع رویدادها ارائه می‌شود) لیست کوتاهی از مشکلات را ببینیم و به آنها پاسخ دهیم. آنها و xhprof به طور خودکار به ما اجازه داد تا نمودارهایی از اجرای کندترین صفحات PHP را از مشتریان جمع آوری کنیم و آنچه می تواند منجر به این شود - با آرامش، ریختن چای یا چیز قوی تر - تجزیه و تحلیل کنیم.

مدتی پیش، جعبه ابزار با موتور نسبتاً ساده و قابل فهم دیگری بر اساس الگوریتم نمایه سازی معکوس، که کاملاً در کتابخانه افسانه ای Lucene - Elastic/Kibana پیاده سازی شده بود، تکمیل شد. ایده ساده ضبط چند رشته ای اسناد در یک نمایه لوسن معکوس بر اساس رویدادهای موجود در گزارش ها و جستجوی سریع در آنها با استفاده از تقسیم جنبه واقعاً مفید بود.

علی‌رغم ظاهر نسبتاً فنی تجسم‌ها در کیبانا با مفاهیم سطح پایین مانند «سطل» «رو به بالا» و زبان اختراع‌شده جبر رابطه‌ای که هنوز کاملاً فراموش نشده است، این ابزار به خوبی به ما در کارهای زیر کمک کرد:

• کلاینت Bitrix24 در یک ساعت گذشته چند خطای PHP در پورتال p1 داشته است و کدام یک؟ درک کنید، ببخشید و سریع اصلاح کنید.
• در 24 ساعت گذشته چند تماس تصویری در پورتال ها در آلمان برقرار شده است، با چه کیفیتی و آیا مشکلی برای کانال/شبکه ​​وجود دارد؟
• عملکرد سیستم (افزونه C ما برای PHP)، که از منبع در آخرین به روز رسانی سرویس کامپایل شده و برای مشتریان عرضه شده است، چقدر خوب کار می کند؟ آیا Segfault هایی وجود دارد؟
• آیا داده های مشتری در حافظه PHP جای می گیرد؟ آیا در مورد تجاوز از حافظه تخصیص داده شده به فرآیندها خطا وجود دارد: "حافظه تمام شده"؟ پیدا کنید و خنثی کنید.

در اینجا یک مثال عینی است. با وجود آزمایش کامل و چند سطحی، مشتری با یک کیس بسیار غیر استاندارد و داده های ورودی آسیب دیده، یک خطای آزاردهنده و غیرمنتظره دریافت کرد، یک آژیر به صدا درآمد و روند رفع سریع آن آغاز شد:

علاوه بر این، kibana به شما امکان می دهد اعلان ها را برای رویدادهای مشخص سازماندهی کنید و در مدت کوتاهی ابزار موجود در شرکت توسط ده ها کارمند از بخش های مختلف - از پشتیبانی فنی و توسعه گرفته تا QA شروع به استفاده کرد.

فعالیت هر بخش در شرکت برای ردیابی و اندازه گیری راحت شده است - به جای تجزیه و تحلیل دستی لاگ ها در سرورها، فقط باید یک بار گزارش تجزیه و تحلیل را تنظیم کنید و آنها را به خوشه الاستیک ارسال کنید تا مثلاً از فکر کردن در کیبانا لذت ببرید. داشبورد تعداد بچه گربه های دو سر فروخته شده چاپ شده روی چاپگر سه بعدی در آخرین ماه قمری.

تجزیه و تحلیل پایه کسب و کار

همه می دانند که تجزیه و تحلیل کسب و کار در شرکت ها اغلب با استفاده بسیار فعال از اکسل شروع می شود. اما نکته اصلی این است که به اینجا ختم نمی شود. Google Analytics مبتنی بر ابر نیز به آتش سوخت می افزاید - شما به سرعت شروع به عادت به چیزهای خوب می کنید.

در شرکت در حال توسعه هماهنگ ما، اینجا و آنجا "پیامبران" کار فشرده تر با داده های بزرگتر ظاهر شدند. نیاز به گزارش های عمیق تر و چند وجهی به طور مرتب ظاهر شد و با تلاش بچه ها از بخش های مختلف، مدتی پیش یک راه حل ساده و عملی - ترکیبی از ClickHouse و PowerBI سازماندهی شد.

برای مدت طولانی، این راه حل انعطاف پذیر کمک زیادی کرد، اما به تدریج این درک شروع شد که ClickHouse لاستیکی نیست و نمی توان آن را به آن تمسخر کرد.

در اینجا مهم است که به خوبی درک کنیم که ClickHouse، مانند Druid، مانند Vertica، مانند Amazon RedShift (که مبتنی بر postgres است)، موتورهای تحلیلی هستند که برای تجزیه و تحلیل نسبتا راحت (مجموع، تجمع، حداقل-حداکثر بر اساس ستون و چند اتصال ممکن) بهینه شده اند. )، زیرا بر خلاف MySQL و دیگر پایگاه‌های داده (ردی‌گرا) که برای ما شناخته شده است، برای ذخیره‌سازی کارآمد ستون‌های جداول رابطه‌ای سازماندهی شده است.

در اصل، ClickHouse فقط یک «پایگاه داده» بزرگ‌تر است، با درج نقطه به نقطه نه چندان راحت (اینطور در نظر گرفته شده است، همه چیز خوب است)، اما تجزیه و تحلیل دلپذیر و مجموعه‌ای از توابع قدرتمند جالب برای کار با داده‌ها. بله، حتی می توانید یک خوشه ایجاد کنید - اما می دانید که چکش زدن میخ ها با میکروسکوپ کاملاً صحیح نیست و ما شروع به جستجوی راه حل های دیگر کردیم.

تقاضا برای پایتون و تحلیلگران

شرکت ما توسعه دهندگان زیادی دارد که تقریباً هر روز به مدت 10-20 سال به زبان های PHP، JavaScript، C#، C/C++، Java، Go، Rust، Python، Bash کد می نویسند. همچنین بسیاری از مدیران سیستم با تجربه هستند که بیش از یک فاجعه کاملاً باورنکردنی را تجربه کرده‌اند که در قوانین آمار نمی گنجد (به عنوان مثال، هنگامی که اکثر دیسک‌های یک Raid-10 در اثر برخورد صاعقه قوی از بین می‌روند). در چنین شرایطی، برای مدت طولانی مشخص نبود که "تحلیلگر پایتون" چیست. پایتون مانند پی‌اچ‌پی است، فقط نام آن کمی طولانی‌تر است و آثاری از مواد تغییردهنده ذهن در کد منبع مفسر کمتر است. با این حال، با ایجاد گزارش های تحلیلی بیشتر و بیشتر، توسعه دهندگان با تجربه به طور فزاینده ای اهمیت تخصص محدود در ابزارهایی مانند numpy، pandas، matplotlib، seaborn را درک کردند.
نقش تعیین کننده، به احتمال زیاد، غش ناگهانی کارمندان از ترکیب کلمات "رگرسیون لجستیک" و نشان دادن گزارش موثر در مورد داده های بزرگ با استفاده از، بله، بله، pyspark بود.

آپاچی اسپارک، پارادایم عملکردی آن که جبر رابطه‌ای کاملاً بر روی آن قرار می‌گیرد، و قابلیت‌های آن چنان تأثیری بر توسعه‌دهندگانی گذاشت که به MySQL عادت کرده‌اند که نیاز به تقویت رتبه‌ها با تحلیلگران با تجربه مثل روز آشکار شد.

تلاش‌های بیشتر Apache Spark/Hadoop برای برخاستن و آنچه که کاملاً مطابق فیلمنامه پیش نمی‌رود

با این حال، به زودی مشخص شد که چیزی از نظر سیستمی در مورد اسپارک درست نیست، یا به سادگی لازم است که دستان خود را بهتر بشویید. اگر پشته Hadoop/MapReduce/Lucene توسط برنامه نویسان نسبتاً باتجربه ساخته شده باشد، که اگر به کد منبع در جاوا یا ایده های داگ کاتینگ در لوسن دقت کنید واضح است، ناگهان Spark به زبان عجیب و غریب Scala نوشته می شود. از نقطه نظر عملی بسیار بحث برانگیز است و در حال حاضر در حال توسعه نیست. و افت منظم محاسبات روی خوشه Spark به دلیل کار غیرمنطقی و نه چندان شفاف با تخصیص حافظه برای عملیات کاهش (بسیاری از کلیدها به یکباره می رسند) هاله ای را در اطراف آن ایجاد کرده است که جا برای رشد دارد. علاوه بر این، وضعیت با تعداد زیادی پورت‌های باز عجیب، فایل‌های موقت در حال رشد در نامفهوم‌ترین مکان‌ها و جهنمی از وابستگی‌های jar تشدید شد - که باعث شد مدیران سیستم احساسی داشته باشند که از کودکی شناخته شده بود: نفرت شدید (یا شاید). آنها باید دست های خود را با صابون بشویند).

در نتیجه، ما از چندین پروژه تحلیلی داخلی که به طور فعال از Apache Spark (از جمله Spark Streaming، Spark SQL) و اکوسیستم Hadoop (و غیره و غیره) استفاده می‌کنند، زنده مانده‌ایم. علیرغم این واقعیت که با گذشت زمان یاد گرفتیم که "آن" را به خوبی آماده و نظارت کنیم و "آن" به دلیل تغییر در ماهیت داده ها و عدم تعادل هش کردن یکنواخت RDD عملاً به طور ناگهانی از کار افتاد، تمایل به گرفتن چیزی از قبل آماده است. ، به روز شده و در جایی در ابر اداره می شود، قوی تر و قوی تر شد. در این زمان بود که سعی کردیم از مونتاژ ابری آماده خدمات وب آمازون استفاده کنیم - EMR و متعاقباً سعی کرد با استفاده از آن مشکلات را حل کند. EMR آپاچی اسپارک است که توسط آمازون با نرم‌افزار اضافی از اکوسیستم تهیه شده است، دقیقاً مانند ساخت‌های Cloudera/Hortonworks.

ذخیره سازی فایل لاستیکی برای تجزیه و تحلیل یک نیاز فوری است

تجربه "پختن" هادوپ/اسپارک با سوختگی در قسمت های مختلف بدن بیهوده نبود. نیاز به ایجاد یک ذخیره‌سازی فایل واحد، ارزان و قابل اعتماد که در برابر خرابی‌های سخت‌افزاری مقاوم باشد و در آن امکان ذخیره فایل‌ها با فرمت‌های مختلف از سیستم‌های مختلف و ساختن نمونه‌های کارآمد و با زمان کارآمد برای گزارش‌های این داده‌ها وجود داشته باشد، روز به روز افزایش یافت. روشن

همچنین می‌خواستم به‌روزرسانی نرم‌افزار این پلتفرم با خواندن ردپای 20 صفحه‌ای جاوا و تجزیه و تحلیل گزارش‌های دقیق کیلومتری خوشه با استفاده از Spark History Server و ذره‌بین با نور پس‌زمینه به کابوس سال نو تبدیل نشود. من می‌خواستم یک ابزار ساده و شفاف داشته باشم که نیازی به غواصی منظم در زیر کاپوت نداشته باشد، اگر درخواست استاندارد MapReduce توسعه‌دهنده زمانی که کاهش داده‌کار از حافظه خارج شد به دلیل الگوریتم پارتیشن‌بندی داده منبع نه چندان خوب، اجرا نمی‌شود.

آیا آمازون S3 کاندیدای DataLake است؟

تجربه با Hadoop/MapReduce به ما آموخت که ما به یک سیستم فایل مقیاس‌پذیر و قابل اعتماد و کارگران مقیاس‌پذیر در بالای آن نیاز داریم که به داده‌ها نزدیک‌تر شوند تا داده‌ها را روی شبکه هدایت نکنند. کارگران باید بتوانند داده ها را در قالب های مختلف بخوانند، اما ترجیحاً اطلاعات غیر ضروری را نخوانند و بتوانند داده ها را از قبل در قالب های مناسب برای کارگران ذخیره کنند.

یک بار دیگر، ایده اصلی. هیچ تمایلی به "ریختن" داده های بزرگ در یک موتور تحلیلی خوشه ای وجود ندارد، که دیر یا زود خفه می شود و مجبور خواهید بود آن را به شکل زشتی خرد کنید. من می‌خواهم فایل‌ها، فقط فایل‌ها را در قالبی قابل فهم ذخیره کنم و با استفاده از ابزارهای مختلف اما قابل فهم، پرس و جوهای تحلیلی مؤثری را روی آنها انجام دهم. و فایل های بیشتری در فرمت های مختلف وجود خواهد داشت. و بهتر است نه موتور، بلکه داده های منبع را خرد کنید. ما به یک DataLake قابل توسعه و جهانی نیاز داریم، تصمیم گرفتیم...

اگر فایل‌ها را در فضای ذخیره‌سازی ابری مقیاس‌پذیر آشنا و شناخته‌شده Amazon S3 ذخیره کنید، بدون اینکه نیازی به تهیه برش‌های خود از Hadoop داشته باشید؟

واضح است که داده‌های شخصی «کم» هستند، اما اگر آن‌ها را بیرون بیاوریم و «به‌طور مؤثری آن‌ها را هدایت کنیم» چه می‌شود؟

اکوسیستم Cluster-bigdata-Alytics of Amazon Web Services - به عبارت بسیار ساده

با قضاوت بر اساس تجربه ما با AWS، Apache Hadoop/MapReduce برای مدت طولانی تحت سس های مختلف، به عنوان مثال در سرویس DataPipeline، به طور فعال در آنجا استفاده شده است (من به همکارانم حسادت می کنم، آنها یاد گرفتند که چگونه آن را درست تهیه کنند). در اینجا ما از جداول DynamoDB از سرویس های مختلف پشتیبان تهیه می کنیم:


و آنها چندین سال است که به طور منظم بر روی خوشه‌های جاسازی شده Hadoop/MapReduce مانند چرخش ساعت در حال اجرا هستند. "تنظیمش کن و فراموشش کن":

همچنین می‌توانید با راه‌اندازی لپ‌تاپ‌های مشتری در فضای ابری برای تحلیلگران و استفاده از سرویس AWS SageMaker برای آموزش و استقرار مدل‌های هوش مصنوعی در نبرد، به طور مؤثر در شیطان پرستی داده‌ها شرکت کنید. در اینجا برای ما به نظر می رسد:

و بله، می‌توانید یک لپ‌تاپ برای خود یا یک تحلیلگر در فضای ابری بردارید و آن را به یک خوشه Hadoop/Spark متصل کنید، محاسبات را انجام دهید و سپس همه چیز را ثابت کنید:

واقعا برای پروژه های تحلیلی فردی مناسب است و برای برخی از آنها ما با موفقیت از سرویس EMR برای محاسبات و تجزیه و تحلیل در مقیاس بزرگ استفاده کرده ایم. در مورد راه حل سیستمی برای DataLake چطور، آیا کار خواهد کرد؟ در این لحظه در آستانه امید و ناامیدی قرار گرفتیم و به جستجو ادامه دادیم.

چسب AWS - Apache Spark با بسته بندی منظم روی استروئیدها

معلوم شد که AWS نسخه مخصوص به خود را از پشته "Hive/Pig/Spark" دارد. نقش کندو، یعنی. کاتالوگ فایل ها و انواع آنها در DataLake توسط سرویس “Data catalog” انجام می شود که سازگاری آن با فرمت Apache Hive را پنهان نمی کند. شما باید اطلاعاتی را در مورد مکان و فرمت فایل های شما به این سرویس اضافه کنید. داده ها می توانند نه تنها در s3، بلکه در پایگاه داده نیز باشند، اما موضوع این پست نیست. در اینجا نحوه سازماندهی فهرست اطلاعات DataLake ما آمده است:

فایل ها ثبت شده است، عالی است. اگر فایل‌ها به‌روزرسانی شده باشند، خزنده‌ها را به صورت دستی یا بر اساس برنامه راه‌اندازی می‌کنیم که اطلاعات مربوط به آن‌ها را از دریاچه به‌روزرسانی می‌کند و ذخیره می‌کند. سپس داده های دریاچه را می توان پردازش کرد و نتایج را در جایی بارگذاری کرد. در ساده ترین حالت در s3 هم آپلود می کنیم. پردازش داده‌ها را می‌توان در هر جایی انجام داد، اما پیشنهاد می‌شود که پردازش را روی یک خوشه Apache Spark با استفاده از قابلیت‌های پیشرفته از طریق API AWS Glue پیکربندی کنید. در واقع، می‌توانید کد قدیمی و آشنای پایتون را با استفاده از کتابخانه pyspark دریافت کنید و اجرای آن را روی N گره از یک خوشه با مقداری ظرفیت با نظارت، پیکربندی کنید، بدون اینکه به درون هادوپ بگردید و کانتینرهای docker-moker را بکشید و درگیری‌های وابستگی را حذف کنید. .

یک بار دیگر، یک ایده ساده. نیازی به پیکربندی آپاچی اسپارک نیست، فقط باید کد پایتون را برای pyspark بنویسید، آن را به صورت محلی روی دسکتاپ خود تست کنید و سپس آن را روی یک خوشه بزرگ در ابر اجرا کنید، و مشخص کنید که منبع داده کجاست و نتیجه را کجا قرار دهید. گاهی اوقات این ضروری و مفید است، و در اینجا نحوه تنظیم آن آمده است:

بنابراین، اگر شما نیاز به محاسبه چیزی در یک خوشه Spark با استفاده از داده‌های موجود در s3 دارید، کدی را در python/pyspark می‌نویسیم، آن را آزمایش می‌کنیم و برای ابر موفق باشید.

در مورد ارکستراسیون چطور؟ اگر تکلیف افتاد و ناپدید شد چه؟ بله، پیشنهاد شده است که یک خط لوله زیبا به سبک آپاچی پیگ بسازیم و ما حتی آنها را امتحان کردیم، اما در حال حاضر تصمیم گرفتیم از ارکستراسیون عمیقا سفارشی شده خود در PHP و جاوا اسکریپت استفاده کنیم (من متوجه شدم، ناهماهنگی شناختی وجود دارد، اما کار می کند، برای سالها و بدون خطا).

فرمت فایل های ذخیره شده در دریاچه کلید عملکرد است

درک دو نکته کلیدی دیگر بسیار بسیار مهم است. برای اینکه درخواست‌های مربوط به داده‌های فایل در دریاچه در سریع‌ترین زمان ممکن اجرا شوند و عملکرد هنگام افزودن اطلاعات جدید کاهش نیابد، باید:

• ستون‌های فایل‌ها را جداگانه ذخیره کنید (به طوری که مجبور نباشید همه خطوط را بخوانید تا بفهمید چه چیزی در ستون‌ها وجود دارد). برای این ما قالب پارکت را با فشرده سازی گرفتیم
• بسیار مهم است که فایل ها را در پوشه هایی مانند: زبان، سال، ماه، روز، هفته به اشتراک بگذارید. موتورهایی که این نوع به اشتراک گذاری را درک می کنند، فقط به پوشه های ضروری نگاه می کنند، بدون اینکه تمام داده ها را پشت سر هم بررسی کنند.

اساساً، به این ترتیب، داده‌های منبع را به کارآمدترین شکل برای موتورهای تحلیلی آویزان در بالا قرار می‌دهید، که حتی در پوشه‌های خرد شده می‌توانند به طور انتخابی فقط ستون‌های لازم را از فایل‌ها وارد کرده و بخوانند. شما نیازی به "پر کردن" داده ها در هیچ کجا ندارید (ذخیره سازی به سادگی منفجر می شود) - فقط فوراً عاقلانه آن را با فرمت صحیح در سیستم فایل قرار دهید. البته در اینجا باید مشخص شود که ذخیره یک فایل csv عظیم در DataLake که ابتدا باید خط به خط توسط خوشه خوانده شود تا ستون ها استخراج شوند، چندان توصیه نمی شود. اگر هنوز مشخص نیست چرا این همه اتفاق می افتد، دوباره به دو نکته بالا فکر کنید.

AWS Athena - جک در جعبه

و سپس، هنگام ایجاد یک دریاچه، به طور تصادفی با آمازون آتنا روبرو شدیم. ناگهان مشخص شد که با مرتب کردن دقیق فایل‌های لاگ عظیم ما در قطعات پوشه در قالب ستون درست (پارکت)، می‌توانید خیلی سریع از آنها انتخاب‌های بسیار آموزنده‌ای انجام دهید و گزارش‌هایی را بدون وجود یک کلاستر Apache Spark/Glue بسازید.

موتور آتنا که توسط داده ها در s3 کار می کند بر اساس افسانه ای است تند - نماینده ای از خانواده رویکردهای MPP (پردازش موازی گسترده) برای پردازش داده ها، بردن داده ها در جایی که نهفته است، از s3 و Hadoop تا Cassandra و فایل های متنی معمولی. شما فقط باید از آتنا بخواهید که یک پرس و جوی SQL را اجرا کند، و سپس همه چیز به سرعت و به طور خودکار کار می کند. توجه به این نکته مهم است که آتنا "هوشمند" است، فقط به پوشه های خرد شده ضروری می رود و فقط ستون های مورد نیاز در درخواست را می خواند.

قیمت گذاری برای درخواست به آتنا نیز جالب است. ما هزینه می کنیم حجم داده های اسکن شده. آن ها نه برای تعداد ماشین‌های موجود در خوشه در دقیقه، بلکه برای داده‌هایی که در واقع روی 100-500 ماشین اسکن شده‌اند، فقط داده‌های لازم برای تکمیل درخواست است.

و با درخواست تنها ستون های لازم از پوشه های به درستی خرد شده، معلوم شد که سرویس آتنا ماهانه ده ها دلار برای ما هزینه دارد. خوب، بسیار عالی، تقریبا رایگان، در مقایسه با تجزیه و تحلیل در خوشه ها!

به هر حال، در اینجا نحوه تقسیم داده های خود در s3 آمده است:

در نتیجه، در مدت زمان کوتاهی، بخش‌های کاملاً متفاوت در شرکت، از امنیت اطلاعات گرفته تا تجزیه و تحلیل، شروع به درخواست فعالانه از آتنا کردند و به سرعت، در چند ثانیه، پاسخ‌های مفیدی را از داده‌های «بزرگ» در دوره‌های نسبتاً طولانی دریافت کردند: ماه‌ها، نیم سال و غیره پ.

اما ما جلوتر رفتیم و شروع کردیم به رفتن به ابر برای پاسخ از طریق درایور ODBC: یک تحلیلگر یک پرس و جوی SQL را در یک کنسول آشنا می نویسد، که در 100-500 ماشین "برای پنی" داده ها را به s3 ارسال می کند و معمولاً در چند ثانیه پاسخ را برمی گرداند. راحت. و سریع. من هنوز نمی توانم آن را باور کنم.

در نتیجه، با تصمیم به ذخیره داده ها در s3، در قالب ستونی کارآمد و با اشتراک گذاری منطقی داده ها در پوشه ها ... ما DataLake و یک موتور تحلیلی سریع و ارزان را - به صورت رایگان دریافت کردیم. و او در این شرکت بسیار محبوب شد، زیرا ... SQL را می‌فهمد و دستورات بزرگی را سریع‌تر از راه‌اندازی/توقف/تنظیم خوشه‌ها انجام می‌دهد. "و اگر نتیجه یکسان است، چرا بیشتر پرداخت کنید؟"

یک درخواست از آتنا چیزی شبیه به این است. در صورت تمایل، البته، می توانید به اندازه کافی فرم دهید پرس و جو پیچیده و چند صفحه ای SQL، اما ما خود را به گروه بندی ساده محدود می کنیم. بیایید ببینیم که مشتری چند هفته پیش چه کدهای پاسخی در گزارش‌های وب سرور داشت و مطمئن شویم که هیچ خطایی وجود ندارد:

یافته ها

پس از گذراندن یک مسیر طولانی، اما پردردسر، به طور مداوم ریسک ها و سطح پیچیدگی و هزینه پشتیبانی را ارزیابی کردیم، راه حلی برای DataLake و تجزیه و تحلیل پیدا کردیم که هرگز از نظر سرعت و هزینه مالکیت ما را خوشحال نمی کند.

معلوم شد که ساخت یک DataLake موثر، سریع و ارزان برای نیازهای بخش‌های کاملاً متفاوت شرکت کاملاً در حیطه توانایی توسعه‌دهندگان با تجربه است که هرگز به عنوان معمار کار نکرده‌اند و نمی‌دانند چگونه مربع‌هایی را روی مربع‌ها ترسیم کنند. فلش و 50 اصطلاح از اکوسیستم هادوپ را بدانید.

در ابتدای سفر، سرم از بسیاری از باغ‌وحش‌های وحشی نرم‌افزارهای باز و بسته و درک بار مسئولیت به فرزندان جدا می‌شد. فقط شروع به ساخت DataLake خود از ابزارهای ساده کنید: nagios/munin -> elastic/kibana -> hadoop/spark/s3...، جمع‌آوری بازخورد و درک عمیق فیزیک فرآیندهای در حال انجام. همه چیز پیچیده و مبهم - آن را به دشمنان و رقبا بدهید.

اگر نمی‌خواهید به فضای ابری بروید و دوست دارید پروژه‌های منبع باز را پشتیبانی، به‌روزرسانی و وصله کنید، می‌توانید طرحی مشابه طرح ما به صورت محلی، روی ماشین‌های اداری ارزان قیمت با Hadoop و Presto در بالا بسازید. نکته اصلی این است که متوقف نشوید و به جلو حرکت نکنید، بشمارید، به دنبال راه حل های ساده و واضح باشید، و قطعا همه چیز درست می شود! برای همه موفق باشید و دوباره شما را ببینم!

منبع: www.habr.com