Notice: Undefined variable: img in /home/amarne/domains/amarnegar.com/public_html/modules/article.php on line 43
آمارنگر شرق | نگاه عمیق، روشنی راه، تصمیم درست | مهندسی داده
مهندسی داده

مهندسی داده

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

همانند دانشمندان داده، مهندسین داده کد می‌نویسند. آنها بسیار تحلیلی هستند و بسیار به بصری‌سازی داده‌ها علاقه‌مند هستند.

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

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

در شرکت‌های کوچکتر-که در آن زیربنای تیم علم داده هنوز شکل نگرفته، مهندسی داده وظایف و بار کاری آن را تقبل می‌کند. این شامل وظایفی مانند راه‌اندازی و اجرای سیستم‌های عاملی مانند Hadoop / Hive / HBase، Spark و … است.

در محیط‌های کوچکتر افراد تمایل دارند از خدمات ارائه شده توسط آمازون یاDatabricks استفاده کنند یا از شرکت‌هایی مانندCloudera یا Hortonworks حمایت کنند – که اساساً نقش مهندسی داده را با بستن قرارداد برون سپاری به شرکت‌های دیگر واگذار می‌کند.

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

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

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

 

ETL در حال تغییر است

ما همچنین تغییر رویکردی کلی از ابزارهای کشیدن و رها کردن ETL (Extract, Transform and Load) به سمت برنامه ریزی بیشتر را مشاهده کرده‌ایم. دانش فنی محصولات رایانه‌ای مثل Informatica، IBM Datastage، Cognos، AbInitio و یا مایکروسافت SSIS میان مهندسان اطلاعات مدرن رایج نیست و مهارت‌های کلی مهندسی نرم افزاری جایگزین آنها شده که همراه با درک سیستم‌های برنامه‌ریزی شده یا پیکربندی مانند Airflow، Oozie، Azkabhan یا Luigi است. همچنین برای مهندسان توسعه و مدیریت کار خود، امری معمول است.

دلایل مختلفی وجود دارد که نشان می‌دهد چرا قطعات پیچیده نرم افزاری با استفاده از ابزارهای کشیدن و رها کردن (‌drag & drop) توسعه نمی‌یابند: در نهایت “کد” بهترین انتزاع برای نرم افزار است. در حالی که بحث در این مورد فراتر از حدود این مقاله است، به راحتی می‌توان نتیجه گرفت که این دلایل برای نوشتن ETL نیز می‌توانند برای هر نرم افزار دیگری به کار بروند. کد امکان دستیابی به سطوح دلخواه انتزاعی را می‌دهد، اجرای عملیات منطقی به روش‌های آشنا را ممکن می‌سازد و به خوبی با کنترل منبع ادغام می‌شود. این حقیقت که ابزارهای ETL برای افشای رابط گرافیکی تکامل یافته‌اند، انحراف مسیری در تاریخ پردازش داده نمایان می‌کند، و قطعاً برای یک پست در وبلاگ می‌تواند بسیار جالب باشد.

 

تأکید می‌کنیم که انتزاعاتی که توسط ابزارهای ETL سنتی نمایش داده می‌شوند غیرکاربردی هستند. مطمئناً نیاز به استخراج و چکیده‌سازی پیچیدگی پردازش داده‌ها، محاسبات و ذخیره سازی وجود دارد. اما به نظر ما راه حل این نیست که موارد ابتدایی ETL (مانند منبع / هدف، جمع آوری ها، فیلتر کردن) را در قالب drag & drop نمایش بدهیم، لازم است که این انتزاعات در سطح بالاتری قرار بگیرند.

به عنوان مثال، یک مثال از انتزاعی مورد نیاز در یک محیط داد‌ه‌ی مدرن، در چارچوب آزمایشی تست A/B را در نظر بگیرید: همه‌ی آزمایش چیست؟ رویکرد‌های مرتبط چیست؟ چند درصد از کاربران باید در معرض آن قرار بگیرند؟ چه معیارهایی در هر آزمایش برای سنجش میزان تأثیرگذاری وجود دارد؟ چه زمانی آزمایش انجام می شود؟ در این مثال، ما چارچوبی داریم که ورودی دقیق و سطح بالا را دریافت می‌کند، محاسبات آماری پیچیده را انجام و نتایج محاسباتی را ارائه می‌دهد. ما انتظار داریم که اضافه کردن یک ورودی برای آزمایش جدید موجب انجام محاسبات اضافی و بدست آمدن نتایج جدید می‌شود. نکته مهم در این مثال این است که پارامترهای ورودی این انتزاع یک ابزار ETL سنتی نیست و ساختار چنین انتزاعی در یک رابط کشیدن و رها کردن قابل کنترل نیست.

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

 

مهارت های مورد نیاز

  • تسلط بر SQL: اگر انگلیسی زبان کسب و کار است،SQL زبان داده است. اگر انگلیسی خوب صحبت نکنید، چگونه می‌توانید در کسب و کار موفق باشید؟ در حالی که نسل‌های فناوری در حال پیر شدن هستند، SQL هنوز هم به عنوان یک زبان پردازنده اطلاعات در جایگاهی بالا و قوی قرار دارد. یک مهندس داده باید بتواند هرگونه درجه پیچیدگی در SQL را با استفاده از تکنیک‌هایی مانند “زیرمجموعه‌های مرتبط” و توابع پنجره نمایش دهد. ابتکارات SQL / DML / DDL به اندازه کافی ساده هستند که هیچ شکافی برای یک مهندس داده باقی نگذارند. فراتر از ماهیت آشکار SQL، مهندس داده باید توانایی خواندن و درک برنامه‌های اجرایی پایگاه داده را داشته باشد و چگونگی کارکرد شاخص‌ها، الگوریتم پیوستن مختلف و ابعاد توزیع شده در همه‌ی مراحل برنامه را درک کند.
  • تکنیکهای مدل سازی داده: برای یک مهندس داده، مدل‌سازی رابطه سازمانی باید یک رفلکس ذهنی-شناختی همراه با یک درک صحیح از نرمال‌سازی باشد و درک درستی از تقلید ناهنجاری‌ها داشته باشد. مهندس داده باید با مدل‌سازی ابعاد و مفاهیم مرتبط و زمینه واژگانی آشنا باشد.
  • طراحی ETL: نوشتن کارآمد، انعطاف پذیربودن و “تکامل” ETL امری کلیدی است. ما در حال برنامه ریزی برای گسترش این موضوع در یک پست وبلاگ دیگر هستیم.
  • پیشبینیهای معماری: مانند هر شخص حرفه‌ای در زمینه تخصصی، مهندس داده نیاز به درک سطح بالایی از ابزار، پلتفرم، کتابخانه‌ها و سایر منابع موجود دارد. مواردی مانند: خصوصیات، موارد مورد استفاده و ظرافت‌های پایگاه داده‌های مختلف، سیستم‌های محاسباتی، پردازنده‌های جریان محاسباتی، ستون‌های پیام، مدیران کار، فرمت‌های شماره‌گذاری، و سایر فن‌آوری‌های مرتبط. هنگام طراحی راه‌حل‌ها، او می‌بایست بتواند انتخاب‌های مناسب را برای اینکه چه فناوری‌هایی را استفاده می‌کند و چشم انداز در مورد چگونگی ایجاد آنها را با یکدیگر هماهنگ کند...

مهندسی داده
SQL
مدل سازی داده
ETL
علم داده
Big Data
شرکت تحقیقات بازاریابی در مشهد

نظرات کاربران


اگر تصویر خوانا نیست اینجا کلیک کنید