Oracle Data Integrator

Oracle Data Integrator (ODI)؛ فراتر از ETL یکپارچه‌سازی داده

ODI  یا Oracle Data Integrator چیست؟ فراتر از  ETLبرای یکپارچه‌سازی داده و انبارداده

مقدمه

Oracle Data Integrator – در سال‌های اخیر، داده از یک خروجی جانبی سامانه‌های عملیاتی به یکی از مهم‌ترین دارایی‌های سازمان‌ها تبدیل شده است. سازمان‌ها دیگر صرفاً به دنبال ذخیره‌سازی داده نیستند! بلکه می‌خواهند داده‌های پراکنده خود را به اطلاعاتی قابل اعتماد، به‌موقع و قابل استفاده برای تصمیم‌گیری تبدیل کنند.

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

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

ODI یا Oracle Data Integrator را می‌توان در همین نقطه مورد بررسی قرار داد. یعنی نه صرفاً به‌عنوان یک ابزار  ETL، بلکه به‌عنوان یک پلتفرم یکپارچه‌سازی داده که فلسفه معماری آن بر E-LT، طراحی اعلانی، ماژول دانش[1]، استفاده از قابلیت‌های بومی موتورهای پایگاه‌داده و مدیریت فرآیندهای پیچیده یکپارچه‌سازی استوار است. خود شرکت اوراکل نیز ODI را راهکاری برای ساخت، استقرار و مدیریت انبارداده و معماری‌های داده‌محور معرفی می‌کند.

بنابراین پرسش اصلی این مقاله این نیست که ODI چیست؟ پرسش مهم‌تر این است: «Oracle Data Integrator چگونه می‌تواند برای یک سازمان، و به‌طور خاص برای یک بانک، ارزش کسب‌وکاری ایجاد کند؟» در این مقاله سعی خواهیم کرد به قدر وسع به این پرسش، پاسخ دهیم.

1- مسئله اصلی بانک، انتقال داده نیست

وقتی درباره یکپارچه‌کردن داده صحبت می‌کنیم، ممکن است در نگاه اول مسئله بسیار ساده به نظر برسد:

داده را از سیستم A بردار، آن را تغییر بده و در سیستم B قرار بده

ODI in Banking
ODI in Banking

اما در یک انبارداده سازمانی بانکی، مسئله بسیار پیچیده‌تر است! فرض کنید یک بانک دارای سیستم‌های زیر باشد:

  • سامانه هسته بانکداری متمرکز
  • سامانه کارت
  • سامانه تسهیلات
  • سامانه اعتباری
  • سامانه پرداخت
  • سامانه مدیریت ارتباط با مشتریان یا CRM
  • سامانه منابع انسانی
  • سامانه حسابداری کل
  • سامانه‌های اینترنت و موبایل‌بانک
  • سامانه‌های نظارتی
  • سامانه‌های مدیریت ریسک

هر کدام از این سامانه‌ها ممکن است مدل داده، ساختار، قواعد کسب‌وکار، کیفیت داده و روش نگهداری متفاوتی داشته باشند. بنابراین مسئله واقعی این نیست که چگونه داده را از نقطه A به B منتقل کنیم. مسئله واقعی این است که:

چگونه داده‌های ناهمگون عملیاتی را به یک دارایی داده‌ای یکپارچه، قابل اعتماد و قابل تحلیل تبدیل کنیم؟

این همان جایی است که یکپارچه‌کردن داده از یک فعالیت صرفاً فنی به یک قابلیت استراتژیک سازمان تبدیل می‌شود.

2- Oracle Data Integrator  چیست؟

ODI  محصول شرکت اوراکل برای توسعه و اجرای فرآیندهای یکپارچه‌کردن داده است. اما یکی از نکات مهم در شناخت Oracle Data Integrator این است که نباید آن را صرفاً با مفهوم سنتی ETL یکی دانست. فلسفه معماری ODI بر مفهوم E-LT یا Extract-Load-Transform  استوار است. در معماری ETL سنتی، بخش قابل توجهی از تبدیلات داده‌ای[2] در یک موتور ETL واسط انجام می‌شود:

