Waktu untuk pelaporan di Excel dengan cepat menghilang - tren menuju alat yang mudah digunakan untuk menyajikan dan menganalisis informasi terlihat di semua bidang. Kami telah lama mendiskusikan digitalisasi pelaporan secara internal dan memilih visualisasi Tableau dan sistem analisis swalayan. Alexander Bezugly, kepala departemen solusi analitis dan pelaporan Grup M.Video-Eldorado, berbicara tentang pengalaman dan hasil pembuatan dasbor tempur.
Saya akan segera mengatakan bahwa tidak semua yang direncanakan menjadi kenyataan, tetapi pengalamannya menarik, semoga bermanfaat juga bagi Anda. Dan jika ada yang punya ide tentang bagaimana hal ini bisa dilakukan dengan lebih baik, saya akan sangat berterima kasih atas saran dan ide Anda.
Di bawah ini adalah tentang apa yang kami temui dan apa yang kami pelajari.
Di mana kita memulai?
M.Video-Eldorado memiliki model data yang dikembangkan dengan baik: informasi terstruktur dengan kedalaman penyimpanan yang diperlukan dan sejumlah besar laporan bentuk tetap (lihat lebih detail ). Dari sini, analis membuat tabel pivot atau buletin berformat di Excel, atau presentasi PowerPoint yang indah untuk pengguna akhir.
Sekitar dua tahun yang lalu, alih-alih membuat laporan dalam bentuk tetap, kami mulai membuat laporan analitik di SAP Analysis (sebuah add-on Excel, yang pada dasarnya adalah tabel pivot di atas mesin OLAP). Namun alat ini tidak mampu memenuhi kebutuhan semua pengguna; mayoritas terus menggunakan informasi tambahan yang diproses oleh analis.
Pengguna akhir kami terbagi dalam tiga kategori:
Manajemen puncak. Meminta informasi dengan cara yang disajikan dengan baik dan dapat dimengerti dengan jelas.
Manajemen menengah, pengguna tingkat lanjut. Tertarik pada eksplorasi data dan mampu membuat laporan secara mandiri jika alat tersedia. Mereka menjadi pengguna utama laporan analitis dalam Analisis SAP.
Pengguna massal. Mereka tidak tertarik menganalisis data secara independen; mereka menggunakan laporan dengan tingkat kebebasan terbatas, dalam format buletin dan tabel pivot di Excel.
Ide kami adalah untuk memenuhi kebutuhan semua pengguna dan memberi mereka satu alat yang mudah digunakan. Kami memutuskan untuk memulai dengan manajemen puncak. Mereka membutuhkan dasbor yang mudah digunakan untuk menganalisis hasil bisnis utama. Jadi, kami memulai dengan Tableau dan pertama-tama memilih dua arah: indikator penjualan ritel dan online dengan analisis mendalam dan luas terbatas, yang mencakup sekitar 80% data yang diminta oleh manajemen puncak.
Karena pengguna dasbor adalah manajemen puncak, KPI tambahan produk lainnya muncul - kecepatan respons. Tidak ada yang akan menunggu 20-30 detik hingga data diperbarui. Navigasi seharusnya dilakukan dalam waktu 4-5 detik, atau lebih baik lagi, dilakukan secara instan. Dan sayangnya, kami gagal mencapai hal ini.
Seperti inilah tata letak dashboard utama kami:
Ide utamanya adalah menggabungkan pendorong utama KPI, yang totalnya ada 19, di sebelah kiri dan menyajikan dinamika serta rinciannya berdasarkan atribut utama di sebelah kanan. Tugasnya tampak sederhana, visualisasinya logis dan mudah dipahami, hingga Anda mendalami detailnya.
Rincian 1. Volume data
Tabel utama kami untuk penjualan tahunan memakan sekitar 300 juta baris. Karena dinamika tahun lalu dan tahun sebelumnya perlu tercermin, volume data penjualan aktual saja adalah sekitar 1 miliar baris. Informasi data rencana dan blok penjualan online juga disimpan secara terpisah. Oleh karena itu, meskipun kami menggunakan DB SAP HANA dalam memori berbentuk kolom, kecepatan kueri dengan pemilihan semua indikator selama satu minggu dari penyimpanan saat ini dengan cepat adalah sekitar 15-20 detik. Solusi untuk masalah ini menunjukkan dirinya sendiri - materialisasi data tambahan. Namun hal ini juga memiliki kelemahan, selengkapnya di bawah ini.
Rincian 2. Indikator non-aditif
Banyak KPI kami yang terkait dengan jumlah penerimaan. Dan indikator ini mewakili COUNT DISTINCT dari jumlah baris (periksa header) dan menunjukkan jumlah yang berbeda tergantung pada atribut yang dipilih. Misalnya, cara menghitung indikator ini dan turunannya:
Agar penghitungan Anda benar, Anda dapat:
- Hitung indikator tersebut dengan cepat di penyimpanan;
- Lakukan perhitungan pada seluruh volume data di Tableau, mis. berdasarkan permintaan di Tableau, berikan semua data sesuai dengan filter yang dipilih dalam rincian posisi penerimaan;
- Buat etalase yang terwujud di mana semua indikator akan dihitung di semua opsi sampel yang memberikan hasil non-aditif yang berbeda.
Jelas bahwa dalam contoh UTE1 dan UTE2 merupakan atribut material yang mewakili hierarki produk. Ini bukanlah suatu hal yang statis, pengelolaan dalam perusahaan terjadi melaluinya, karena Manajer yang berbeda bertanggung jawab atas kelompok produk yang berbeda. Kami mengalami banyak revisi global pada hierarki ini, ketika semua tingkatan berubah, ketika hubungan direvisi, dan perubahan titik yang konstan, ketika satu kelompok berpindah dari satu simpul ke simpul lainnya. Dalam pelaporan konvensional, semua ini dihitung dengan cepat berdasarkan atribut material; jika data ini terwujud, perlu dikembangkan mekanisme untuk melacak perubahan tersebut dan secara otomatis memuat ulang data historis. Sebuah tugas yang sangat tidak sepele.
Rincian 3. Perbandingan data
Poin ini mirip dengan poin sebelumnya. Intinya, ketika menganalisis suatu perusahaan, biasanya dibuat beberapa tingkat perbandingan dengan periode sebelumnya:
Perbandingan dengan periode sebelumnya (hari ke hari, minggu ke minggu, bulan ke bulan)
Dalam perbandingan ini, diasumsikan bahwa bergantung pada periode yang dipilih oleh pengguna (misalnya, minggu ke-33 dalam setahun), kita harus menunjukkan dinamika pada minggu ke-32; jika kita memilih data untuk satu bulan, misalnya, Mei , maka perbandingan ini akan menunjukkan dinamika pada bulan April.
Perbandingan dengan tahun lalu
Nuansa utama di sini adalah ketika membandingkan hari dan minggu, Anda tidak mengambil hari yang sama tahun lalu, yaitu. Anda tidak bisa begitu saja memasukkan tahun ini dikurangi satu. Anda harus melihat hari dalam seminggu yang Anda bandingkan. Sebaliknya, saat membandingkan bulan, Anda harus mengambil hari kalender yang persis sama dengan tahun lalu. Ada juga nuansa tahun kabisat. Dalam repositori asli, semua informasi didistribusikan berdasarkan hari; tidak ada bidang terpisah dengan minggu, bulan, atau tahun. Oleh karena itu, untuk mendapatkan penampang analitis yang lengkap dalam panel, Anda perlu menghitung bukan satu periode, misalnya seminggu, tetapi 4 minggu, lalu membandingkan data tersebut, mencerminkan dinamika dan penyimpangannya. Oleh karena itu, logika untuk menghasilkan perbandingan dalam dinamika juga dapat diterapkan baik di Tableau atau di sisi etalase. Ya, dan tentu saja kami mengetahui dan memikirkan detail ini pada tahap desain, namun sulit untuk memprediksi dampaknya terhadap kinerja dasbor akhir.
Saat menerapkan dasbor, kami mengikuti jalur Agile yang panjang. Tugas kami adalah menyediakan alat kerja dengan data yang diperlukan untuk pengujian secepat mungkin. Oleh karena itu, kami melakukan sprint dan mulai meminimalkan pekerjaan pada sisi penyimpanan saat ini.
Bagian 1: Keyakinan pada Tableau
Untuk menyederhanakan dukungan TI dan menerapkan perubahan dengan cepat, kami memutuskan untuk membuat logika untuk menghitung indikator non-aditif dan membandingkan periode sebelumnya di Tableau.
Tahap 1. Semuanya Live, tidak ada modifikasi jendela.
Pada tahap ini, kami menghubungkan Tableau ke etalase saat ini dan memutuskan untuk melihat bagaimana jumlah penerimaan selama satu tahun akan dihitung.
Hasilnya:
Jawabannya menyedihkan - 20 menit. Transfer data melalui jaringan, beban tinggi di Tableau. Kami menyadari bahwa logika dengan indikator non-aditif perlu diterapkan di HANA. Hal ini tidak terlalu membuat kami takut, kami sudah memiliki pengalaman serupa dengan BO dan Analisis dan kami tahu cara membuat etalase cepat di HANA yang menghasilkan indikator non-aditif yang dihitung dengan benar. Sekarang yang tersisa hanyalah menyesuaikannya dengan Tableau.
Tahap 2. Kami menyetel etalase, tanpa materialisasi, semuanya berjalan dengan cepat.
Kami membuat etalase baru terpisah yang menghasilkan data yang diperlukan untuk TABLEAU dengan cepat. Secara umum, kami mendapatkan hasil yang baik; kami mengurangi waktu untuk menghasilkan semua indikator dalam satu minggu menjadi 9-10 detik. Dan sejujurnya kami berharap di Tableau waktu respons dasbor adalah 20-30 detik saat pertama kali dibuka dan kemudian karena cache dari 10 hingga 12, yang secara umum cocok untuk kami.
Hasilnya:
Dasbor terbuka pertama: 4-5 menit
Klik apa saja: 3-4 menit
Tidak ada yang mengharapkan peningkatan tambahan dalam pekerjaan etalase.
Bagian 2. Selami Tableau
Tahap 1. Analisis kinerja Tableau dan penyetelan cepat
Kami mulai menganalisis di mana Tableau menghabiskan sebagian besar waktunya. Dan ada alat yang cukup bagus untuk ini, yang tentu saja merupakan nilai tambah dari Tableau. Masalah utama yang kami identifikasi adalah kueri SQL yang sangat kompleks yang dibuat oleh Tableau. Mereka terutama terkait dengan:
β transposisi data. Karena Tableau tidak memiliki alat untuk mentransposisi kumpulan data, untuk membuat sisi kiri dasbor dengan representasi mendetail dari semua KPI, kami harus membuat tabel menggunakan kasus. Ukuran query SQL dalam database mencapai 120 karakter.
- pilihan periode waktu. Kueri seperti itu di tingkat basis data membutuhkan lebih banyak waktu untuk dikompilasi daripada dieksekusi:
Itu. pemrosesan permintaan 12 detik + eksekusi 5 detik.
Kami memutuskan untuk menyederhanakan logika penghitungan di sisi Tableau dan memindahkan bagian penghitungan lainnya ke tingkat etalase dan database. Hal ini membawa hasil yang baik.
Pertama, kami melakukan transposisi dengan cepat, kami melakukannya melalui gabungan luar penuh pada tahap akhir perhitungan VIEW, sesuai dengan pendekatan yang dijelaskan di wiki ΠΈ .
Artinya, kami membuat tabel pengaturan - matriks transposisi (21x21) dan menerima semua indikator dalam pengelompokan baris demi baris.
Dulu:
Menjadi:
Hampir tidak ada waktu yang dihabiskan untuk transposisi database itu sendiri. Permintaan seluruh indikator untuk minggu ini terus diproses dalam waktu sekitar 10 detik. Namun di sisi lain, fleksibilitas telah hilang dalam membangun dashboard berdasarkan indikator tertentu, yaitu untuk sisi kanan dashboard yang menyajikan dinamika dan rincian detail indikator tertentu, sebelumnya etalase bekerja dalam 1-3 detik, karena permintaannya didasarkan pada satu indikator, dan sekarang database selalu memilih semua indikator dan memfilter hasilnya sebelum mengembalikan hasilnya ke Tableau.
Alhasil, kecepatan dashboard berkurang hampir 3 kali lipat.
Hasilnya:
- 5 detik β mengurai dasbor, visualisasi
- 15-20 detik - persiapan untuk menyusun kueri dengan melakukan pra-perhitungan di Tableau
- 35-45 detik - kompilasi kueri SQL dan eksekusi berurutan paralelnya di Hana
- 5 detik β memproses hasil, mengurutkan, menghitung ulang visualisasi di Tableau
- Tentu saja, hasil seperti itu tidak sesuai dengan bisnis, dan kami terus melakukan optimasi.
Tahap 2. Logika minimum di Tableau, materialisasi lengkap
Kami memahami bahwa tidak mungkin membuat dasbor dengan waktu respons beberapa detik di etalase yang berjalan selama 10 detik, dan kami mempertimbangkan opsi untuk mewujudkan data di sisi database khusus untuk dasbor yang diperlukan. Namun kami menghadapi masalah global yang dijelaskan di atas - indikator non-aditif. Kami tidak dapat memastikan bahwa saat mengubah filter atau penelusuran, Tableau secara fleksibel beralih antara etalase dan level berbeda yang telah dirancang sebelumnya untuk hierarki produk berbeda (dalam contoh, tiga kueri tanpa UTE, dengan UTE1 dan UTE2 menghasilkan hasil yang berbeda). Oleh karena itu, kami memutuskan untuk menyederhanakan dasbor, mengabaikan hierarki produk di dasbor, dan melihat seberapa cepatnya dalam versi yang disederhanakan.
Jadi, pada tahap terakhir ini, kami menyusun repositori terpisah di mana kami menambahkan semua KPI dalam bentuk yang dialihkan. Di sisi database, setiap permintaan ke penyimpanan tersebut diproses dalam 0,1 - 0,3 detik. Di dasbor kami menerima hasil berikut:
Pembukaan pertama: 8-10 detik
Setiap klik: 6-7 detik
Waktu yang dihabiskan oleh Tableau terdiri dari:
- 0,3 detik. β penguraian dasbor dan kompilasi kueri SQL
- 1,5-3 detik. β Eksekusi query SQL di Hana untuk visualisasi utama (berjalan secara paralel dengan langkah 1)
- 1,5-2 detik. β rendering, perhitungan ulang visualisasi
- 1,3 detik. β eksekusi kueri SQL tambahan untuk mendapatkan nilai filter yang relevan (Merek, Divisi, Kota, Toko), penguraian hasil
Singkatnya
Kami menyukai alat Tableau dari perspektif visualisasi. Pada tahap pembuatan prototipe, kami mempertimbangkan berbagai elemen visualisasi dan menemukan semuanya di perpustakaan, termasuk segmentasi multi-level yang kompleks dan air terjun multi-driver.
Saat menerapkan dasbor dengan indikator penjualan utama, kami menemui kesulitan kinerja yang belum dapat kami atasi. Kami menghabiskan lebih dari dua bulan dan menerima dasbor yang tidak lengkap secara fungsional, yang kecepatan responsnya hampir dapat diterima. Dan kami menarik kesimpulan sendiri:
- Tableau tidak dapat bekerja dengan data dalam jumlah besar. Jika dalam model data asli Anda memiliki lebih dari 10 GB data (kira-kira 200 juta X 50 baris), dasbor akan sangat melambat - dari 10 detik menjadi beberapa menit untuk setiap klik. Kami bereksperimen dengan koneksi langsung dan ekstrak. Kecepatan pengoperasiannya sebanding.
- Batasan saat menggunakan banyak penyimpanan (dataset). Tidak ada cara untuk menunjukkan hubungan antar kumpulan data menggunakan cara standar. Jika Anda menggunakan solusi untuk menghubungkan kumpulan data, ini akan sangat memengaruhi kinerja. Dalam kasus kami, kami mempertimbangkan opsi untuk mewujudkan data di setiap bagian tampilan yang diperlukan dan melakukan peralihan pada kumpulan data yang terwujud ini sambil mempertahankan filter yang dipilih sebelumnya - hal ini ternyata tidak mungkin dilakukan di Tableau.
- Tidak mungkin membuat parameter dinamis di Tableau. Anda tidak dapat mengisi parameter yang digunakan untuk memfilter kumpulan data dalam ekstrak atau selama koneksi langsung dengan hasil pilihan lain dari kumpulan data atau hasil kueri SQL lain, hanya input pengguna asli atau konstanta.
- Keterbatasan yang terkait dengan pembuatan dasbor dengan elemen OLAP|PivotTable.
Di MSTR, SAP SAC, Analisis SAP, jika Anda menambahkan kumpulan data ke laporan, maka semua objek di dalamnya terkait satu sama lain secara default. Tableau tidak memiliki ini; koneksi harus dikonfigurasi secara manual. Ini mungkin lebih fleksibel, tetapi untuk semua dasbor kami, ini adalah persyaratan wajib untuk elemen - jadi ini adalah biaya tenaga kerja tambahan. Selain itu, jika Anda membuat filter terkait sehingga, misalnya, saat memfilter suatu wilayah, daftar kota dibatasi hanya pada kota-kota di wilayah tersebut, Anda akan segera mendapatkan kueri berturut-turut ke database atau Ekstrak, yang secara signifikan memperlambat proses dasbor. - Keterbatasan fungsi. Transformasi massal tidak dapat dilakukan pada ekstrak atau, TERUTAMA, pada kumpulan data dari Live-connecta. Hal ini dapat dilakukan melalui Tableau Prep, namun ini merupakan pekerjaan tambahan dan alat lain yang harus dipelajari dan dipelihara. Misalnya, Anda tidak dapat mengubah urutan data atau menggabungkannya dengan data itu sendiri. Apa yang ditutup melalui transformasi pada kolom atau bidang individual, yang harus dipilih melalui huruf besar/kecil atau jika, dan ini menghasilkan kueri SQL yang sangat kompleks, di mana database menghabiskan sebagian besar waktunya untuk menyusun teks kueri. Ketidakfleksibelan alat ini harus diatasi pada tingkat etalase, yang mengakibatkan penyimpanan yang lebih kompleks, pengunduhan tambahan, dan transformasi.
Kami belum menyerah pada Tableau. Namun kami tidak menganggap Tableau sebagai alat yang mampu membangun dasbor industri dan alat untuk menggantikan dan mendigitalkan seluruh sistem pelaporan perusahaan.
Kami sekarang secara aktif mengembangkan dasbor serupa di alat lain dan, pada saat yang sama, mencoba merevisi arsitektur dasbor di Tableau untuk lebih menyederhanakannya. Jika komunitas tertarik, kami akan memberi tahu Anda hasilnya.
Kami juga menunggu ide atau saran Anda tentang bagaimana di Tabeau Anda dapat membuat dasbor cepat untuk data dalam jumlah besar, karena kami memiliki situs web yang memiliki lebih banyak data daripada di ritel.
Sumber: www.habr.com