Komponen ETL bagi gudang data sering dibayangi oleh gudang itu sendiri dan kurang mendapat perhatian daripada pangkalan data utama atau komponen bahagian hadapan, BI dan pelaporan. Pada masa yang sama, dari sudut pandangan mekanik mengisi gudang dengan data, ETL memainkan peranan penting dan memerlukan perhatian yang tidak kurang daripada pentadbir berbanding komponen lain. Nama saya Alexander, saya kini mentadbir ETL di Rostelecom, dan dalam artikel ini saya akan cuba berkongsi sedikit perkara yang perlu ditangani oleh pentadbir salah satu sistem ETL yang paling terkenal dalam gudang data besar di Rostelecom.
Jika pembaca yang dihormati sudah biasa secara umum dengan projek gudang data kami dan dengan produk Informatica PowerCenter, maka anda boleh terus ke bahagian seterusnya.
Beberapa tahun yang lalu, idea satu gudang data korporat telah matang dan mula dilaksanakan di Rostelecom. Sejumlah repositori yang menyelesaikan masalah individu telah pun dibuat, tetapi bilangan senario meningkat, kos sokongan juga meningkat, dan menjadi jelas bahawa masa depan terletak pada pemusatan. Dari segi seni bina, ini adalah storan itu sendiri, yang terdiri daripada beberapa lapisan, dilaksanakan pada Hadoop dan GreenPlum, pangkalan data tambahan, mekanisme ETL dan BI.
Pada masa yang sama, disebabkan sejumlah besar sumber data heterogen yang diedarkan secara geografi, mekanisme muat naik data khas telah dicipta, operasinya dikawal oleh Informatica. Akibatnya, pakej data berakhir di kawasan antara muka Hadoop, selepas itu proses memuatkan data melalui lapisan storan, Hadoop dan GreenPlum bermula, dan ia diuruskan oleh apa yang dipanggil mekanisme kawalan ETL yang dilaksanakan dalam Informatica. Oleh itu, sistem Informatica adalah salah satu elemen utama yang memastikan operasi gudang.
Storan kami akan diterangkan dengan lebih terperinci dalam salah satu siaran berikut.
Informatica PowerCenter/Pengurusan Data Besar pada masa ini dianggap sebagai perisian terkemuka dalam bidang alat penyepaduan data. Ini adalah produk syarikat Amerika Informatica, yang merupakan salah satu pemain terkuat dalam ETL (Extract Transform Load), pengurusan kualiti data, MDM (Master Data Management), ILM (Information Lifecycle Management) dan banyak lagi.
PowerCenter yang kami gunakan ialah pelayan aplikasi Tomcat bersepadu yang mana aplikasi Informatica sendiri dijalankan, melaksanakan perkhidmatannya:
domain, sebenarnya, ini adalah asas untuk semua perkhidmatan, pengguna dan komponen GRID beroperasi dalam domain.
Konsol Pentadbir, alat pengurusan dan pemantauan berasaskan web, sebagai tambahan kepada pelanggan Pembangun Informatica, alat utama untuk berinteraksi dengan produk
PUAN, Perkhidmatan Repositori Model, repositori metadata, ialah lapisan antara pangkalan data di mana metadata disimpan secara fizikal dan klien Informatica Developer di mana pembangunan sedang berlaku. Repositori menyimpan perihalan data dan maklumat lain, termasuk untuk beberapa perkhidmatan Infromatica lain, contohnya, jadual untuk menjalankan tugas (Jadual) atau data pemantauan, serta parameter aplikasi, khususnya, membenarkan penggunaan aplikasi yang sama untuk bekerja dengan pelbagai sumber data dan penerima.
DIS, Perkhidmatan Penyepaduan Data, ini ialah perkhidmatan di mana proses berfungsi utama berlaku, aplikasi dijalankan di dalamnya dan pelancaran sebenar Aliran Kerja (penerangan urutan pemetaan dan interaksinya) dan Pemetaan (transformasi, blok di mana transformasi itu sendiri berlaku, pemprosesan data ) ambil tempat.
Konfigurasi GRID – pada asasnya, pilihan untuk membina kompleks menggunakan beberapa pelayan, apabila beban yang dilancarkan oleh DIS diedarkan di antara nod (iaitu, pelayan yang merupakan sebahagian daripada domain). Dalam kes pilihan ini, selain mengagihkan beban dalam DIS melalui lapisan abstraksi GRID tambahan yang menyatukan beberapa nod, di mana DIS berjalan dan bukannya bekerja pada nod tunggal tertentu, contoh MRS sandaran tambahan juga boleh dibuat. Anda juga boleh melaksanakan ketersediaan tinggi, di mana panggilan luaran boleh dibuat melalui nod sandaran jika nod utama gagal. Kami telah meninggalkan pilihan pembinaan ini buat masa ini.
Informatica PowerCenter, skema
Pada peringkat awal kerja sebagai sebahagian daripada rantaian bekalan data, masalah kerap timbul, beberapa daripadanya disebabkan oleh operasi Informatica yang tidak stabil pada masa itu. Saya akan berkongsi beberapa detik yang tidak dapat dilupakan dalam saga ini - menguasai Informatica 10.
Bekas logo Informatica
Bidang tanggungjawab kami juga termasuk persekitaran Informatica yang lain, mereka mempunyai spesifikasi mereka sendiri kerana beban yang berbeza, tetapi buat masa ini saya akan ingat dengan tepat bagaimana Informatica dibangunkan sebagai komponen ETL dari gudang data itu sendiri.
Bagaimana ini berlaku
Pada tahun 2016, apabila kami bertanggungjawab untuk kerja Informatica, ia telah pun mencapai versi 10.0, dan untuk rakan sekerja optimistik yang memutuskan untuk menggunakan produk dengan versi kecil .0 dalam penyelesaian yang serius, semuanya kelihatan jelas - kami perlu menggunakan versi baharu! Dari sudut sumber perkakasan, semuanya baik-baik saja pada masa itu.
Sejak musim bunga 2016, kontraktor telah bertanggungjawab untuk kerja Informatica, dan menurut beberapa pengguna sistem, "ia berfungsi beberapa kali seminggu." Di sini adalah perlu untuk menjelaskan bahawa repositori adalah de facto pada peringkat PoC, tiada pentadbir dalam pasukan dan sistem sentiasa ranap atas pelbagai sebab, selepas itu jurutera kontraktor mengambilnya semula.
Pada musim gugur, tiga pentadbir menyertai pasukan itu, membahagikan bidang tanggungjawab mereka antara mereka sendiri, dan kerja biasa mula mengatur operasi sistem dalam projek itu, termasuk Informatica. Secara berasingan, mesti dikatakan bahawa produk ini tidak meluas dan mempunyai komuniti yang besar di mana anda boleh mencari jawapan kepada sebarang soalan dan menyelesaikan sebarang masalah. Oleh itu, sokongan teknikal penuh daripada rakan kongsi Informatica Rusia adalah sangat penting, dengan bantuan semua kesilapan dan kesilapan kami Informatica 10 yang masih muda telah diperbetulkan.
Perkara pertama yang perlu kami lakukan untuk pembangun pasukan kami dan kontraktor adalah untuk menstabilkan kerja Informatica itu sendiri, untuk memastikan kefungsian konsol pentadbiran web (Informatica Administrator).
Beginilah cara kami sering bertemu dengan pembangun Informatica
Mengetepikan proses mencari sebab, sebab utama ranap sistem adalah corak interaksi perisian Informatica dengan pangkalan data repositori, yang terletak pada pelayan yang agak jauh, dari sudut pandangan landskap rangkaian. Ini menyebabkan kelewatan dan mengganggu mekanisme yang memantau keadaan domain Informatica. Selepas beberapa penalaan pangkalan data, menukar parameter Informatica, yang menjadikannya lebih bertolak ansur dengan kelewatan pangkalan data, dan akhirnya mengemas kini versi Informatica kepada 10.1 dan memindahkan pangkalan data dari pelayan sebelumnya ke pelayan yang terletak lebih dekat dengan Informatica, masalahnya hilang. perkaitan, dan sejak itu terdapat ranap jenis ini yang tidak kami perhatikan.
Salah satu percubaan untuk mendapatkan Informatica Monitor berfungsi
Keadaan dengan konsol pentadbiran juga kritikal. Memandangkan pembangunan aktif sedang dijalankan secara langsung pada persekitaran yang agak produktif, rakan sekerja sentiasa perlu menganalisis kerja pemetaan dan aliran kerja "sedang dalam perjalanan". Dalam Informatica baharu, Perkhidmatan Integrasi Data tidak mempunyai alat yang berasingan untuk pemantauan sedemikian, tetapi bahagian pemantauan telah muncul dalam konsol web pentadbiran (Informatica Administrator Monitor), di mana anda boleh memantau operasi aplikasi, aliran kerja dan pemetaan, pelancaran, log. Secara berkala, konsol menjadi tidak tersedia sepenuhnya, atau maklumat tentang proses semasa dalam DIS berhenti mengemas kini, atau ralat berlaku semasa memuatkan halaman.
Pemilihan parameter java untuk menstabilkan prestasi
Masalahnya telah diperbetulkan dalam banyak cara, eksperimen telah dijalankan untuk menukar parameter, log dan jstack dikumpulkan, dihantar ke sokongan, pada masa yang sama terdapat googling aktif dan hanya pemerhatian.
Pertama sekali, MRS yang berasingan telah dicipta untuk pemantauan, seperti yang ternyata kemudian, ini adalah salah satu pengguna utama sumber dalam persekitaran kami, kerana pemetaan dilancarkan dengan sangat intensif. Parameter mengenai timbunan java dan beberapa yang lain telah diubah.
Akibatnya, dengan kemas kini seterusnya Informatica 10.1.1, operasi konsol dan monitor telah stabil, pembangun mula berfungsi dengan lebih cekap, dan proses tetap menjadi lebih teratur.
Pengalaman interaksi antara pembangunan dan pentadbiran mungkin menarik. Isu pemahaman umum tentang bagaimana sesuatu berfungsi, apa yang boleh dilakukan dan apa yang tidak boleh dilakukan, sentiasa penting apabila menggunakan sistem yang kompleks. Oleh itu, kami boleh mengesyorkan anda terlebih dahulu melatih pasukan pentadbiran tentang cara mentadbir perisian, dan pasukan pembangunan tentang cara menulis kod dan melukis proses dalam sistem, dan hanya kemudian menghantar yang pertama dan kedua untuk mengusahakan hasilnya. Ini sangat penting apabila masa bukanlah sumber yang tidak terhingga. Banyak masalah boleh diselesaikan walaupun dengan mencari pilihan secara rawak, tetapi kadangkala ada yang memerlukan pengetahuan priori - kes kami mengesahkan kepentingan memahami aksiom ini.
Sebagai contoh, apabila kami cuba mendayakan versi dalam MRS (seperti yang ternyata pada akhirnya, versi SVN yang berbeza diperlukan), selepas beberapa lama kami terkejut apabila mendapati masa mulakan semula sistem telah meningkat kepada beberapa puluh minit. Setelah menemui sebab kelewatan dalam permulaan dan melumpuhkan versi, kami berjaya sekali lagi.
Halangan ketara yang dikaitkan dengan Informatica termasuk pertempuran epik dengan benang java yang semakin meningkat. Pada satu ketika, masanya telah tiba untuk replikasi, iaitu, untuk melanjutkan proses yang telah ditetapkan kepada sejumlah besar sistem sumber. Ternyata tidak semua proses dalam 10.1.1 berfungsi dengan baik, dan selepas beberapa lama DIS menjadi tidak boleh beroperasi. Berpuluh-puluh ribu utas telah dikesan, bilangannya semakin meningkat terutamanya semasa prosedur penggunaan aplikasi. Kadang-kadang saya terpaksa memulakan semula beberapa kali sehari untuk memulihkan fungsi.
Di sini kita perlu berterima kasih kepada sokongan; masalah telah disetempatkan dan diperbaiki dengan agak cepat menggunakan EBF (Pembetulan Pepijat Kecemasan) - selepas itu, semua orang mendapat perasaan bahawa alat itu benar-benar berfungsi.
Ia masih berfungsi!
Apabila kami mula bekerja dalam mod sasaran, Informatica kelihatan seperti ini. Informatica versi 10.1.1HF1 (HF1 ialah HotFix1, binaan vendor bagi suit EBF) dengan EBF tambahan dipasang, membetulkan isu penskalaan kami dan beberapa isu lain, pada satu pelayan daripada tiga yang merupakan sebahagian daripada GRID, dengan 20 teras dan storan x86_64, pada susunan cakera setempat yang besar dan perlahan—itu sahaja. konfigurasi pelayan untuk kluster Hadoop. Pelayan lain yang serupa menjalankan Oracle DBMS, yang mengendalikan kedua-dua domain Informatica dan enjin pengurusan ETL. Semua ini dipantau oleh alat pemantauan standard pasukan (Zabbix + Grafana) di kedua-dua belah pihak—Informatica sendiri dengan perkhidmatannya, dan proses yang dimuatkan ke dalamnya. Pada masa ini, prestasi dan kestabilan, tanpa mengira faktor luaran, bergantung pada tetapan pengehad beban.
Secara berasingan, kita boleh katakan tentang GRID. Persekitaran dibina pada tiga nod, dengan kemungkinan pengimbangan beban. Walau bagaimanapun, semasa ujian, didapati bahawa disebabkan masalah interaksi antara contoh berjalan aplikasi kami, konfigurasi ini tidak berfungsi seperti yang diharapkan, dan mereka memutuskan untuk meninggalkan skim pembinaan ini buat sementara waktu, mengalih keluar dua daripada tiga nod daripada domain. Pada masa yang sama, skim itu sendiri kekal sama, dan kini ia adalah tepat perkhidmatan GRID, tetapi merosot kepada satu nod.
Pada masa ini, kesukaran masih dikaitkan dengan penurunan prestasi apabila kerap membersihkan litar monitor - dengan proses serentak dalam CNN dan menjalankan pembersihan, kerosakan dalam pengendalian mekanisme kawalan ETL mungkin berlaku. Ini sedang diselesaikan "sebagai tongkat" - dengan membersihkan litar monitor secara manual, dengan kehilangan semua data sebelumnya. Ini tidak terlalu kritikal untuk produktiviti, semasa operasi rutin biasa, tetapi buat masa ini pencarian untuk penyelesaian biasa sedang dijalankan.
Masalah lain timbul daripada situasi yang sama ini - kadangkala beberapa pelancaran mekanisme kawalan kami berlaku.
Pelancaran berbilang aplikasi yang membawa kepada kegagalan mekanisme
Apabila berjalan mengikut jadual, pada masa beban berat pada sistem, situasi kadangkala berlaku yang membawa kepada kerosakan mekanisme. Masalahnya masih dibetulkan secara manual, dan penyelesaian kekal sedang dicari.
Secara umum, kita boleh merumuskan bahawa apabila terdapat beban yang berat, adalah sangat penting untuk menyediakan sumber yang mencukupi untuknya, ini juga terpakai kepada sumber perkakasan untuk Informatica itu sendiri, dan sama untuk repositori pangkalan datanya, serta menyediakan tetapan optimum untuk mereka. Di samping itu, persoalan tetap terbuka tentang skema penempatan pangkalan data yang lebih baik - pada hos yang berasingan, atau pada hos yang sama di mana perisian Informatica dijalankan. Di satu pihak, ia akan menjadi lebih murah pada satu pelayan, dan apabila digabungkan, kemungkinan masalah dengan interaksi rangkaian secara praktikal dihapuskan, sebaliknya, beban pada hos dari pangkalan data ditambah dengan beban dari Informatica.
Seperti mana-mana produk yang serius, Informatica juga mempunyai detik-detik lucu.
Suatu ketika, semasa menyelesaikan beberapa jenis kemalangan, saya perhatikan bahawa log MRS secara pelik menunjukkan masa kejadian.
Dualisme temporal dalam log MRS "dengan reka bentuk"
Ternyata setem masa ditulis dalam format 12 jam, tanpa menyatakan AM/PM, iaitu sebelum tengah hari atau selepas. Permohonan juga telah dibuka mengenai perkara ini, dan maklum balas rasmi telah diterima - ini adalah bagaimana ia dimaksudkan, tanda ditulis dalam log MRS dalam format ini. Iaitu, kadang-kadang masih terdapat beberapa tipu muslihat mengenai masa berlakunya beberapa KESILAPAN...
Berusaha untuk yang terbaik
Hari ini, Informatica ialah alat yang agak stabil, mudah untuk pentadbir dan pengguna, sangat berkuasa dari segi keupayaan dan potensi semasanya. Ia melebihi keperluan fungsi kami berkali-kali dan de facto kini digunakan dalam projek dengan cara yang bukan yang paling tipikal dan tipikal. Kesukaran sebahagiannya berkaitan dengan cara mekanisme berfungsi - perkara khusus ialah dalam tempoh yang singkat sejumlah besar benang dilancarkan yang secara intensif mengemas kini parameter dan berfungsi dengan pangkalan data repositori, manakala sumber perkakasan pelayan digunakan hampir sepenuhnya. oleh CPU.
Kami kini hampir beralih ke Informatica 10.2.1 atau 10.2.2, yang telah mengolah semula beberapa mekanisme dalaman dan janji sokongan untuk menghapuskan beberapa isu prestasi dan kefungsian yang kami ada sekarang. Dan dari sudut perkakasan, kami menjangkakan pelayan dengan konfigurasi optimum untuk kami, dengan mengambil kira rizab untuk masa depan terdekat disebabkan oleh pertumbuhan dan perkembangan storan.
Sudah tentu, akan ada ujian, semakan keserasian, dan mungkin perubahan seni bina dalam bahagian HA GRID. Pembangunan dalam Informatica akan diteruskan, kerana dalam jangka pendek kami tidak dapat membekalkan apa-apa untuk menggantikan sistem.
Dan mereka yang akan bertanggungjawab untuk sistem ini pada masa hadapan pasti akan dapat membawanya kepada kebolehpercayaan dan penunjuk prestasi yang diperlukan yang dikemukakan oleh pelanggan.
Artikel itu disediakan oleh pasukan pengurusan data Rostelecom
Logo Informatica semasa
Sumber: www.habr.com
