زیرساخت های داده مدرن ETL را انجام نمی دهند

کسب و کار در زمان واقعی اتفاق می افتد، اما بسیاری از سیستم های تجاری اینطور نیستند. زمان آن رسیده است که پایگاه داده های سرویس گیرنده-سرور، انبارهای داده و فرآیندهای دسته ای را پشت سر بگذارید.

کسب و کارها ۲۴ ساعته هستند. این شامل همه چیز از وب سایت، دفتر پشتیبان، زنجیره تامین و غیره می شود. در زمان دیگری، همه چیز در دسته اجرا شد. حتی چند سال پیش، سیستم‌های عملیاتی متوقف می‌شدند تا داده‌ها در انبار داده بارگیری شوند و گزارش‌ها اجرا شوند. در حال حاضر گزارش ها در مورد وضعیت فعلی هستند. زمانی برای ETL وجود ندارد.

بسیاری از معماری فناوری اطلاعات هنوز بر اساس سیستم هاب و اسپیک است. سیستم‌های عملیاتی یک انبار داده را تغذیه می‌کنند که سپس سیستم‌های دیگر را تغذیه می‌کند. نرم افزار تخصصی تجسم گزارش ها و داشبوردها را بر اساس “انبار” ایجاد می کند. با این حال، این در حال تغییر است، و این تغییرات در کسب و کار نیاز به هر دو پایگاه داده و معماری سیستم برای انطباق دارد.

کپی های کمتر، پایگاه داده های بهتر

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

پایگاه های داده در حال تغییر هستند. پایگاه داده های رابطه ای اکنون قادر به مدیریت داده های بدون ساختار، اسناد و JSON هستند. پایگاه داده های NoSQL در حال حاضر حداقل از پشتیبانی تراکنشی برخوردار هستند. در همین حال پایگاه‌های داده SQL توزیع‌شده، یکپارچگی داده، داده‌های رابطه‌ای و مقیاس‌پذیری شدید را در عین حفظ سازگاری با پایگاه‌های داده و ابزارهای SQL موجود، فعال می‌کنند.

با این حال، این به خودی خود کافی نیست. خط بین سیستم های معاملاتی یا عملیاتی و سیستم های تحلیلی نمی تواند مرز باشد. یک پایگاه داده حداقل در بیشتر مواقع نیاز به رسیدگی به تعداد زیادی از کاربران و پرس و جوهای طولانی مدت دارد. برای این منظور، پایگاه‌های اطلاعاتی عملیاتی/تراکنشی قابلیت‌های تحلیلی را در قالب شاخص‌های ستونی یا قابلیت‌های MPP (پردازش انبوه موازی) اضافه می‌کنند. اکنون امکان اجرای پرس و جوهای تحلیلی بر روی برخی پایگاه های داده عملیاتی توزیع شده، مانند MariaDB Xpand (SQL توزیع شده) یا Couchbase (NoSQL توزیع شده) وجود دارد.

هرگز استخراج نشود

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

در بسیاری از موارد، پاسخ این است که چگونه داده ها در وهله اول جمع آوری می شوند. به جای ارسال داده ها به یک پایگاه داده و سپس کشیدن داده ها از دیگری، تراکنش می تواند برای هر دو اعمال شود. ابزارهای مدرنی مانند Apache Kafka یا Amazon Kinesis این نوع جریان‌گذاری داده‌ها را فعال می‌کنند. در حالی که این رویکرد تضمین می کند که داده ها بدون تأخیر به هر دو مکان می رسند، برای اطمینان از یکپارچگی داده ها به توسعه پیچیده تری نیاز دارد. با اجتناب از فشار کشش داده ها، هر دو پایگاه داده تراکنشی و تحلیلی را می توان همزمان به روز کرد و در صورت نیاز به پایگاه داده تخصصی، امکان تجزیه و تحلیل بلادرنگ را فراهم می کند.

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

پایگاه های داده قدیمی و جدید

پایگاه داده های سرویس گیرنده-سرور در دوره خود شگفت انگیز بودند. آنها تکامل یافتند تا از تعداد زیادی CPU و کنترلرها برای ارائه عملکرد به طیف گسترده ای از برنامه ها به خوبی استفاده کنند. با این حال، پایگاه داده های سرویس گیرنده-سرور برای کارمندان، گروه های کاری و سیستم های داخلی طراحی شده اند، نه اینترنت. آنها در عصر مدرن سیستم های مقیاس وب و وجود داده ها در همه جا کاملاً غیرقابل دفاع شده اند.

بسیاری از برنامه‌ها از پایگاه‌های داده‌های مختلف stove-pipe استفاده می‌کنند. مزیت شعاع انفجار کوچک است اگر یکی پایین بیاید. نقطه ضعف این است که همیشه چیزی خراب است. ترکیب پایگاه‌های داده کمتر در بافت داده‌های توزیع‌شده به بخش‌های فناوری اطلاعات اجازه می‌دهد تا زیرساخت داده قابل اعتمادتری ایجاد کنند که مقادیر متفاوتی از داده و ترافیک را با زمان خرابی کمتر مدیریت می‌کند. همچنین به این معنی است که وقتی زمان تجزیه و تحلیل داده ها است، کمتر داده می شود.

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

یک معماری بلادرنگ جدید

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

تغییر سخت است و زمان می برد. این فقط یک مشکل فنی نیست بلکه یک مسئله پرسنلی و لجستیکی است. بسیاری از برنامه ها با معماری های stovepipe به کار گرفته شده اند و جدا از چرخه توسعه بقیه زیرساخت های داده زندگی می کنند. با این حال، فشار اقتصادی، رقابت فزاینده، و مدل‌های تجاری جدید این تغییر را حتی در محافظه‌کارترین و سرسخت‌ترین شرکت‌ها تحت فشار قرار داده است.

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

اندرو سی. الیور مدیر ارشد بازاریابی محصول در MariaDB است.

—

New Tech Forum مکانی برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.