Dari crash harian hingga stabilitas: Informatica dengan 10 mata admin

Komponen ETL dari gudang data sering kali berada dalam bayang-bayang gudang itu sendiri dan lebih sedikit perhatian diberikan untuk itu daripada database utama atau komponen depan, BI, pelaporan. Pada saat yang sama, dari sudut pandang mekanisme pengisian data warehouse, ETL memainkan peran kunci dan membutuhkan perhatian yang tidak kurang dari administrator daripada komponen lainnya. Nama saya Alexander, saya saat ini mengelola ETL di Rostelecom, dan dalam artikel ini saya akan mencoba berbagi sedikit dengan apa yang administrator dari sistem ETL paling terkenal di gudang data besar Rostelecom harus berurusan dengan.

Jika pembaca yang budiman sudah terbiasa dengan proyek data warehouse kami dan produk Informatica PowerCenter secara umum, Anda dapat melompat ke bagian selanjutnya.

Beberapa tahun yang lalu, gagasan gudang data perusahaan tunggal jatuh tempo dan mulai diberlakukan di Rostelecom. Sejumlah penyimpanan yang menyelesaikan tugas individu telah dibuat, tetapi jumlah skenario bertambah, biaya dukungan juga meningkat, dan menjadi jelas bahwa masa depan terpusat. Secara arsitektur, ini adalah repositori itu sendiri, yang terdiri dari beberapa lapisan, diimplementasikan pada Hadoop dan GreenPlum, database tambahan, mekanisme ETL, dan BI.

Pada saat yang sama, karena sejumlah besar sumber data yang tersebar secara geografis dan heterogen, mekanisme pengunggahan data khusus dibuat, pekerjaan yang dikendalikan oleh Informatica. Akibatnya, paket data berakhir di area ujung depan Hadoop, setelah itu proses pemuatan data melalui lapisan penyimpanan, di Hadoop dan GreenPlum, dimulai, dan mereka dikendalikan oleh apa yang disebut mekanisme kontrol ETL yang diterapkan di Informatica. Dengan demikian, sistem Informatica adalah salah satu elemen kunci yang memastikan operasi penyimpanan.

Rincian lebih lanjut tentang penyimpanan kami akan dibahas di salah satu posting berikut.

Informatica PowerCenter / Big Data Management saat ini dianggap sebagai perangkat lunak terkemuka di bidang alat integrasi data. Ini adalah produk dari perusahaan Amerika Informatica, yang merupakan salah satu pemain terkuat di ETL (Extract Transform Load), manajemen kualitas data, MDM (Master Data Management), ILM (Information Lifecycle Management) dan banyak lagi.

PowerCenter yang kami gunakan adalah server aplikasi Tomcat terintegrasi, di mana aplikasi Informatica beroperasi sendiri, mengimplementasikan layanannya:

Domain , pada kenyataannya, adalah dasar untuk segala sesuatu yang lain, dalam domain, layanan, pengguna, dan komponen GRID bekerja.

Administrator Console , alat manajemen dan pemantauan berbasis web, di samping klien Pengembang Informatica, alat utama untuk berinteraksi dengan produk

MRS, Model Repository Service , repositori metadata, adalah lapisan antara database di mana metadata disimpan secara fisik dan klien Pengembang Informatica di mana ia sedang dikembangkan. Gudang menyimpan deskripsi data dan informasi lainnya, termasuk untuk sejumlah layanan Infromatica lainnya, misalnya, Jadwal untuk meluncurkan tugas atau memantau data, serta parameter aplikasi, khususnya, memungkinkan untuk menggunakan aplikasi yang sama untuk pekerjaan dengan berbagai sumber data dan penerima.

DIS, Layanan Integrasi Data , adalah layanan di mana proses fungsional utama berlangsung, aplikasi bekerja di dalamnya dan peluncuran Workflow yang sebenarnya (deskripsi urutan pemetaan dan interaksinya) dan Pemetaan (transformasi, blok di mana transformasi itu sendiri terjadi, pemrosesan data) terjadi.

Konfigurasi GRID , pada kenyataannya, merupakan pilihan untuk membangun kompleks menggunakan beberapa server, ketika beban diluncurkan oleh DIS didistribusikan di antara node (yaitu, server yang merupakan bagian dari domain). Dalam hal opsi ini, selain mendistribusikan beban ke DIS melalui lapisan abstraksi GRID tambahan, menggabungkan beberapa node, di mana DIS bekerja alih-alih bekerja pada node tunggal tertentu, instance MRS cadangan tambahan juga dapat dibuat. Anda bahkan dapat menerapkan ketersediaan tinggi ketika panggilan eksternal dapat dilakukan melalui node cadangan jika terjadi kegagalan primer. Kami sejauh ini menolak opsi konstruksi semacam itu.


