معماری متمرکز برای تیم هایی که به جابه جایی کنترل شده داده، قراردادهای پایدار رویداد و یکپارچه سازی نزدیک به بلادرنگ در کنار سامانه هایی که هم اکنون کسب وکار را اجرا می کنند نیاز دارند.
این صفحه نسبت به نمای کلی DevOps عمیق تر است و به خود لایه داده می پردازد. Debezium تغییرات committed پایگاه های داده را به جریان رویداد قابل اتکا تبدیل می کند، Apache NiFi نحوه حرکت و تبدیل این رویدادها را ارکستره می کند، Apache Kafka (یا Red Hat AMQ Streams) آن ها را در مقیاس حمل می کند و Apache Avro قراردادها را پایدار نگه می دارد. تمام این مجموعه روی Red Hat OpenShift، در کنار هر پایگاه داده هسته ای که سازمان شما استفاده می کند — Oracle، SQL Server، IBM DB2، PostgreSQL، MySQL یا غیره — به راحتی اجرا می شود.
سکوی داده روی Red Hat
Debezium تغییرات Oracle، SQL Server، IBM DB2 و سایر پایگاه های داده را به رویداد تبدیل می کند. Apache NiFi مسیر آن ها را شکل می دهد، Apache Kafka آن ها را در مقیاس حمل می کند و Apache Avro Schemaها را پایدار نگه می دارد — همه روی Red Hat OpenShift.
Apache NiFi Routing، Enrichment و Transformation را به صورت بصری مدیریت می کند. Apache Kafka رویدادها را به شکلی پایدار، ترتیب دار و در مقیاس به مصرف کنندگان می رساند. تیم های عملیاتی هر مرحله را می بینند و عیب یابی می کنند.
AMQ Streams
DB2Oracle · SQL Server · DB2 — هسته محفوظ
هرچه پایگاه داده هسته باشد — Oracle، SQL Server، IBM DB2 یا غیره — هدف ثابت است: حفظ هسته تراکنشی و مدرن سازی لایه توزیع داده، APIها و سرویس های پیرامون آن، روی Red Hat OpenShift.
ثبت تغییرات committed از Oracle، SQL Server، IBM DB2، PostgreSQL، MySQL و MongoDB و تبدیل آن ها به جریان رویداد حاکمیت شده.
Routing، Enrichment، Transformation، Buffering و کنترل جریان های یکپارچه سازی سازمانی با رابط بصری و مشاهده پذیری کامل عملیاتی.
Apache Kafka — یا Red Hat AMQ Streams — تحویل پایدار، ترتیب دار و با توان عملیاتی بالای رویدادها میان تولیدکنندگان و مصرف کنندگان را فراهم می کند.
حفظ پایداری قراردادهای تولیدکننده و مصرف کننده در طول تکامل خط لوله ها، سرویس ها و سامانه های پایین دستی.
Red Hat OpenShift Runtime را فراهم می کند. Debezium، Apache NiFi و Apache Kafka (یا Red Hat AMQ Streams) لایه استخراج، جریان و انتقال رویدادها را تشکیل می دهند و Apache Avro قراردادها را پایدار نگه می دارد. این اکوسیستم در محیط های رگوله بلوغ و سابقه اثبات شده دارد.
Red HatOpenShift
Debezium
Apache NiFiApache Kafkaدر بیشتر برنامه های نوسازی سازمانی، Runtime برنامه دشوارترین مسئله نیست؛ دشوارترین مسئله مسیر داده میان سامانه های قدیمی و جدید است. کانال های دیجیتال به داده تازه تر نیاز دارند، تیم های پایین دستی قراردادهای تمیزتر می خواهند و تیم های یکپارچه سازی به جریان هایی نیاز دارند که قابل مشاهده و قابل پشتیبانی باشند، نه مجموعه ای از Jobهای سفارشی شکننده.
پاسخ ما تفکیک تمیز مسئولیت هاست. سامانه های هسته ای تراکنشی — چه روی Oracle، چه SQL Server، چه IBM DB2، چه موتور دیگری — authoritative باقی می مانند. Debezium تغییرات committed آن ها را به رویداد تبدیل می کند. Apache NiFi نحوه حرکت، تبدیل و رسیدن این رویدادها به مقصد را ارکستره می کند. Apache Kafka (یا Red Hat AMQ Streams) به عنوان ستون فقرات رویداد عمل می کند. Apache Avro ساختار هر رویداد را تحت کنترل نگه می دارد.
تمام پلتفرم روی Red Hat OpenShift اجرا می شود؛ یعنی همان مدل امنیت، انضباط استقرار و ابزار عملیاتی بقیه پشته تحویل را به ارث می برد. سرویس های جدید، یکپارچه سازی ها و محصولات داده می توانند سریع تکامل پیدا کنند، در حالی که سامانه های هسته ای همان کاری را که به آن ها اعتماد شده ادامه می دهند.
معماری رسمی Debezium
Debezium تغییرات Oracle، SQL Server، IBM DB2 و سایر پایگاه های داده را به رویداد تبدیل می کند. Apache NiFi مسیر آن ها را شکل می دهد، Apache Kafka آن ها را در مقیاس حمل می کند و Apache Avro Schemaها را پایدار نگه می دارد — همه روی Red Hat OpenShift.
Debezium تغییرات committed را از پایگاه هایی مثل Oracle، SQL Server، IBM DB2، PostgreSQL و MySQL ثبت می کند — بدون اصلاح برنامه مبدا. این موضوع زمانی اهمیت پیدا می کند که سامانه منبع حیاتی، حساس یا متعلق به تیمی باشد که توان پذیرش تغییر مستقیم را ندارد.
هر تغییر committed به رویدادی تبدیل می شود که مصرف کنندگان پایین دستی می توانند برای همگام سازی، تحلیل، بی اعتبارسازی Cache یا Triggerهای فرآیندی از آن استفاده کنند. یکپارچه سازی به جای شبانه، نزدیک به بلادرنگ می شود؛ در حالی که پایگاه داده System of Record باقی می ماند.
به جای آنکه هر سامانه پایین دستی مستقیماً از جداول تولیدی بخواند، مصرف کنندگان به یک جریان رویداد حاکمیت شده Subscribe می شوند. Coupling کم می شود، Interfaceها قابل درک تر می شوند و تغییر در هر دو سمت بسیار امن تر می شود.
NiFi نمایی شفاف و گرافیکی از نحوه حرکت داده می دهد: Routing، Transformation، Retry، Throttling، Prioritization و Delivery. به ویژه وقتی چند سامانه پایین دستی به رفتارهای متفاوت روی همان رویدادهای بالادستی نیاز دارند.
جریان داده سازمانی فقط نباید اجرا شود — باید قابل پشتیبانی هم باشد. NiFi نشان می دهد داده در کجاست، چرا انتقالی شکست خورده، چه چیزی در صف است و هر Payload از کدام مسیر عبور کرده. تیم های عملیاتی می توانند واقعاً پاسخ بدهند، نه حدس بزنند.
وقتی داده از سامانه های هسته ای خارج می شود، NiFi می تواند Enrichment، Filtering، Redaction، Reshaping و Routing رکوردها را به سمت APIها، سکوهای تحلیلی و سرویس های داخلی انجام دهد — جایگزینی انبوه اسکریپت های یکپارچه سازی سفارشی با یک پلتفرم واحد و قابل مشاهده.
Avro به تیم ها روشی عملی برای تعریف و تکامل Schema می دهد. در سامانه های رویدادمحور، همین چیز است که جلوی شکست خاموش مصرف کنندگان را وقتی تولیدکننده فیلدی را تغییر می دهد یا معنای Payload را عوض می کند می گیرد.
وقتی چند تیم به یک خانواده رویداد وابسته اند، انضباط Schema یک نیاز حاکمیتی است، نه یک ترجیح. Avro به وضوح مشخص می کند کدام فیلدها می توانند تغییر کنند و کدام باید ثابت بمانند.
با قراردادهایی که پایدار باقی می مانند، اضافه کردن ابزارهای جدید گزارش گیری، تحلیل، سرویس های عملیاتی یا مصرف کنندگان یادگیری ماشین تبدیل به کاری بسیار کوچک تر می شود — دیگر نیازی به بازتعریف معنای هر Payload در هر تکرار نیست.
در بیشتر سازمان ها، سامانه های هسته ای تراکنشی — دفتر کل، اطلاعات مشتری، تسویه، صورتحساب — سال ها پیش روی پایگاه هایی مثل Oracle، IBM DB2 یا SQL Server ساخته شده اند. این سامانه ها کسب وکار را اجرا می کنند، به آن ها اعتماد شده، و بازنویسی سریع آن ها معمولاً تصمیم درستی نیست. ریسک بالا و ارزش جا افتاده درون آن ها بسیار زیاد است.
الگوی بهتر این است که بگذاریم این هسته ها همان کاری را که در آن خوب اند انجام دهند، و لایه پیرامون آن ها را مدرن کنیم. Debezium تغییرات committed آن ها را به صورت رویداد بیرونی می کند. Apache NiFi جریان حاصل را شکل می دهد و Routing می کند. Apache Avro قراردادها را منظم نگه می دارد. Apache Kafka (یا Red Hat AMQ Streams) رویدادها را در مقیاس حمل می کند. سرویس هایی که روی Red Hat OpenShift اجرا می شوند این جریان ها را مصرف یا APIهای جدید روی آن ها عرضه می کنند.
نتیجه، یک مسیر نوسازی تدریجی و قابل بازگشت است: پیرامون — کانال های دیجیتال، محصولات داده، سرویس های یکپارچه سازی، اتوماسیون عملیاتی — جلو می رود، در حالی که System of Recordها محافظت شده باقی می مانند. سرعت بالا می رود، ریسک پایین می آید و سازمان قابلیت های جدید را به دست می آورد، بدون آنکه همه چیز را روی یک پروژه جایگزینی شرط بندی کند.
پایگاه های تراکنشی موجود — Oracle، SQL Server، IBM DB2، PostgreSQL یا MySQL — به عنوان authoritative برای وضعیت اصلی کسب وکار و رویدادهای committed باقی می مانند.
Debezium تغییرات committed را ثبت و به صورت یک جریان تمیز از رویدادها برای مصرف پایین دستی کنترل شده منتشر می کند.
Apache Kafka — یا Red Hat AMQ Streams روی OpenShift — تحویل پایدار، ترتیب دار و Partitioned رویدادها را در مقیاس سازمانی فراهم می کند.
Apache NiFi منطق Routing، Enrichment، Filtering، Buffering، خطا و سیاست های جابه جایی داده برای مصرف کنندگان مختلف را به شکل بصری و قابل پشتیبانی اعمال می کند.
Apache Avro مدل Schema-governed رویداد را فراهم می کند تا تولیدکننده و مصرف کننده مستقل از هم و بدون شکست کنترل نشده تکامل پیدا کنند.
سرویس های مستقر روی Red Hat OpenShift، ابزارهای گزارش گیری، سکوهای تحلیلی و APIهای عملیاتی از جریان های حاکمیت شده داده و رویداد استفاده می کنند.
اگر در کنار این صفحه به یک خلاصه قابل دانلود نیاز دارید، تا آماده شدن PDF اختصاصی سکوی داده می توانید از نسخه فعلی معرفی پلتفرم استفاده کنید.