محصولات ما

جهت مشاهده مسیر آموزشی خود از منوی مسیر های آموزشی اقدام کنید

مشاهده دوره های بیشتر

Loading…

آموزش ETL در اوراکل و ODI

آشنایی با ETL

ETL و هوش تجاری

ETL(ای تی ال) بخش مهمی از فرایندها و سیستم های هوش تجاری (BI) امروزی است. این فرایند فناوری اطلاعات است که از آن می توان داده های منابع مختلف را در یک مکان قرار داد تا به طور برنامه ای تجزیه و تحلیل و کشف بینشهای تجاری شود.

 

آشنایی با انبار داده (Data Warehouse) و کاربردهای آن

امروزه انبار داده (Data Warehouse) که به اختصار DW هم در منابع مختلف از آن یاد شده است، کاربرد فراوانی در صنعت و علوم جدید پیدا کرده است. با گسترش روزافزون داده‌ها و منابع ذخیره‌سازی مختلف داده، نیاز به ابزارها و روش‌هایی ایجاد شد که به کمک آن‌ها بتوان داده‌ها در جای بخصوصی ذخیره کرد تا مناسب عملیات پردازش و یا مصورسازی شوند. به این کار در اصطلاح انبار کردن داده‌ها گفته می‌شود و ابزارها و روش‌های مختلفی جهت انبارش داده در سال‌های اخیر به وجود آمده است.

انبار داده (Data Warehouse) چیست؟

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

راه غیر کاربردی برای این کار این است که هر گاه به وسیله‌ای احتیاج داشتید بروید و آن را از مغازه خریداری کنید که طبیعتا برای هر بار خرید باید مسافتی را طی کنید و زمان زیاد بگذارید. اما راه ساده و کاربردی این است که این وسائل را از مغازه‌های تامین کننده خریداری کنید و آن را در یک گوشه انبار کنید.

حالا وقتی نیاز به هر کدام از وسايل دارید، به انبار خود مراجعه می‌کنید و آن قطعه را برمیدارید. این یک مثال ساده از انبار کردن در دنیای واقعی بود. در دنیای داده‌ها و اطلاعات نیز، به همین صورت انبار کردن داده داریم که به آن Data Warehouse یا به اختصار DW نیز می‌گویند و در این درس به آن خواهیم پرداخت.

در درس هوش تجاری گفتیم که در یک سازمان نرم‌افزارهای مختلفی قرار دارد که هر کدام داده‌هایی را تولید می‌کنند و در فرآیند هوش تجاری بایستی از آن‌ها جهت ایجاد ارزش استفاده کنیم. مثلا بفهمیم کدام مشتریان ممکن است سرویس خود را تمدید نکنند و ریزش کنند. هر کدام از نرم‌افزارهای موجود در سازمان (و داده‌های تولید شده توسط آن‌ها) مانند مثال بالا یک مغازه هستند که داده‌های مختلفی دارند. اگر بخواهیم برای هر پرس و جو (Query) که به تحلیل ما کمک کند، به این نرم‌افزارها درخواستی دهیم، احتمالا وقت و زمان خود را هدر داده‌ایم. پس بهتر است داده‌ها را با توجه به موضوعی که می‌خواهیم تحلیل کنیم در یک مکان انبار کنیم. به این مکان انبار داده (Data Warehouse) می‌گویند.

در مورد انبار داده یک تعریف از آقای بیل اینمن (Bill Inmon) وجود دارد که بسیاری از منابع، آن را به عنوان تعریف مرجع قبول دارند:

انباره داده یک مجموعه‌ از داده‌های موضوع‌گرا (Subject Oriented)، مجتمع (Integrated)،نگهدار زمان‌های مختلف (Timevariying) و غیر فرَار (none-volatile) است که پشتیبان فرآیندهای تصمیم سازی مدیریتی است.

در این تعریف به ۴ویژگی در انبار داده اشاره شده است. اجازه بدهید تک تک این تعاریف را مورد بررسی قرار دهیم:

موضوع‌گرا (Subject Oriented): به این معنا است که انبار داده‌ای که شما می‌سازید بایستی در مورد یک موضوع مشخص (یا یک سری موضوع مشخص) باشد. مثلا یک فروشگاه می‌خواهد رفتار خریداران خود را بررسی کند. پس موضوع در این‌جا رفتار خریداران است. برای همین بایستی اطلاعاتی که در مورد رفتار خریداران در نرم‌افزارهای مختلف سازمان (مثلا CRM یا سیستم حسابداری) موجود است را در یک انبار داده جمع آوری کنید.

مجتمع (Integrated): این ویژگی بسیار واضح است. در واقع انبار داده به صورت تکه تکه در جاهای مختلف نیست و به صورت مجتمع در یک منبع ذخیره شده است. فرض کنید یک سیستم CRM و یک سیستم حسابداری دارید. یک خریدار در سازمان شما، با کد ملی در CRM مشخص می‌شود و همین شخص با شماره شناسنامه در سیستم حسابداری مشخص می‌شود. اما بعد از پردازش و بارگزاری داده‌ها در انبار داده، این شخص فقط بایستی با یک شماره مشخص شود (مثلا یک ID خاص) تا به اشتباه دو نفر مستقل برداشت نشود.

نگهدار زمان‌های مختلف (Timevariying): به این معنا که در انبار داده، داده‌های قدیمی‌تر نیز ذخیره می‌شوند. مثلا اگر اطلاعات فروش ۱ماه اخیر را خواستیم می‌توانیم از انبار داده پیدا کنیم. اگر اطلاعات فروش ۱سال پیش را نیز خواستیم بایستی در انبار داده موجود باشد.

غیر فرَار (none-volatile): به این معنا که اگر داده‌ای در انبار داده ثبت شد، دیگر امکان تغییر آن وجود ندارد. برای مثال در یک پایگاه داده عادی (غیر انبار داده‌ای) اگر یک شخص آدرس خود را عوض کرد، آدرس جدید جایگزین آدرس قبلی می‌شود، ولی در انبار داده سابقه آدرس‌های شخص ذخیره می‌شود و تغییرات آدرس یک شخص به صورت جدید‌تر در انبار داده ثبت می‌شود و آدرس‌های قبلی نیز در انبار داده جهت بررسی موجود می‌باشد.

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

  

لایه های معماری انباره داده

لایه پایینی:

سرور معماری انبار داده، شامل سرور پایگاه داده رابطه‌ای است که از ابزارهای  Back-End و دیگر ابزارهای کاربردی برای انتقال اطلاعات از منابع مختلف داده‌ای مانند پایگاه داده‌های تراکنشی و غیره، به لایه پایینی استفاده می‌شود. این ابزارهای کاربردی و ابزارهای  Back-End عملکردهای Extract، Clean ،Load و Refresh را انجام می‌دهند.

لایه میانی:

لایه‌ی میانی یک سرور OLAP را در اختیار می‌گیرد که به وسیله‌ی آن داده‌ها را به یک ساختار مناسب‌تر تبدیل می‌کند تا بتوان به کوئری‌های پیچیده بر روی داده‌ها و تحلیل آن‌ها دسترسی داشت. این سرور به دو روش می‌تواند کار کند:

الف) Relational OLAP (ROLAP): یک سیستم مدیریت پایگاه داده رابطه‌ای گسترده است. ROLAP عملیات بر روی داده‌های چند بعدی را به عملیات‌های رابطه‌ای استاندارد تبدیل می‌کند.

ب) Multidimensional OLAP (MOLAP): که به طور مستقیم داده‌های چند بعدی و عملیات را اجرا می کند.

لایه بالایی:

لایه بالایی، لایه client یا front-end است. این لایه، ابزارهایی را برای استفاده در زمینه‌های تجزیه و تحلیل داده، پرس وجو (کوئری) گزارش‌گیری و داده کاوی فراهم می‌آورد.

نمودار زیر نشان دهنده معماری سه لایه‌ای انباره داده می‌باشد.

 

استقرار هوش تجاری

 

مدل‌های انباره داده

از منظر معماری‌های انباره داده، ما سه مدل انباره داده داریم:

  1. انباره داده مجازی
  2. دیتا مارت
  3. انباره داده سازمانی

انباره داده مجازی

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

دیتا مارت

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

انباره داده‌های سازمانی

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

شِماهای(Schema) ستاره‌ای و گلوله برفی