Informatica PowerCenter, skematis

Pada tahap pertama pekerjaan, masalah muncul secara teratur dalam rantai pasokan data, beberapa di antaranya karena pekerjaan Informatica yang tidak stabil pada waktu itu. Saya akan membagikan beberapa momen yang tak terlupakan dari kisah ini - perkembangan Informatica 10.


Logo mantan Informatica

Lingkungan Informatica lainnya juga merupakan bagian dari area tanggung jawab kami, mereka memiliki kekhasan masing-masing karena beban yang berbeda, tetapi untuk saat ini saya akan mengingat dengan tepat bagaimana Informatica berkembang sebagai komponen ETL dari gudang data itu sendiri.

Bagaimana itu bisa terjadi?

Pada 2016, ketika kami bertanggung jawab atas Informatica, sudah mencapai versi 10.0, dan untuk rekan-rekan yang optimis yang memutuskan untuk menggunakan produk dengan versi minor .0 dalam solusi serius, semuanya tampak jelas - Anda harus menggunakan versi baru! Dari sudut pandang sumber daya perangkat keras, semuanya sangat baik pada saat itu.

Sejak musim semi 2016, kontraktor bertanggung jawab atas pekerjaan Informatica, dan menurut beberapa pengguna sistem, "itu bekerja beberapa kali seminggu". Di sini perlu dijelaskan bahwa penyimpanan adalah de facto pada tahap PoC, tidak ada administrator dalam tim dan sistem terus-menerus macet karena berbagai alasan, setelah itu insinyur kontraktor mengangkatnya lagi.

Pada musim gugur, tiga administrator muncul di tim, berbagi tanggung jawab mereka dan mulai mengatur kerja normal pada sistem operasi dalam proyek, termasuk Informatica. Secara terpisah, harus dikatakan bahwa produk ini tidak tersebar luas dan memiliki komunitas besar di mana Anda dapat menemukan jawaban untuk pertanyaan apa pun dan menyelesaikan masalah apa pun. Oleh karena itu, dukungan teknis lengkap dari mitra Rusia Informatica sangat penting, dengan bantuan yang semua kesalahan kami dan kesalahan dari Informatca 10 muda diperbaiki.

Hal pertama yang harus kami lakukan untuk pengembang tim dan kontraktor kami adalah menstabilkan pekerjaan Informatica itu sendiri, untuk membuat konsol administrasi berbasis web (Administrator Informatika) beroperasi.


Jadi kami sering bertemu pengembang Informatica

Mengesampingkan proses mencari tahu penyebabnya, alasan utama crash adalah interaksi antara perangkat lunak Informatica dan database repositori yang terletak di server yang relatif jauh dari sudut pandang lanskap jaringan. Hal ini menyebabkan keterlambatan dan mengganggu mekanisme untuk memantau status domain Informatica. Setelah beberapa penyetelan database, mengubah parameter Informatica, yang membuatnya lebih toleran terhadap keterlambatan database, dan sebagai akibat dari memperbarui versi Informatica ke 10.1 dan mentransfer database dari server sebelumnya ke server yang terletak lebih dekat ke Informatica, masalahnya telah kehilangan relevansinya, dan sejak itu terjadi semacam crash kami tidak mengamati.


Salah satu upaya untuk membuat Monitor Informatica berfungsi

Dengan konsol administrasi, situasinya juga kritis. Karena ada pengembangan aktif tepat di lingkungan yang kondisional produktif, kolega terus-menerus perlu menganalisis pekerjaan pemetaan, alur kerja "saat bepergian". Di Informatica baru, Layanan Integrasi Data tidak memiliki alat terpisah untuk pemantauan tersebut, tetapi bagian pemantauan (Informatica Administrator Monitor) telah muncul di konsol web administrasi, di mana Anda dapat mengamati pengoperasian aplikasi, alur kerja dan pemetaan, mulai, log. Secara berkala, konsol menjadi benar-benar tidak tersedia, atau informasi tentang proses saat ini dalam DIS tidak lagi diperbarui, atau kesalahan terjadi saat memuat halaman.


Pemilihan parameter java untuk menstabilkan pekerjaan

