Sekitar 4 tahun yang lalu, kami memindahkan sistem pelaporan kami dari Oracle ke SAP Hana. Saat ini, ia menyimpan sekitar 10.000 meja, 38.000 orang menggunakannya, dan lebih dari 5.000 proses pemuatan terjadi setiap hari. Saat ini, kompleks kami, tempat sistem bekerja, terdiri dari 8 server dengan memori 14 TB. Setiap hari, sistem pelaporan memproses 1,5 pb data. Pada saat yang sama, Hana sekitar 20 kali lebih produktif daripada Oracle, DB2 dan MySQL. Dan hari ini saya ingin memberi tahu bagaimana, dalam kerangka integrasi M.Video dan Eldorado, kami juga meningkatkan kinerja sistem pelaporan, yang kami optimalkan.
Muat
Saat ini, dari beberapa ribu laporan yang dibuat oleh sistem, hanya 10 yang menghasilkan 70% dari total beban. Laporan terberat dalam database Hana adalah Weekly Bussines Review. Ini berjalan selama 30 menit dan menghabiskan 4 TB memori. 90% dari semua laporan dihasilkan oleh pusat kontak: kami menciptakan layanan yang, ketika klien memanggil dengan nomor teleponnya, secara otomatis membuka laporan dan menunjukkan kepada operator seluruh sejarah pembelian penelepon dan interaksinya dengan perusahaan.
Model data
Model data utama tempat sebagian besar laporan dibangun berisi 1.500 tabel. Kebanyakan dari mereka adalah tabel referensi. Dengan menggunakan model ini, Anda dapat menganalisis segala arah perusahaan. Contohnya adalah visualisasi model data yang dibuat menggunakan desainer Universe. Benar, itu hanya mencerminkan sepersepuluh dari sistem kami.
Performa
Pada saat penggabungan M.Video dan Eldorado, jumlah data dalam dua sistem pelaporan adalah sekitar 10 TB: 7 TB di BW pada sistem HANA M.Video, 2 TB di BW pada HANA Eldorado dan 1 TB data tambahan di HADOOP (data historis). Ketika menggabungkan sistem, kami memiliki keterbatasan perangkat keras: kompleks M. Video terdiri dari 6 node (masing-masing 2 TB), termasuk satu cadangan. Sistem ini dapat diperluas hingga maksimum 8 node, di mana satu cadangan.
Dalam persiapan untuk merger, kami mengasumsikan bahwa jumlah total semua data akan mencapai 13 TB. Oleh karena itu, berdasarkan rekomendasi SAP, kami membutuhkan sistem 16 node masing-masing 2 TB, termasuk dua node cadangan. Juga, satu node harus dialokasikan sebagai master node, yang, dengan volume informasi seperti itu, akan mengambil alih fungsi manajemen. Artinya, untuk operasi yang benar perlu untuk menggunakan 13 node.
Seperti yang Anda lihat, sumber daya yang tersedia tidak cukup. Dan itu adalah tantangan pertama.
Kesulitan utama kedua sebelum merger adalah bahwa kecepatan sistem seringkali tidak memuaskan kebutuhan bisnis. Alasan utama adalah banyaknya panggilan bersamaan ke database. Dari sudut pandang sistem, itu tampak seperti bola salju, yang dapat menyebabkan pembekuan dan gangguan bagian dari proses, atau bahkan ke pembuangan global "kehabisan memori" pada node.
Jelas bahwa tanpa modifikasi yang signifikan, peningkatan dua kali lipat dalam jumlah data dalam laporan (untuk dua merek) akan menyebabkan memburuknya situasi sekitar dua kali lipat.
Oleh karena itu, kami memutuskan untuk mengoptimalkan sistem di bidang berikut:
- Pelaporan Akselerasi laporan yang paling kritis dan paling intensif sumber daya dan revisi model data.
- Repositori . Pengoptimalan pengarsipan dan penyimpanan.
- Unduhan . Rampingkan prosedur dan ubah jadwal pengunduhan.
Pendekatan umum untuk optimasi adalah ini:
Pertama, kami melakukan analisis ke segala arah, mengidentifikasi penyebab masalah, dan kemudian menganalisis kemampuan sistem dengan sumber daya yang diperlukan. Kami juga segera mencoba untuk mengotomatisasi proses ini sebanyak mungkin sehingga di masa depan kami dapat dengan cepat mengidentifikasi penyebab masalah dan dengan cepat mengembalikan kinerja.
Apa yang telah kami lakukan:
- Mengubah konfigurasi server aplikasi ABAP: jumlah instance, penggunaan efektif teknologi NUMA dan jumlah optimal alur kerja.
- Kami menerapkan parameter optimal HANA dan sistem operasi Linux.
- Kami menganalisis penurunan konsumsi CPU.
- Kami menganalisis konsumsi RAM dalam seluruh interval waktu yang diamati.
- Kami menganalisis terjadinya OOM di HANA.
- Kami menganalisis terjadinya kunci dalam sistem dan ketersediaan sumber daya sistem untuk operasi tunggu (tunggu).
- Kami menganalisis perimbangan data dengan mempertimbangkan redistribusi dan partisi ulang data untuk solusi SCALE-OUT HANA.
- Kami menganalisis penyebab dump ABAP yang memengaruhi operasi rantai kritis.
Berdasarkan hasil, laporan kinerja dikompilasi, serta instruksi sehingga di masa depan dimungkinkan untuk secara mandiri menentukan kemacetan dalam sistem dan interval waktu puncak.
Apa hasil yang dicapai:
Sejumlah laporan yang dioptimalkan SAP BO mulai bekerja
beberapa kali lebih cepat dan mengkonsumsi
memori ratusan kali lebih sedikit .
Berikut adalah beberapa contoh mencolok tentang bagaimana sistem secara tidak benar memenuhi persyaratan pemilihan, dan cara membuat kueri dengan benar di HANA.
Masalah terungkap saat memfilter oleh objek yang tidak terwujud, terutama (!) Saat menggunakan indikator
COUNT DISTINCT (CD dapat ditulis baik di tingkat Universe dan dalam fungsi di CV).
Bahkan jika Anda mengecualikan CD dari kueri, opsi pertama masih akan berjalan 20 kali lebih lambat dari yang kedua, dan dengan CD, kecepatannya akan lebih dari 500 kali lebih tinggi.
Kasus khusus menggunakan objek yang tidak terwujud dalam filter: filter komposit dari dua objek atau lebih, misalnya, menempelkan satu minggu dan satu tahun:
Kueri dengan filter terpaku tidak berfungsi selambat konversi ke tanggal, tetapi kueri masih melambat (sekitar 2-3 kali).
Untuk mengumpulkan statistik tentang pengoperasian sistem pelaporan, proses pemuatan, dan rantai, kami mengembangkan skema berikut:
Pada saat yang sama, kami menambahkan komentar khusus pada laporan dengan nama laporan. Dengan demikian, kita dapat membandingkan beban dari berbagai bagian sistem dan membandingkan periode ke periode.
Paket
Kami memiliki banyak rencana untuk pengembangan fungsionalitas bisnis dan revisi substansial dari alat visualisasi data. Tren global di mana kami berpartisipasi secara aktif adalah untuk mengintegrasikan sistem pelaporan ke dalam paradigma transformasi digital.
Apa maksudmu
Ketika sistem pelaporan kami masih muda, pengguna sering mendatangi kami dengan permintaan serupa: "Mengotomatiskan pembuatan laporan yang menunjukkan berapa laba bersih yang diterima toko ini atau itu, atau seluruh perusahaan."
Kemudian mereka mulai mendatangi kami dengan permintaan untuk membuat algoritma yang akan membangun rencana atau perkiraan untuk laba bersih, tergantung pada faktor-faktor tertentu.
Dan hari ini kita sampai pada kesimpulan bahwa pengguna ingin mengetahui perkiraan laba bersih yang akurat. Kami memiliki semua data yang diperlukan untuk pengembangan algoritma peramalan, dan ada spesialis analisis data yang dapat membuat model pembelajaran mesin. Seperti yang Anda ketahui, ini membutuhkan data dalam jumlah sangat besar, jadi salah satu tren utama dalam pengembangan sistem pelaporan kami adalah transisi ke analisis dan pembuatan model berdasarkan data besar.
Beberapa kata tentang tim kami
Saat ini, perusahaan besar semakin memperkenalkan sistem peramalan yang didasarkan pada algoritma pembelajaran mesin yang dikembangkan oleh sistem itu sendiri. Dua tahun lalu, kami menciptakan pusat kompetensi di bidang analisis data dari Pusat Sains Data Ritel Digital, dan tahun ini kami memiliki sekelompok insinyur data. Kami memperkenalkan sistem baru untuk memproses dan menganalisis data besar. Dan kami membutuhkan orang-orang dalam tim di departemen dukungan, pengembangan, dan analisis data terapan.
Jika Anda tertarik pada bidang-bidang ini, jika Anda merasakan kekuatan dalam diri Anda sendiri - selamat datang! Anda akan menemukan pekerjaan yang menarik dan sulit, terkadang membuat stres, tetapi selalu kreatif.