Source → Extract → ETL Engine → Transform → Target

اما در رویکرد E-LT، ODI  تلاش می‌کند از ظرفیت پردازشی سیستم‌های داده، به‌خصوص موتورهای پایگاه داده[3]، استفاده کند:

Source → Extract/Load → Target/Staging → Transform

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

3- چرا E-LT برای بانک اهمیت دارد؟

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

ODI Features for Banking
ODI Features for Banking
  • مصرف بالای شبکه
  • افزایش زمان انتقال
  • گلوگاه پردازشی
  • افزایش میزان پردازش دسته‌ای
  • نیاز به منابع سخت‌افزاری بیشتر
  • پیچیدگی مدیریت حجم‌های بالا

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

در محیط‌هایی که انبارداده مبتنی بر پایگاه داده اوراکل است، این موضوع اهمیت بیشتری پیدا می‌کند. زیرا می‌توان از قابلیت‌های پایگاه داده اوراکل مانند پردازش‌های SQL، پردازش‌های موازی، پارتیشن‌بندی داده و سایر قابلیت‌های ذاتی این پایگاه داده برای پردازش داده استفاده کرد. بنابراین ارزش E-LT صرفاً یک روش متفاوت برای ETL نیست. ارزش اصلی آن می‌تواند در این موارد باشد:

  • کاهش انتقال غیرضروری داده
  • استفاده از ظرفیت پردازشی پایگاه داده
  • افزایش مقیاس‌پذیری
  • کاهش وابستگی به یک موتور مرکزی ETL

4-  طراحی اعلانی[4]، تمرکز بر «چه چیزی» به جای «چگونه»

یکی دیگر از مفاهیم کلیدی ODI، طراحی اعلانی است. در روش‌های سنتی، توسعه‌دهنده ممکن است مجبور باشد مراحل اجرای فرآیند را به‌صورت جزئی تعریف کند:

ODI Declarative Design
ODI Declarative Design
  1. داده را واکشی کن
  2. آن را ذخیره کن
  3. اشتراکات داده با جداول مرتبط پیدا کن
  4. دنبال داده موردنیاز بگرد
  5. تبدیلات داده انجام بده
  6. نتیجه را در مقصد قرار بده

در رویکرد اعلانی، تمرکز اصلی روی تعریف قواعد و نتیجه مورد انتظار است. به زبان ساده:

توسعه‌دهنده بیشتر مشخص می‌کند «چه داده‌ای باید تولید شود» و ODI با استفاده از متاداده و ماژول‌های دانش مشخص می‌کند «چگونه این فرآیند اجرا شود»

این تفکیک بین قواعد کسب‌وکاری و استراتژی پیاده‌سازی یکی از نقاط قوت معماری ODI است.شرکت اوراکل نیز طراحی اعلانی را یکی از مفاهیم اصلی ODI معرفی می‌کند. این موضوع از منظر معماری سازمانی[5] اهمیت زیادی دارد، زیرا باعث می‌شود منطق کسب‌وکار از جزئیات فنی اجرای فرآیند تا حدی جدا شود.

5- Knowledge Module. قلب معماری ODI

اگر بخواهیم یکی از مهم‌ترین مفاهیم Oracle Data Integrator را انتخاب کنیم، ماژول‌های دانش یا KM بدون تردید در میان گزینه‌های اصلی قرار می‌گیرد. ماژول‌های دانش  تمپلیت‌های قابل استفاده مجدد هستند که مشخص می‌کنند یک فرآیند یکپارچه‌سازی چگونه اجرا شود. شرکت اوراکل انواع مختلفی از ماژول‌های دانش را برای وظایفی مانند:

ODI Knowledge Modules
ODI Knowledge Modules
  • مهندسی معکوس یا Reverse Engineering
  • لود کردن داده یا Loading
  • یکپارچه‌سازی یا Integration
  • تشخیص تغییرات تدریجی داده یا Changed Data Capture
  • کیفیت‌سنجی داده و Data Quality / Integrity
  • خدمات یا Service