Masalahnya diperbaiki dalam banyak cara, percobaan dilakukan untuk mengubah parameter, log dikumpulkan, jstack dikirim untuk mendukung, googling aktif sedang berlangsung pada saat yang sama dan pengamatan baru saja dilakukan.

Pertama-tama, MRS terpisah dibuat untuk pemantauan, karena nantinya menjadi salah satu konsumen utama sumber daya di lingkungan kita, karena pemetaan diluncurkan sangat intensif. Parameter tentang heap java, dan sejumlah lainnya diubah.
Akibatnya, pembaruan berikutnya ke Informatica 10.1.1 berhasil menstabilkan konsol dan monitor, pengembang mulai bekerja lebih efisien, dan proses reguler menjadi lebih teratur.

Pengalaman interaksi antara pengembangan dan administrasi mungkin menarik. Pertanyaan tentang pemahaman bersama tentang bagaimana segala sesuatu bekerja, apa yang bisa dan tidak bisa dilakukan, selalu penting ketika menggunakan sistem yang kompleks. Oleh karena itu, kami dapat dengan aman merekomendasikan agar Anda terlebih dahulu melatih tim administrasi tentang cara mengelola perangkat lunak, dan tim pengembangan tentang cara menulis kode dan menggambar proses dalam sistem, dan hanya kemudian mengirim yang pertama dan kedua untuk mengerjakan hasilnya. Ini sangat penting ketika waktu bukanlah sumber daya yang tidak ada habisnya. Banyak masalah dapat diselesaikan bahkan dengan penghitungan opsi secara acak, tetapi kadang-kadang beberapa membutuhkan pengetahuan apriori - kasus kami menegaskan pentingnya memahami aksioma ini.

Sebagai contoh, ketika kami mencoba memasukkan versi dalam MRS (ternyata, kami membutuhkan versi SVN yang berbeda), setelah beberapa waktu kami ingin menemukan bahwa waktu restart sistem meningkat hingga beberapa puluh menit. Pergi ke penyebab mulai terlambat dan menonaktifkan versi, mereka melakukannya dengan baik lagi.

Dari hambatan-hambatan penting yang terkait dengan Informatica, orang dapat mengingat pertempuran epik dengan aliran java yang tumbuh. Pada titik tertentu, saatnya tiba untuk replikasi, yaitu, untuk memperluas proses yang telah ditetapkan ke sejumlah besar sistem sumber. Ternyata tidak semua proses di 10.1.1 bekerja dengan baik, dan setelah beberapa waktu, DIS menjadi tidak beroperasi. Puluhan ribu utas terdeteksi, jumlah mereka tumbuh terutama selama prosedur penerapan aplikasi. Terkadang perlu untuk memulai kembali beberapa kali sehari untuk memulihkan kinerja.

Di sini Anda perlu berterima kasih atas dukungannya, masalahnya relatif cepat dilokalisasi dan diperbaiki menggunakan EBF (Emergency Bug Fix) - setelah semua orang merasa alat itu benar-benar berfungsi.

Itu masih berfungsi!

Pada saat pekerjaan dimulai dalam mode target, Informatica tampak sebagai berikut. Informatica versi 10.1.1HF1 (HF1 adalah HotFix1, rakitan vendor dari kompleks EBF) yang diinstal dengan EBF tambahan yang memperbaiki masalah penskalaan kami dan beberapa lainnya, pada salah satu dari tiga server GRID, 20 inti x86_64 dan penyimpanan, di array lambat besar disk lokal - ini adalah konfigurasi server untuk cluster Hadoop. Di server lain dari jenis yang sama, Oracle DBMS dengan mana domain Informatica dan mekanisme kontrol ETL bekerja. Semua ini dipantau oleh alat pemantauan standar yang digunakan dalam tim (Zabbix + Grafana), di kedua sisi - Informatica sendiri dengan layanannya, dan proses pemuatan masuk ke dalamnya. Sekarang baik kinerja dan stabilitas, tanpa memperhitungkan faktor-faktor eksternal, sekarang tergantung pada pengaturan yang membatasi beban.

Secara terpisah, kita dapat mengatakan tentang GRID. Lingkungan dibangun di atas tiga simpul, dengan kemungkinan penyeimbangan muatan. Namun, selama pengujian, ditemukan bahwa karena masalah interaksi antara instance yang berjalan dari aplikasi kami, konfigurasi ini tidak berfungsi seperti yang diharapkan, dan untuk sementara waktu memutuskan untuk meninggalkan skema konstruksi ini dengan menghapus dua dari tiga node dari domain. Pada saat yang sama, skema itu sendiri tetap sama, dan sekarang ini adalah layanan GRID, tetapi merosot menjadi satu node.

