1. Loyihani asoslash va ma'lumotlarni birlashtirish zaruriyati
Zamonaviy korporativ boshqaruv muhitida loyiha boshqaruvi tizimi oddiy ish boshqaruvi vositasidan tashqari, korporativ faoliyatning muhim platformasi sifatida joylashmoqda.
Xususan katta tashkilotlarda loyiha jarayonining holati, muddatlari, resurslari, munosabatlar ma'lumotlari asosida turli qarorlar qabul qilinadi.
Bu jarayonda eng muhim elementlardan biri ma'lumotlarning ishonchliligi va to'liqligidir.
Loyihani boshlashda eng katta vazifa bir qancha Legacy tizimlarda tarqalgan loyiha ma'lumotlarini bitta markazlashtirilgan Ishlab chiqarish tizimiga birlashtirish edi.
Muammo oddiy ma'lumotlarni ko'chirishdan iborat emas edi. Har bir Legacy tizim turli maqsadlar va tuzilmalar bilan ishladi va foydalanilayotgan DBMS va ma'lumotlar modeli ham farq qilardi.
Shuningdek, har bir tizimda har kuni ma'lumotlar yaratilishi va tahrirlash davom etmoqda.
Xususan, loyiha boshqaruv ma'lumotlari xususiyatlariga ko'ra, Activity va Relationship ma'lumotlari juda murakkab bog'langan edi.
Masalan, quyidagi muammo mavjud edi.
- Tizimlar o'rtasida ma'lumotlar tuzilishi mos kelmaydi
- Faoliyat munosabatlar modeli farqlari
- Kalit tizimi farqlari
- O'chirish ma'lumotlarini qayta ishlash muammosi
- O'zgarish tarixini kuzatish yo'qligi
- Ma'lumotlarning to'g'riligi ta'minlanishi zarur
Umuman olganda, ma'lumotlarni birlashtirish loyihalarida CDC (O'zgartirish Ma'lumotlarni Olingan) usuli keng qo'llaniladi.
Ya'ni, o'zgartirilgan ma'lumotlarni faqat kuzatib borish va maqsad tizimiga uzatish usulidir.
Ammo, ushbu loyihada CDC asosidagi yondashuv mos kelmadi. Sababi, manba tizimi o'z-o'zidan o'zgartirish tarixini to'liq boshqarib turmaganligi sababli.
Bundan tashqari, ba'zida istisno holatlarda o'chirilgan ma'lumotlar yoki o'zgartirishlar yo'qolishi mumkinligi mavjud edi.
Xususan, biznes maydonida ma'lumotlarning 100% yaxlitligini juda muhim deb talab qilingan.
Oxir-oqibatda loyiha “har kuni butun ma’lumotlarni qayta to‘plash”ga asoslangan Full-Load strategiyasini tanladi.
Ya’ni, har kuni Legacy tizimning butun ma’lumotlari ETL orqali to‘planadi va mehnat qilayotgan tizimdagi ma’lumotlar bilan taqqoslanib, yangi va o‘zgargan ma’lumotlar kiritiladi. Bu juda jasur yondashuv edi.
Aslida har kuni ishlov berilishi kerak bo'lgan ma'lumotlar hajmi quyidagi kabi edi.
- o'nlab ming faoliyat ma'lumotlari
- O'n millionlik Relationship ma'lumotlari
- O'n milliondan ko'p Full-Load qayta ishlash
Oxir-oqibat, ushbu loyihaning asosi oddiy ma'lumotlarni ko'chirish emas, balki “katta hajmdagi Full-Load ma'lumotlarni qanday ishonchli va samarali ravishda qayta ishlash” masalasida edi.
2. Full-Load asosidagi ma'lumotlarni birlashtirish strategiyasi
Ushbu loyihada eng muhim dizayn falsafalaridan biri ma'lumotlar yaxlitligini mutlaqo ta'minlash edi.
Oddiy CDC usuli samaradorlik jihatidan afzalliklarga ega bo'lsa-da, o'zgarishlar yo'qotilishi yoki istisno holatlar yuzaga kelganda ma'lumotlarning to'g'riligi buzilishi ehtimoli mavjud.
Xususan, loyiha boshqaruvi ma'lumotlari aloqalar tuzilishi murakkab bo'lganligi sababli, ba'zi ma'lumotlar yo'qolsa, butun ulanish tuzilishi buzilishi mumkin edi.
Shuning uchun loyiha doirasida har kuni barcha ma'lumotlarni qayta to'plash uchun Full-Load strategiyasi qabul qilindi.
Ya'ni, manba tizimining Source Table butun ma'lumotlarini har kuni ETL orqali olish usuli edi. Albatta, bu usul ma'lumotlar miqdori jihatidan juda katta yuklamani keltirib chiqaradi.
Har kuni o'n minglab Activity ma'lumotlari va o'n milliondan ortiq Relationship ma'lumotlarini qayta ishlashimiz kerak edi.
Lekin shu qadar foyda ham aniq edi.
Birinchisi - ma'lumotlarning to'g'riligi kafolatidir.
Manba tizimining oxirgi holatini to'g'ridan-to'g'ri aks ettirgani uchun o'zgartirishlarni yo'qotish ehtimolini aslida bartaraf etish imkoniga ega bo'ldik.
Ikkinchisi - o'chirilgan ma'lumotlarga moslashish edi.
CDC asosidagi tuzilishda o'chirilgan ma'lumotlarni kuzatish qiyin bo'lishi mumkin, ammo To'liq yuk tuzilishida hozirda mavjud bo'lmagan ma'lumotlarni osonlik bilan aniqlash mumkin edi.
Uchinchisi, operatsion barqarorlik edi.
Merosi tizimning o'zgarish tarixini boshqarish sifatiga bog'liq bo'lmasligi kerak edi.
Ammo bunday tuzilma oddiy DB ishlov berish orqali hal qila olmaydigan katta hajmdagi ma'lumotlarni qayta ishlash muammolarini ham keltirib chiqardi.
Xususan quyidagi muammolar juda katta edi.
- Katta ma'lumotlarni taqqoslash operatsiyasi
- Upsert qilish xarajatlari oshdi
- Join asosidagi standartlash jarayoni
- Joylash vaqt cheklovlari
- DB yuklanishini oshirish
Amaliy loyiha doirasida tong soatlari ichida taxminan 3 soat ichida to'liq partiya qayta ishlashni tugatishimiz kerak edi.
Shuning uchun oddiy so'rovni optimallashtirish darajasidan tashqari, arxitekturani katta ma'lumotlarni qayta ishlash uchun optimallashtirish zarur edi.
Natijada loyiha ko'p bosqichli quvur asosidagi tuzilmani loyihalash va bosqichma-bosqich ma'lumotlarni tarqatish strategiyasini tanladi.
3. Bosqich 1 ~ 2 : To'plash va tozalash arxitekturasi
Birinchi qadam Ingestion (to'plama bosqichi) edi.
Loyihada bir nechta Legacy tizimlardan ma'lumotlarni yig'ish kerak edi, har bir tizim bir-biridan farqli server va DBMS muhitlarida ishlaydi.
Masalan, ba'zi tizimlar Oracle, ba'zi tizimlar MSSQL, ba'zi tizimlar esa MySQL asosida ishlanmoqda. Dastlab tizimga xos Adapterlarni to'g'ridan-to'g'ri ishlab chiqish usuli ham ko'rib chiqildi.
Lekin Legacy tizimlari qo'shilgan sari yangi Adapter ishlab chiqish zarurati tug'ildi va xizmat ko'rsatish xarajatlari ham juda katta bo'lishi mumkin edi.
Natijada biz ETL yechimlari bo'yicha xar xil ma'lumotlarni birlashtirishga ixtisoslashgan Informatica-dan foydalanishga qaror qildik.
Informatica turli DBMS ulanishlari va ma'lumotlarni to'plash imkoniyatlarini asosiy ta'minlaydi, shuning uchun tizimlar orasidagi ulanish tuzilmasını ancha samarali ravishda tashkil qilish imkonini berdi.
Shuningdek, Legacy operatsion tizimining yuklanishini minimalizatsiya qilish ham juda muhim talab edi. Aslida, Legacy tizimlar barcha faoliyatdagi ish tizimlari edi, shuning uchun ETL ishlaridan kelib chiqadigan samaradorlik pasayishi bo'lmasligi kerak edi.
Buni hal qilish uchun loyiha Replica asosidagi tuzilmani loyihaladi.
Ya'ni, Legacy ish faoliyatidagi DB ma'lumotlarini to'g'ridan-to'g'ri Working System ichidagi Replica DB ga ko'chirgandan so'ng, asl tozalash jarayoni Replica DB asosida amalga oshirildi.
Bu jarayonda Truncate & Insert asosidagi Full-Load strategiyasi qo'llanildi.
Sizning yordamingiz bilan ishga tushirish DB yukini minimal darajada saqlab, eng so'nggi ma'lumotlarni ishonchli ravishda olish imkoniyatiga ega bo'ldik.
Ikkinchi bosqich Refinement (tozalash bosqichi) edi.
Merosi tizimga oid ma'lumotlar har biri o'zining tuzilishiga ega edi.
Masalan, Activity jadvalining tuzilishi va Relationship tuzilishi har bir tizimda mutlaqo farq qilardi. Bu holatda integratsiyalangan taqqoslash va Upsert ishlov berish mumkin emas edi, shuning uchun standartlashtirish ishlarini amalga oshirish shart edi.
Loyihada Activity va Relationship ma'lumotlarini umumiy standart modelga tozalashning tuzilishini ishlab chiqdik.
Muammo ma'lumotlar hajmi edi. Har kuni ishlov berilishi kerak bo'lgan ma'lumotlar soni o'n millionlab edi va standartlashtirish jarayonida Join, satrni qayta ishlash, munosabatlarni hisoblash kabi ishlov berishlar katta hajmdagi bajarilishi kerak edi. Oddiy so'rov optimallashtirish bilan ishlov berish vaqtini belgilash qiyin edi.
Nihoyat paralel qayta ishlash tuzilmasini joriy etdik.
Legacy tizimlar o'rtasida ma'lumotlar bog'lanmaganini inobatga olib, tizimlar bo'yicha tozalash ishlarini paralel ravishda amalga oshirdik. Natijada, umumiy ishlov berish vaqtini yarmigacha qisqartirishga erishdik.
4. Stage 3 ~ 4 : Integratsiya va oxirgi yuklash
Uchinchi bosqich Integratsiya (integratsiya bosqichi) edi.
Stage 2-da Legacy tizimlar bo'yicha tozalangan Activity va Relationship ma'lumotlarini bitta integratsiya modeliga birlashtirish jarayoni edi.
Ushbu bosqichda oddiy Merge dan ko'ra murakkablik mavjud edi.
Eng katta muammo kalitlarning takrorlanish ehtimoli edi. Turli meros tizimlarida bir xil kalit qiymatlari ishlatilishi mumkin edi.
Buni hal qilish uchun Origin System asosidagi identifikatsiya tizimini birgalikda tashkil etdik.
Ya'ni, oddiy PKdan foydalanish bilan birga, "qanday Legacy tizimida yaratilgan ma'lumotlar ekanligini" boshqarishni ham ta'minlash uchun loyiha qilindi.
Buning yordamida ma'lumotlar to'qnashuvi mumkinligini yo'q qildik va izlanish imkoniyatlarini ta'minladik.
Shuningdek, barcha ma'lumotlarga Origin System Tag qo'shildi.
Ushbu tuzilma sababli, keyinchalik operatsion jarayonlarda muayyan ma'lumotlarning qaysi manba tizimida yaratilganini osonlik bilan izlab topish mumkin bo'ldi.
To'rtinchi bosqich Transformation & Loading bosqichi edi.
Ushbu bosqichning asosiy maqsadi, mavjud Working DB ma'lumotlarini va yangi Full-Load ma'lumotlarni samarali ravishda solishtirishdan iborat edi.
Muammo ma'lumotlar miqdoriga bog'liq edi. Har kuni o'n millionlab ma'lumotlarni to'liq taqqoslash uchun oddiy taqqoslash usuli davomiy vaqt talab qilishi mumkin edi.
Buni hal qilish uchun loyiha Hash asosidagi taqqoslash strategiyasini qo'lladi.
Har bir qator ma'lumotlariga asoslanib Hash qiymatini yaratish va bir xil PKga ega mavjud ma'lumotlar bilan Hashni taqqoslash usuli edi.
Ya'ni, asl ma'lumotlarning barchasini taqqoslamasdan, faqat Hash qiymatlarini taqqoslab, o'zgarishni tezda aniqladik.
Ushbu tuzilma orqali quyidagi ma'lumotlarni tezda aniqlash imkoniyatiga ega bo'ldik.
- Yangi qo'shish maqsadi
- Yangilanish maqsadi
- O'zgarmagan ma'lumotlar
Shuningdek, asl Upsert jarayoni ham asinxron tuzilma sifatida loyihalangan. Tasdiqlangan Insert va Update ma'lumotlari Kafka orqali har bir xizmatning vaqtincha jadvaliga uzatilgan.
Keyinchalik, har bir xizmat o'z-o'zidan Upsertni amalga oshirib, yakuniy Ishlash DBsini yangilash uchun o'rnatilgan.
Bunday Kafka asosidagi asinxron tuzilma tizimlar o'rtasidagi bog'lanishni kamaytirib, nosozliklarni izolyatsiya qilish effektini ham taqdim etdi.
5. Ishlash samaradorligini optimallashtirish va operatsion barqarorlik
Ushbu loyihaning eng katta maqsadlaridan biri oddiy ma'lumotlarni qayta ishlash muvaffaqiyati emas, balki “har kuni barqaror qayta ishlash mumkin bo'lgan tuzilmani” yaratish edi.
Xususan, katta hajmdagi Full-Load tuzilmasi uchun qayta ishlash samaradorligi va operatsion barqarorlikni ta'minlash juda muhim edi.
Loyihada quyidagi optimallashtirish strategiyalari qo'llanildi.
- Parallel qayta ishlash tuzilmasi
- Hash asosida taqqoslash
- Bosqichma-bosqich tarqatilgan qayta ishlash
- Replica asosidagi yukni taqsimlash
- Kafka asosidagi asinxron qayta ishlash
- Stage asosidagi nosozlik izolyatsiyasi
Ayniqsa Stage asosidagi pipeline tuzilishi operatsion barqarorlik nuqtai nazaridan juda samarali bo'ldi.
Har bir bosqichda loglarni qoldirib, xato yuzaga kelganda o'sha muhitda ishlov berishni to'xtatish bo'yicha loyihalashtirildi.
Ya'ni, noto'g'ri ma'lumotlarning nihoyatgi Ishlayotgan DB ga o'tishining oldini oldik.
Shuningdek, nosozlik yuzaga kelganda administratorlarga avtomatik elektron pochta ogohlantirishlarini yuborib, tezkor javob berish uchun tashkil etilgan.
Bunday tuzilish tufayli operatsion barqarorlikni va ma'lumotlarga ishonchlilikni ham ta'minlash mumkin bo'ldi.
Amaliy loyihalarda yuz milliondan millionlab ma'lumotlarni har kuni barqaror qayta ishlash imkoniyatiga ega bo'lgan samaradorlikni ta'minladik. Eng muhimi, Full-Load asosidagi tuzilma hamda ish holatida ishlash tezligini ta'minlash juda muhim edi.
Shuningdek, Kafka asosidagi tuzilma tufayli ma'lum bir xizmatning ishdan chiqishi butun ma'lumotlar quvuri ishdan chiqishiga tarqalishini oldini olish imkoniyatiga ega bo'ldik.
Natijada loyiha oddiy ETL tizimidan “katta hajmdagi ma'lumotlarni integratsiya платформаси” darajasidagi barqarorlik va kengaytirilishi bilan ta'minlangan.
6. Yakun
Ushbu loyiha oddiy ma'lumotlarni ko'chirish loyihasi emas edi.
Bir necha Legacy tizimlarda tarqalgan katta hajmdagi loyiha boshqaruv ma'lumotlarini bitta markazlashgan platformaga birlashtirish va buning asosida barqaror biznes qarorlarini qo'llab-quvvatlash uchun ma'lumotlarni integratsiya arxitekturasini qurish loyihasi edi.
Xususan eng katta xususiyat Full-Load asosidagi tuzilmani amalda ishlatish mumkin bo'lgan darajada amalga oshirishidir.
Umuman olganda, keng ko'lamli Full-Load tuzilmalari ko'pincha noaniq deb baholanadi, ammo loyihada ma'lumotlar yaxlitligini ustuvor qadriyat sifatida belgilab, arxitekturani shunga muvofiq optimallashtirdik.
Natijada quyidagi natijalarga erishildi.
- Ma'lumotlar to'g'riligi ta'minlandi
- O'chirish ma'lumotini barqaror aks ettirish
- Ishlatish barqarorligini oshirish
- Katta ma'lumotlarni qayta ishlash samaradorligini ta'minlash
- Muammolarni izolyatsiya qilish strukturasini yaratish
- Kengaytiriladigan ma'lumotlar quvurini ta'minlash
Eng muhimi, oddiy texnik amalga oshirishni oshirib, “biznes ishonchliligi” ni ma'lumotlar strukturasiga kafolatlashga urinish edi.
Loyihani amalga oshirayotganda ma'lumotlarni integratsiya qilish faqatgina ma'lumotlarni ko'chirish emas, balki kompaniya qarorlarini qabul qilishning asosini yaratish uchun juda muhim soha ekanligini yana bir bor his qildim.
Bundan tashqari, ushbu tajriba orqali katta ma'lumotlarni qayta ishlash muhitida oddiy so'rovlarni optimallashtirish darajasidan tashqari, butun ma'lumotlar oqimi va arxitekturasini birgalikda loyihalashtirish zarurligini ham chuqur his qildim.
Kelajakda shunga o'xshash katta miqdordagi ma'lumotlarni integratsiya qilish loyihalarini amalga oshirganimizda, ushbu tajriba juda muhim me'zor bo'lishiga ishonaman.
informalife