ارائه کرده است. برخی از مهم‌ترین آنها عبارت‌اند از:

LKM – Loading Knowledge Module: برای انتقال داده بین سیستم‌ها یا انتقال داده به محیط استیج استفاده می‌شود.

IKM – Integration Knowledge Module: برای اعمال استراتژی‌های یکپارچه‌سازی روی مقصد استفاده می‌شود. از جمله Insert/Update و برخی استراتژی‌های مربوط به Slowly Changing Dimensions

JKM – Journalizing Knowledge Module: برای پیاده‌سازی Changed Data Capture یا CDC مورد استفاده قرار می‌گیرد

CKM – Check Knowledge Module: برای کنترل Integrity و بررسی کیفیت و صحت داده در جریان یکپارچه‌سازی استفاده می‌شود

RKM – Reverse Knowledge Module: برای مهندسی معکوس و استخراج متاداده از سیستم‌های مختلف استفاده می‌شود

SKM – Service Knowledge Module: برای ایجاد سرویس‌های داده کاربرد دارد

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

6- جایی که تخصص واقعی Oracle Data Integrator خودش را نشان می‌دهد

یک کاربر مبتدی ODI ممکن است نگاشت ایجاد کند و یک LKM و IKM را انتخاب کند. اما یک متخصص ODI سؤال‌های متفاوتی می‌پرسد:

ODI IKM JKM
ODI IKM JKM
  • چرا این LKM؟
  • چرا این IKM؟
  • محیط استیج کجا باشد؟
  • تبدیلات داده در کجا انجام شود؟
  • حجم داده چقدر است؟
  • مبدا و مقصد چه نوع پایگاه داده‌هایی هستند؟
  • گلوگاه شبکه کجاست؟
  • آیا بارگذاری مستقیم داده مناسب است؟
  • آیا موازی‌ کردن پردازش باید فعال شود؟
  • آیا باید پارتیشن در نظر گرفته شود؟
  • آیا بارگذاری تاریخچه‌ای[6] مناسب است یا بارگذاری تدریجی[7]؟
  • آیا باید ماژول دانش شخصی‌سازی شده ایجاد شود؟
  • آیا اجرای نگاشت با پردازش دسته‌ای[8] سازگار است؟

در واقع، تسلط واقعی بر ODI از توانایی ساخت Mapping عبور می‌کند و به توانایی انتخاب Strategy مناسب برای اجرای Mapping می‌رسد.

این نقطه تمایز مهمی میان «کاربر  ODI» و «معمار یا متخصص  ODI» است.

7- Oracle Data Integrator در معماری انبارداده بانکی

می‌توان یک معماری مفهومی برای استفاده از ODI در بانک را به شکل زیر تصور کرد:

سامانه‌های عملیاتی بانک شامل:

سامانه هسته بانکداری متمرکز
سامانه کارت
سامانه تسهیلات
سامانه مدیریت ارتباط با مشتریان یا CRM
سامانه حسابداری کل
سامانه مدیریت منابع انسانی HR
کانال‌ها Channels

↓

ODI Data Integration Layer

Extract Load
CDC
Data Quality
Transformation
Integration

↓

Staging Area

↓

Enterprise Data Warehouse

↓

Data Marts

Customer
Credit
Finance
Risk
HR
Branch

↓

BI & Analytics

Dashboards
Reports
Advanced Analytics
Management Information

در این معماری، Oracle Data Integrator فقط وظیفه انتقال داده را بر عهده ندارد. بلکه می‌تواند در بخش‌هایی از این زنجیره نقش مهمی ایفا کند.

  • Data Acquisition
  • Data Movement
  • Transformation
  • Data Quality
  • Orchestration
  • Operationalization

8- ارزش Oracle Data Integrator برای بانکداری

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

8-1. کاهش زمان رسیدن به داده

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