شمای ستاره‌ای و شمای گلوله برفی دو روش برای ساختار دادن به انباره داده می‌باشد.

  • شمای ستاره‌ای یک مخزن داده‌ای متمرکز دارد و ذخیره‌سازی آن در جدول‌های fact table انجام می‌شود. این شِما، جدول fact table را به یک سری از جداول dimension tables که نرمال‌سازی نشده‌اند، تقسیم می‌کند. fact table شامل داده های تجمعی است و برای اهداف گزارش‌دهی مورد استفاده قرار می‌گیرند، در حالی که dimension tables،داده‌های ذخیره شده را توصیف می‌کند.
  • طراحی نرمال‌سازی نشده، دارای پیچیدگی‌های کمتری است، به این دلیل که داده‌ها به صورت گروه‌بندی شده هستند. جدول fact table تنها از یک لینک برای پیوستن (Join) به هر جدول dimension table استفاده می‌کند. طراحی انباره داده با شِمای ستاره‌ای، نوشتن کوئری‌های پیچیده را آسان‌تر می‌کند. نمایی از این شِما در شکل زیر قابل مشاهده است.

پیاده سازی انباره داده

 

  • شِمای گلوله برفی متفاوت است به این دلیل که داده‌ها به صورت نرمال‌سازی شده هستند. نرمال‌سازی به معنای سازماندهی موثر داده‌ها است تا همه وابستگی‌های داده به خوبی تعریف شوند و هر جدول شامل حداقل انحرافات باشد. در این نوع ساختار جداول dimension tables به صورت واحد هستند بنابراین شاخه‌ها درون dimension tables جداگانه قرار می‌گیرد. شِمای گلوله برفی از فضای دیسک کمتری استفاده می‌کند و موجب می شود حفظ یکپارچگی داده بهتر صورت بگیرد.عیب اصلی این روش پیچیدگی کوئری‌ها برای دستیابی به داده‌هاست.(برای به دست آوردن داده‌ها، معمولا در کوئری‌ها باید از multiple joins استفاده کرد) نمایی از این شِما در شکل زیر قابل مشاهده است.

 

پیاده سازی هوش تجاری

 

ETL چیست؟

ETL مخفف Extract Transform and Load است که به معنای استخراج، پالایش و بارگذاری اطلاعات می‌باشد. از ETL در زمان ساخت انبار داده‌ها (Data Warehouse) استفاده می‌شود. فرایندی که به موجب آن اطلاعات از یک یا چند منبع مختلف جمع آوری، پالایش و در نهایت در انبار داده بارگذاری می‌شود.

Extract:

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

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

در مرحله اولی، داده‌ها از منابع مختلف، توسط فرآیند استخراج (Extract)، استخراج شده و در مخزنی به نام محل استقرار (Staging Area) قرار می‌گیرد. در واقع در مرحله استخراج داده، که مرحله اول ETL است، داده‌ها از منابع داده‌ای استخراج شده و در Staging Area ذخیره می‌شوند. مرحله استخراج باعث می‌شود داده‌هایی که در منابع مختلف بوده و دارای سیستم عامل‌های متفاوت و ساختار بازیابی گوناگون هستند جمع‌آوری شوند تا بتوان بر روی آن‌ها عملیات پردازشی را انجام داد.

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

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

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

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

مرحله استخراج اطلاعات معمولا در سطح منابع اطلاعاتی انجام می­شود به ویژه اگر منبع اطلاعاتی مورد نظر، پایگاه ­داده باشد. در سیستم­ های قدیمی، روش متداول برای استخراج اطلاعات، تولید فایل­ های متنی از روی اطلاعات می­باشد. در سیستم­ های جدیدتر از امکاناتی مانند API، OLE DB وODBC ها برای این امر استفاده می­شود.

 

 

Transform:

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

  • بررسی کیفیت داده‌ها (Verify data quality): کیفیت داده‌ها به وسیله پرسش‌هایی از قبیل سوالات زیر مورد بررسی قرار می‌گیرند:
    • آیا داده‌ها کامل هستند (مواردی مورد نیازمان را پوشش می‌دهند)؟
    • داده‌ها صحیح هستند یا اشتباهاتی دارند؟ اگر اشتباه هستند علت اشتباهات چیست؟
    • آیا ارزش‌های گم شده در داده وجود دارد؟ اگر اینگونه است آن‌ها چگونه نمایش داده می‌شود؟ عموماً در کجا اتفاق افتاده است؟

 

  • پاک‌سازی داده‌ها (Clean data): بالا بردن کیفیت داده‌ها نیازمند انتخاب تکنیک آنالیز می‌باشد. این انتخاب شامل پاک کردن زیر مجموعه‌ای از داده‌های نامناسب و درج پیش‌فرض‌های مناسب می‌باشد.

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

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

  • شکل دادن داده‌ها (Construct data): این قسمت شامل عملیات ویژه‌ای مانند تولید خصوصیت‌های مشتق شده، تولید رکوردهای جدید و کامل یا مقادیر تبدیل شده از خصوصیات موجود می‌باشد.
  • ادغام داده‌ها (Integrate data): روش‌هایی وجود دارد که به وسیله آن اطلاعات از چند جدول ترکیب شده و رکوردهای جدید یا مقادیری جدیدی ایجاد می‌شود.

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

    یکپارچه سازی داده­ها از سه فاز کلی تشکیل شده است:

    شناسایی فیلدهای یکسان: فیلدهای یکسان که در جدول‌های مختلف دارای نام‌های مختلف میباشند.

    شناسایی افزونگی‌های موجود در داده‌های ورودی: داده­های ورودی گاهی دارای افزونگی هستند. مثلاً بخشی از رکورد در جدول دیگری وجود دارد.

    مشخص کردن برخورد‌های داده­ای: مثالی از برخوردهای داده­ای، یکسان نبودن واحدهای نمایش داده­ای است. مثلاً فیلد وزن در یک جدول بر حسب کیلوگرم و در جدولی دیگر بر حسب گرم ذخیره شده است.

  • قالب بندی داده‌ها (Format data): منظور از قالب بندی داده‌ها، تغییر و تبدیل قواعد اولیه داده موردنیاز ابزار مدل سازی می‌باشد.

 

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

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

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

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

ممکن است داده ها دارای مقادیر Blank باشند یا برای برخی از داده ها مقادیر غیر منطقی درج شده باشد (به طور مثال عدد ۷ رقمی برای کد ملی مشتری) که در این صورت می توان برای مدیریت آن ها تدابیری اندیشید.

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

در این مرحله باید قوانین و جداول کمکی (Lookup Tables) جهت استاندارد سازی مقادیر بهره گرفت. همچنین در این مرحله تبدیل واحد ها به یکدیگر صورت می پذیرد. به طور مثال ممکن است در جایی فروش به صورت دلاری ذخیره شده باشد و در جای دیگر به صورت ریالی که باید در این مرحله استاندارد سازی صورت پذیرد.

همچنین بررسی صحت و اعتبار سنجی داده ها در این مرحله نیز صورت می پذیرد. به طور مثال سن نباید بیشتر از ۲ عدد باشد یا کد ملی نمی تواند کمتر یا بیشتر از ۱۰ رقم باشد.

اگر نیاز به ادغام ستون ها یا جدا سازی ستون ها و تبدیل آن ها به چندین ستون باشد در این مرحله صورت می پذیرد. همچنین عمل چرخاندن جداول (Pivot OR Unpivot) در این مرحله صورت می پذیرد.

مرحله دوم تبدیل (Transformation) ، این مرحله که قلب اصلی فرآیند ETL به شمار می‌رود در Staging Area انجام می‌شود تا انجام عملیات (بعضا سنگین) مزاحم انبارداده و یا منابع داده‌ای منبع نباشد. حتما توجه دارید که داده‌هایی که در منابع داده‌ای مختلف هستند به صورت خام ذخیره شده‌اند و قبل از این‌که در انبارداده ذخیره شوند نیاز به تغییراتی دارند. با این تغییرات و تبدیل‌ها، داده‌ها آماده انبار کردن می‌شوند. مثلا اگر بخواهید نام و نام خانوادگی یک شخص را همراه با پسوند این شخص در یک فیلد انبار کنید و هر کدام از این‌ها در مخزن جدایی باشد، در این مرحله (مرحله تبدیل) بایستی این تغییرات را انجام دهید.

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

تأکید و سفارش زیاد در این بخش مقیاس‌پذیری و سرباره زمانی است که در حین محاسبات و پردازش بر روی‌داده‌ها صورت می‌گیرد.

 

Load:

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

س از بارگذاری داده‌ها نوبت به استفاده از اطلاعات ذخیره شده در انبار داده‌ها است. این کار توسط ابزارهای گزارش گیری (Reporting Services)، داده‌کاوی و OLAP انجام می‌شود.

انواع Loading

Full Load

در این نوع بارگذاری کلیه داده ها از انبار داده حذف و دوباره عمل بارگذاری از ابتدا صورت می گیرد. این عمل معمولا برای بارگذاری اولیه جداول انبار داده مورد استفاده قرار می گیرد.

Incremental Load

در این نوع از بارگذاری تنها تغییرات اعمال شده در پایگاه داده به انبار داده منتقل می شود. در واقع هنگامی که فرآیند ETL به صورت شبانه اجرا می شود داده های جدید و تغییر یافته وارد انبار داده می شود.

