Masa untuk melaporkan dalam Excel semakin hilang dengan cepat - arah aliran ke arah alat yang mudah untuk mempersembahkan dan menganalisis maklumat dapat dilihat di semua kawasan. Kami telah lama membincangkan pendigitalan pelaporan secara dalaman dan memilih visualisasi Tableau dan sistem analitik layan diri. Alexander Bezugly, ketua bahagian penyelesaian analisis dan pelaporan Kumpulan M.Video-Eldorado, bercakap tentang pengalaman dan hasil membina papan pemuka pertempuran.
Saya akan katakan dengan segera bahawa tidak semua yang dirancang dapat direalisasikan, tetapi pengalaman itu menarik, saya harap ia akan berguna kepada anda juga. Dan jika sesiapa mempunyai sebarang idea tentang cara ia boleh dilakukan dengan lebih baik, saya amat berterima kasih atas nasihat dan idea anda.
Di bawah potongan adalah tentang perkara yang kami temui dan perkara yang kami pelajari.
Di mana kita bermula?
M.Video-Eldorado mempunyai model data yang dibangunkan dengan baik: maklumat berstruktur dengan kedalaman storan yang diperlukan dan sejumlah besar laporan bentuk tetap (lihat butiran lanjut ). Daripada ini, penganalisis membuat sama ada jadual pangsi atau surat berita berformat dalam Excel, atau persembahan PowerPoint yang cantik untuk pengguna akhir.
Kira-kira dua tahun yang lalu, bukannya laporan bentuk tetap, kami mula membuat laporan analisis dalam Analisis SAP (tambahan Excel, pada asasnya jadual pangsi ke atas enjin OLAP). Tetapi alat ini tidak dapat memenuhi keperluan semua pengguna; majoriti terus menggunakan maklumat yang diproses tambahan oleh penganalisis.
Pengguna akhir kami terbahagi kepada tiga kategori:
Pihak atasan. Meminta maklumat dengan cara yang disampaikan dengan baik dan boleh difahami dengan jelas.
Pengurusan pertengahan, pengguna lanjutan. Berminat dalam penerokaan data dan boleh membina laporan secara bebas jika alat tersedia. Mereka menjadi pengguna utama laporan analisis dalam Analisis SAP.
Pengguna beramai-ramai. Mereka tidak berminat untuk menganalisis data secara bebas; mereka menggunakan laporan dengan tahap kebebasan yang terhad, dalam format surat berita dan jadual pangsi dalam Excel.
Idea kami adalah untuk menampung keperluan semua pengguna dan memberi mereka satu alat yang mudah. Kami memutuskan untuk bermula dengan pengurusan tertinggi. Mereka memerlukan papan pemuka yang mudah digunakan untuk menganalisis hasil perniagaan utama. Jadi, kami bermula dengan Tableau dan mula-mula memilih dua arah: penunjuk jualan runcit dan dalam talian dengan kedalaman dan keluasan analisis terhad, yang akan meliputi kira-kira 80% daripada data yang diminta oleh pengurusan atasan.
Memandangkan pengguna papan pemuka adalah pengurusan tertinggi, satu lagi KPI tambahan produk muncul - kelajuan tindak balas. Tiada siapa yang akan menunggu 20-30 saat untuk data dikemas kini. Navigasi sepatutnya dilakukan dalam masa 4-5 saat, atau lebih baik lagi, dilakukan serta-merta. Dan kami, malangnya, gagal mencapai ini.
Beginilah rupa reka letak papan pemuka utama kami:
Idea utama adalah untuk menggabungkan pemacu KPI utama, yang mana terdapat 19 kesemuanya, di sebelah kiri dan mempersembahkan dinamik serta pecahan mengikut atribut utama di sebelah kanan. Tugas itu kelihatan mudah, visualisasi adalah logik dan boleh difahami, sehingga anda menyelami butirannya.
Butiran 1. Jumlah data
Jadual utama kami untuk jualan tahunan mengambil kira-kira 300 juta baris. Memandangkan adalah perlu untuk mencerminkan dinamik untuk tahun lepas dan tahun sebelumnya, jumlah data pada jualan sebenar sahaja adalah kira-kira 1 bilion baris. Maklumat mengenai data yang dirancang dan blok jualan dalam talian juga disimpan secara berasingan. Oleh itu, walaupun kami menggunakan kolumnar dalam memori DB SAP HANA, kelajuan pertanyaan dengan pemilihan semua penunjuk selama seminggu dari storan semasa dengan cepat adalah kira-kira 15-20 saat. Penyelesaian kepada masalah ini mencadangkan dirinya sendiri - pewujudan data tambahan. Tetapi ia juga mempunyai perangkap, lebih lanjut mengenainya di bawah.
Perincian 2. Penunjuk bukan tambahan
Banyak KPI kami terikat dengan bilangan resit. Dan penunjuk ini mewakili COUNT DISTINCT daripada bilangan baris (semak pengepala) dan menunjukkan jumlah yang berbeza bergantung pada atribut yang dipilih. Sebagai contoh, bagaimana penunjuk ini dan terbitannya harus dikira:
Untuk membuat pengiraan anda betul, anda boleh:
- Kira penunjuk sedemikian dengan cepat dalam storan;
- Lakukan pengiraan pada keseluruhan isipadu data dalam Tableau, i.e. atas permintaan dalam Tableau, sediakan semua data mengikut penapis yang dipilih dalam butiran kedudukan penerimaan;
- Buat pameran terwujud di mana semua penunjuk akan dikira dalam semua pilihan sampel yang memberikan hasil bukan tambahan yang berbeza.
Adalah jelas bahawa dalam contoh UTE1 dan UTE2 ialah atribut material yang mewakili hierarki produk. Ini bukan perkara yang statik; pengurusan dalam syarikat berlaku melaluinya, kerana Pengurus yang berbeza bertanggungjawab untuk kumpulan produk yang berbeza. Kami mempunyai banyak semakan global hierarki ini, apabila semua peringkat berubah, apabila perhubungan disemak, dan titik tetap berubah, apabila satu kumpulan berpindah dari satu nod ke nod yang lain. Dalam pelaporan konvensional, semua ini dikira dengan cepat dari atribut bahan; dalam kes pewujudan data ini, adalah perlu untuk membangunkan mekanisme untuk menjejaki perubahan tersebut dan memuat semula data sejarah secara automatik. Satu tugas yang sangat tidak remeh.
Perincian 3. Perbandingan data
Perkara ini serupa dengan yang sebelumnya. Intinya ialah apabila menganalisis syarikat, adalah kebiasaan untuk membentuk beberapa peringkat perbandingan dengan tempoh sebelumnya:
Perbandingan dengan tempoh lalu (hari ke hari, minggu ke minggu, bulan ke bulan)
Dalam perbandingan ini, diandaikan bahawa bergantung pada tempoh yang dipilih oleh pengguna (contohnya, minggu ke-33 dalam setahun), kami harus menunjukkan dinamik menjelang minggu ke-32; jika kami memilih data untuk sebulan, contohnya, Mei , maka perbandingan ini akan menunjukkan dinamik menjelang April.
Perbandingan dengan tahun lepas
Nuansa utama di sini ialah apabila membandingkan mengikut hari dan mengikut minggu, anda tidak mengambil hari yang sama tahun lepas, i.e. anda tidak boleh meletakkan tahun semasa tolak satu sahaja. Anda mesti melihat hari dalam minggu yang anda bandingkan. Apabila membandingkan bulan, sebaliknya, anda perlu mengambil hari kalendar yang sama pada tahun lepas. Terdapat juga nuansa dengan tahun lompat. Dalam repositori asal, semua maklumat diedarkan mengikut hari; tiada medan berasingan dengan minggu, bulan atau tahun. Oleh itu, untuk mendapatkan keratan rentas analitik yang lengkap dalam panel, anda perlu mengira bukan satu tempoh, contohnya seminggu, tetapi 4 minggu, dan kemudian membandingkan data ini, mencerminkan dinamik, sisihan. Sehubungan itu, logik ini untuk menjana perbandingan dalam dinamik juga boleh dilaksanakan sama ada di Tableau atau di bahagian hadapan kedai. Ya, dan sudah tentu kami tahu dan memikirkan butiran ini pada peringkat reka bentuk, tetapi sukar untuk meramalkan kesannya terhadap prestasi papan pemuka akhir.
Apabila melaksanakan papan pemuka, kami mengikuti laluan Agile yang panjang. Tugas kami adalah untuk menyediakan alat yang berfungsi dengan data yang diperlukan untuk ujian secepat mungkin. Oleh itu, kami berlari pecut dan bermula daripada meminimumkan kerja pada sisi storan semasa.
Bahagian 1: Iman dalam Tableau
Untuk memudahkan sokongan IT dan melaksanakan perubahan dengan cepat, kami memutuskan untuk membuat logik untuk mengira penunjuk bukan aditif dan membandingkan tempoh lalu dalam Tableau.
Peringkat 1. Semuanya Langsung, tiada pengubahsuaian tetingkap.
Pada peringkat ini, kami menyambungkan Tableau ke etalase semasa dan memutuskan untuk melihat bagaimana bilangan resit untuk satu tahun akan dikira.
Keputusan:
Jawapannya menyedihkan - 20 minit. Pemindahan data melalui rangkaian, beban tinggi pada Tableau. Kami menyedari bahawa logik dengan penunjuk bukan tambahan perlu dilaksanakan pada HANA. Ini tidak menakutkan kami, kami sudah mempunyai pengalaman yang sama dengan BO dan Analisis dan kami tahu cara membina pameran pantas dalam HANA yang menghasilkan penunjuk bukan aditif yang dikira dengan betul. Sekarang yang tinggal hanyalah menyesuaikannya dengan Tableau.
Peringkat 2. Kami menala kes paparan, tidak menjadi kenyataan, semuanya dengan cepat.
Kami mencipta pameran baharu yang berasingan yang menghasilkan data yang diperlukan untuk TABLEAU dengan segera. Secara umum, kami mendapat keputusan yang baik; kami mengurangkan masa untuk menjana semua penunjuk dalam satu minggu kepada 9-10 saat. Dan kami dengan jujur ββmenjangkakan bahawa dalam Tableau masa tindak balas papan pemuka ialah 20-30 saat pada pembukaan pertama dan kemudian disebabkan oleh cache dari 10 hingga 12, yang secara amnya sesuai dengan kami.
Keputusan:
Papan pemuka pertama dibuka: 4-5 minit
Sebarang klik: 3-4 minit
Tiada siapa yang menjangkakan peningkatan tambahan sedemikian dalam kerja etalase.
Bahagian 2. Menyelam ke dalam Tableau
Peringkat 1. Analisis prestasi Tableau dan penalaan pantas
Kami mula menganalisis tempat Tableau menghabiskan sebahagian besar masanya. Dan terdapat alat yang cukup baik untuk ini, yang, tentu saja, merupakan tambahan dari Tableau. Masalah utama yang kami kenal pasti ialah pertanyaan SQL yang sangat kompleks yang sedang dibina oleh Tableau. Mereka terutamanya dikaitkan dengan:
- transposisi data. Memandangkan Tableau tidak mempunyai alat untuk menukar set data, untuk membina bahagian kiri papan pemuka dengan perwakilan terperinci semua KPI, kami perlu mencipta jadual menggunakan kes. Saiz pertanyaan SQL dalam pangkalan data mencapai 120 aksara.
- memilih tempoh masa. Pertanyaan sedemikian di peringkat pangkalan data mengambil lebih banyak masa untuk disusun daripada melaksanakan:
Itu. permintaan pemprosesan 12 saat + 5 saat pelaksanaan.
Kami memutuskan untuk memudahkan logik pengiraan di sebelah Tableau dan memindahkan bahagian pengiraan yang lain ke peringkat etalase dan pangkalan data. Ini membawa hasil yang baik.
Mula-mula, kami melakukan transposisi dengan cepat, kami melakukannya melalui gabungan luar penuh pada peringkat akhir pengiraan VIEW, mengikut pendekatan yang diterangkan di wiki ini ΠΈ .
Iaitu, kami membuat jadual tetapan - matriks transposisi (21x21) dan menerima semua penunjuk dalam pecahan baris demi baris.
Adakah:
menjadi:
Hampir tiada masa dihabiskan untuk transposisi pangkalan data itu sendiri. Permintaan untuk semua penunjuk untuk minggu itu terus diproses dalam kira-kira 10 saat. Tetapi sebaliknya, fleksibiliti telah hilang dari segi membina papan pemuka berdasarkan penunjuk tertentu, i.e. untuk bahagian kanan papan pemuka yang memaparkan dinamik dan pecahan terperinci penunjuk tertentu, sebelum ini kes paparan berfungsi dalam 1-3 saat, kerana permintaan itu berdasarkan satu penunjuk, dan kini pangkalan data sentiasa memilih semua penunjuk dan menapis hasilnya sebelum mengembalikan hasilnya ke Tableau.
Akibatnya, kelajuan papan pemuka berkurangan hampir 3 kali ganda.
Keputusan:
- 5 saat β menghuraikan papan pemuka, visualisasi
- 15-20 saat - persediaan untuk menyusun pertanyaan dengan melakukan pra-pengiraan dalam Tableau
- 35-45 saat - kompilasi pertanyaan SQL dan pelaksanaan berurutan selari mereka dalam Hana
- 5 saat β memproses hasil, menyusun, mengira semula visualisasi dalam Tableau
- Sudah tentu, keputusan sedemikian tidak sesuai dengan perniagaan, dan kami meneruskan pengoptimuman.
Peringkat 2. Logik minimum dalam Tableau, pewujudan lengkap
Kami memahami bahawa adalah mustahil untuk membina papan pemuka dengan masa tindak balas selama beberapa saat pada etalase yang berjalan selama 10 saat, dan kami mempertimbangkan pilihan untuk merealisasikan data pada bahagian pangkalan data khusus untuk papan pemuka yang diperlukan. Tetapi kami menghadapi masalah global yang diterangkan di atas - penunjuk bukan tambahan. Kami tidak dapat memastikan bahawa apabila menukar penapis atau drilldown, Tableau bertukar secara fleksibel antara etalase dan tahap yang berbeza yang direka bentuk untuk hierarki produk yang berbeza (dalam contoh, tiga pertanyaan tanpa UTE, dengan UTE1 dan UTE2 menjana hasil yang berbeza). Oleh itu, kami memutuskan untuk memudahkan papan pemuka, meninggalkan hierarki produk dalam papan pemuka dan melihat sejauh mana ia boleh menjadi dalam versi yang dipermudahkan.
Jadi, pada peringkat terakhir ini, kami memasang repositori berasingan di mana kami menambah semua KPI dalam bentuk transposed. Di bahagian pangkalan data, sebarang permintaan kepada storan sedemikian diproses dalam 0,1 - 0,3 saat. Dalam papan pemuka kami menerima keputusan berikut:
Pembukaan pertama: 8-10 saat
Sebarang klik: 6-7 saat
Masa yang dibelanjakan oleh Tableau terdiri daripada:
- 0,3 saat. β penghuraian papan pemuka dan penyusunan pertanyaan SQL
- 1,5-3 saat. β pelaksanaan pertanyaan SQL dalam Hana untuk visualisasi utama (berjalan selari dengan langkah 1)
- 1,5-2 saat. β rendering, pengiraan semula visualisasi
- 1,3 saat β pelaksanaan pertanyaan SQL tambahan untuk mendapatkan nilai penapis yang berkaitan (Jenama, Bahagian, Bandar, Kedai), hasil penghuraian
Untuk merumuskannya secara ringkas
Kami menyukai alat Tableau dari perspektif visualisasi. Pada peringkat prototaip, kami mempertimbangkan pelbagai elemen visualisasi dan mendapati semuanya dalam perpustakaan, termasuk pembahagian pelbagai peringkat yang kompleks dan air terjun berbilang pemacu.
Semasa melaksanakan papan pemuka dengan penunjuk jualan utama, kami menghadapi kesukaran prestasi yang belum dapat kami atasi. Kami menghabiskan lebih daripada dua bulan dan menerima papan pemuka yang berfungsi tidak lengkap, kelajuan tindak balas yang hampir boleh diterima. Dan kami membuat kesimpulan untuk diri kami sendiri:
- Tableau tidak boleh berfungsi dengan jumlah data yang besar. Jika dalam model data asal anda mempunyai lebih daripada 10 GB data (kira-kira 200 juta X 50 baris), maka papan pemuka akan menjadi perlahan - dari 10 saat hingga beberapa minit untuk setiap klik. Kami bereksperimen dengan sambungan langsung dan ekstrak. Kelajuan operasi adalah setanding.
- Had apabila menggunakan berbilang storan (set data). Tiada cara untuk menunjukkan hubungan antara set data menggunakan cara standard. Jika anda menggunakan penyelesaian untuk menyambung set data, ini akan mempengaruhi prestasi. Dalam kes kami, kami mempertimbangkan pilihan untuk merealisasikan data dalam setiap bahagian paparan yang diperlukan dan menukar set data terwujud ini sambil mengekalkan penapis yang dipilih sebelum ini - ini ternyata mustahil untuk dilakukan di Tableau.
- Tidak mustahil untuk membuat parameter dinamik dalam Tableau. Anda tidak boleh mengisi parameter yang digunakan untuk menapis set data dalam ekstrak atau semasa penyambungan langsung dengan hasil pemilihan lain daripada set data atau hasil pertanyaan SQL lain, hanya input pengguna asli atau pemalar.
- Had yang dikaitkan dengan membina papan pemuka dengan elemen OLAP|PivotTable.
Dalam MSTR, SAP SAC, Analisis SAP, jika anda menambah set data pada laporan, maka semua objek padanya berkaitan antara satu sama lain secara lalai. Tableau tidak mempunyai ini; sambungan mesti dikonfigurasikan secara manual. Ini mungkin lebih fleksibel, tetapi untuk semua papan pemuka kami ini adalah keperluan mandatori untuk elemen - jadi ini adalah kos buruh tambahan. Lebih-lebih lagi, jika anda membuat penapis yang berkaitan supaya, sebagai contoh, apabila menapis rantau, senarai bandar dihadkan hanya kepada bandar-bandar di rantau ini, anda serta-merta berakhir dengan pertanyaan berturut-turut kepada pangkalan data atau Ekstrak, yang ketara memperlahankan papan pemuka. - Had dalam fungsi. Transformasi jisim tidak boleh dilakukan sama ada pada ekstrak atau, TERUTAMA, pada set data daripada Live-connecta. Ini boleh dilakukan melalui Tableau Prep, tetapi ia adalah kerja tambahan dan alat lain untuk belajar dan mengekalkan. Sebagai contoh, anda tidak boleh menukar data atau menyertainya dengan dirinya sendiri. Perkara yang ditutup melalui transformasi pada lajur atau medan individu, yang mesti dipilih melalui kes atau jika, dan ini menjana pertanyaan SQL yang sangat kompleks, di mana pangkalan data menghabiskan sebahagian besar masanya menyusun teks pertanyaan. Ketidakfleksibelan alat ini perlu diselesaikan di peringkat pameran, yang membawa kepada storan yang lebih kompleks, muat turun tambahan dan transformasi.
Kami tidak berputus asa dengan Tableau. Tetapi kami tidak menganggap Tableau sebagai alat yang mampu membina papan pemuka industri dan alat untuk menggantikan dan mendigitalkan keseluruhan sistem pelaporan korporat syarikat.
Kami kini sedang giat membangunkan papan pemuka yang serupa dalam alat lain dan, pada masa yang sama, cuba menyemak semula seni bina papan pemuka di Tableau untuk memudahkannya lagi. Jika komuniti berminat, kami akan memberitahu anda tentang hasilnya.
Kami juga sedang menunggu idea atau nasihat anda tentang cara di Tabeau anda boleh membina papan pemuka pantas atas volum data yang begitu besar, kerana kami mempunyai tapak web yang mempunyai lebih banyak data berbanding dalam runcit.
Sumber: www.habr.com