به عنوان یک مهندس داده، از کارم لذت می برم، اما وقتی نوبت به یکپارچه سازی و مدیریت داده ها می رسد، کارهای زیادی وجود دارد که کاملا خسته کننده هستند. از بازسازی داده‌ها گرفته تا استفاده از نرم‌افزار برای رسیدگی به بازیابی فاجعه، گاهی اوقات ما به سادگی در حال غرق شدن هستیم. همانطور که می گویند، این یک کار سخت است، اما کسی باید آن را انجام دهد!
بازسازی داده ها
وقتی از ابتدا شروع به ساخت یک راه حل می کنید، با یک تخته سنگ تمیز روبرو هستید. زیرساخت آماده است، تمام داده‌ها کاملاً به شیوه‌ای تقریباً هنرمندانه مدل‌سازی شده‌اند و اکنون به شکلی زیبا و تمیز در جریان هستند.
با این حال، مشکلات به زودی شروع می شود. اساساً تحلیلگران دقیق و دانشمندان داده دست خود را بر روی خلقت باشکوه شما می گیرند. آنها مدام درخواست افزایش داده ها، ادغام منابع جدید داده ها و مدل های مختلف داده برای پرسیدن انواع مختلف سوالات را می کنند. روی شانه‌های شما می‌افتد، و شما احساس می‌کنید که به نوعی شخصاً مقصر هستید که از ایجاد ارزش مبتنی بر داده‌های شرکت خود جلوگیری می‌کنید، در حالی که آنها هیچ قدردانی از اثر هنری قابل توجهی که شما خلق کرده‌اید ندارند.
مدل‌سازی داده‌ها از مدل مفهومی به مدل منطقی پیشرفت می‌کند و دنیایی قوی از اشیاء داده و روابط آنها با سایر اشیاء داده را ایجاد می‌کند. عمدتاً این توانایی را برای تحلیلگران فراهم می کند تا سؤالات مورد نیاز خود را به روشی سریع و مقرون به صرفه و ساده بپرسند. دقیقاً ماهیت قوی آن، همراه با فراوانی تغییرات مورد نیاز است که چرخه بی پایان یکپارچه سازی، آماده سازی داده ها و مدل سازی را ایجاد می کند.
مقیاس بندی خوشه ها
الگوریتم های خوشه بندی عملی برای دستیابی به همگرایی به اسکن داده های متعدد نیاز دارند. برای پایگاه های داده بزرگ، این اسکن ها بسیار گران، دست و پا گیر و وقت گیر می شوند. آنها همچنین ظرفیت زیرساخت فیزیکی را افزایش می‌دهند و خطری را برای منابع کم‌تأمین ایجاد می‌کنند.
با توجه به اینکه معماری آنها بر روی یک سرور اجرا می شود، ماهیت مشکل ساز کلاسترهای مقیاس بندی با RDBMS بیشتر است. از نظر عملی، این بدان معناست که وقتی یک RDBMS نیاز به مقیاس دارد، باید سخت‌افزار اختصاصی بزرگ‌تر، پیچیده‌تر و گران‌تر با قدرت پردازش، حافظه و ظرفیت ذخیره‌سازی بیشتر خریداری کنید. همه این موارد مستلزم توقف طولانی مدت و تنظیمات برای ایجاد تغییر است.
مقیاس بندی خوشه ها در زیرساخت های ابری به طور کلی مشکل مقیاس پذیری را حل می کند. به عنوان مثال، مهم ترین مزیت BigQuery تغییر اندازه یکپارچه و سریع یک خوشه، تا مقیاس پتابایت است. برخلاف Redshift، نیازی به ردیابی و تجزیه و تحلیل مداوم اندازه و رشد خوشه در تلاش برای بهینه سازی اندازه آن برای مطابقت با الزامات مجموعه داده فعلی نیست.
مقیاس‌پذیری معماری Redshift به کاربران اجازه می‌دهد تا زمانی که منابعی از جمله حافظه و ظرفیت ورودی/خروجی افزایش می‌یابند، از افزایش عملکرد لذت ببرند. Panoply برای به دست آوردن بهترین ها برای پول خود، به طور یکپارچه دسته ها را بر اساس تقاضا مقیاس می دهد و اطمینان حاصل می کند که عملکرد انبار داده به خوبی با هزینه ها متعادل است.
پشتیبان گیری و بازیابی فاجعه
به طور سنتی، کسب‌وکارها چندین راه‌حل نرم‌افزاری را برای رسیدگی به بازیابی بلایا (DR)، پشتیبان‌گیری و بایگانی به‌عنوان بخشی از شیوه‌های حفاظت از داده‌های بزرگ‌تر ترکیب می‌کنند. این رویکرد برای مهندس داده ای که وظیفه مدیریت هر یک از این راه حل ها را بر عهده دارد، بسیار ناکارآمد است. همچنین یک رویکرد نسبتاً گران است. یک راه متفاوت برای مقابله با DR، استفاده از معماری ابری برای گردش‌های کاری ثانویه مانند پشتیبان‌گیری، بایگانی و بازیابی فاجعه (DR) است.
BigQuery به طور خودکار داده ها را تکرار می کند تا از در دسترس بودن و دوام آن اطمینان حاصل کند. با این حال، از دست دادن کامل داده ها به دلیل فاجعه کمتر از نیاز به بازیابی سریع و فوری، به عنوان مثال، یک جدول خاص یا حتی یک رکورد خاص است. برای هر دو هدف، Redshift به طور خودکار پشتیبان‌گیری‌ها را در S3 ذخیره می‌کند و به شما امکان می‌دهد تا در هر نقطه از زمان در نود روز گذشته مجدداً از داده‌ها بازدید کنید. در همه موارد، بازیابی شامل مجموعه‌ای از اقدامات است که می‌تواند بازیابی فوری را به یک عملیات طاقت‌فرسا و طولانی تبدیل کند.
ETL و آماده سازی داده
بارگذاری داده های خود به روشی تمیز و منطقی در معماری تجزیه و تحلیل نه تنها اولین گام در مدیریت داده ها است، بلکه قطعا یکی از مراحل مهم آن است. تفاوت در روش های بارگذاری می تواند بر مقیاس پذیری فرآیند و غنای داده های بارگذاری شده تأثیر بگذارد و در بیشتر موارد بخش هایی از داده های خام در واقع از بین می روند.
هنگام بارگذاری داده‌ها، معمولاً فکر می‌کنیم که فقط داده‌های مهم را بارگذاری کنیم، یعنی داده‌های واقعی را که می‌خواهیم تحلیل کنیم. مشکل این است که در بیشتر موارد (بیشتر موارد همه) هرگز نمی دانید در روز اول کدام داده برای تجزیه و تحلیل در آینده مهم خواهد بود و بنابراین آزمایشات فکری و آزمایش های طولانی درباره داده ها بارگذاری می شوند.
رفع انسداد داده ها با Panoply
اساساً، ETL و انبار داده باید عملکرد پروتکل غربالگری بودن را انجام دهند که در نهایت مجموعه داده های تمیزی را تولید می کند که بررسی دقیق آن برای برنامه های تحلیلی آسان است.
اغلب اوقات شما در نهایت نرم افزارهای پشتیبانی را روی تعداد زیادی سرور اجرا می کنید تا بتوانند داده ها را از منابع متعدد از جمله OLTP های مختلف ذخیره کنند.
با توجه به طیف گسترده ای از ناهماهنگی های احتمالی داده ها و حجم بسیار زیاد داده ها، پاکسازی داده ها به عنوان یکی از بزرگترین چالش ها در انبار داده ها در نظر گرفته می شود. تعدادی ابزار با عملکردهای مختلف برای پشتیبانی از وظایف ETL موجود است. حتی با این ابزارها، بخش قابل توجهی از کار تمیز کردن و تبدیل باید به صورت دستی یا توسط برنامه های سطح پایین انجام شود.
Snowflake از درخواست های همزمان کاربران از طریق انبارهای مجازی مختلف پشتیبانی می کند. می‌توانید فرآیندهای ETL یک شبه خود را بر روی منابع انبار کندتر و کم‌هزینه‌تر اجرا کنید و سپس پرس‌وجوهای موقتی را در زمان واقعی از طریق یک انبار قدرتمندتر در ساعات کاری فعال کنید. با این حال، با مقیاس Redshift و کارایی عملیاتی، ETL را می توان به عنوان یک پارادایم سفت و سخت و قدیمی نام برد.
با استفاده از مقیاس پذیری Redshift با Panoply، می توانید فرآیندهای ETL یک شبه را فراموش کنید. Panoply از فرآیند ELT پیروی می کند ، به موجب آن تمام داده های خام فوراً در زمان واقعی در دسترس هستند و تبدیل ها به صورت ناهمزمان در زمان پرس و جو اتفاق می افتد.
عیب یابی عملکرد
یک گودال بی انتها، یک پرتگاه، یک خلاء…. باید ادامه بدم؟ اگر سیستم کند است، تقریباً هر چیزی ممکن است مشکل داشته باشد. این می تواند مدل سازی ضعیف داده، نمایه سازی نامناسب، مشکلات شبکه، سخت افزار ذخیره سازی، اساساً هر چیزی باشد.
سپس، هنگامی که شروع می کنید، به خصوص در مورد مشکلی با یک ابر خصوصی یا راه حل های مدیریت نشده، مهندس داده یک گلوگاه را پاک می کند تا به گلوگاه دیگری برخورد کند. عیب یابی انبار داده می تواند کمی ترسناک باشد. گاهی اوقات حتی فهمیدن اینکه از کجا شروع کنیم می تواند دشوار باشد.
بیشتر از هیچ‌کدام، و ناامیدکننده‌تر از هر چیزی، حداقل از تجربه شخصی من، زمانی است که مشکل در نوع پرسش‌هایی است که توسط تحلیلگران غیرمسئول، مانند برخی SELECT *بر روی یک جدول بزرگ، اجرا می‌شوند. من سعی می کنم به عنوان بخشی از وظایف خود، دانش و آگاهی را در این مورد افزایش دهم. مسائل متداول دیگری که من می بینم در مورد نحوه ساختار داده ها در انبار است، به عنوان مثال در موردی که داده ها با جدول های فرعی زیادی مدل می شوند، تجزیه و تحلیل حتی بر روی مجموعه کوچکی از داده ها می تواند طولانی باشد.
وقت آن است که راه بهتری داشته باشیم
Panoply یک پلتفرم داده ابری است که برای دسترسی آسان به داده های مورد نیاز شما طراحی شده است. می‌توانید منابع داده را به هم متصل کنید، داده‌هایتان را به‌طور خودکار ذخیره کنید و آنها را به ابزار BI ارسال کنید، همه اینها تنها با چند کلیک. این کار زمان شما را آزاد می کند تا بتوانید روی آنچه واقعاً مهم است تمرکز کنید: پیشبرد کسب و کارتان.
آیا می خواهید در مورد مهندس داده بیشتر بدانید ؟ اینجا کلیک کنید