یکی از بهترین و قویترین ابزارها برای عملیات ETL، ابزار SSIS است که استفاده از آن سرعت و دقت در عملیات را بالا می‌برد.

برای درک بهتر ETL، فرض کنید شما یک تاجر چایی هستید. بایستی چایی را از منابع آن، یعنی باغ‌ها و مزارع مختلف چایی استخراج کنید. در مرحله استخراج (Extract) کردن، چایی‌ها را از باغ‌ها و مزارع استخراج می‌کنید و قبل از انبار کردن در سوله‌هایی مخصوص قرار می‌دهید (مانند Staging Area). در این سوله‌ها چایی‌های خام را به چایی‌های فرآوری شده تبدیل (Transform) می‌کنید و بعد از بسته بندی آن‌ها را در انبار‌های چایی، بارگزاری (Load) می‌کنید تا آماده عملیات فروش و صادرات شوند. این‌جا هم شما سه مرحله ETL را برای فروش چایی انجام داده‌اید تا داده‌های خود را آماده انبار کردن کنید.

 

 

ELT در انبار داده و تفاوت آن با ETL

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

در فرآیند ELT قسمت بارگزاری (Load) و تبدیل (Transformation) را جا به جا شده است. در واقع داده‌ها از منابع مختلف داده به انبار داده (Data Warehouse) بارگزاری می‌شوند و سپس در آن‌جا (اگر نیاز باشد) عملیات تبدیل (Transformation) بر روی آن‌ها انجام می‌شود. ELT زمانی استفاده می‌شود که حجم داده‌ها بسیار زیاد باشد. در واقع در ELT، محل استقرار حذف شده و داده‌ها مستقیماً از منابع داده به انبار داده منتقل می‌شوند.

داده‌هایی به صورت NoSQL ذخیره شده‌اند و حجم بالایی نیز دارند، معمولا از روش ELT استفاده می‌کنند. برای مثال در اکوسیستم Hadoop برای بارگزاری داده‌ها می‌توان از ELT استفاده نمود تا حجم زیادی از داده‌ها را از منابع مختلف به انبار داده بارگزاری کند و سپس اگر نیاز باشد، عملیات تبدیل و تغییرات را (در همان انبار داده) بر روی داده‌ها انجام دهد

تفاوت انبار داده و پایگاه داده چیست؟

وظیفه اصلی سیستم‌های پایگاه داده، پشتیبانی از تراکنش‌های آنلاین و پردازش پرس و جو است. این سیستم‌ها، سیستم پردازش تراکنش آنلاین (OLTP) نامیده می‌شوند و بیشتر عملیات روزمره یک سازمان را پوشش می‌‌دهند.

وظیفه اصلی سیستم‌های پایگاه داده، پشتیبانی از تراکنش‌های آنلاین و پردازش پرس و جو است. این سیستم‌ها، سیستم پردازش تراکنش آنلاین (OLTP) نامیده می‌شوند و بیشتر عملیات روزمره یک سازمان را پوشش می‌‌دهند.

از سوی دیگر انبار داده که بعنوان نوع خاصی از پایگاه‌های داده معرفی می‌شود به کاربران یا knowledge workers خدماتی در نقش تحلیلگر داده و تصمیم گیرنده ارائه می‌دهند. چنین سیستمهایی قادر هستند داده‌ها را در قالبهای گوناگون برای هماهنگی با نیازهای مختلف کاربران، سازماندهی کرده و ارائه دهند. این سیستم‌ها با نام سیستم‌های پردازش تحلیلی آنلاین(OLAP) نیز شناخته‌ می‌شوند.

  • از لحاظ مدل‌های داده‌ای؛ پایگاه‌های داده برای مدل OLTP بهینه سازی شده که براساس مدل داده رابطه‌ای امکان پردازش تعداد زیادی تراکنش همروند_ که اغلب حاوی رکورد‌های اندکی هستند_ را دارد. اما در انبارهای داده که برای پردازش تحلیلی آنلاین طراحی شده‌اند امکان پردازش تعداد کمی‌ پرس و جو پیچیده برروی تعداد بسیار زیادی رکورد داده فراهم می‌شود. سرورهای OLAP هم می‌توانند رابطه‌ای  باشند ( ROLAP ) وهم می‌توانند چند‌بعدی باشند (MOLAP ).
  • از لحاظ کاربران؛ کاربران پایگاه داده کارمندان دفتری و مسئولان می‌باشند در حالی که کاربران انبار داده مدیران و تصمیم‌گیرنده‌ها هستند.
  • از لحاظ عملیات قابل اجرا برروی آنها؛ عملیاتی که برروی پایگاه داده‌ها صورت می‌‌گیرد، عموماً شامل عملیات ‌بهنگام سازی است در حالی که عمل خواندن از انبار، عمده عملیات قابل اجرا بر روی انبار داده را تشکیل می‌دهد.
  • از لحاظ مقدار داده‌ها؛ مقدار داده‌های یک پایگاه داده در حدود چند مگابایت تا چند گیگابایت است در حالیکه این مقدار در انبار داده در حدود چند گیگابایت تا چند ترابایت است.

در بسیاری از شرکت ها حجم زیادی از داده های مهم غیر قابل دسترس و در نتیجه بلا استفاده هستند. نتایج تحقیقات نشان می دهد، دو سوم کسب و کار ها یا به ندرت از داده ها استفاده می کنند یا هیچ استفاده ای نمی کنند. تحقیقات دیگری نشان می دهد که ۵۰ درصد مدیران اعتقاد دارند که سازمان آن ها بر اساس داده و تحلیل رقابت نمی کنند، که دلیل عمده آن حبس شدن داده در سیستم های قدیمی و بلا استفاده است.

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

 

چرا سازمان ها به ETL نیاز دارند؟

دلایل مختلفی برای نیاز به ETL وجود دارد که برخی از آن ها به شرح زیر است:

ETL به سازمان ها کمک می کند که داده های خود را در یک انبار داده واحد جمع آوری کنند و بر اساس تحلیل تمام داده های خود تصمیمات کلیدی و داده محور اتخاذ کنند. در واقع تحلیل بدون استفاده از تمامی داده های موجود در سازمان به نتایج مناسب منجر نخواهد شد. داده هایی که در سیستم های قدیمی یا کم استفاده گرفتار شده اند با فرآیند ETL به جریان می افتند و وارد فرآیند تحلیل می شوند.

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

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

ابزارهای ETL

ابزارهای بسیاری در زمینه ETL و ساخت انبار داده وجود دارد که مهمترین آن ها عبارتند از:

Informatica – PowerCenter

IBM – Infosphere Information Server

Oracle Data Integrator(ODI)

Microsoft – SQL Server Integration Services (SSIS)

Talend – Talend Open Studio for Data Integration

Pentaho Data Integration

SAS – Data Integration Studio

SAP – BusinessObjects Data Integrator

سایت etltool به تازگی مقایسه‌ای را (بر اساس نظرات کاربران خود) بین ابزارهای مختلف ETL موجود در بازار انجام داده و نتایج آن را منتشر نموده است.
ابزارهای مورد نظر در ۴ گروه مورد مقایسه قرارگرفته‌اند:
گروه اول) ابزارهایی که صرفا برای عملیات ETL مورد استفاده دارند.
گروه دوم) ابزارهایی که برای یکپارچه‌سازی داده‌های بانک‌های اطلاعات مختلف کاربرد دارند.
گروه سوم) ابزارهای یکپارچه‌ساز داده با کاربرد در Business intelligence
و گروه چهارم) ابزارهای خاص برای موارد خاص
ابزارهای مورد مقایسه را می‌توانید در تصویر زیر مشاهده نمایید:

 

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

طي فرآيند ETL داده­ها از منابع اطلاعاتي مورد نياز موجود در سازمان يا خارج از آن مانند، پايگاه­هاي داده، فايل­هاي متني، سيستم­هاي قديمي و صفحات گسترده (Spread Sheets) استخراج شده و تبديل به اطلاعاتي سازگار با فرمت معين مي­شوند و سپس در يک مخزن اطلاعاتي که در اغلب اوقات يک DWH است، قرار داده مي­شوند. براي انجام ETL نياز به تخصص­هاي مختلفي چون تجزيه و تحليل تجاري، طراحي پايگاه داده و برنامه­نويسي وجود دارد.

پيش از انجام فرآيند ETL ابتدا بايد منابع اطلاعاتي که قرار است داده­هاي آنها به DWH منتقل شوند، شناسايي شوند، مقصد آنها در DWH مشخص شوند و تبديلاتي که بايد بر آنها انجام شود تا واردDWH شوند، تعيين شوند. نحوه نگاشت اطلاعات به صورت اوليه، بايد در مرحله جمع­آوري نيازها و مدل­سازي اطلاعات انجام شود. اطلاعات جزيي تر مربوط به نحوه نگاشت داده ها از منابع اطلاعاتي اوليه به DWH در مرحله طراحي و پياده­سازي ETL مشخص مي­شود.

  • شناسايي منابع اطلاعاتي: پايگاه­هاي داده mainframe مانند:VSAM ،DB2 ،IBMS Adabas و ISAM پايگاه­هاي داده client-server مانندInformix  و Oracle پايگاه­هاي اطلاعاتي PC مانند Access، صفحات گسترده مانند Excel نمونه­هايي از مهمترين انواع منابع اطلاعاتي را تشکيل مي­دهند. در برخي سيستم­ها شناسايي منابع اطلاعاتي به سادگي مکان­يابي سرورهاي پايگاه­داده سيستم است. در برخي سيستم­هاي پيچيده­تر، براي شناسايي اين منابع بايد اعمالي نظير تعريف دقيق فيلدهاي اطلاعاتي و تعريف ارزش­هاي اطلاعاتي مربوط به اين فيلدها انجام شود.
  • تعِيين مقصد داده­ها: براي تمامي اطلاعات موجود در منابع اطلاعاتي شناسايي شده بايد مکاني در DWH در نظر گرفته شود. داده هاي اطلاعاتي در قسمت­هاي مختلفDWH قرار مي­گيرند.
  • نگاشت داده­هاي اطلاعاتي از مبدأ به مقصد: نحوه نگاشت داده­ها از مبدأ به مقصد و تغييراتي که بايد بر داده­هاي اوليه اعمال شود تا به فرمت مناسب براي DWH درآيند بايد تعيين شوند. اين تغييرات موارد زير شامل مي­شود:

o       خلاصه سازي اطلاعات.

o       تغيير اطلاعات.

o       کدگشايي اطلاعات کد شده.

o       ايجاد تغييرات لازم براي هماهنگ سازي داده­هاي اطلاعاتي مشابه که در چند منبع اطلاعاتي مختلف وجود دارند.

اطلاعات مربوط به نحوه نگاشت اطلاعات در نقشه اطلاعات (Data Map) نگهداري مي شود.

چگونه فرایند ETL را انجام دهیم؟

در طی سالیان مختلف ابزارها، سرویس‌ها و فرایندهای مختلفی توسعه یافته اند تا سازمان ها با چالش داده ای خود کنار بیایند. برای نمونه اگر  قصد داریم که یک پروژه مصورسازی داده را با Power BI انجام دهیم، با استفاده از کامپونت power query، فرایند ETL به صورت کامل روی داده ها انجام می‌شود. سرویس یکپارچه‌سازی SQL Server  (SSIS) و زبان TSQL نیز  به ما در فرایند ETL کمک خواهد کرد. زبان‌های برنامه نویسی مثل پایتون و R نیز در فاز پالایش داده می‌توانند استفاده شوند.

چرا ETL مهم است؟

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

از طرفی نباید این نکته را از یاد برد که یکی از مراحل پیاده سازی هوش کسب و کار (BI)، در هر سازمانی ETL است.

 

 

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

  1. هنگامی که با انبار داده‌های سازمانی (اطلاعات در حالت استراحت) استفاده می‌شود ETL زمینه‌های تاریخی عمیقی برای کسب و کار فراهم می‌آورد.
  2. با ارائه یک نمایه تلفیقی، ETL باعث می‌شود که تجزیه و تحلیل و گزارش داده‌ها و ابتکارات در ارتباط با آن‌ها، برای کاربران کسب و کار آسان‌تر شود.
  3. ETL می‌تواند بهره‌وری حرفه‌ای داده‌ها را بهبود ببخشد؛ زیرا این پروتکل‌ها رمزهای پردازش شده را مجددا مورد استفاده قرار می‌دهد که این امر باعث می‌شود داده‌ها را بدون نیاز به مهارت‌های فنی برای نوشتن کد یا اسکریپت انتقال داد.
  4. ETL در طول زمان تکامل یافته است تا از نیازهایی که در ارتباط با یکپارچگی برای مواردی مانند جریان داده‌ای بروز می‌کنند، پشتیبانی کند.
  5. سازمان‌ها به ETL نیاز دارند تا داده‌ها را با هم تجمیع کنند، از دقت داده‌ها اطمینان حاصل کنند و حسابرسی مورد نیاز برای انباره داده‌ها، گزارش‌دهی و تجزیه و تحلیل را فراهم آورند.

ETL چگونه کار می کند؟

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

ساخت ETL با پردازش دسته‌ای

از طریق پردازش زیر شما می‌توانید یک ETL ایجاد نماید.در این مدل از ETL پردازش و انتقال به صورت دسته‌ای از منابع پایگاه داده به منابع انباره داده صورت می‌گیرد.برای ساخت ETL با روش پردازش دسته‌ای به صورت زیر عمل می‌کنیم:

  1. داده‌های مرجع

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

  1. استخراج از منابع داده‌ای

پایه‌ی موفقیت در مراحل بعدی ETL، استخراج داده‌ها به صورت درست است. بیشتر سیستم‌های ETL ترکیبی از داده‌ها از منابع داده‌ای مختلف هستند، که هر کدام از منابع، سازماندهی داده‌ای و فرمت خود را دارند.(که شامل پایگاه دادهای رابطه‌ای، پایگاه داده‌های غیر رابطه‌ای،XML ، JSON ، CSV، فایل‌ها و .. می‌باشند) استخراج موفق ، داده‌ها را به یک فرمت واحد تبدیل می‌کند تا پردازش استاندارد باشد.

  1. اعتبارسنجی داده‌ها

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

  1. تبدیل داده‌ها

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

  1. مرحله‌ی نمایش داده‌ها در پایگاه داده

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

  1. انتشار داده‌ها در انبار داده

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

 

·         ساخت ETL با پردازش جریان داده‌ای

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

امروزه ابزارهای پردازش جریان داده‌ای زیادی در دسترس هستند که برخی از آن‌ها در زیر آمده است:

Apache Samza, Apache Storm, and Apache Kafka .

 

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

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

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

 