8-2. کاهش هزینه توسعه

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

8-3. کاهش هزینه نگهداری

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

8-4. افزایش مقیاس‌پذیری

در محیط‌های بزرگ، معماری E-LT امکان استفاده از توان پردازشی موتور داده را فراهم می‌کند.

8-5. افزایش قابلیت اعتماد[9]

قابلیت‌هایی مانند مانیتورینگ، لاگ‌گذاری، قابلیت شروع مجدد[10] و مدیریت استثناها و خطاها[11] برای محیط‌های عملیاتی[12] اهمیت زیادی دارند.

8-6. افزایش اعتماد به داده

کنترل‌های کیفیت داده و انطباق باعث می‌شوند کاربران کسب‌وکار اعتماد بیشتری به داده‌های تحلیلی داشته باشند.

9- Oracle Data Integrator ابزار نیست، بخشی از معماری داده است

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

  • Data Architecture
  • Database Architecture
  • Data Warehouse
  • Data Quality
  • Security
  • Governance
  • BI
  • Operations

هماهنگ شود. در این حالت ODI بخشی از یک پلتفرم داده می‌شود.Oracle Data Integrator را می‌توان از دو زاویه متفاوت مشاهده کرد.

از یک زاویه، ODI یک ابزار یکپارچه‌سازی داده است که برای انتقال، تبدیلات داده و تجمیع داده استفاده می‌شود. اما از زاویه‌ای عمیق‌تر، ODI یک Metadata-driven و E-LT-oriented Integration Platform است که می‌تواند در معماری‌های Enterprise Data نقش مهمی ایفا کند.

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

Declarative Design + Knowledge Modules + E-LT + CDC + Data Quality + Load Plans + Monitoring + Lifecycle Management = Enterprise Data Integration

و در صنعت بانکداری، این Enterprise Data Integration می‌تواند زیربنای بسیاری از قابلیت‌های تحلیلی و مدیریتی باشد:

  • Customer 360
  • Customer Profitability
  • Credit & Risk Analytics
  • Branch Analytics
  • Financial Analytics
  • Regulatory Reporting
  • Fraud Analytics

و در نهایت: Data-Driven Banking

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

و شاید مهم‌ترین تفاوت میان یک کاربر معمولی ODI و یک متخصص ODI نیز همین باشد:

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

در نهایت، ODI زمانی بیشترین ارزش را ایجاد می‌کند که از یک «ابزار توسعه ETL» به یک قابلیت سازمانی برای مدیریت جریان ارزش داده تبدیل شود.

[1] ماژول دانش Knowledge Module یا KM در ODI را می‌توان به‌عنوان الگوی اجرایی یکپارچه‌سازی و پردازش داده در نظر گرفت. مجموعه‌ای از قواعد و دستورالعمل‌های قابل‌استفاده مجدد که مشخص می‌کند یک فرآیند داده‌ای چگونه متناسب با فناوری، معماری و روش اجرای موردنظر پیاده‌سازی شود. برای استفاده راحت از این به بعد در این مقاله هر جا که نیاز بود Knowledge Module ذکر گردد از معادل آن یعنی ماژول دانش استفاده می‌شود.

[2] Data Transformation

[3] Database Engine

[4] Declarative Design یا طراحی اعلانی رویکردی است که در آن توسعه‌دهنده به‌جای تعریف گام‌به‌گامِ نحوه انتقال و تبدیل داده، نتیجه و منطق کسب‌وکاری موردنظر را مشخص می‌کند و ODI نحوه اجرای فرآیند انتقال و تبدیل داده را بر اساس متادیتا و قوانین تعریف‌شده مدیریت می‌کند.

[5] Enterprise Architecture

[6] Full Load

[7] Incremental Load

[8] Batch Window

[9] Reliability

[10] Restartability

[11] Exception Handling

[12] Production

تألیف: آقای مهندس رضا بهادری زاده

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

    اطلاعات مورد نیاز شما

    نوشتن نظر

    نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *