مؤلفه ETL انبار داده اغلب تحت الشعاع خود انبار قرار می گیرد و نسبت به پایگاه داده اصلی یا مؤلفه front-end، BI و گزارش کمتر مورد توجه قرار می گیرد. در عین حال، از نقطه نظر مکانیک پر کردن انبار با داده ها، ETL نقش کلیدی ایفا می کند و نیازی به توجه کمتر مدیران نسبت به سایر اجزا ندارد. نام من الکساندر است، من در حال حاضر ETL را در Rostelecom مدیریت می کنم و در این مقاله سعی می کنم کمی از آنچه مدیر یکی از معروف ترین سیستم های ETL در یک انبار داده بزرگ در Rostelecom با آن سر و کار دارد را به اشتراک بگذارم.
اگر خوانندگان عزیز به طور کلی با پروژه انبار داده ما و محصول Informatica PowerCenter آشنا هستند، می توانید بلافاصله به بخش بعدی بروید.
چندین سال پیش، ایده یک انبار داده شرکتی واحد به بلوغ رسید و شروع به پیاده سازی در Rostelecom کرد. تعدادی از مخازن که مشکلات فردی را حل می کردند قبلا ایجاد شده بودند، اما تعداد سناریوها افزایش یافت، هزینه های پشتیبانی نیز افزایش یافت و مشخص شد که آینده در تمرکز است. از نظر معماری، این خود ذخیره‌سازی است که شامل چندین لایه است که بر روی Hadoop و GreenPlum، پایگاه‌های اطلاعاتی کمکی، مکانیزم‌های ETL و BI پیاده‌سازی شده‌اند.
در همان زمان، به دلیل تعداد زیاد منابع داده ناهمگون و پراکنده جغرافیایی، مکانیسم بارگذاری داده ویژه ایجاد شد که عملکرد آن توسط Informatica کنترل می شود. در نتیجه بسته‌های داده به قسمت رابط Hadoop ختم می‌شوند و پس از آن فرآیند بارگذاری داده‌ها از طریق لایه‌های ذخیره‌سازی، Hadoop و GreenPlum آغاز می‌شود و توسط مکانیزم به اصطلاح کنترل ETL که در Informatica پیاده‌سازی شده است، مدیریت می‌شوند. بنابراین، سیستم Informatica یکی از عناصر کلیدی است که عملکرد انبار را تضمین می کند.
ذخیره سازی ما در یکی از پست های بعدی با جزئیات بیشتر توضیح داده خواهد شد.
Informatica PowerCenter/Big Data Management در حال حاضر نرم افزار پیشرو در زمینه ابزارهای یکپارچه سازی داده ها محسوب می شود. این محصول شرکت آمریکایی Informatica است که یکی از قوی ترین بازیگران در ETL (Extract Transform Load)، مدیریت کیفیت داده، MDM (Master Data Management)، ILM (Information Lifecycle Management) و غیره است.
PowerCenter ما یک سرور برنامه کاربردی Tomcat یکپارچه است که خود برنامه های Informatica در آن اجرا می شوند و خدمات آن را پیاده سازی می کنند:
دامنهدر واقع، این اساس هر چیز دیگری است؛ خدمات، کاربران و اجزای GRID در دامنه کار می کنند.
کنسول مدیر، یک ابزار مدیریت و نظارت مبتنی بر وب، علاوه بر مشتری توسعه دهنده Informatica، ابزار اصلی برای تعامل با محصول است.
MRS، سرویس مخزن مدلمخزن ابرداده، لایه ای بین پایگاه داده ای است که ابرداده به صورت فیزیکی در آن ذخیره می شود و سرویس گیرنده توسعه دهنده Informatica که توسعه در آن انجام می شود. مخازن توضیحات داده ها و سایر اطلاعات را ذخیره می کنند، از جمله برای تعدادی دیگر از سرویس های Infromatica، به عنوان مثال، برنامه زمانی برای اجرای وظایف (Schedules) یا نظارت بر داده ها، و همچنین پارامترهای برنامه، به ویژه، اجازه استفاده از یک برنامه مشابه را برای کار با منابع و گیرنده های مختلف داده
DIS، سرویس یکپارچه سازی داده هااین سرویسی است که در آن فرآیندهای عملکردی اصلی انجام می‌شود، برنامه‌های کاربردی در آن اجرا می‌شوند و راه‌اندازی واقعی گردش‌های کاری (توضیحات توالی نقشه‌برداری‌ها و تعاملات آنها) و Mappings (تبدیل‌ها، بلوک‌هایی که خود تبدیل‌ها در آن اتفاق می‌افتد، پردازش داده‌ها. ) اتفاق افتادن.
پیکربندی GRID - اساساً، گزینه ای برای ساخت یک مجتمع با استفاده از چندین سرور، زمانی که بار راه اندازی شده توسط DIS بین گره ها (یعنی سرورهایی که بخشی از دامنه هستند) توزیع می شود. در مورد این گزینه، علاوه بر توزیع بار در DIS از طریق یک لایه انتزاعی GRID اضافی که چندین گره را متحد می کند، که DIS به جای کار بر روی یک گره خاص روی آن اجرا می شود، نمونه های MRS پشتیبان اضافی نیز می توانند ایجاد شوند. حتی می‌توانید در دسترس بودن بالا را پیاده‌سازی کنید، جایی که تماس‌های خارجی می‌توانند از طریق گره‌های پشتیبان در صورت شکست گره اصلی برقرار شوند. ما در حال حاضر این گزینه ساخت و ساز را رها کرده ایم.
Informatica PowerCenter، شماتیک
در مراحل اولیه کار به عنوان بخشی از زنجیره تامین داده، مشکلاتی به طور منظم به وجود آمد که برخی از آنها به دلیل عملکرد ناپایدار Informatica در آن زمان بود. من قصد دارم برخی از لحظات به یاد ماندنی این حماسه - تسلط بر Informatica 10 را به اشتراک بگذارم.
لوگوی سابق اینفورماتیکا
حوزه مسئولیت ما شامل سایر محیط‌های Informatica نیز می‌شود، آنها به دلیل بار متفاوت، مشخصات خاص خود را دارند، اما در حال حاضر دقیقاً به یاد خواهم آورد که Informatica چگونه به عنوان یک جزء ETL از خود انبار داده توسعه یافته است.
چگونه اتفاق افتاد
در سال 2016، زمانی که ما مسئولیت کار Informatica را بر عهده گرفتیم، قبلاً به نسخه 10.0 رسیده بود، و برای همکاران خوشبین که تصمیم داشتند از محصولی با نسخه جزئی 0 در یک راه حل جدی استفاده کنند، همه چیز واضح به نظر می رسید - ما باید از آن استفاده کنیم. نسخه جدید! از نظر منابع سخت افزاری در آن زمان همه چیز خوب بود.
از بهار 2016، یک پیمانکار مسئولیت کار انفورماتیکا را بر عهده داشته است و به گفته معدود کاربران این سیستم، "هفته ای یکی دو بار کار می کرد." در اینجا لازم به توضیح است که مخزن به طور عملی در مرحله PoC بود، هیچ مدیری در تیم وجود نداشت و سیستم به دلایل مختلف دائماً از کار می افتاد و پس از آن مهندس پیمانکار دوباره آن را برداشت.
در پاییز، سه مدیر به تیم ملحق شدند و حوزه های مسئولیت خود را بین خود تقسیم کردند و کار عادی برای سازماندهی عملیات سیستم ها در پروژه از جمله Informatica آغاز شد. به طور جداگانه باید گفت که این محصول فراگیر نیست و جامعه بزرگی دارد که می توانید در آن به هر سوالی پاسخ دهید و هر مشکلی را حل کنید. بنابراین، پشتیبانی فنی کامل از طرف شریک روسی Informatica بسیار مهم بود که با کمک آن تمام خطاها و خطاهای ما در آن زمان جوان Informatica 10 اصلاح شد.
اولین کاری که ما باید برای توسعه دهندگان تیم خود و پیمانکار انجام می دادیم این بود که کار خود اینفورماتیکا را تثبیت کنیم تا از عملکرد کنسول مدیریت وب (Informatica Administrator) اطمینان حاصل کنیم.
اینگونه است که ما اغلب با توسعه دهندگان Informatica ملاقات می کنیم
از روند کشف دلایل که بگذریم، دلیل اصلی خرابی ها، الگوی تعامل نرم افزار انفورماتیکا با پایگاه داده مخزن بود که بر روی یک سرور نسبتاً راه دور قرار داشت، از نظر چشم انداز شبکه. این باعث تأخیر و اختلال در مکانیسم‌هایی شد که وضعیت دامنه Informatica را نظارت می‌کنند. پس از کمی تنظیم پایگاه داده، تغییر پارامترهای انفورماتیکا که باعث تحمل بیشتر تاخیر در پایگاه داده شد و در نهایت به روز رسانی نسخه انفورماتیکا به 10.1 و انتقال پایگاه داده از سرور قبلی به سروری که نزدیکتر به انفورماتیکا قرار داشت، مشکل خود را از دست داد. مربوط است، و از آن زمان تاکنون چنین خرابی هایی وجود داشته است که ما مشاهده نکرده ایم.
یکی از تلاش ها برای به کار انداختن مانیتور Informatica
وضعیت کنسول مدیریت نیز بحرانی بود. از آنجایی که توسعه فعال مستقیماً در محیط نسبتاً مولد در جریان بود، همکاران دائماً به تجزیه و تحلیل کار نقشه‌برداری و گردش کار «در حال حرکت» نیاز داشتند. در Informatica جدید، سرویس یکپارچه سازی داده ها ابزار جداگانه ای برای چنین نظارتی ندارد، اما یک بخش نظارت در کنسول وب مدیریت (Informatica Administrator Monitor) ظاهر شده است که در آن می توانید عملکرد برنامه ها، گردش کار و نقشه برداری ها را نظارت کنید. راه اندازی، سیاهههای مربوط. به طور دوره ای، کنسول به طور کامل در دسترس نبود، یا اطلاعات مربوط به فرآیندهای فعلی در DIS به روز رسانی متوقف می شد، یا هنگام بارگیری صفحات خطاهایی رخ می داد.
انتخاب پارامترهای جاوا برای تثبیت عملکرد
مشکل از طرق مختلف تصحیح شد، آزمایش‌هایی برای تغییر پارامترها انجام شد، لاگ‌ها و jstack جمع‌آوری شد، به پشتیبانی ارسال شد، در همان زمان Google فعال و مشاهده ساده وجود داشت.
اول از همه، یک MRS جداگانه برای نظارت ایجاد شد؛ همانطور که بعدا مشخص شد، این یکی از مصرف کنندگان اصلی منابع در محیط های ما است، زیرا نقشه برداری ها بسیار فشرده راه اندازی می شوند. پارامترهای مربوط به java heap و تعدادی دیگر تغییر کرده اند.
در نتیجه، با به روز رسانی بعدی Informatica 10.1.1، عملکرد کنسول و مانیتور تثبیت شد، توسعه دهندگان شروع به کارکرد بهتر کردند و فرآیندهای منظم بیش از پیش منظم شدند.
تجربه تعامل بین توسعه و مدیریت ممکن است جالب باشد. موضوع درک کلی از چگونگی کار کردن کارها، آنچه که می توان انجام داد و چه کاری را نمی توان انجام داد، همیشه هنگام استفاده از سیستم های پیچیده مهم است. بنابراین، ما می توانیم با خیال راحت توصیه کنیم که ابتدا تیم اداری را در مورد نحوه مدیریت نرم افزار و تیم توسعه را در مورد نحوه کدنویسی و ترسیم فرآیندها در سیستم آموزش دهید و تنها پس از آن نفر اول و دوم را برای کار بر روی نتیجه ارسال کنید. وقتی زمان منبع نامحدودی نیست، این واقعاً مهم است. بسیاری از مشکلات را می توان حتی با جستجوی تصادفی گزینه ها حل کرد، اما گاهی اوقات برخی از آنها نیاز به دانش پیشینی دارند - مورد ما اهمیت درک این اصل را تأیید می کند.
به عنوان مثال، زمانی که سعی کردیم نسخه سازی را در MRS فعال کنیم (همانطور که در پایان مشخص شد، نسخه دیگری از SVN مورد نیاز بود)، پس از مدتی متوجه شدیم که زمان راه اندازی مجدد سیستم به چند ده دقیقه افزایش یافته است. پس از یافتن دلیل تاخیر در شروع و غیرفعال کردن نسخه، دوباره خوب عمل کردیم.
موانع قابل توجه مرتبط با Informatica شامل نبرد حماسی با موضوعات در حال رشد جاوا است. در برخی مواقع، زمان تکرار فرا رسیده است، یعنی گسترش فرآیندهای ایجاد شده به تعداد زیادی از سیستم های منبع. معلوم شد که همه فرآیندهای 10.1.1 به خوبی کار نمی کنند و پس از مدتی DIS غیر قابل اجرا شد. ده‌ها هزار رشته شناسایی شدند که تعداد آنها به‌ویژه در طول مراحل استقرار برنامه به طور قابل توجهی افزایش یافت. گاهی اوقات مجبور می شدم چندین بار در روز برای بازیابی عملکرد دوباره راه اندازی کنم.
در اینجا باید از پشتیبانی تشکر کنیم؛ مشکلات با استفاده از EBF (رفع اشکال اضطراری) بومی سازی و نسبتاً سریع رفع شدند - پس از آن، همه این احساس را داشتند که ابزار واقعاً کار می کند.
هنوز هم کار می کند!
زمانی که کار را در حالت هدف شروع کردیم، Informatica به این شکل به نظر می رسید. نسخه Informatica 10.1.1HF1 (HF1 HotFix1 است، مونتاژ فروشنده از مجموعه ای از EBF ها) با EBF نصب شده اضافی، که مشکلات ما را در مورد مقیاس گذاری و برخی دیگر، در یک سرور از سه سرور که بخشی از GRID بودند، 20 هسته x86_64 تصحیح می کند. و ذخیره سازی، روی یک آرایه آهسته عظیم از دیسک های محلی - این پیکربندی سرور برای یک خوشه Hadoop است. در سرور مشابه دیگری - Oracle DBMS که هم دامنه Informatica و هم مکانیسم کنترل ETL با آن کار می کنند. همه اینها توسط ابزارهای نظارت استاندارد مورد استفاده در تیم (Zabbix + Grafana) در هر دو طرف - خود انفورماتیکا با خدماتش و فرآیندهای بارگیری که در آن انجام می شود نظارت می شود. اکنون هم عملکرد و هم پایداری، بدون در نظر گرفتن عوامل خارجی، اکنون به تنظیماتی بستگی دارد که بار را محدود می کند.
به طور جداگانه، می توانیم در مورد GRID بگوییم. محیط بر روی سه گره، با امکان متعادل سازی بار ساخته شده است. با این حال، در طول آزمایش، مشخص شد که به دلیل مشکلات تعامل بین نمونه‌های در حال اجرا برنامه‌های ما، این پیکربندی آنطور که انتظار می‌رفت کار نمی‌کند و آنها تصمیم گرفتند به طور موقت این طرح ساخت و ساز را کنار بگذارند و دو تا از سه گره را از دامنه حذف کنند. در همان زمان، خود طرح یکسان باقی مانده است، و اکنون دقیقاً یک سرویس GRID است، اما به یک گره منحط شده است.
در حال حاضر، هنگام تمیز کردن منظم مدار مانیتور، مشکل همچنان با کاهش عملکرد همراه است - با فرآیندهای همزمان در CNN و تمیز کردن در حال اجرا، ممکن است نقص در عملکرد مکانیسم کنترل ETL رخ دهد. این در حال حاضر "به عنوان یک عصا" حل می شود - با پاک کردن دستی مدار مانیتور، با از دست دادن تمام داده های قبلی آن. این برای بهره وری، در طول عملیات معمول عادی، خیلی حیاتی نیست، اما در حال حاضر جستجو برای یک راه حل عادی در حال انجام است.
مشکل دیگری از همین وضعیت ناشی می شود - گاهی اوقات چندین راه اندازی مکانیسم کنترل ما رخ می دهد.
راه اندازی چندین برنامه که منجر به خرابی مکانیزم می شود
هنگام اجرا بر اساس یک برنامه، در مواقعی که بار سنگین بر روی سیستم وجود دارد، گاهی اوقات موقعیت هایی رخ می دهد که منجر به خرابی مکانیزم می شود. مشکل هنوز به صورت دستی رفع می شود و به دنبال راه حل دائمی است.
به طور کلی می توان خلاصه کرد که وقتی بار سنگینی وجود دارد، تهیه منابع مناسب برای آن بسیار مهم است، این امر در مورد منابع سخت افزاری برای خود انفورماتیکا و همین طور برای مخزن پایگاه داده آن و همچنین ارائه تنظیمات بهینه صدق می کند. برای آنها. علاوه بر این، این سوال باز می ماند که کدام طرح قرار دادن پایگاه داده بهتر است - در یک میزبان جداگانه یا در همان جایی که نرم افزار Informatica در آن اجرا می شود. از یک طرف روی یک سرور ارزان‌تر خواهد بود و در صورت ترکیب، مشکل احتمالی تعامل با شبکه عملا برطرف می‌شود؛ از طرف دیگر، بار روی هاست از پایگاه داده با بار Informatica تکمیل می‌شود.
مانند هر محصول جدی، Informatica نیز لحظات خنده‌داری دارد.
یک بار، در حالی که نوعی تصادف را مرتب می کردم، متوجه شدم که سیاهه های MRS به طرز عجیبی زمان وقایع را نشان می دهد.
دوگانگی زمانی در گزارش‌های MRS «بر اساس طراحی»
معلوم شد که مهرهای زمانی در قالب 12 ساعت بدون مشخص کردن AM/PM، یعنی قبل از ظهر یا بعد از ظهر نوشته می‌شوند. حتی یک برنامه در مورد این موضوع باز شد و یک پاسخ رسمی دریافت شد - اینگونه در نظر گرفته شده است ، علائم دقیقاً با این قالب در ورود به سیستم MRS نوشته شده است. یعنی گاهی اوقات فتنه ای در مورد زمان وقوع یک ERROR باقی می ماند...
برای بهترین ها تلاش کنید
امروزه انفورماتیکا یک ابزار نسبتاً پایدار است که برای مدیران و کاربران مناسب است و از نظر قابلیت ها و پتانسیل فعلی بسیار قدرتمند است. این نیازهای عملکردی ما را چندین برابر بیشتر می کند و عملاً اکنون در پروژه به روشی استفاده می شود که معمولی ترین و معمولی نیست. مشکلات تا حدی به نحوه کار مکانیسم ها مربوط می شود - نکته خاص این است که در مدت زمان کوتاهی تعداد زیادی رشته راه اندازی می شود که به شدت پارامترها را به روز می کند و با پایگاه داده مخزن کار می کند، در حالی که منابع سخت افزاری سرور تقریباً به طور کامل استفاده می شود. توسط CPU
اکنون به انتقال به Informatica 10.2.1 یا 10.2.2 نزدیک شده ایم که برخی از مکانیسم های داخلی را بازسازی کرده اند و وعده های پشتیبانی برای حذف برخی از مشکلات عملکرد و عملکردی که در حال حاضر داریم را پشتیبانی می کنند. و از نظر سخت افزاری با در نظر گرفتن ذخیره برای آینده نزدیک به دلیل رشد و توسعه فضای ذخیره سازی، انتظار سرورهایی با پیکربندی بهینه را برای ما داریم.
البته تست، بررسی سازگاری و احتمالاً تغییرات معماری در قسمت HA GRID وجود خواهد داشت. توسعه در انفورماتیکا ادامه خواهد داشت، زیرا در کوتاه مدت نمی توانیم چیزی را جایگزین سیستم کنیم.
و کسانی که در آینده مسئولیت این سیستم را بر عهده خواهند داشت قطعاً می توانند آن را به شاخص های اطمینان و عملکرد مورد نیاز ارائه شده توسط مشتریان برسانند.
مقاله توسط تیم مدیریت داده Rostelecom تهیه شده است
لوگوی فعلی انفورماتیکا
منبع: www.habr.com