مقدمه  (ODI (Oracle Data Integrator

ODI به عنوان ابزاری مناسب برای فعالیتهای ETL و ELT توسط شرکت Oracle ارائه شده است. در این سند سعی شده است تا مراحل نصب و آمادهسازی، ایجاد پروژه جدید در محیط ODI ،کار با توپولوژیها، mappingها و Agentها مورد بررسی قرار گیرد. الزم به ذکر است که سند پیشرو صرفا مروری مقدماتی بر مفاهیم و کلیت فعالیتها در ODI Oracle است و به منظور آموزش حرفهای سندهای Manual User و Manual Developer که توسط شرکت Oracle ارائه شده است، راهگشا خواهد بود

نصب

به منظور نصب ODI باید توجه داشت که این محصول نیاز به پایگاه دادهای برای نگهداری اطلاعات مربوط به خود دارد، البته این پایگاه داده میتواند غیر از پایگاه داده اوراکل هم باشد. بعد از فرآیند نصب این محصول، باید به ایجاد repository برای ایجاد محیط کاری پرداخت و در فرآیند ایجاد repository است که با در اختیار قرار دادن
اطلاعات مربوط به اتصال به پایگاه داده به همراه نام کاربری و رمز عبور برای کاربری که قابلیت dba را دارد، مطابق با نظر کاربر چندین کاربر برای نگه داری اطلاعات مختلف ODI ایجاد میشود.
به طور کلی این محصول در دو قالب Enterprise و Standalone قابلیت نصب را دارد، به منظور نصب این محصول در حالت Enterprise نیاز است تا Oracle Fusion Middleware نصب شده باشد و محل نصب odi نیز Oracle_HOME مربوطه باشد. تفاوت های این دو نسخه شامل امکان ایجاد agent های JEE میشود که در بخش مربوط به agent ها مورد بررسی قرار می گیرد.
به طور کلی دو فرآیند نصب در این بخش موجود است، گام اول نصب ODI Studio است که به سادگی قابل انجام است و در گام بعدی ایجاد repository است که با استفاده از RCU (Repository Creation Utility) در محل نصب شده انجام می شود. در ادامه به نحوه ایجاد Master, Work Repository پرداخته شده است.
برای انجام این کار با ورود به بخش Oracle_HOME و در شاخه oracle_common\bin هم برای ویندوز و هم برای لینوکس اسکریپت اجرایی به نام RCU موجود است. پس از اجرای این اسکریپت اجرای محیط گرافیکی برای ایحاد ریپوزیتوری در اختیار شما قرار داده می شود، که امکان یک ریپوزتوری جدید یا حذف یک ریپوزیتوری موجود را فراهم می آورد. تصویر زیر صفحه مربوط به این محیط گرافیکی را نمایش می دهد

 

با ادامه فرآیند، در صفحه بعد امکان انتخاب ایجاد یا حذف ریپوزتوری وجود دارد. در قسمت ایجاد ریپوزیتوری امکان ایجاد و یا تولید اسکریپت، موجود است. با انتخاب گزینه اول در گام بعدی به معرفی کاربری با دسترسی
DBA می پردازیم:

 

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

 

در این بخش نام کاربر )نام اسکیما( و رمز عبور برای هر بخش لازمه معرفی می شود و با توجه به دسترسی DBA برای کاربری که قبلا معرفی کرده ایم، این اسکیماها ایجاد می شوند. تصاویر زیر مراحل بعدی ایجاد یک ریپوزیتوری Master و Work را به نمایش می گذارد. این مقادیر به صورت پیش فرض هستند، اما در صورت امکان
می توان مقادیری متناسب برای آن ها انتخاب کرد.

 

 

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

 

 

 

اطلاعات ارائه شده در تصویر بالا بر حسب تنظیماتی است که در فرآنید تولید یک ریپوزتوری انجام شده است. نام کاربری و رمز عبور برای شمای در نظر گرفته شده در پایگاه داده و انتخاب Work repository با توجه به نامی که برای آن در نظر گرفته شده است و در نهایت تنها المان مهم انتخاب نام کاربری SUPERVISOR « است که پسورد آ در بخش ایجاد ریپوزتوری توسط کاربر انتخاب شده است.
پس از ایجاد اتصال امکان ایجاد پروژه ها و فعالیت های مربوطه توسط محیط ODI فراهم می شود. علاوه براین امکان ایجاد repository های work دیگر نیز در محیط ODI وجود دارد. برای این کار باید کاربری در پایگاه داده ایجاد شود و سپس دسترسی های به آن اختصاص داده شود. پس از آن می توان به شکل زیر اقدام به ایجاد work repository کرد.

 

با توجه به سادگی و تکراری بودن، فرآیندهای بعدی ایجاد work repository جدید فاکتور گرفته شده است.

روال کاری یک پروژه در ODI

به طور کلی مراحل یک پروژه در ORACLE ODI STUDIO در گام های زیر خلاصه می شود:
۱ – ایجاد توپولوژی فیزیکی )برای همه منابع و مقاصد داده(
۲ – ایجاد توپولوژی منطقی و برقراری ارتباط بین بخش فیزیکی و منطقی با استفاده از مفهوم کانتکست
۳ – ایجاد مدل داده برای توپولوژی های منطقی ایجاد شده
۴ – استفاده از امکانات طراحی شده ) Procedure, Package و Mapping ( به منظور ایجاد فرآیند انتقال و تبدیل
۵ – تبدیل فرآیندهای طراحی شده به Scenario و Load Plan
۶ – ایجاد و اجرای agent
۷ – معرفی سناریوها و Load Plan های مربوطه به Agent برای اجرای آنها )قابلیت زمانبندی(
۸ – استفاده از بخش Operator برای بررسی روند اجرا و کشف خطاهای احتمالی در ادامه هر بخش به صورت اجمالی مورد بررسی قرار می گیرد و توضیح مربوط به مفاهیم موجود در هر بخش با توجه به نیاز توضیح داده شده است.

ایجاد توپولوژی فیزیکی

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

 

 

 

پس از ایجاد یک دیتا سرور می توان یک اسکیمای فیزیکی را به شکل زیر اضافه کرد.

 

 

 

همانطور که در تصویر بالا مشاهده میشود این اسکیمای فیزیکی مشخص می کند که شمای اصلی چیست، شمای فعالیتها چیست و نام گذاری جدوال تولید در فرآیند ETL چگونه است. همچنین کدگذاری متن ) Charset ( برای متون به چه شکلی است. پس از ایجاد این اسکیماهای فیزیکی نوبت به ایجاد توپولوژی منطقی است. یکی از امکانات دیگر این بخش امکان Import/Export گرفت از دیتا سرورهایی است که تعریف شده است.

 

 

ایجاد توپولوژی منطقی و برقراری ارتباط با بخش فیزیکی

در ODI فعالیت های لازمه در لایه منطقی تعریف می شوند. این لایه نیز مانند لایه فیزیکی وابسته به نوع تکنولوژی است، اما در فعالیت های مربوط به تولید مدل داده، این لایه منطقی است که مورد استفاده قرار می گیرد. لایه منطقی به خودی خود فعالیت خاصی را انجام نمی دهد، اما با توجه به نگاشتی که در یک context تعریف می
شود به یک لایه فیزیکی مربوط می شود. Context در واقع مشخص کننده نگاشت بین بخش فیزیکی و بخش منطقی است و می توان در یک پروژه چندین کانتکست مختلف داشت، اما در لحظه اجرا است که نوع کانتکست را مشخص می کنیم. برای مثال می توان با تعریف دو کانتکست توسعه و محصول نهایی، به سادگی مراحل توسعه را با جداول مربوط به مرحله توسعه و مرحله محصول را با توجه به جداول فیزیکی مربوط به محصول نهایی به اشیای موجود در لایه منطقی نگاشت داد و این کار به سادگی در مرحله اجرا و با انتخاب کانتکست انجام می شود.
شکل زیر کانتکست را به نمایش گذاشته است:

 

شکل بالا نگاشت بین شمای منطقی و شمای فیزیکی را نمایش می دهد. شکل زیر نحوه تولید شمای منطقی را به نمایش گذاشته است:

 

 

همانطور که در تصویر بالا مشخص شده است صرفا با تعیین یک نام و نحوه نگاشت آن در کانتکست های مختلف، شمای منطقی ایجاد می شود. تنها نکته در این بخش این است که نوع تکنولوژی فیزیکی و منطقی لزوما یکسان است، اما در کانتکست های مختلف فرآیند نگاشت یک شمای منطقی به شماهای فیزیکی متفاوت باشد.
ایجاد مدل داده در این گام داده های موجود در ساختارهای مختلف که درون شمای منطقی قرار دارند تعیین می شوند. برای مثال در صورتی که شمای منطقی ما Oracle DB باشد داده های موجود به شکل جدول خواهند بود و در صورتی که سرور داده از نوع File Server باشد، این داده ها به صورت فایل خواهند بود. در این بخش با ایجاد پوشه بندی مدل داده هایی برای هر شمای منطقی ایجاد می کنیم. لازم به ذکر است که این داده ها )جداول/فایل( باید چه در مبدا و چه در مقصد به صورت فیزیکی موجود باشند و در این بخش هم شی Model ای بر مبنای آنها ایجاد شود. ماژول Reverse Engineering در این بخش می تواند اطلاعات مربوط به این اشیا را به صورت اتوماتیک به مدل اضافه کند. برای مثال برای یک جدول مدلی در این بخش ایجاد می کنیم با استفاده از ماژول Reverse Engineering می توانیم تمامی Constraint ها، ساختار ستونها و … را به صورت اتوماتیک ایجاد کنیم. شکل زیر نحوه ایجاد یک مدل داده را به نمایش می گذارد. به طور کلی هر مدل در اینجا مترادف با یک شمای منطقی است و هر دیتا سورس در آن مترادف با یک جز از آن شمای منطقی خواهد بود.

 

 

نحوه استفاده از ماژول Reverse Engineering برای اخذ اطلاعات دیتا سورس هم در شکل زیر به نمایش در آمده است:

 

برای چک کردن صحت ایجاد دیتا مدل و دیتا سورس ها می توان با استفاده از View Data داده های موجود در آن ها را چک کرد و درست بودن فرآیند اتصال و مدلسازی مطمئن شد

 

ایجاد فرآیند انتقال داده و تبدیل

پس از تعریف مدل داده برای ورودی ها و خروجی های فرآیند ETL گام بعدی در این قسمت ایجاد رویکرد تبدیل دادههای ورودی به خروجی های مورد نیاز و قرار دادن آنها با مکانیزمی صحیح در مقاصد داده است. برای این کار امکاناتی با نام Procedure, Package, Mapping در نظر گرفته شده است. علاوه بر این مواردی مانند Variable هم
وجود دارند که به منظور افزایش قدرت فرآیند در این سه مورد استفاده می شوند. برای استفاده از این امکانات اولین گام ایجاد پروژه است. نحوه ایجاد پروژه جدید در ODI Studio به شکل زیر است:

 

 

پس از ایجاد پروژه، برای تبدیلاتی که از نظر مفهومی با هم در ارتباط هستند، فولدرهایی ایجاد می شوند. و در هر فولدر پکیجها، پروسیجرها و مپینگ هایی را می توان ایجاد کرد.

 

ایجاد و استفاده از Package :

این بخش بخ صورت گرافیکی امکان انجام فعالیت های سطح بالا را فراهم می آورد و نسبت به Procedure و mapping به نظر کم کاربردتر می آید. در این بخش می توان امکان انجام و عدم انجام فعالیت را به صورت مجزا مورد توجه قرار داد و در صورت موفقیت آمیز بودن یا نبودن رویکرد متفاوت اتخاذ کرد. شکل زیر نحوه ایجاد
package را به نمایش می گذارد.

 

ابزارهای موجود در ایجاد Package در بخش toolbox مشخص است. امکان استفاده از variable ها در این بخش ایجاد for و if را فراهم می آورد. )با استفاده از setVariable, checkVariable و …(. از امکانات دیگر این بخش امکان Export, Import گرفتن به صورت یک روال، امکان ارسال ایمیل انجام موفق و غیرموفق و …. است.

 

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

 

در شکل زیر هم گام ها مشخص می شود و کدهایی مطابق نوع ورودی و خروجی هر گام تعیین می شود.

 

در هر گام هم می توان مشخص کرد که آیا در صورت عدم موفقیت خطا تبدیل به اخطاز شود و کار ادامه یابد یا کلا با پیغام خطا متوقف شود. توضیحات مربوط به سایر آپشنهای مربوط به هر گام نیز در سندهای مربوطه موجود است.
ایجاد و استفاده از Mapping :
Mapping یکی از مهمترین بخش های ایجاد فرآیند ETL است. که به صورت گرافیکی امکان ایجاد بسیاری از فرآیندهای مربوط به انتقال را فراهم می آورد. شکل زیر نحوه ایجاد یک Mapping را به نمایش می گذارد.

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

نکته قابل توجه در این بخش این است که ریز فعالیت انجام شده در بخش physical قابل مشاهده است. دلیل این امر استفاده پنهانی است که در بخش logical انجام می شود و در بخش physical به سادگی قابل مشاهده است. برای مثال در این تبدیل که از منبع فایلی به منبع پایگاه داده انتقال می یابد، از ماژول دانشی انتقال فایل به پایگاه داده استفاده می شود. شکل زیر نمایش بخش physical را در شکل زیر مشاهده می کنید.

تبدیل فرآیندهای طراحی شده به Scenario و Load Plan موارد گفته شده که نحوه انتقال را به صورت فرآیندی انجام میدهد، همگی مواردی هستند که قابلیت اجرا را
ندارند. برای اجرای آنها چه در محیط توسعه ) ODI Studio ( و چه در محیط عملیاتی این اشیا و امکانات تبدیل به کدهایی اجرایی میشوند. این کدهای اجرایی توسط اجرا کننده هایی با نام Agent مشخص می شوند که در بخش بعد مورد بررسی اجمالی قرار گرفته است. اما منظور از بخش اجرایی سناریوها و پلان اجرایی است. سناریو به ازای هر Procedure, Mapping و Package ارائه می شود ولی Load Plan مجموعه ای از این سناریوها را به صورت چیدمانی درختی برای اجرای کلی آماده می کند. در واقع هر زمان که فعالیتی در Oracle ODI Studio اجرا می شود، به صورت اتوماتیک و موقت سناریو اجرایی فراهم می آید. اما در فاز عملیاتی باید به ازای موارد مورد نیاز سناریوهایی دائمی تولید شوند و بر اساس روند اجرایی و عملیاتی load plan مربوطه ایجاد شود. برای ایجاد سناروی از هر نوع به شکل عمل می شود. در شکل زیر از یک Mapping سناریویی ساخته شده است اما برای Procedure و Package هم به همین روال است.

سپس سناریو ایجاد شده در زیربخش سناریو در شی مربوطه موجود خواهد بود:

بخش دیگری که تمام سناریوها در آن قابل مشاهده است به شکل زیر است:

سناریوها، قابلیت دریافت متغیرهای موجود برای اجرا را دارد. علاوه براین امکان تعیین زمان بندی اجرا نیز برای این سناریوها موجود است.بخش بعدی Load Plan است که همانطور که گفته شد، سناریوهای مختلف را بر حسب یک ساختار درختی به صورت یک کلیت اجرا می کند. برای ایجاد یک Load Plan به شکل زیر اقدام می کنیم:

برای ایجاد Load Plan بخش تعریف گامها مطرح است. در هرگام سناریویی مطابق با تعریف درخت ایجاد می شود. به طور کلی یک بخش مجازی root وجود دارد که زیر مجموعهی آن از ۴ نوع نود می توان ایجاد کرد. این ۴ نود به شکل زیر است.

نود Run Scenario Step در زیر شاخه خود به اجرای سناریویی مطابق با تعیین کاربر می پردازد. اما سه نود دیگر برای ایجاد روال درختی فرآیند ایجاد می شوند و نمی توانند در ساختار درخت، نود برگ باشند. Serial Step برای اجرای سریالی نودهای زیر مجموعه به کار می رود. Parallel Step برای اجرای موازی زیر مجموعه های خود به
کار می رود. Case Step و زیر مجموعه های آن که شامل When و Else است برای ایجاد ساختار شرطی در درخت اجرا در Load Plan است. بخش Restart مشخص کنند این است که در صورت fail شدن هر نود چه نود برگ و چه نود شاخه، چه اتفاقی در فرآیند کلی و فرآیندهای زیر شاخه آن بیفتد. نمونهای از ساختار درخت اجرایی را در شکل زیر مشاهده می کنید که در آن دو سناریو در قالب یک اجرای سریالی ایجاد شده اند.

Load Plan ها و Scenario مورد بحث در بخش بعد و با معرفی Agent ها می توانند قابلیت اجرایی داشته باشند.
ایجاد و اجرای agent همانطور که در بخش قبلی مورد بررسی قرار گرفت، Agent ها به عنوان اجرا کنندهی Scenario ها و Load Plan ها مطرح هستند. به طور کلی Agent یک process است که می تواند به یکی از سه نوع زیر ایجاد و طبقه بندی شود:
۱ – Standalone Agent : این نوع Agent ها هیچ نیازی به Weblogic ندارند و به صورت مجزا اجرا و مدیریت می شوند.
۲ – Collocated Agent : این نوع Agent از کتابخانه های مشترک موجود در Weblogic استفاده می کنند ولی به صورت مجزا اجزا و مدیریت می شوند.
۳ – JEE Agent : این نوع Agent ها به صورت یک جز در محیط Weblogic قرار می گیرند و امکان مدیریت، اجرا و توقف آنها در محیط weblogic فراهم می آید.
لازم به ذکر است که در صورتی که نوع نصب ODI ، به صورت standalone بوده باشد صرفا نوع اول این agent ها را می توان ایجاد کرد، اما برای نصب enterprise می توان دو نوع دیگر را نیز ایجاد کرد.
برای ایجاد یک Agent باید با توجه به اسکریپت اجرایی واقع در زیر شاخه محل نصب ODI و در پوشه common\bin با نام config.cmd / config.sh است، اقدام کرد. پس از اجرای اسکریپت مربوطه فرآیند تولید یک Agent شروع می شود و در طول نصب انتخاب نوع agent ، محل نصب آن و مواردی از این قبیل تعیین می گردد. علاوه بر این در طول فرآیند نصب، اطلاعات ریپوزیتوری ای که agent در حیطه کاری آن عمل می کند از کاربر پرسیده خواهد شد. شکل های زیر روال نصب یک agent از نوع standalon را به نمایش گذاشته است.

در صورتی که ODI نصب شده از نوع Enterprise باشد، در شکل زیر سه نوع agent قابل انتخاب است، اما شکل زیر برای نسخه standalone تهیه شده است.

اطلاعات مربوط به JDK در این قسمت گرفته می شود. باید توجه کرد که نسخه JDK با نسخه ای که agent به آن نیاز دارد یکسان باشد.

 

اطلاعات ریپوزیتوری در این بخش گرفته می شود.

در ادامه نام Agent و پورتی که برای اجرا به آن اختصاص داده می شود مورد توجه قرار می گیرد.

سایر موارد در ادامه شامل کانفیگ خاصی نخواهد بود و نصب و ایجاد agent به سادگی پایان می پذیرد.
در ادامه این بخش نحوه اجرای agent و معرفی سناریو و load plan برای اجرا به آن، مورد توجه قرار می گیرد.برای اجرای agent به محل نصب آن که در گام اول مشخص کردیم می رویم )برای agent های JEE از weblogicاستفاده می شود ولی در اینجا نوع agent مورد نصب از نوع standalone است و روش کاری مختص آن در ادامه توضیج داده شده است(. در محل نصب agent فایل اجرایی agent.cmd را اجرا می کنیم )به شکل زیر( و منتظر لاگی به شکل زیر می مانیم. لازم به ذکر است که نام و پورت در موقع نصب داده شده و در اینجا همان باید وارد میشود.

 

برای بار اول شروع یک agent کمی طول می کشد، اما برای دفعات بعدی این کار به سرعت انجام می شود. پس از شروع یک agent به صورت یک پروسه، باید در محیط ODI یک Physical Agent و یک logical agent مطابق آن ایجاد کرد. برای ایجاد این دو مورد همانند تصاویر زیر عمل می کنیم.

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

معرفی سناریوها و Load Plan های مربوطه به Agent برای اجرای آنها در ادامه پس از ایجاد یک agent در صورت بالا بودن پروسس مربوط به آن می توان فرآیند اجرای یکی فرآیند که به صورت سناریو یا load plan است را می توان توسط آن اجرا کرد.
برای اجرا یک سناریو در یک agent به شکل زیر می توان عمل کرد:

برای اجرای یک Load Plan با استفاده از یک agent نیز به شکل زیر می توان اقدام کرد.

استفاده از بخش Operator برای بررسی روند اجرا و کشف خطاهای احتمالی بخش میانی در ODI Studio به نام Operator است که در آن تمامی فرآیندهای اجرا با توجه به دسته بندی های مختلف و در قالب زمانی قابل بررسی است. برای مثال برای بررسی موفقیت یا عدم موفقیت مربوط به یک Load plan که توسط یک agent اجرا شده است، می توان هم از طریق بخش مربوط به load plan در قسمت operator و هم از طریق بخش agent در زبانه مربوطه اقدام بررسی را انجام داد. اطلاعات مربوط به خطا در صورت بروز آن نیز در این قسمت قابل بررسی است و از طرف دیگر امکان مشاهده لاگ هر قسمت به صورت مرتب شده در این
زبانه فراهم آمده است. شکل زیر نمونه ای از کاربرد بخش operator برای بررسی انجام Load plan را برای یک agent نمایش می دهد.

همانطور که در شکل زیر مشاهده می شود به صورت مرتب شده ای اطلاعات هر بخش در این زبانه قابل مشاهده است، این اطلاعات شامل زمان اجرا، زمان اتمام، تعداد تغییرات و در صورت وجود خطا اطلاعات مربوط خطا است.

 

 

اوراكل ، فنآوری Sunopsis ETL را كه در پائیز گذشته خریداری كرده ، طوری ارتقا داده است كه نیازهای SOA و مدیریت داده‌های اصلی و نیز نگهداری (Warehousing) داده‌ها و انتقال داده‌ها را نیز بر آورده كند . تسلط بر این ابزار آن قدرها آسان نیست. ولی برای سرمایه گذاری در زمینه ی آموزش ، گزینه ی خوبی است.
در ماه اكتبر گذشته ، اوراكل ، Sunopsis و محصول Active Integration Platform (AIP) آن را كه شامل زیر مجموعه‌ای از امكاناتی است كه به عنوان Data Conductor فروخته می‌شوند ، خریداری و در ماه اكتبر ، اولین نسخه ی ارتقا یافته ی این محصول ETL گرا [۱]را با امكانات پیشرفته یكپارچه‌سازی برنامه عرضه كرد . نام و نسخه ی این محصول تغییر یافت تا با خط تولید مدیریت داده‌های اوراكل سازگار باشد.
این محصول كه اكنون Oracle Data Integrator v ۱۰.۱.۳ (ODI) نامیده می شود ، معماری و كاركرد Sunopsis AIP را حفظ كرده و چند تغییر ارتقا دهنده ی درخور توجه نیز در آن داده است كه مهمترین آن ها ، بهبود قابلیت ادغام با برنامه‌های Service-Oriented Architecture (SOA) است . ODI ، تبادل اطلاعات بین برنامه‌ها را خودكار می‌كند .

اوراكل این محصول را در چهار زمینه ی كلیدی ارتقا بخشیده است :

● نگهداری داده‌ها و هوش كسب و كار[۲] SOA Master Data Management (MDM) انتقال(Migration)
پس از كار با ODI در محیط آزمایش و گفت و گو با كاربران فراوان آخرین نسخه ی Sunopsis ، به این نتیجه رسیدیم كه ODI با معماری ساده ای که دارای حداقل نیازمندی سخت‌افزاری است ، به هر چهار نیاز به خوبی پاسخ می‌دهد . ابزارها و ساختار ODI ، مدیریت كردن آن را نسبتاً ساده می‌كند ، به ویژه وقتی كه افرادی از بخش های مختلف سازمان بخواهند در كل پروژه ، نقش داشته باشند.
در اینجا لازم است به دو مطلب توجه کرد : اول اینكه ، ODI برای تبدیل داده‌ها از رویكرد قوانین كسب و كار استفاده می‌كند. به این ترتیب كه شما ساختارها و قوانین تبدیل را تعریف می‌كنید و ODI ، كد لازم و مناسب برای فنآوری های داده‌ ای مبداء و مقصد را ایجاد می‌كند . دوم اینكه ، ODI به سرور میانجی نیاز ندارد و داده‌ها مستقیما بین سرورهای مبدا و مقصد جا به جا می‌شوند . این امر سبب حذف نیاز به حركت در شبكه برای داده‌ها می شود و نیز به فنآوری پایگاه داده ی سرور مبداء یا مقصد امكان می دهد که تبدیلات لازم را در مورد داده‌ها انجام دهد.

● نگاهی به معماری
برای سازگاری با دامنه ی وسیعی از سكوها ، قسمت عمده ی ODI با جاوا پیاده‌سازی شده است . ODI حاوی مؤلفه‌های زمان اجرا و زمان طراحی است كه از مجموعه ی مشتركی از مخزن های فراداده‌ای بهره می برند. چند میانجی و API از ادغام با برنامه های بیرونی از جمله برنامه‌های SOA و سیستم های سنتی زمان‌بندی كارها پشتیبانی می‌كنند.
ODI ، چندین میانجی كاربری اصلی دارد. میانجی Topology Manager برای تعریف فنآوری‌های دستیابی به داده‌ها و محل ذخیره‌سازی سطح بالای داده‌ها به صورت فیزیكی و منطقی (كه مبداء و مقصد جابه جایی و تبدیل داده‌ها در پروژه‌هایی كه ایجاد می‌كنید ، خواهند بود) به كار می‌رود .

هر فنآوری داده‌ای پشتیبانی شده (مثلاً پایگاه داده ، فایل معمولی ، فایل صفحه گسترده و ساختار داده XML) یك Knowledge Module (KM) از پیش برنامه‌ریزی شده مربوط به خود دارد . هر KM به همراه یك لایه ی اتصال مناسب مانند JDBC یا JMS ، كد لازم برای كار با آن فنآوری را ارائه می‌كند. ODI همچنین دارای SQL عام و JMS Knowledge Module است و API هایی دارد كه برای ایجاد Knowledge Module برای سرویس های داده‌ای و دیگر فنآوری‌های اختصاصی به كار می‌روند.
میانجی كاربری Designer كه برنامه‌نویسان و توسعه‌دهندگان ، بیشتر وقت خود را در آن صرف خواهند كرد ، برای ارائه ی اسكیمای[۳] تفصیلی و جریان داده‌هایی كه برای كار ارزش حیاتی دارند ، به كار می رود . در این میانجی، Model ها برای توصیف ساختار داده‌ها ، جدول ها ، ستون‌ها ، محدودیت ها و … به كار می‌روند. Project (پروژه) برای توصیف چگونگی استفاده از این ساختار داده‌ها .

در یك پروژه ، یك Interface ایجاد می‌كنید تا برای توصیف چگونگی بارگذاری داده‌ها و تبدیل آن ها از یك یا چند مخزن ذخیره‌سازی داده‌ها در مبداء به یك مخزن ذخیره‌سازی در مقصد استفاده شود . از تركیب Interface ها و Procedure ها ، ابزارها و اشیای دیگر ، Package به دست می‌آید كه بزرگترین شیء قابل اجرای ODI است .پس از تكمیل این مراحل ، نسخه ی كامپایل شده Interface ها ، Procedure ها یا Package ها كه Scenario نام دارند در Repository ذخیره می‌شود.
Scenario ، واحدی است كه برای اجراء ، زمان‌بندی می‌شود . توانایی ایجاد چندین Context به شما امكان می‌دهد تا به سرعت ، Project ها و Scenario های خود را به مخزن داده‌های فیزیكی (مثلا بین مخزن داده ی ایجاد و توسعه و مخزن داده ی تولید) اختصاص دهید.
از میانجی كاربری Operator برای زمان‌بندی و مدیریت اجرای كارها استفاده می شود . میانجی كاربری Security ، كنترل تفكیك شده‌ای بر دستیابی اشخاص به یك پروژه و برای انجام كارهایی که مجاز به انجام آن هستند ، ارائه می كند . یك میانجی تحت وب سبك به نام Lightweight Designer به شما امكان می‌دهد تا بر اجرای كارها از راه دور نظارت کنید و برای اصلاح مشكلات عملیاتی ، اقدام‌های اولیه را انجام دهید.

● کار با ODI

پس از مدتی کار کردن با ODI ، چند موضوع برایم روشن شد . یكی از این مسائل آن بود كه به سرعت نمی‌توان بر این محصول تسلط پیدا كرد . ولی برای اهداف خاص پروژه و آموزش مقدماتی ، می توان آنچه را كه برای انجام كار لازم است ، یاد گرفت . فكر می‌كنم كه بیشتر برنامه‌نویسان در ظرف چند روز بتوانند با معماری و میانجی های كاربری ODI آشنا شوند و كار كنند. آن هایی كه سیستم های ETL را با استفاده از روشهای غیر سیستماتیک پیاده‌سازی كرده‌اند ، سطح جداسازی ODI را تحسین خواهند كرد . این سطح به شما امكان می‌دهد بدون اینكه زیاد نگران جزئیات برنامه‌نویسی باشید ، بر توصیف آنچه می‌خواهید انجام دهید ، تمركز كنید.
نصب ODI آسان است .
ODI برای آسان كردن منحنی یادگیری شما ، یك محیط آزمایشی با Test Repository و یك Demonstration Repository حاوی اشیای پایگاه داده‌ها و فایل های از پیش تعریف شده نصب می‌كند . یك اسكریپت Getting Started به من كمك كرد بفهمم كه چگونه با ODI كار كنم . دانش مقدماتی SQL نیز لازم است ، زیرا برای تعریف محدویت‌ها و تبدیل‌ها باید از دستورهای SQL استفاده كرد . امكانات اعتبارسنجی داده‌ها ، مجموعه ای از داده‌های غیر معتبر ایجاد می‌كند كه می‌توانید آن‌ها را تصحیح كنید و دوباره مورد استفاده قرار دهید . برای ایجاد Interface می‌توانید از كشیدن (drag) جدول های مبداء و مقصد از Model های خود استفاده كنید.
به این صورت ، ODI به شکل خودكار ، ستون‌های جدول های مبداء و مقصد را كه نام یكسانی دارند به یكدیگر نگاشت می‌كند و اعتبار دستورهای SQL شما را بر اساس سرور ، می سنجند . Expression Editor ، نمونه دستورهای SQL را ارائه می‌كند تا در نحو دستوری آن ها به شما كمك ، و تعریف تبدیل داده‌ها را آسان كند.
برگه Business Rules به افرادی كه از داده‌ها آگاهی دارند ، امكان می‌دهد تا تبدیلات ستون ها را تعریف كنند . یك ایجاد كننده SQL ، میانجی را تكمیل می‌كند .
قسمت عملیات ODI ، انعطاف زیادی دارد . بعد از اینكه عناصر پروژه را ایجاد كردید ، با كشیدن و رها كردن این عناصر می‌توانید آن ها را در یك Package با یكدیگر تركیب كنید . تصویر سمت چپ ، یك پكیج كامل را نشان می‌دهد كه دارای یك Procedure و چند Interface است كه ظرف چند دقیقه ایجاد شده‌اند. یك كلیك راست ، اولین مرحله را آغاز می‌كند . ابزارهای OK و Non-OK به شما امكان می‌دهند مشخص كنید كه در صورت موفقیت یا عدم موفقیت ، چه مرحله‌ای اجرا شود .
با Designer نیز می توانید یك پكیج را اجرا كنید. برای پیگیری روند پیشرفت آن می توانید به میانجی كاربری Operator بروید . همان طور كه در شكل نشان داده شده است ، Operator به شما امكان می‌دهد تا مراحلی را كه ODI برای هر Interface ایجاد كرده و نیز جزئیات خطاهائی را كه ممكن است رخ دهد ، مشاهده كنید.
مرحله ی بعدی این است كه Package را كامپایل ، و به یك Scenario تبدیل كنید. Scenario كه در یك Repository ذخیره می‌شود ، واحد اجرایی در محیط تولید است . Scenario را می‌توان برای اجرا زمان بندی كرد ، به Repository دیگری منتقل كرد ، از یك CLI عرضه شده و یا در Context های دیگر اجرا کرد تا بتواند با مخزن داده‌های فیزیكی مختلف كار كند.
با استفاده از یك Repository دست نخورده ، من خود یك برنامه ایجاد كردم ،جای داده‌ها را از یك SQL Server تغییر دادم و یك نسخه ی تغییر یافته از آن را با سه جدول ، روی یك SQL Server دیگر ایجاد كردم . برای انجام این كارها از مثال های اسكریپت دمو استفاده كردم . در پایان ، این برنامه به خوبی اجرا شد.
همچنین ODI را به طور كامل و روی سیستم ویندوز ۲۰۰۳ كاملاً خالی و تازه نصب كردم و با استفاده از مستندات ، یك Master Repository روی SQL Server ۲۰۰۵ ایجاد كردم . بدون استفاده از مستندات ، نمی‌توان خیلی پیش رفت . البته با اینكه مستندات سودمند بودند ولی به جزئیات نپرداخته بودند .
پیغام خطاهایی كه ODI ارائه می‌دهد ، مفیدند ولی در هنگام مشكل ، راه‌حل های خوبی ارائه نمی‌دهند.به طور كلی ، مستند سازی پروژه‌های عظیم ، یك ضرورت است . ODI ، مستندات پروژه‌ها و اجزای آن ها را به فرمت PDF و در چند سطح از نظر جزئیات ایجاد می‌كند . این روش خوبی برای مستند سازی وضعیت پروژه در زمانی خاص است .
Overstock.com ، كاربر Synopsis ، نیاز داشت كه یک سیستم گزارش‌گیری تقریباً بلادرنگ ایجاد كند تا جایگزین سیستم گزارش‌گیری برنامه‌های كاربردی فروش شود . Jack Garzella مدیر نگهداری داده‌ها می‌گوید:”یكی از دلایل اصلی كه ما Data conductor را به عنوان محصول اصلی خود انتخاب كردیم این است كه داخل پایگاه داده كار می‌كند و به سرور برنامه كاربردی[۴] یا دیسك اضافه نیاز ندارد .”
از جمله دلایل اصلی دیگر برای تصمیم Overstock.com برای استفاده از این محصول آن است كه كاربران جدید به راحتی می‌توانند به یك پروژه نگاه كنند و ببینند كه دیگران چه كاری انجام داده‌اند . زیرا ODI ، كد SQL لازم را ایجاد می‌كند . به علاوه ، ابزارهای موجود در Designer ، از كنترل تغییر و تجزیه و تحلیل تأثیر[۵] پشتیبانی می‌كنند و به شما نشان می‌دهند كه جدول ها و Inetrface ها كجا به كار می‌روند . Garzella می‌گوید:”ما بیش از چهارصد كار داریم كه برخی روزانه هستند و برخی به صورت پیوسته اجرا می‌شوند كه در مجموع ۹۰ هزار بار در روز اجرا می‌شوند. این محیط ، یك محیط بسیار با ثبات است . “

● حرف آخر

امكانات و قابلیت های بسیاری وجود دارد كه در اینجا مورد بحث قرار نداده‌ام ، از جمله تغییر در دستیابی به داده‌ها ، یكپارچه‌سازی سرویس های وب و نظارت بر رخدادها . برای یادگیری کار با این محصول نمی‌توانید تنها در میانجی های كاربری آن كاوش كنید . تعداد زیادی مستندات وجود دارد كه باید با آن ها آشنا شوید . من ODI را برای پروژه ی انتقالی كه فقط یك بار انجام می‌شود ، توصیه نمی‌كنم ، مگر اینكه افرادی داشته باشید كه به ODI تسلط کامل داشته باشند . در مجموع ، این محصول به همان شکل كه در مورد آن تبلیغ شده است ، كار می‌كند و من آن را به سازمان هایی كه نیازهای مستمر دارند و فكر می‌كنند كه نتایج دراز مدت ناشی از بهره‌وری ، ارزش سرمایه‌گذاری دارد ، توصیه می‌كنم .
ODI V ۱۰.۱.۳ برای پایگاه داده ی مقصد ، به ازای هر پردازنده ، ۱۲ هزار دلار و برای پایگاه داده ی مبداء ، به ازای هر پردازنده ، چهار صد دلار قیمت دارد .(برای منبع داده‌های مبتنی بر JMS (Java Message Service) یا فایلی ، مبلغی دریافت نمی‌شود.)

● موافقان

به شما امكان می‌دهد تا ساختار داده‌ها را مهندسی معكوس كنید و در سطح “قوانین كسب و كار ” از انتزاع كار كنید تا به سرعت بتوانید پروژه‌ها را ایجاد كنید .
معماری ، مستقیماً و با استفاده از فنآوری ویژه ی آن در سرور مبداء و مقصد ، داده‌ها را از سرورهای مبداء به سرورهای مقصد منتقل می‌كند.
میانجی های كاربری گرافیكی و ارجاع مستقل( (cross-referencing به كاربران جدید كمك می كنند تا به سرعت بتوانند پروژه‌ها را از جایی كه دیگران آن را رها كرده‌اند ، ادامه دهند .

● مخالفان

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