Di Playrix, sejumlah besar sumber daya dialokasikan untuk persiapan dan analisis data, kami mencoba menggunakan teknologi canggih dan melakukan pelatihan karyawan dengan serius. Perusahaan ini adalah salah satu dari 3 pengembang game seluler teratas di dunia, jadi kami berusaha menjaga level yang sesuai dalam analisis data dan khususnya dalam Business Intelligence. Lebih dari 27 juta pengguna memainkan game kami setiap hari, dan angka ini dapat memberikan gambaran kasar tentang jumlah data yang dihasilkan oleh perangkat seluler setiap hari. Selain itu, data diambil dari lusinan layanan dalam berbagai format, setelah itu dikumpulkan dan dimuat ke penyimpanan kami. Kami bekerja dengan AWS S3 sebagai Data Lake, sementara Data Warehouse di AWS Redshift dan PostgreSQL memiliki penggunaan terbatas. Kami menggunakan database ini untuk analitik. Perpindahan gigi lebih cepat tetapi lebih mahalitulah mengapa kami menyimpan data yang paling banyak diminta di sana. PostgreSQL lebih murah dan lebih lambat, ia menyimpan sejumlah kecil data atau data yang kecepatan pembacaannya tidak penting. Untuk data yang telah digabungkan sebelumnya, kami menggunakan cluster Hadoop dan Impala.
Alat BI utama di Playrix adalah Tableau. Produk ini terkenal di dunia, memiliki banyak peluang untuk analisis dan visualisasi data, bekerja dengan berbagai sumber. Selain itu, Anda tidak perlu menulis kode untuk tugas analisis sederhana, sehingga Anda dapat melatih pengguna dari berbagai departemen untuk menganalisis data bisnis mereka sendiri. Vendor alat Tableau Software juga memposisikan produknya sebagai alat untuk analisis data sendiri, yaitu untuk Self-Service.
Ada dua pendekatan utama untuk analisis data di BI:
- Pabrik Pelaporan . Pendekatan ini memiliki departemen dan / atau orang yang mengembangkan laporan untuk pengguna bisnis.
- Self-Service. - .
Pendekatan pertama adalah tradisional, dan sebagian besar perusahaan memiliki pabrik pelaporan berskala perusahaan seperti ini. Pendekatan kedua relatif baru, terutama untuk Rusia. Ini bagus karena datanya diteliti oleh pengguna bisnis itu sendiri - mereka tahu proses lokalnya jauh lebih baik. Ini membantu menurunkan pengembang, membebaskan mereka dari kebutuhan untuk menyelami proses tim secara spesifik dan membuat laporan paling dasar setiap saat. Ini membantu memecahkan apa yang mungkin menjadi masalah terbesar - menjembatani jurang antara pengguna bisnis dan pengembang. Bagaimanapun, masalah utama dari pendekatan Pabrik Pelaporan justru sebagian besar laporan mungkin tetap tidak diklaim hanya karena fakta bahwa programmer-pengembang salah memahami masalah pengguna bisnis dan, karenanya, membuat laporan yang tidak perlu.yang dikerjakan ulang nanti, atau tidak digunakan.
Di Playrix, programmer dan analis awalnya terlibat dalam pengembangan laporan di perusahaan, yaitu spesialis yang bekerja dengan data setiap hari. Tetapi perusahaan berkembang sangat pesat, dan seiring dengan meningkatnya kebutuhan pengguna akan laporan, pengembang laporan tidak lagi tepat waktu untuk menyelesaikan semua tugas pembuatan dan dukungan mereka. Kemudian muncul pertanyaan apakah akan memperluas kelompok pengembangan BI, atau mentransfer kompetensi ke departemen lain. Arah Self Service tampak menjanjikan bagi kami, jadi kami memutuskan untuk mengajari pengguna bisnis untuk membuat proyek mereka sendiri dan menganalisis data sendiri.
Di Playrix, divisi Business Intelligence (Tim BI) bekerja pada tugas-tugas berikut ini:
- Pengumpulan, persiapan dan penyimpanan data.
- Pengembangan layanan analitik internal.
- Integrasi dengan layanan eksternal.
- Pengembangan antarmuka web.
- Pengembangan pelaporan di Tableau.
Kami terlibat dalam otomatisasi proses dan analitik internal. Dengan cara yang disederhanakan, struktur kami dapat direpresentasikan menggunakan diagram:
Tim BI mini-tim
Persegi panjang di sini mewakili tim mini. Di tim bek kiri, di tim kanan depan. Masing-masing memiliki kompetensi yang cukup untuk bekerja dengan tugas tim terkait dan mengambil alih ketika tim lain kelebihan beban.
Tim BI memiliki siklus pengembangan penuh: mulai dari mengumpulkan persyaratan hingga penerapan di lingkungan produk dan dukungan selanjutnya. Setiap tim mini memiliki analis sistem, pengembang, dan insinyur penguji sendiri. Mereka berfungsi sebagai Pabrik Pelaporan , menyiapkan data dan laporan untuk penggunaan internal.
Penting untuk dicatat di sini bahwa di sebagian besar proyek Tableau kami mengembangkan bukan laporan sederhana, yang biasanya ditampilkan dalam demo, tetapi alat dengan fungsionalitas yang kaya, sekumpulan besar kontrol, kemampuan ekstensif dan koneksi modul eksternal. Alat-alat ini terus direvisi, fitur-fitur baru ditambahkan.
Namun, masalah lokal yang sederhana juga datang, yang dapat diselesaikan sendiri oleh pelanggan.
Transfer kompetensi dan peluncuran proyek percontohan
Menurut pengalaman kami bekerja dan berkomunikasi dengan perusahaan lain, masalah utama saat mentransfer kompetensi data ke pengguna bisnis adalah:
- Keengganan pengguna itu sendiri untuk mempelajari alat baru dan bekerja dengan data.
- Kurangnya dukungan dari manajemen (investasi dalam pelatihan, lisensi, dll.).
Kami mendapat dukungan besar dari manajemen, terlebih lagi, manajemen menawarkan untuk memperkenalkan Self-Service. Pengguna juga memiliki keinginan untuk belajar bagaimana bekerja dengan data dan Tableau - ini menarik untuk teman-teman, ditambah analisis data sekarang adalah keterampilan yang sangat penting yang pasti akan berguna di masa depan.
Menerapkan ideologi baru di seluruh perusahaan biasanya membutuhkan banyak sumber daya dan saraf, jadi kami mulai dengan uji coba. Proyek percontohan Layanan Mandiri diluncurkan di departemen Akuisisi Pengguna satu setengah tahun yang lalu, dan selama proses percontohan, kesalahan dan pengalaman diakumulasikan untuk diteruskan ke departemen lain di masa mendatang.
Arahan Akuisisi Pengguna berfungsi pada tugas meningkatkan audiens produk kami, menganalisis cara membeli lalu lintas, dan memilih ke arah mana untuk menarik pengguna, perlu menginvestasikan dana perusahaan. Sebelumnya untuk arahan ini, laporan disiapkan oleh tim BI, atau yang diolah sendiri adalah upload dari database menggunakan Excel atau Google Sheets. Tetapi dalam lingkungan pengembangan yang dinamis, analisis semacam itu memerlukan penundaan, dan jumlah data yang dianalisis dibatasi oleh kemampuan alat ini.
Pada awal uji coba, kami melakukan pelatihan dasar bagi karyawan untuk bekerja dengan Tableau, membuat sumber data umum pertama - tabel di database Redshift, di mana terdapat lebih dari 500 juta baris dan metrik yang diperlukan. Perlu dicatat bahwa Redshift adalah database kolom (atau kolom), dan database ini menyajikan data jauh lebih cepat daripada database relasional. Tabel percontohan di Redshift sangat besar untuk orang-orang yang tidak pernah bekerja dengan lebih dari 1 juta baris pada waktu yang sama. Namun, merupakan tantangan bagi mereka untuk mempelajari cara bekerja dengan data dengan volume sebesar itu.
Kami tahu bahwa masalah kinerja akan dimulai saat laporan ini menjadi lebih kompleks. Kami tidak memberi pengguna akses ke database itu sendiri, tetapi sumber diimplementasikan di server Tableau, terhubung dalam mode langsung ke tabel di Redshift. Pengguna memiliki lisensi Pencipta dan dapat terhubung ke sumber ini baik dari server Tableau, mengembangkan laporan di sana, atau dari Desktop Tableau. Saya harus mengatakan bahwa ketika mengembangkan laporan di web (Tableau memiliki mode edit web), ada beberapa batasan di server. Tableau Desktop tidak memiliki batasan seperti itu, jadi kami terutama mengembangkan di Desktop. Selain itu, jika hanya satu pengguna bisnis yang membutuhkan analisis, tidak perlu mempublikasikan proyek semacam itu di server - Anda dapat bekerja secara lokal.
Latihan
Di perusahaan kami, sudah menjadi kebiasaan untuk melakukan webinar dan berbagi pengetahuan, di mana setiap karyawan dapat berbicara tentang produk baru, fitur, atau kemampuan alat yang dia gunakan untuk bekerja atau yang dia teliti. Semua aktivitas semacam itu dicatat dan disimpan di basis pengetahuan kami. Proses ini juga berfungsi di tim kami, jadi kami juga secara berkala berbagi pengetahuan atau menyiapkan webinar pelatihan dasar.
Untuk semua pengguna dengan lisensi Tableau, kami menyelenggarakan dan merekam webinar setengah jam tentang bekerja dengan server dan dasbor. Mereka berbicara tentang proyek di server, bekerja dengan kontrol asli dari semua dasbor - ini adalah panel atas (segarkan, jeda, ...). Sangat penting untuk memberi tahu semua pengguna Tableau tentang hal ini sehingga mereka dapat sepenuhnya bekerja dengan kemampuan asli dan tidak membuat permintaan untuk pengembangan fitur yang mengulangi pekerjaan kontrol asli.
Hambatan utama untuk menguasai suatu alat (dan memang sesuatu yang baru) biasanya adalah ketakutan bahwa tidak mungkin untuk memahami dan bekerja dengan fungsi ini. Oleh karena itu, pelatihan mungkin merupakan langkah terpenting dalam menerapkan pendekatan BI swalayan. Hasil dari penerapan model ini akan sangat bergantung padanya - apakah model itu akan mengakar di perusahaan atau tidak dan, jika demikian, seberapa cepat. Saat meluncurkan webinar, hambatan untuk menggunakan Tableau harus dihilangkan.
Ada dua grup webinar yang kami lakukan untuk orang-orang yang tidak terbiasa dengan pekerjaan database:
- Kit Pengetahuan Pemula Pemula:
- Koneksi data, tipe koneksi, tipe data, transformasi data dasar, normalisasi data (1 jam).
- Visualisasi dasar, agregasi data, penghitungan dasar (1 jam).
- /, (2 ).
Dalam webinar pembuka pertama ini, kami membahas semua yang terkait dengan konektivitas data dan transformasi data di Tableau. Karena orang biasanya memiliki tingkat kemahiran dasar dalam MS Excel, di sini penting untuk menjelaskan bagaimana bekerja di Excel secara fundamental berbeda dari bekerja di Tableau. Ini adalah poin yang sangat penting, karena Anda perlu mengalihkan seseorang dari logika tabel dengan sel berwarna ke logika data database yang dinormalisasi. Di webinar yang sama, kami menjelaskan karya JOIN, UNION, PIVOT, dan juga menyentuh Blending. Di webinar pertama, kami hampir tidak menyentuh visualisasi data, tujuannya adalah menjelaskan cara bekerja dan mengubah data Anda untuk Tableau. Penting bagi orang-orang untuk memahami bahwa data adalah yang utama dan sebagian besar masalah muncul di tingkat data, bukan di tingkat visualisasi.
Webinar kedua tentang Self-Service bertujuan untuk berbicara tentang logika visualisasi bangunan di Tableau. Tableau sangat berbeda dari alat BI lainnya tepatnya karena ia memiliki mesin dan logikanya sendiri. Di sistem lain, misalnya, di PowerBI, ada sekumpulan visual yang sudah jadi (Anda dapat mengunduh modul tambahan di toko), tetapi modul ini tidak dapat disesuaikan. Di Tableau, Anda sebenarnya memiliki papan tulis kosong di mana Anda dapat membangun apa pun yang Anda inginkan. Tentu saja, Tableau memiliki ShowMe - menu visualisasi dasar, tetapi semua grafik dan diagram ini dapat dan harus dibangun sesuai dengan logika Tableau. Menurut pendapat kami, jika Anda ingin mengajari seseorang untuk bekerja dengan Tableau, maka Anda tidak perlu menggunakan ShowMe untuk membuat bagan - kebanyakan dari mereka tidak akan berguna bagi orang-orang pada awalnya, tetapi Anda perlu mengajarkan dengan tepat logika membangun visualisasi. Untuk dasbor bisnis, cukup tahucara membangun:
- Deret Waktu. Grafik Garis / Area (grafik garis),
- Diagram batang
- Plot Sebar,
- Tabel
Kumpulan visualisasi ini cukup untuk analisis data sendiri.
Rangkaian Waktu: mereka sangat sering digunakan dalam bisnis karena menarik untuk membandingkan metrik dalam periode waktu yang berbeda. Mungkin semua karyawan perusahaan sedang melihat dinamika hasil bisnis di negara kita. Kami menggunakan Diagram Batang untuk membandingkan metrik berdasarkan kategori. Scatter Plots jarang digunakan, biasanya untuk menemukan korelasi antar metrik. Tabel: sesuatu yang tidak dapat sepenuhnya dihilangkan oleh dasbor bisnis, tetapi jika memungkinkan kami mencoba meminimalkan jumlahnya. Dalam tabel, kami mengumpulkan nilai numerik metrik berdasarkan kategori.
Artinya, kami mengirim orang dengan free float setelah 1 jam pelatihan dalam bekerja dengan data dan 1 jam pelatihan dalam penghitungan dan visualisasi dasar. Kemudian orang-orang itu sendiri bekerja dengan datanya untuk beberapa waktu, menghadapi masalah, mendapatkan pengalaman, dapatkan saja. Tahap ini rata-rata memakan waktu 2-4 minggu. Wajar saja, selama periode ini ada peluang untuk berkonsultasi dengan Tim BI jika ada yang tidak berjalan.
Setelah tahap pertama, rekan kerja perlu meningkatkan keterampilan mereka dan menjajaki peluang baru. Untuk ini, kami telah menyiapkan webinar pelatihan yang mendalam. Di dalamnya, kami menunjukkan cara bekerja dengan fungsi LOD, fungsi tabel, skrip Python untuk TabPy. Kami bekerja dengan data perusahaan langsung, yang selalu lebih menarik daripada palsu atau data dari kumpulan data Tableau dasar - Superstore. Di webinar yang sama, kami berbicara tentang fitur dan trik utama Tableau yang digunakan pada dasbor berpemilik, misalnya:
- Sheet Swapping (penggantian lembaran),
- Agregasi grafik menggunakan parameter,
- Format tanggal dan metrik
- Membuang periode yang tidak lengkap untuk agregasi mingguan / bulanan.
Semua trik dan fitur ini biasa digunakan beberapa tahun yang lalu, jadi semua orang di perusahaan terbiasa dengannya, dan kami mengadopsinya dalam standar pengembangan dasbor. Kami menggunakan skrip Python untuk menghitung beberapa metrik internal, semua skrip sudah siap, dan untuk Layanan Mandiri kami perlu memahami cara memasukkannya ke dalam perhitungan kami.
Jadi, kami hanya menjalankan 4 jam webinar untuk memulai Layanan Mandiri, dan ini biasanya cukup bagi orang yang termotivasi untuk mulai bekerja dengan Tableau dan menganalisis datanya sendiri. Selain itu, untuk analis data, kami memiliki webinar sendiri, tersedia untuk umum, dan Anda dapat mengenalinya.
Pengembangan sumber data untuk Self-Service
Setelah pilot project dilaksanakan, kami menganggapnya berhasil dan menambah jumlah pengguna Self-Service. Salah satu tantangan terbesar adalah mempersiapkan sumber data untuk tim yang berbeda. Orang-orang di Self-Service dapat bekerja dengan 200+ juta baris, jadi tim Data Engineering harus mencari cara untuk mengimplementasikan sumber data tersebut. Untuk sebagian besar tugas analitis, kami menggunakan Redshift karena kecepatan membaca data dan kemudahan penggunaan. Tetapi memberikan akses ke database untuk setiap orang dari Self-Service berisiko dari sudut pandang keamanan informasi.
Ide pertama adalah untuk membuat sumber dengan koneksi langsung ke database, yaitu, beberapa sumber diterbitkan di Tableau Server yang terlihat baik dalam tabel atau tampilan Redshift yang disiapkan. Dalam kasus ini, kami tidak menyimpan data di server Tableau, dan pengguna melalui sumber ini sendiri pergi dari Desktop Tableau (klien) ke database. Ini berfungsi ketika tabel kecil (jutaan) atau kueri Tableau tidak terlalu rumit. Saat mereka berkembang, orang-orang itu mulai memperumit dasbor mereka di Tableau, menggunakan LOD, jenis kustom, dan skrip Python. Secara alami, ini menyebabkan perlambatan dalam kerja beberapa dasbor Self-Service. Oleh karena itu, beberapa bulan setelah dimulainya Layanan Mandiri, kami merevisi pendekatan untuk bekerja dengan sumber.
Pendekatan baru yang kami gunakan sejauh ini telah menerapkan ekstrak yang diterbitkan ke Server Tableau. Saya harus mengatakan bahwa Self-Service terus-menerus memiliki tugas baru, dan mereka menerima permintaan untuk menambahkan bidang baru ke sumber, tentu saja, sumber data terus diubah. Kami telah mengembangkan strategi berikut untuk bekerja dengan sumber:
- Menurut TOR untuk sumber dari sisi Self-Service, data dikumpulkan dalam tabel database.
- Tampilan yang tidak terwujud dibuat dalam skema pengujian database Redshift.
- Pengajuan diuji kebenaran datanya oleh tim QA.
- Dalam kasus hasil positif dari pemeriksaan, pandangan dimunculkan pada skema prod pergeseran merah.
- Tim Teknik Data mengambil pandangan untuk mendapatkan dukungan - skrip untuk menganalisis validitas data terhubung, alarm ETL terhubung, dan hak baca diberikan kepada tim Self-Service.
- Tableau Server (), .
- ETL .
- .
- , Self-Service.
Sedikit tentang poin 7. Secara asli, Tableau memungkinkan Anda membuat ekstrak sesuai jadwal dengan perbedaan minimum 5 menit. Jika Anda tahu pasti bahwa tabel Anda di database selalu diperbarui pada jam 4 pagi, maka Anda cukup mengatur ekstrak pada jam 5 pagi agar data Anda terkumpul. Ini mencakup berbagai tugas. Dalam kasus kami, tabel dikumpulkan berdasarkan data dari berbagai penyedia, termasuk. Karenanya, jika satu penyedia atau layanan internal kami tidak berhasil memperbarui bagian datanya, maka seluruh tabel dianggap tidak valid. Artinya, Anda tidak bisa begitu saja mengatur jadwal untuk waktu yang tetap. Oleh karena itu, kami menggunakan API Tableau untuk menjalankan ekstrak saat tabel siap. Sinyal peluncuran ekstrak dihasilkan oleh layanan ETL kami setelah memastikan bahwa semua data baru telah tiba dan valid.
Pendekatan ini memungkinkan Anda memiliki data valid baru yang diekstrak dengan latensi minimal.
Menerbitkan Dashboard Self-Service ke Tableau Server
Kami sengaja tidak membatasi orang dalam eksperimen dengan data mereka dan mengizinkan kami untuk menerbitkan dan membagikan buku kerja kami. Dalam setiap tim, jika seseorang berpikir bahwa dasbornya berguna bagi orang lain, atau bahwa karyawan membutuhkan dasbor di server, dia dapat mempublikasikannya. Tim BI tidak ikut campur dalam eksperimen internal tim, masing-masing, mereka mengerjakan semua logika dasbor dan perhitungannya sendiri. Ada kasus ketika proyek yang menarik tumbuh dari Layanan Mandiri, yang kemudian sepenuhnya ditransfer ke dukungan tim BI dan masuk ke produksi. Inilah efek dari Self-Service, ketika orang-orang, yang memiliki pemahaman yang baik tentang tugas-tugas bisnis mereka, mulai bekerja dengan data mereka dan membentuk strategi baru untuk pekerjaan mereka. Berdasarkan ini, kami membuat skema proyek berikut di server:
Diagram Proyek Server Tableau
Setiap pengguna Pencipta dapat menerbitkan buku kerja mereka ke server atau melakukan analisis secara lokal. Untuk Self-Service, kami membuat Sandbox kami sendiri dengan grup proyek kami.
Situs di Tableau terbagi secara ideologis sehingga pengguna satu situs tidak melihat konten situs lainnya, jadi kami membagi server menjadi situs di area yang tidak tumpang tindih: misalnya, analisis dan keuangan game. Kami menggunakan akses grup. Setiap situs memiliki proyek yang mewarisi hak atas buku kerja dan sumbernya. Artinya, grup pengguna Grup 1 hanya melihat buku kerja dan sumber data mereka. Pengecualian untuk aturan ini adalah situs Sandbox, yang juga memiliki subproyek. Kami menggunakan Sandbox untuk membuat prototipe, mengembangkan dasbor baru, mengujinya, dan untuk kebutuhan Self-Service. Siapa pun yang memiliki akses publikasi ke proyek Kotak Pasir mereka dapat menerbitkan prototipe mereka.
Memantau sumber dan dasbor di Tableau Server
Karena kami mentransfer beban permintaan dasbor Self-Service dari database ke Server Tableau, kami bekerja dengan sumber data besar dan tidak membatasi orang pada permintaan ke sumber yang diterbitkan, masalah lain muncul - memantau kinerja dasbor tersebut dan memantau yang dibuat sumber.
Memantau kinerja dashboard dan kinerja server Tableau merupakan tugas yang dihadapi oleh perusahaan menengah dan besar, oleh karena itu cukup banyak artikel yang ditulis tentang kinerja dashboard dan penyetelannya. Kami tidak menjadi pelopor di bidang ini, pemantauan kami adalah beberapa dasbor berdasarkan database internal Server PostgreSQL Tableau. Pemantauan ini berfungsi dengan semua konten, tetapi Anda dapat memilih dasbor Self-Service dan melihat kinerjanya.
Tim BI memecahkan masalah pengoptimalan dasbor dari waktu ke waktu. Pengguna terkadang muncul dengan pertanyaan "Mengapa dasbor lambat?", Dan kita perlu memahami apa yang "lambat" dari sudut pandang pengguna dan kriteria numerik apa yang dapat mencirikan "lambat" ini. Agar tidak mewawancarai pengguna dan tidak menyia-nyiakan waktu kerjanya untuk menceritakan kembali masalah secara mendetail, kami memantau dan menganalisis permintaan http, menemukan yang paling lambat, dan mencari tahu alasannya. Setelah itu, kami akan mengoptimalkan dasbor, jika ini dapat menyebabkan peningkatan kinerja. Jelas bahwa dengan koneksi langsung ke sumber, akan ada penundaan yang terkait dengan pembentukan tampilan di database, penundaan penerimaan data. Ada juga penundaan jaringan yang kami selidiki dengan tim dukungan kami untuk seluruh infrastruktur TI, tetapi kami tidak akan membahasnya di artikel ini.
Sedikit tentang permintaan http
Setiap interaksi pengguna dengan dasbor di browser memulai permintaan http-nya sendiri, dikirim ke Server Tableau. Seluruh sejarah query tersebut disimpan dalam database internal PostgreSQL Tableau Server, periode penyimpanan default adalah 7 hari. Periode ini dapat ditingkatkan dengan mengubah pengaturan Server Tableau, tetapi kami tidak ingin meningkatkan tabel permintaan http, jadi kami cukup mengumpulkan ekstrak tambahan yang hanya berisi data baru setiap hari, sedangkan yang lama tidak ditimpa. Ini adalah cara yang baik dengan sumber daya yang minimal untuk tetap di ekstrak pada data historis server yang sudah tidak ada lagi di database.
Tiap permintaan http memiliki tipenya sendiri (tipe_aksi). Misalnya, _bootstrap adalah pemuatan awal tampilan, filter-tanggal-relatif adalah filter tanggal (penggeser). Sebagian besar jenis dapat diidentifikasi dengan namanya, sehingga jelas apa yang dilakukan setiap pengguna dengan dasbor: seseorang lebih banyak melihat tooltips, seseorang mengubah parameter, seseorang membuat custom_views sendiri, dan seseorang membongkar data.
Di bawah ini adalah dasbor layanan kami yang memungkinkan kami untuk menentukan dasbor lambat, jenis permintaan lambat, dan pengguna yang harus menunggu.
Dasbor untuk memantau permintaan http
Memantau Sesi VizQL
Ketika dasbor dibuka di browser, sesi VizQL diluncurkan di server Tableau, di mana visualisasi diberikan, sumber daya juga dialokasikan untuk mempertahankan sesi. Sesi ini dihentikan setelah 30 menit tidak aktif secara default.
Karena jumlah pengguna di server meningkat dan Self-Service diperkenalkan, kami menerima beberapa permintaan untuk meningkatkan batas sesi VizQL. Masalah bagi pengguna adalah mereka membuka dasbor, mengatur filter, melihat sesuatu dan beralih ke tugas lain di luar Server Tableau, setelah beberapa saat mereka kembali ke dasbor terbuka, tetapi mereka disetel ulang ke tampilan default, dan mereka harus melakukannya. digunakan kembali lagu. Tugas kami adalah membuat pengalaman pengguna lebih nyaman dan memastikan bahwa beban di server tidak meningkat secara kritis.
Dua parameter berikutnya di server dapat diubah, tetapi Anda harus memahami bahwa beban di server dapat meningkat.
vizqlserver.session.expiry.minimum 5
Jumlah menit waktu idle setelah sesi VizQL memenuhi syarat untuk dibuang jika proses VizQL mulai kehabisan memori.
vizqlserver.session.expiry.timeout 30 Jumlah menit waktu idle setelah sesi VizQL dibuang.
Oleh karena itu, kami memutuskan untuk memantau sesi VizQL dan melacak:
- Jumlah sesi,
- Jumlah sesi per pengguna,
- Rata-rata durasi sesi,
- Durasi sesi maksimal.
Selain itu, kami perlu memahami pada hari apa dan jam berapa sesi dibuka paling banyak.
Hasilnya adalah dashboard seperti ini:
Dasbor untuk memantau sesi VizQL
Sejak awal Januari tahun ini, kami mulai secara bertahap meningkatkan batas dan memantau durasi sesi dan pemuatan. Durasi sesi rata-rata meningkat dari 13 menjadi 35 menit - ini dapat dilihat pada grafik durasi sesi rata-rata. Pengaturan terakhir adalah sebagai berikut:
vizqlserver.session.expiry.minimum 120 vizqlserver.session.expiry.timeout 240
Setelah itu, kami menerima umpan balik positif dari pengguna, yang menjadi jauh lebih menyenangkan untuk bekerja - sesi berhenti memudar.
Peta panas dasbor ini juga memungkinkan kami menjadwalkan pekerjaan layanan selama jam-jam dengan permintaan server minimal.
Kami memantau perubahan beban pada cluster - CPU dan RAM - di konsol Zabbix dan AWS. Kami tidak mencatat perubahan yang signifikan pada beban selama peningkatan waktu tunggu.
Jika kita berbicara tentang apa yang dapat membengkokkan server Tableau Anda, maka itu bisa menjadi, misalnya, dasbor yang tidak dioptimalkan. Misalnya, buat tabel di Tableau dengan puluhan ribu baris menurut kategori dan id dari beberapa peristiwa, dan di Ukur gunakan kalkulasi LOD di tingkat id. Dengan probabilitas tinggi, tampilan tabel di server tidak akan berfungsi, dan Anda akan mengalami crash dengan Kesalahan Tidak Terduga, karena semua LOD dalam granulasi minimum akan menghabiskan banyak memori, dan segera proses akan berjalan ke 100% konsumsi memori.
Contoh ini diberikan di sini untuk memperjelas bahwa satu dasbor yang tidak optimal dapat menghabiskan semua sumber daya server, dan bahkan 100 sesi VizQL dari dasbor yang optimal tidak akan menghabiskan begitu banyak sumber daya.
Memantau Sumber Data Server
Di atas, kami mencatat bahwa untuk Self-Service, kami menyiapkan dan menerbitkan beberapa sumber data di server. Semua sumber adalah ekstrak data. Sumber yang diterbitkan disimpan di server dan tersedia untuk orang-orang yang bekerja dengan Desktop Tableau.
Tableau memiliki kemampuan untuk menandai sumber sebagai bersertifikat. Inilah yang dilakukan tim BI saat menyiapkan sumber data untuk Self-Service. Ini memastikan bahwa sumber itu sendiri telah diuji.
Sumber yang diterbitkan bisa sebesar 200 juta baris dan 100 bidang. Untuk Self-Service, ini adalah volume yang sangat besar, karena tidak banyak perusahaan yang memiliki sumber volume tersebut untuk analitik independen.
Biasanya, saat mengumpulkan persyaratan untuk menghasilkan sumber, kami melihat bagaimana kami dapat mengurangi jumlah data dalam sumber dengan mengelompokkan kategori, memecah sumber berdasarkan proyek, atau membatasi periode waktu. Namun, sebagai aturan, sumber diperoleh dari 10 juta baris.
Karena sumbernya besar, gunakan ruang di server, gunakan sumber daya server untuk memperbarui ekstrak, maka semuanya perlu dimonitor, untuk melihat seberapa sering digunakan dan seberapa cepat volumenya bertambah. Untuk ini, kami melakukan pemantauan dari sumber data yang dipublikasikan. Ini memperlihatkan pengguna yang menyambungkan ke sumber, buku kerja yang menggunakan sumber tersebut. Ini memungkinkan Anda menemukan sumber yang tidak relevan atau sumber bermasalah yang tidak dapat dikumpulkan ekstrak.
Dasbor pemantauan sumber
Hasil
Kami telah menggunakan pendekatan Self-Service selama 1,5 tahun. Selama waktu ini, 50 pengguna mulai bekerja dengan data secara mandiri. Hal ini mengurangi beban Tim BI dan memungkinkan mereka untuk tidak menunggu sampai Tim BI sampai pada tugas khusus mereka untuk mengembangkan dashboard. Sekitar 5 bulan yang lalu, kami mulai menghubungkan area lain ke analisis mandiri.
Kami berencana untuk mengadakan pelatihan tentang praktik terbaik literasi dan visualisasi data.
Penting untuk dipahami bahwa proses Self-Service tidak dapat diterapkan dengan cepat di seluruh perusahaan; ini akan memakan waktu. Jika proses transisi bersifat organik, tanpa mengejutkan karyawan, maka setelah beberapa tahun implementasi, Anda bisa mendapatkan proses yang berbeda secara fundamental untuk bekerja dengan data di berbagai departemen dan area perusahaan.