Komponen ETL dari gudang data sering kali dibayangi oleh gudang itu sendiri dan kurang mendapat perhatian dibandingkan database utama atau komponen front-end, BI, dan pelaporan. Pada saat yang sama, dari sudut pandang mekanisme pengisian gudang dengan data, ETL memainkan peran kunci dan memerlukan perhatian yang tidak kalah pentingnya dari administrator dibandingkan komponen lainnya. Nama saya Alexander, sekarang saya mengelola ETL di Rostelecom, dan dalam artikel ini saya akan mencoba berbagi sedikit tentang apa yang harus dihadapi oleh administrator salah satu sistem ETL paling terkenal di gudang data besar di Rostelecom.
Jika para pembaca yang budiman sudah familiar secara umum dengan proyek gudang data kami dan produk Informatica PowerCenter, maka Anda dapat langsung melanjutkan ke bagian berikutnya.
Beberapa tahun yang lalu, gagasan gudang data perusahaan tunggal matang dan mulai diterapkan di Rostelecom. Sejumlah repositori yang memecahkan permasalahan individual telah dibuat, namun jumlah skenario bertambah, biaya dukungan juga meningkat, dan menjadi jelas bahwa masa depan terletak pada sentralisasi. Secara arsitektural, ini adalah penyimpanan itu sendiri, terdiri dari beberapa lapisan, diimplementasikan pada Hadoop dan GreenPlum, database tambahan, mekanisme ETL, dan BI.
Pada saat yang sama, karena banyaknya sumber data heterogen yang tersebar secara geografis, mekanisme pengunggahan data khusus telah dibuat, yang pengoperasiannya dikendalikan oleh Informatica. Akibatnya, paket data berakhir di area antarmuka Hadoop, setelah itu proses memuat data melalui lapisan penyimpanan, Hadoop dan GreenPlum dimulai, dan dikelola oleh apa yang disebut mekanisme kontrol ETL yang diterapkan di Informatica. Dengan demikian, sistem Informatica merupakan salah satu elemen kunci yang menjamin pengoperasian gudang.
Penyimpanan kami akan dijelaskan lebih detail di salah satu postingan 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 bidang 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 tempat aplikasi Informatica dijalankan, mengimplementasikan layanannya:
Domain, pada kenyataannya, ini adalah dasar dari segalanya; layanan, pengguna, dan komponen GRID beroperasi dalam domain.
Konsol Administrator, alat manajemen dan pemantauan berbasis web, selain klien Pengembang Informatica, alat utama untuk berinteraksi dengan produk
MRS, Layanan Repositori Model, repositori metadata, adalah lapisan antara database tempat metadata disimpan secara fisik dan klien Pengembang Informatica tempat pengembangan berlangsung. Repositori menyimpan deskripsi data dan informasi lainnya, termasuk sejumlah layanan Infromatica lainnya, misalnya jadwal pelaksanaan tugas (Jadwal) atau data pemantauan, serta parameter aplikasi, khususnya yang memungkinkan penggunaan aplikasi yang sama untuk bekerja dengan berbagai sumber dan penerima data.
DIS, Layanan Integrasi Data, ini adalah layanan di mana proses fungsional utama berlangsung, aplikasi berjalan di dalamnya dan peluncuran Alur Kerja yang sebenarnya (deskripsi urutan pemetaan dan interaksinya) dan Pemetaan (transformasi, blok tempat transformasi itu sendiri terjadi, pemrosesan data ) terjadi.
Konfigurasi GRID β pada dasarnya, opsi untuk membangun kompleks menggunakan beberapa server, ketika beban yang diluncurkan oleh DIS didistribusikan ke node (yaitu, server yang merupakan bagian dari domain). Dalam kasus opsi ini, selain mendistribusikan beban di DIS melalui lapisan abstraksi GRID tambahan yang menyatukan beberapa node, di mana DIS berjalan alih-alih bekerja pada satu node tertentu, instance MRS cadangan tambahan juga dapat dibuat. Anda bahkan dapat menerapkan ketersediaan tinggi, di mana panggilan eksternal dapat dilakukan melalui node cadangan jika node utama gagal. Kami telah mengabaikan opsi konstruksi ini untuk saat ini.
Informatica PowerCenter, skema
Pada tahap awal pekerjaan sebagai bagian dari rantai pasokan data, masalah sering muncul, beberapa di antaranya disebabkan oleh ketidakstabilan pengoperasian Informatica pada saat itu. Saya akan membagikan beberapa momen berkesan dari saga ini - menguasai Informatica 10.
Logo bekas Informatica
Area tanggung jawab kami juga mencakup lingkungan Informatica lainnya, mereka memiliki spesifiknya sendiri 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 hal itu terjadi
Pada tahun 2016, ketika kami bertanggung jawab atas pekerjaan Informatica, itu sudah mencapai versi 10.0, dan bagi rekan-rekan optimis yang memutuskan untuk menggunakan produk dengan versi minor .0 dalam solusi serius, semuanya tampak jelas - kami perlu menggunakan versi baru! Dari sudut pandang sumber daya perangkat keras, semuanya baik-baik saja pada saat itu.
Sejak musim semi tahun 2016, seorang kontraktor bertanggung jawab atas pekerjaan Informatica, dan menurut beberapa pengguna sistem, βsistem ini bekerja beberapa kali seminggu.β Di sini perlu diklarifikasi bahwa repositori tersebut secara de facto berada pada tahap PoC, tidak ada administrator dalam tim dan sistem terus-menerus mogok karena berbagai alasan, setelah itu teknisi kontraktor mengambilnya kembali.
Pada musim gugur, tiga administrator bergabung dengan tim, membagi wilayah tanggung jawab mereka di antara mereka sendiri, dan pekerjaan normal mulai mengatur pengoperasian sistem dalam proyek, termasuk Informatica. Secara terpisah, harus dikatakan bahwa produk ini tidak tersebar luas dan memiliki komunitas besar di mana Anda dapat menemukan jawaban atas pertanyaan apa pun dan menyelesaikan masalah apa pun. Oleh karena itu, dukungan teknis penuh dari mitra Rusia Informatica sangat penting, yang dengannya semua kesalahan kami dan kesalahan Informatica 10 yang masih muda diperbaiki.
Hal pertama yang harus kami lakukan untuk pengembang tim kami dan kontraktor adalah menstabilkan pekerjaan Informatica itu sendiri, untuk memastikan fungsionalitas konsol administrasi web (Administrator Informatica).
Ini adalah bagaimana kami sering bertemu dengan pengembang Informatica
Terlepas dari proses mencari tahu alasannya, penyebab utama crash adalah pola interaksi perangkat lunak Informatica dengan database repositori, yang terletak di server yang relatif jauh, dari sudut pandang lanskap jaringan. Hal ini menyebabkan penundaan dan mengganggu mekanisme yang memantau keadaan domain Informatica. Setelah beberapa penyetelan database, mengubah parameter Informatica, yang membuatnya lebih toleran terhadap penundaan database, dan akhirnya memperbarui versi Informatica ke 10.1 dan mentransfer database dari server sebelumnya ke server yang berlokasi lebih dekat dengan Informatica, masalahnya hilang. relevansinya, dan sejak itu telah terjadi kerusakan seperti ini yang tidak kami amati.
Salah satu upaya agar Informatica Monitor berfungsi
Situasi dengan konsol administrasi juga kritis. Karena pengembangan aktif sedang dilakukan secara langsung pada lingkungan yang relatif produktif, para kolega terus-menerus perlu menganalisis pekerjaan pemetaan dan alur kerja βsaat bepergian.β Di Informatica baru, Layanan Integrasi Data tidak memiliki alat terpisah untuk pemantauan tersebut, tetapi bagian pemantauan telah muncul di konsol web administrasi (Informatica Administrator Monitor), di mana Anda dapat memantau pengoperasian aplikasi, alur kerja, dan pemetaan, peluncuran, log. Secara berkala, konsol menjadi tidak tersedia sama sekali, atau informasi tentang proses saat ini di DIS berhenti diperbarui, atau terjadi kesalahan saat memuat halaman.
Pemilihan parameter java untuk menstabilkan operasi
Masalahnya diperbaiki dengan banyak cara, percobaan dilakukan untuk mengubah parameter, log dan jstack dikumpulkan, dikirim ke dukungan, pada saat yang sama ada googling aktif dan observasi sederhana.
Pertama-tama, MRS terpisah diciptakan untuk pemantauan; ternyata kemudian, ini adalah salah satu konsumen utama sumber daya di lingkungan kita, karena pemetaan diluncurkan dengan sangat intensif. Parameter mengenai java heap dan sejumlah parameter lainnya telah diubah.
Hasilnya, pada pembaruan berikutnya Informatica 10.1.1, pengoperasian konsol dan monitor menjadi stabil, pengembang mulai bekerja lebih efisien, dan proses reguler menjadi semakin teratur.
Pengalaman interaksi antara pembangunan dan administrasi mungkin menarik. Masalah pemahaman umum tentang cara kerja, apa yang bisa dilakukan dan apa yang tidak bisa dilakukan, selalu penting ketika menggunakan sistem yang kompleks. Oleh karena itu, kami dapat dengan aman menyarankan agar Anda terlebih dahulu melatih tim administratif tentang cara mengelola perangkat lunak, dan tim pengembangan tentang cara menulis kode dan menggambar proses dalam sistem, dan baru kemudian mengirimkan tim pertama dan kedua untuk mengerjakan hasilnya. Hal ini sangat penting ketika waktu bukanlah sumber daya yang tidak terbatas. Banyak masalah dapat diselesaikan bahkan dengan pencarian pilihan secara acak, tetapi terkadang beberapa masalah memerlukan pengetahuan apriori - kasus kami menegaskan pentingnya memahami aksioma ini.
Misalnya, ketika kami mencoba mengaktifkan pembuatan versi di MRS (ternyata pada akhirnya, diperlukan versi SVN yang berbeda), setelah beberapa waktu kami terkejut menemukan bahwa waktu restart sistem telah meningkat menjadi beberapa puluh menit. Setelah menemukan alasan penundaan dalam memulai dan menonaktifkan versi, kami melakukannya dengan baik lagi.
Hambatan penting yang terkait dengan Informatica termasuk pertempuran epik dengan berkembangnya java thread. Pada titik tertentu, waktunya telah tiba untuk replikasi, yaitu memperluas proses yang sudah ada ke sejumlah besar sistem sumber. Ternyata tidak semua proses di 10.1.1 bekerja dengan baik, dan setelah beberapa waktu DIS tidak dapat dioperasikan. Puluhan ribu thread terdeteksi, jumlahnya bertambah terutama selama prosedur penerapan aplikasi. Terkadang saya harus memulai ulang beberapa kali sehari untuk memulihkan fungsionalitas.
Di sini kita perlu berterima kasih kepada dukungannya; masalah dapat dilokalisasi dan diperbaiki dengan relatif cepat menggunakan EBF (Perbaikan Bug Darurat) - setelah itu, semua orang merasa bahwa alat tersebut benar-benar berfungsi.
Ini masih berfungsi!
Saat kami mulai bekerja dalam mode target, Informatica terlihat seperti ini. Versi Informatica 10.1.1HF1 (HF1 adalah HotFix1, rakitan vendor dari kompleks EBF) dengan EBF tambahan yang diinstal, yang memperbaiki masalah penskalaan kami dan beberapa lainnya, pada satu dari tiga server yang merupakan bagian dari GRID, 20 x86_64 core dan penyimpanan, pada sejumlah besar disk lokal yang lambat - ini adalah konfigurasi server untuk cluster Hadoop. Di server lain yang serupa - Oracle DBMS yang bekerja dengan domain Informatica dan mekanisme kontrol ETL. Semua ini dipantau oleh alat pemantauan standar yang digunakan dalam tim (Zabbix + Grafana) di kedua sisi - Informatica sendiri dengan layanannya, dan proses pemuatan yang masuk ke dalamnya. Kini baik performa maupun stabilitas, tanpa memperhitungkan faktor eksternal, kini bergantung pada pengaturan yang membatasi beban.
Secara terpisah, kita dapat mengatakan tentang GRID. Lingkungan dibangun pada tiga node, dengan kemungkinan penyeimbangan beban. Namun, selama pengujian, ditemukan bahwa karena masalah interaksi antara instance aplikasi kami yang berjalan, konfigurasi ini tidak berfungsi seperti yang diharapkan, dan mereka memutuskan untuk meninggalkan skema konstruksi ini untuk sementara, menghapus dua dari tiga node dari domain. Pada saat yang sama, skema itu sendiri tetap sama, dan sekarang menjadi layanan GRID, tetapi merosot menjadi satu node.
Saat ini, kesulitannya tetap terkait dengan penurunan kinerja saat membersihkan sirkuit monitor secara teratur - dengan proses simultan di CNN dan menjalankan pembersihan, kegagalan fungsi dalam pengoperasian mekanisme kontrol ETL dapat terjadi. Hal ini saat ini sedang diselesaikan "sebagai penopang" - dengan membersihkan sirkuit monitor secara manual, dengan hilangnya semua data sebelumnya. Hal ini tidak terlalu penting untuk produktivitas, selama pengoperasian rutin normal, namun untuk saat ini pencarian solusi normal sedang dilakukan.
Masalah lain muncul dari situasi yang sama - terkadang terjadi beberapa kali peluncuran mekanisme kontrol kami.
Peluncuran beberapa aplikasi menyebabkan kegagalan mekanisme
Ketika berjalan sesuai jadwal, pada saat beban berat pada sistem, terkadang terjadi situasi yang menyebabkan rusaknya mekanisme. Masalahnya masih diperbaiki secara manual, dan solusi permanen sedang dicari.
Secara umum dapat kita simpulkan bahwa ketika ada beban yang berat maka sangat penting untuk menyediakan resource yang memadai, hal ini juga berlaku untuk resource hardware untuk Informatica itu sendiri, begitu pula untuk repositori database-nya, serta memberikan pengaturan yang optimal. untuk mereka. Selain itu, pertanyaannya tetap terbuka mengenai skema penempatan database mana yang lebih baik - pada host terpisah, atau pada host yang sama tempat perangkat lunak Informatica dijalankan. Di satu sisi, akan lebih murah di satu server, dan bila digabungkan, kemungkinan masalah dengan interaksi jaringan praktis dihilangkan; di sisi lain, beban pada host dari database ditambah dengan beban dari Informatica.
Seperti halnya produk serius lainnya, Informatica juga memiliki momen lucu.
Suatu kali, ketika sedang memilah suatu kecelakaan, saya memperhatikan bahwa log MRS secara aneh menunjukkan waktu kejadian.
Dualisme temporal dalam catatan MRS βberdasarkan desainβ
Ternyata stempel waktu ditulis dalam format 12 jam, tanpa menyebutkan AM/PM, yaitu sebelum siang atau sesudahnya. Sebuah aplikasi bahkan dibuka mengenai masalah ini, dan tanggapan resmi telah diterima - begitulah yang dimaksudkan, tanda ditulis di log MRS dengan format yang persis seperti ini. Artinya, terkadang masih ada intrik mengenai waktu terjadinya beberapa KESALAHAN...
Berusahalah untuk yang terbaik
Saat ini, Informatica adalah alat yang cukup stabil, nyaman bagi administrator dan pengguna, dan sangat kuat dalam hal kemampuan dan potensinya saat ini. Ini melebihi kebutuhan fungsional kami berkali-kali dan secara de facto sekarang digunakan dalam proyek dengan cara yang tidak biasa dan khas. Kesulitannya sebagian terkait dengan cara kerja mekanisme - hal spesifiknya adalah bahwa dalam waktu singkat sejumlah besar thread diluncurkan yang secara intensif memperbarui parameter dan bekerja dengan database repositori, sementara sumber daya perangkat keras server digunakan hampir seluruhnya. oleh CPU.
Kami sekarang hampir berpindah ke Informatica 10.2.1 atau 10.2.2, yang telah mengerjakan ulang beberapa mekanisme internal dan janji dukungan untuk menghilangkan beberapa masalah kinerja dan fungsionalitas yang kami miliki saat ini. Dan dari sudut pandang perangkat keras, kami mengharapkan server dengan konfigurasi optimal, dengan mempertimbangkan cadangan dalam waktu dekat karena pertumbuhan dan perkembangan penyimpanan.
Tentu saja, akan ada pengujian, pemeriksaan kompatibilitas, dan kemungkinan perubahan arsitektur di bagian HA GRID. Pengembangan dalam Informatica akan terus berlanjut, karena dalam jangka pendek kami tidak dapat menyediakan apa pun untuk menggantikan sistem tersebut.
Dan mereka yang akan bertanggung jawab atas sistem ini di masa depan pasti akan mampu membawanya ke indikator keandalan dan kinerja yang dikehendaki oleh pelanggan.
Artikel ini disiapkan oleh tim manajemen data Rostelecom
Logo Informatica saat ini
Sumber: www.habr.com