مهندسی داده و معماری BI چیست؟

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

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

نقش داده ها در تیم های داده و مجموعه مهارت های شما. با استفاده از ریاضی

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

یک مهندس داده (در تیم‌های BI) کسی است که تحلیلگران BI/تحلیلگران داده، دانشمندان داده، مدل‌های ML، محصولات داده، مدیران و کل شرکت را به داده‌های قابل اعتماد مجهز می‌کند. آنها با استفاده از ابزارهایی برای پردازش داده ها در مقیاس بزرگ، ایجاد، مدیریت و نظارت بر روال ها به این امر دست می یابند. آنها ابزارهایی مانند APIها و برنامه‌هایی را توسعه می‌دهند که فعالیت‌های کاربر را انتزاعی می‌کنند و استفاده از داده‌ها را برای همه بخش‌ها آسان‌تر می‌کنند و فرآیندهای شفاف و قابل حسابرسی را تضمین می‌کنند. آن‌ها از تکنیک‌هایی مانند مدل‌سازی داده‌ها، پیروی از تمام قوانین عادی‌سازی استفاده می‌کنند و از ابزارهای فعلی برای توسعه انبارهای داده مقیاس‌پذیر و کارآمد، دریاچه‌های داده و دریاچه‌های داده که از حداقل منابع ذخیره‌سازی و پردازش استفاده می‌کنند، استفاده می‌کنند.

در اکثریت قریب به اتفاق شرکت ها، تجزیه و تحلیل داده ها با استفاده از Excel و Google Sheets انجام می شود. به طور معمول، این یک کار تکراری است که وقت فرد را می گیرد و می تواند صرف کارهای دیگر شود. علاوه بر این، دارای نقاط ضعف مختلفی است، مانند عدم تجسم با نمودارها، که درک بزرگی داده ها و تصمیم گیری آگاهانه تر را برای افراد دشوار می کند. با توجه به اینکه اکسل مستعد خطاهای انسانی است، استفاده از آن به عنوان روش اصلی برای تجزیه و تحلیل داده ها یک نقطه ضعف قابل توجه است.

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

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

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

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

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

همانطور که شرکت‌ها، تیم‌ها و عملیات‌ها رشد می‌کنند، طبیعی است که این فرآیندهای قدیمی عقب بمانند و یک تیم BI شروع به تشکیل شدن می‌کند (یا حداقل باید). در این مرحله، با مطالعه نوع معماری مورد استفاده، وارد حوزه مهندسی داده می شویم. آیا ما یک انبار داده یا شاید یک داده دریاچه را اجرا خواهیم کرد؟ آیا از یک راه حل ابری استفاده خواهیم کرد یا یک راه حل داخلی؟ بودجه ما چه چیزی به ما اجازه توسعه می دهد؟ از کدام ابزارها برای نظارت روزانه KPI، PowerBI، Tableau یا گزینه دیگری استفاده خواهیم کرد؟ همه این سؤالات، از جمله، با همکاری سایر بخش‌ها، با در نظر گرفتن وضعیت فعلی، بافت تاریخی و فرهنگی شرکت، و مهارت‌هایی که افراد مستقیماً درگیر آن هستند، پاسخ داده می‌شود. اینها برخی از متغیرهای “بدیهی” هستند که باید در فرآیند برنامه ریزی یک مرکز عالی مهندسی داده در نظر گرفته شوند.

توسعه و ابزار

هنگامی که به این سؤالات مرتبط پاسخ داده شد، مراحل بعدی باید مستحکم، مبتنی بر متریک، به خوبی مستند شده و به خوبی طراحی شوند تا از فرآیندهای ETL/ELT قابل اطمینان اطمینان حاصل شود. توسعه خطوط لوله عمدتاً شامل انتقال اطلاعات از یک سیستم به سیستم دیگر است. شما می توانید یک ETL (Extract-Transform-Load) را مستقیماً در یک انبار داده در RDS خود یا یک فرآیند ELT (extract-load-transform) در دریاچه داده خود انجام دهید. شما ممکن است داده ها را از پایگاه داده تولید خود جمع آوری کنید یا از یک FTP از یک شرکت شریک برای غنی سازی پایگاه داده خود استفاده کنید. توسعه API برای سرویس‌های دیگر برای مصرف داده‌های تبدیل‌شده شما یا دسترسی دانشمندان داده به آن بسیار رایج است و مختص توسعه‌دهندگان بک‌اند نیست. انتخاب ابزارها را می توان در مرحله توسعه تعیین کرد، اما به طور کلی با شیوه های رایج همسو است. برای ارکستراسیون خط لوله، یک نامزد قوی Airflow است، یک چارچوب پایتون برای مدیریت روال‌ها. برای پردازش توزیع شده، PySpark و Spark را در اختیار دارید. برای یک دریاچه داده در محل، می توانید از MinIO استفاده کنید. برای انبار داده‌های شما، PostgreSQL با مدل‌سازی طرح‌واره ستاره‌ای یک انتخاب رایج است، اما اگر با جدول‌های واقعی و ابعاد متعدد مقیاس‌بندی کنید و طرح ستاره‌ای را غیرعملی‌سازی کنید، می‌توانید مدل‌سازی دانه‌های برف را انتخاب کنید. اگر در حال انجام خراش دادن داده‌ها هستید و می‌خواهید داده‌های خود را غنی کنید، می‌توانید از نرم‌افزار کم‌کد مانند IBM RPA استفاده کنید، یا اگر ترجیح می‌دهید با پایتون ادامه دهید، می‌توانید از scrapy، یک چارچوب عالی برای خزیدن وب استفاده کنید.

در آینده مقالات بیشتری در مورد MinIO و دریاچه های داده، جریان هوا و ارکستراسیون وظایف و پردازش توزیع شده با Spark خواهم نوشت.

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

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

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

از شما بسیار سپاسگزارم برای خواندن

نقش داده ها در تیم های داده و مجموعه مهارت های شما. با استفاده از ریاضی