Waktu pelaporan di Excel cepat habis - tren untuk alat yang mudah digunakan untuk menyajikan dan menganalisis informasi terlihat di semua bidang. Kami telah lama membahas di dalam digitalisasi gedung pelaporan dan telah memilih visualisasi Tableau dan sistem analisis swalayan. Alexander Bezugly, kepala solusi analitik dan departemen pelaporan Grup M. Video-Eldorado, berbicara tentang pengalaman dan hasil membangun dasbor tempur.Saya harus segera mengatakan bahwa tidak semua yang direncanakan terwujud, tetapi pengalaman itu menarik, saya harap ini akan bermanfaat bagi Anda juga. Dan jika seseorang menemukan ide tentang bagaimana melakukan yang lebih baik, saya akan sangat berterima kasih atas saran dan ide tersebut.
Di bawah potongan tentang apa yang kami temui dan apa yang kami pelajari.
Di mana kita mulai
"M. Video-Eldorado" memiliki model data yang berkembang dengan baik: informasi terstruktur dengan kedalaman penyimpanan yang diperlukan dan sejumlah besar laporan bentuk tetap (lihat
artikel ini untuk detail). Dari jumlah tersebut, analis membuat tabel pivot atau surat terformat di Excel, atau presentasi indah di PowerPoint untuk pengguna akhir.
Sekitar dua tahun yang lalu, alih-alih laporan formulir tetap, kami mulai membuat laporan analitik dalam Analisis SAP (tambahan untuk Excel, pada kenyataannya - tabel pivot di atas mesin OLAP). Tetapi alat ini tidak dapat menutup kebutuhan semua pengguna, kebanyakan dari mereka terus menggunakan informasi yang diproses oleh para analis.
Pengguna akhir kami dibagi menjadi tiga kategori:
Manajemen puncak . Meminta informasi dalam bentuk yang disajikan dengan baik dan dapat dipahami dengan jelas.
Manajemen menengah , pengguna tingkat lanjut. Tertarik untuk meneliti data dan dapat secara mandiri membuat laporan dengan alat. Mereka menjadi pengguna utama laporan analitik dalam Analisis SAP.
Pengguna massal . Tidak tertarik pada analisis data secara mandiri, gunakan laporan dengan tingkat kebebasan terbatas, dalam format buletin dan tabel pivot di Excel.
Gagasan kami adalah untuk memenuhi kebutuhan semua pengguna dan memberi mereka satu alat yang praktis. Mereka memutuskan untuk memulai dengan manajemen puncak. Mereka membutuhkan dasbor yang nyaman untuk menganalisis hasil bisnis utama. Jadi, kami mulai dengan Tableau dan sebagai permulaan kami memilih dua bidang: penjualan ritel dan penjualan online dengan kedalaman dan keluasan analisis yang terbatas, yang mencakup sekitar 80% dari 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 harus pas dalam 4-5 detik, dan lebih baik untuk langsung berolahraga. Dan kami, sayangnya, gagal mencapai ini.
Inilah tampilan tata letak dasbor dasar kami:
Gagasan utamanya adalah menggabungkan driver KPI utama, di mana ada 19 di akhirnya, di sebelah kiri dan menyajikan dinamika mereka dan penguraian atribut utama di sebelah kanan. Tugasnya tampaknya tidak rumit, visualisasi itu logis dan dapat dimengerti, sampai Anda masuk ke rinciannya.
Rincian 1. Volume Data
Tabel penjualan utama untuk tahun ini menempati sekitar 300 juta baris. Karena itu perlu untuk mencerminkan dinamika yang terakhir dan tahun sebelumnya, jumlah data pada penjualan aktual saja sekitar 1 miliar baris. Dan informasi tentang data yang direncanakan dan unit penjualan online juga disimpan secara terpisah. Oleh karena itu, meskipun kami menggunakan SAP HANA dalam memori DB dalam memori, 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 - materialisasi data tambahan. Tetapi juga memiliki jebakan, tentang mereka di bawah ini.
Bagian 2. Indikator non-aditif
Kami memiliki banyak KPI terkait dengan jumlah cek. Dan indikator ini adalah COUNT DISTINCT dari jumlah baris (header tanda terima) dan menunjukkan jumlah yang berbeda tergantung pada atribut yang dipilih. Misalnya, bagaimana indikator ini dan turunannya harus dipertimbangkan:
Untuk kebenaran perhitungan, Anda dapat:
- Melakukan perhitungan indikator tersebut dengan cepat di penyimpanan;
- Hitung seluruh jumlah data di Tableau, mis. atas permintaan, di Tableau, berikan semua data untuk filter yang dipilih dalam rincian posisi pemeriksaan;
- Untuk membuat showcase terwujud di mana semua indikator akan dihitung dalam semua varian sampel yang memberikan hasil non-aditif yang berbeda.
Jelas bahwa dalam contoh UTE1 dan UTE2 adalah atribut material yang mewakili hierarki produk. Ini bukan hal yang statis, karena berjalan manajemen dalam perusahaan, karena kelompok produk yang berbeda bertanggung jawab untuk manajer yang berbeda. Kami memiliki banyak revisi global hierarki ini, ketika semua level berubah, ketika korelasi direvisi, dan titik konstan berubah, ketika satu kelompok bergerak dari satu node ke yang lain. Dalam pelaporan biasa, semua ini dipertimbangkan dengan cepat dari atribut material, dalam hal materialisasi data ini, perlu untuk mengembangkan mekanisme untuk melacak perubahan tersebut dan secara otomatis membebani data historis. Tugas yang sangat sepele.
Detail 3. Perbandingan Data
Item ini mirip dengan yang sebelumnya. Intinya adalah bahwa ketika menganalisis suatu perusahaan, adalah kebiasaan untuk membentuk beberapa tingkat perbandingan dengan periode sebelumnya:
Perbandingan dengan periode sebelumnya (hari ke hari, minggu ke minggu, bulan ke bulan)Dalam perbandingan ini, diasumsikan bahwa, tergantung pada periode yang dipilih oleh pengguna (misalnya, minggu 33 tahun), kami harus menunjukkan dinamika pada minggu 32, jika kami memilih data untuk bulan itu, misalnya, Mei, perbandingan ini akan menunjukkan dinamika pada bulan April.
Perbandingan dengan tahun laluDi sini peringatan utama adalah bahwa ketika membandingkan hari dan minggu, Anda tidak mengambil hari yang sama tahun lalu, mis. Anda tidak bisa hanya menempatkan tahun ini minus satu. Anda harus menonton hari yang dibandingkan dalam seminggu. Dan ketika membandingkan bulan, sebaliknya, Anda harus mengambil hari kalender yang sama persis tahun lalu. Ada juga nuansa tahun kabisat. Dalam repositori sumber, semua informasi didistribusikan berdasarkan hari, tidak ada bidang terpisah dengan minggu, bulan, tahun. Oleh karena itu, untuk mendapatkan potongan analitik lengkap dalam panel, perlu untuk mempertimbangkan tidak satu periode, misalnya satu minggu, tetapi 4 minggu, dan kemudian data ini harus dibandingkan, mencerminkan dinamika, penyimpangan. Dengan demikian, logika pembentukan perbandingan dalam dinamika ini juga dapat diimplementasikan baik di Tableau atau di sisi etalase. Ya, dan tentu saja kami tahu dan memikirkan detail ini pada tahap desain, tetapi dampaknya pada kinerja dasbor terakhir sulit diprediksi.
Dengan diperkenalkannya 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 di sisi penyimpanan saat ini.
Bagian 1. Iman di Tablo
Untuk menyederhanakan dukungan TI dan mengimplementasikan 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 perbaikan ganti jendela.
Pada titik ini, kami menghubungkan Tableau ke etalase saat ini dan memutuskan untuk melihat bagaimana jumlah cek akan dihitung dalam satu tahun.
Hasil:Jawabannya menyedihkan - 20 menit. Distilasi data jaringan, beban tinggi di Tableau. Kami menyadari bahwa logika dengan metrik non-aditif perlu diterapkan pada HANA. Ini tidak membuat kami takut banyak, kami sudah memiliki pengalaman yang sama dengan BO dan Analisis dan kami dapat membangun showcase cepat di HANA yang menghasilkan indikator non-aditif yang dihitung dengan benar. Sekarang tinggal mengubah mereka di bawah Tableau.
Tahap 2. Kami menyetel jendela, tanpa materialisasi, semuanya berjalan dengan cepat.
Kami membuat showcase baru yang terpisah, yang dengan cepat menghasilkan data yang diperlukan untuk TABLEAU. Secara umum, kami mendapat hasil yang baik, kami mengurangi waktu pembentukan semua indikator dalam satu minggu menjadi 9-10 detik. Dan kami dengan jujur berharap bahwa di Tableau waktu respons dasbor adalah 20-30 detik pada pembukaan pertama dan kemudian karena cache dari 10 hingga 12, yang secara umum sesuai untuk kami.
Hasil:Dasbor terbuka pertama: 4-5 menit
Setiap klik: 3-4 menit
Tidak ada yang mengharapkan peningkatan tambahan untuk pekerjaan jendela toko.
Bagian 2. Perendaman dalam Tableau
Tahap 1. Analisis kinerja tablo dan penyetelan cepat
Kami mulai menganalisis apa yang Tableau habiskan sebagian besar waktu. Dan untuk ini ada toolkit yang cukup bagus, yang tentu saja ditambah Tableau. Masalah utama yang kami identifikasi adalah pertanyaan SQL yang sangat kompleks yang dibuat Tableau. Mereka terutama terkait dengan:
- transposisi data. Karena Tableau tidak memiliki alat untuk mentransposisi dataset, untuk membangun sisi kiri dashboard dengan tampilan terperinci dari semua KPI, kami harus membuat tabel melalui case. Ukuran query SQL dalam database mencapai 120.000 karakter.
- pilihan periode waktu. Permintaan seperti itu di tingkat basis data membutuhkan waktu lebih lama untuk dikompilasi daripada dieksekusi:
Yaitu meminta pemrosesan 12 detik + 5 detik eksekusi.
Kami memutuskan untuk menyederhanakan logika perhitungan di sisi Tableau dan mentransfer satu bagian lagi dari perhitungan ke etalase dan tingkat basis data. Itu membawa hasil yang bagus.
Pertama, kami melakukan transpos dengan cepat, membuatnya melalui gabungan luar penuh pada tahap akhir perhitungan VIEW, menurut pendekatan ini yang dijelaskan pada wiki
Transpose - Wikipedia, ensiklopedia bebas dan
matriks Dasar - Wikipedia, ensiklopedia gratis .
Yaitu, kami membuat tabel tala - matriks transpos (21x21) dan mendapatkan semua indikator dalam rincian baris-demi-baris.
Itu:
Itu menjadi:
DB sendiri hampir tidak menghabiskan waktu untuk mentransposisi dirinya sendiri. Permintaan semua indikator untuk minggu ini dipenuhi seperti sebelumnya dalam waktu sekitar 10 detik. Namun di sisi lain, fleksibilitas dalam hal membangun dashboard dengan indikator tertentu, yaitu untuk sisi kanan dashboard di mana dinamika dan rincian rincian dari indikator tertentu disajikan, showcase bekerja dalam 1-3 detik sebelumnya, karena kueri melanjutkan satu indikator, dan sekarang database selalu memilih semua indikator dan memfilter hasilnya sebelum mengembalikan hasilnya ke Tableau.
Hasilnya, kecepatan dasbor berkurang hampir 3 kali lipat.
Hasil:- 5 dasbor pengurai, visualisasi
- 15-20 dtk - persiapan untuk kompilasi pertanyaan dengan eksekusi prekalkulasi di Tableau
- 35-45 dtk - kompilasi query SQL dan eksekusi paralel-sekuensial mereka di Hana
- 5 detik hasil pemrosesan, penyortiran, penghitungan ulang visualisasi di Tableau
- Tentu saja, hasil seperti itu tidak sesuai dengan bisnis, dan kami terus mengoptimalkan.
Tahap 2. Logika minimum di Tableau, materialisasi penuh
Kami memahami bahwa membangun dasbor dengan waktu respons beberapa detik di jendela toko yang berfungsi selama 10 detik tidak mungkin dilakukan, dan kami mempertimbangkan opsi untuk mematerialisasi data di sisi basis data khusus untuk dasbor yang diperlukan. Tetapi dihadapkan dengan masalah global yang dijelaskan di atas - indikator non-aditif. Kami tidak dapat melakukannya sehingga ketika mengganti filter atau pemindaian Tableau secara fleksibel beralih antara etalase dan tingkat yang berbeda yang dihitung untuk hierarki produk yang berbeda (dalam contoh, tiga kueri tanpa UTE, dengan UTE1 dan UTE2 membentuk hasil yang berbeda). Oleh karena itu, kami memutuskan untuk menyederhanakan dasbor, meninggalkan hierarki produk di dasbor dan melihat seberapa cepat bisa dalam versi yang disederhanakan.
Jadi, pada tahap terakhir ini, kami menyusun repositori terpisah di mana semua KPI ditransformasikan. Di sisi basis data, setiap permintaan ke repositori tersebut dipenuhi dalam 0,1 - 0,3 detik. Di dasbor, kami mendapat hasil berikut:
Pembukaan pertama: 8-10 detik
Klik apa saja: 6-7 detik
Waktu yang dihabiskan Tableau terdiri dari:
- 0,3 dtk - parsing dashboard dan kompilasi query SQL
- 1,5-3 dtk. - eksekusi query SQL di Hana untuk visualisasi dasar (dimulai secara paralel dengan poin 1)
- 1,5-2 detik - rendering, perhitungan ulang visualisasi
- 1.3sec - pelaksanaan query SQL tambahan untuk mendapatkan nilai filter yang relevan (Merek, Divisi, Kota, Toko), hasil parsing
Untuk meringkas
Kami menyukai alat Tableau dalam hal visualisasi. Pada tahap prototyping, kami memeriksa berbagai elemen visualisasi dan menemukan semuanya di perpustakaan, termasuk segmentasi multi-level yang kompleks dan air terjun multi-driver.
Memperkenalkan dashboard dengan indikator penjualan utama, kami mengalami kesulitan kinerja yang belum dapat kami atasi. Kami menghabiskan lebih dari dua bulan dan mendapatkan dasbor yang secara fungsional tidak lengkap, kecepatan responsnya di ambang batas yang diizinkan. Dan untuk saya sendiri, kami menyimpulkan:
- Tableau tidak tahu cara bekerja dengan data dalam jumlah besar. Jika dalam model data asli Anda memiliki lebih dari 10 GB data (sekitar 200 juta X 50 baris), maka dasbor sangat melambat - dari 10 detik hingga beberapa menit per klik. Kami bereksperimen dengan koneksi langsung dan ekstrak. Kecepatan kerja sebanding.
- Batasan saat menggunakan beberapa penyimpanan (kumpulan data). Tidak ada cara untuk menunjukkan hubungan dataset menggunakan alat standar. Jika Anda menggunakan solusi untuk menghubungkan kumpulan data, maka ini akan sangat mempengaruhi kinerja. Dalam kasus kami, kami mempertimbangkan opsi mematerialisasi data di setiap bagian representasi yang diinginkan, dan pada dataset terwujud ini untuk melakukan peralihan dengan menyimpan filter yang dipilih sebelumnya - ini ternyata mustahil dilakukan di Tableau.
- Di Tableau, tidak mungkin membuat parameter dinamis. Anda tidak dapat menggunakan parameter yang digunakan untuk memfilter dataset dalam ekstrak, baik selama live-connecte, untuk mengisi hasil seleksi lain dari dataset atau hasil dari query SQL lain, hanya input pengguna asli atau konstan.
- Keterbatasan terkait dengan membangun dasbor dengan elemen OLAP | PivotTable.
Di MSTR, SAP SAC, Analisis SAP, jika Anda menambahkan dataset ke laporan, maka semua objek di dalamnya terhubung satu sama lain secara default. Di Tableau ini bukan, 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 hanya terbatas pada kota-kota di wilayah ini, Anda akan segera mendapatkan kueri berturut-turut ke database atau mengekstrak, yang terasa memperlambat dasbor. - Pembatasan Fitur. Baik atas ekstrak dan LEBIH DARI pada dataset dari Live-connecta Anda tidak dapat melakukan konversi massal. Ini dapat dilakukan melalui Tableau Prep, tetapi ini merupakan pekerjaan tambahan dan alat lain yang perlu dipelajari dan dipelihara. Anda, misalnya, tidak dapat memindahkan data, membuatnya bergabung sendiri. Apa yang ditutup melalui transformasi pada masing-masing kolom atau bidang yang harus dipilih melalui kasus atau jika dan ini menghasilkan pertanyaan SQL yang sangat kompleks, di mana database menghabiskan sebagian besar waktu mengkompilasi teks kueri. Kekakuan instrumen ini harus diselesaikan di tingkat etalase, yang mengarah pada penyimpanan yang lebih rumit, beban tambahan, dan transformasi.
Kami tidak mengakhiri Tableau. Tetapi sebagai alat yang dapat membangun dasbor industri dan alat yang dengannya Anda dapat mengganti dan mendigitalkan seluruh sistem pelaporan perusahaan perusahaan, Tableau tidak dipertimbangkan.
Sekarang kami secara aktif mengembangkan dasbor serupa pada alat lain dan secara paralel kami mencoba merevisi arsitektur dasbor di Tableau untuk lebih menyederhanakannya. Jika komunitas tertarik, kami akan memberi tahu Anda tentang hasilnya.
Kami juga menunggu ide atau saran Anda tentang bagaimana Tabeau dapat membangun dashboard cepat atas volume data yang begitu besar, karena kami juga memiliki situs web di mana terdapat lebih banyak data daripada di ritel.