Saat ini, masih ada kerumitan yang terkait dengan penurunan kinerja selama pembersihan rutin sirkuit monitor - dengan proses simultan di CNN dan pembersihan berjalan, kegagalan fungsi dalam operasi mekanisme kontrol ETL dapat terjadi. Sejauh ini sedang diselesaikan oleh "crutch" - pembersihan manual dari rangkaian monitor, dengan hilangnya semua data sebelumnya. Ini tidak terlalu penting untuk produk, dengan pekerjaan penuh-waktu normal, tetapi sejauh ini pencarian untuk solusi normal sedang berlangsung.

Masalah lain muncul dari situasi yang sama - terkadang beberapa peluncuran mekanisme kontrol kami terjadi.


Peluncuran beberapa aplikasi, yang menyebabkan kerusakan mekanisme

Ketika memulai sesuai dengan jadwal pada saat beban berat pada sistem, situasi yang menyebabkan kerusakan mekanisme terkadang terjadi. Sampai sekarang, masalahnya telah diperbaiki secara manual, solusi permanen sedang dicari.

Secara umum, dapat diringkas bahwa di bawah beban berat sangat penting untuk menyediakan sumber daya yang memadai untuk itu, ini juga berlaku untuk sumber daya perangkat keras untuk Informatica itu sendiri, dan hal yang sama untuk repositori basis datanya, serta untuk memastikan pengaturan optimal bagi mereka. Selain itu, pertanyaannya tetap tentang tata letak database mana yang lebih baik - pada host yang terpisah, atau pada yang sama di mana perangkat lunak Informatica bekerja. Di satu sisi, itu akan lebih murah di satu server, dan ketika dikombinasikan, masalah yang mungkin terjadi dengan interaksi jaringan secara praktis dihilangkan, di sisi lain, beban pada host dari database ditambah dengan beban dari Informatica.

Seperti halnya produk serius, Informatica memiliki beberapa momen yang aneh.
Suatu ketika, menganalisis semacam kecelakaan, saya perhatikan bahwa waktu kejadian sangat aneh di log MRS.


Dualisme sementara dalam log MRS “sesuai desain”

Ternyata cap waktu ditulis dalam format 12 jam, tanpa menentukan AM / PM, yaitu, sebelum siang atau sesudahnya. Aplikasi bahkan dibuka pada subjek ini, dan tanggapan resmi diterima - itu sudah direncanakan, tanda-tanda dalam log MRS ditulis dalam format ini. Artinya, terkadang masih ada beberapa intrik mengenai waktu terjadinya beberapa ERROR ...

Berusaha keras untuk yang terbaik

Today Informatica adalah alat yang cukup stabil, nyaman bagi administrator dan pengguna, sangat kuat dalam hal kemampuan dan potensi saat ini. Ini berkali-kali melebihi secara fungsional kebutuhan kita dan sekarang secara de facto digunakan dalam proyek dengan cara yang tidak terlalu khas dan khas. Bagian dari kesulitannya adalah bagaimana mekanisme bekerja - kekhususan adalah bahwa sejumlah besar utas diluncurkan dalam waktu singkat, yang secara intensif memperbarui parameter dan bekerja dengan basis data repositori, sementara sumber daya perangkat keras server hampir sepenuhnya digunakan oleh CPU.

Sekarang kita hampir beralih ke Informatica 10.2.1 atau 10.2.2, di mana beberapa mekanisme internal telah dirancang ulang, dan dukungan menjanjikan tidak adanya sejumlah masalah saat ini dengan kinerja dan fungsi. Dan dari sudut pandang perangkat keras, server diharapkan menjadi optimal bagi kami, mengingat margin untuk waktu dekat karena pertumbuhan dan perkembangan penyimpanan.

Tentu saja, pengujian, pengujian kompatibilitas, dan kemungkinan perubahan arsitektur di bagian HA GRID ada di depan. Pengembangan di dalam Informatica akan berlanjut, karena dalam jangka pendek kita tidak dapat meletakkan apa pun untuk menggantikan sistem.
Dan mereka yang akan terus bertanggung jawab atas sistem ini tentu akan dapat membawanya ke keandalan yang dibutuhkan dan indikator kinerja yang diajukan oleh pelanggan.

Artikel ini disiapkan oleh tim manajemen data Rostelecom


Logo Informatica aktual