Kami mengumpulkan lebih dari dua miliar peristiwa analitis per hari. Berkat ini, kita dapat menemukan banyak hal yang diperlukan: apakah mereka mengklik hati lebih dari pada bintang-bintang, jam berapa mereka menulis deskripsi yang lebih rinci, di daerah mana mereka sering kehilangan tombol hijau.

Sistem pengumpulan dan analisis acara dapat secara umum disebut clickstream. Saya akan memberi tahu Anda tentang sisi teknis dari clickstream di Avito: pengaturan acara, pengiriman dan pengirimannya, analitik, laporan. Mengapa Anda menginginkannya sendiri, jika ada Google Analytics dan Yandex.Metrica, yang pengembang clickstream merusak kehidupan dan mengapa go-coders tidak bisa melupakan php.

Tentang saya

Dmitry Khasanov, sepuluh tahun dalam pengembangan web, tiga tahun di Avito. Saya bekerja di tim platform, mengembangkan alat infrastruktur umum. Saya suka hackathons .

Tantangan

Bisnis membutuhkan pemahaman yang mendalam tentang proses yang terjadi di situs. Misalnya, saat mendaftar pengguna, saya ingin tahu dari wilayah mana, dari perangkat mana dan melalui browser mana pengguna telah login. Bagaimana kolom isian diisi, apakah itu dikirimkan, atau pengguna menyerah. Dan jika Anda menyerah, pada langkah apa. Dan berapa banyak waktu yang dibutuhkan.

Saya ingin tahu apakah mereka akan mengklik tombol lebih sering jika dicat ulang dengan warna hijau. Apakah tombol hijau akan lebih sering ditekan di Murmansk atau di Vladivostok, siang atau malam, oleh pengguna aplikasi seluler atau situs; pengguna yang berasal dari utama atau dari pencarian; yang membeli sebelumnya di Avito atau yang datang untuk pertama kalinya.

Semua tanda-tanda ini: sistem operasi, ID pengguna, waktu permintaan, perangkat, browser, nilai-nilai di bidang - harus tersedia untuk analisis. Kumpulkan, susun, berikan akses cepat ke data.

Selain itu, seringkali diperlukan untuk membagi aliran acara. Proyek perlu mengambil tindakan ketika peristiwa tertentu terjadi. Misalnya, dengan cara ini, umpan balik diperoleh untuk melatih ulang model untuk pengenalan pola dan moderasi otomatis, dan statistik waktu nyata dikompilasi.

Menggunakan clickstream sebagai produk, semestinya mudah bagi programmer untuk mengirim acara dari suatu proyek, dan bagi analis untuk mengelola acara yang dikumpulkan dan membuat berbagai laporan yang menunjukkan tren dan hipotesis pendukung.

Laporan berdasarkan alur acara.
Contoh 1

Contoh 2

Alat jadi

Kami tahu tentang Yandex Metric dan Google Analytics, kami menggunakannya untuk beberapa tugas. Dengan bantuan mereka, baik dan cepat untuk mengumpulkan data analitik dari ujung depan. Tetapi untuk mengekspor data dari backends ke sistem analitik eksternal, Anda harus melakukan integrasi rumit.

Dengan alat eksternal, Anda harus secara mandiri menyelesaikan masalah pemisahan aliran acara.

Informasi analitis sangat berharga. Kami telah mengumpulkannya selama bertahun-tahun, memungkinkan kami untuk mengetahui dengan sangat rinci bagaimana perilaku pengguna kami. Saya tidak ingin berbagi pengetahuan seperti itu dengan dunia luar.

Legislasi berkewajiban untuk menyimpan data di wilayah Rusia.

Alasan-alasan ini cukup untuk mengembangkan solusi kami sendiri sebagai alat utama untuk mengumpulkan dan memproses data analitis.

Solusi

Acara dikirim melalui transportasi berkinerja tinggi (Pemrosesan Streaming Acara, ESP) di penyimpanan (Data Warehouse, DWH). Berdasarkan data dalam repositori, laporan analitis dibuat.

Acara

Entitas pusat. Dalam dirinya sendiri, itu berarti fakta. Sesuatu yang konkrit terjadi dalam satuan waktu yang ditentukan.

Penting untuk membedakan satu peristiwa dari yang lain. Ini adalah pengidentifikasi unik acara tersebut.

Juga tertarik dengan waktu terjadinya peristiwa. Kami mengirimkannya di setiap acara dengan akurasi mikrodetik. Dalam acara yang tiba dari frontend, kami juga memperbaiki waktu pada perangkat klien untuk mengembalikan urutan tindakan dengan lebih akurat.

Lapangan

Acara terdiri dari bidang. Field adalah unit semantik terkecil dari sistem analitik. Dalam paragraf sebelumnya ada contoh bidang: pengidentifikasi acara, waktu pengiriman.

Atribut bidang: tipe (string, angka, array), wajib.

Lingkungan

Peristiwa yang sama dapat terjadi di berbagai bagian sistem: misalnya, otorisasi dimungkinkan di situs atau dalam aplikasi seluler. Dalam hal ini, kami mengirim acara yang sama, tetapi selalu menambahkan pengidentifikasi unik dari sumber acara di dalam.

Sumber sangat berbeda satu sama lain. Ini bisa berupa setan internal dan mahkota, layanan frontend atau backend, aplikasi mobile. Bagian dari bidang harus dikirim dengan setiap peristiwa dari sumber tertentu.

Ada konsep "lingkungan." Ini adalah pengelompokan logis peristiwa berdasarkan sumber dengan kemampuan untuk mengatur bidang umum untuk semua peristiwa sumber.

Contoh lingkungan: "backend of service A", "frontend of service A", "ios-application of service A".

Direktori Acara

Semua peristiwa yang ada dijelaskan dalam direktori yang dapat diedit oleh pengembang dan analis. Peristiwa secara logis dikelompokkan berdasarkan lingkungan, setiap peristiwa memiliki pemilik, log perubahan dalam direktori disimpan.

Saat ini, direktori menggambarkan beberapa ratus bidang, beberapa puluhan lingkungan dan lebih dari seribu peristiwa.

Langpack

Kami menolak penyiksaan, dan kami tidak lagi memaksa pengembang untuk menulis kode pengiriman acara secara manual. Sebagai gantinya, berdasarkan pada direktori, kami menghasilkan satu set file untuk masing-masing bahasa server yang didukung oleh perusahaan: php, go atau python. Kode yang dihasilkan seperti itu disebut "langpack".

File-file dalam langpack sesederhana mungkin, mereka tidak tahu tentang logika bisnis proyek. Ini adalah seperangkat getter dan setter bidang untuk masing-masing acara dan kode untuk mengirim acara.

Satu langpack dibuat untuk setiap lingkungan. Ini terurai menjadi repositori paket (satis untuk php, pypi untuk python). Itu diperbarui secara otomatis ketika perubahan dibuat ke direktori.

Anda tidak bisa berhenti menulis dalam PHP. Kode untuk layanan yang menghasilkan langpack ditulis dalam Go. Perusahaan ini memiliki cukup proyek PHP, jadi saya harus mengingat bahasa pemrograman tiga huruf favorit saya dan menghasilkan kode PHP on Go. Jika Anda sedikit terhanyut, Anda juga dapat membuat tes untuk menguji kode yang dihasilkan dengan tes ini.

Versi

Referensi dapat diedit. Kode dalam pertempuran tidak bisa dilanggar. Kami menghasilkan kode tempur berdasarkan direktori. Berbahaya.

Setelah setiap perubahan acara, versi baru dibuat di direktori. Semua versi peristiwa yang pernah dibuat hidup selamanya di direktori. Jadi kami memecahkan masalah ketidakberubahan peristiwa tertentu. Proyek selalu menunjukkan versi acara yang sedang kami tangani.

Jika kode langpack berubah (misalnya, hanya ada setter, tapi sekarang kami juga memutuskan untuk menambahkan getter), buat versi baru dari langpack. Dia juga akan hidup selamanya. Proyek selalu meminta versi langpack khusus untuk lingkungannya. Jadi kami memecahkan masalah invarian antarmuka langpack.

Kami menggunakan semver. Versi setiap bahasa terdiri dari tiga angka. Yang pertama selalu nol, yang kedua adalah versi kode langpack, yang ketiga adalah kenaikan. Digit ketiga paling sering berubah, setelah setiap perubahan peristiwa.

Versi dua tingkat memungkinkan Anda untuk mengedit direktori tanpa melanggar kode dalam pertempuran. Ini didasarkan pada dua prinsip: Anda tidak dapat menghapus apa pun; Anda tidak dapat mengedit entitas yang dibuat, cukup buat salinan yang dimodifikasi berdampingan.

Transportasi

Tidak seperti orang-orang dari Badoo di LSD , kami tidak pernah belajar menulis file dengan indah . Dan kami percaya bahwa NSQ tidak hanya server antrian , tetapi juga transportasi untuk acara.

Mereka menyembunyikan NSQ di belakang lapisan kecil kode go, meletakkan kolektor untuk setiap node di cluster Kubernetes menggunakan set daemon, dan menulis konsumeris yang dapat menambahkan acara ke sumber yang berbeda.

Saat ini, transportasi memberikan sekitar dua miliar peristiwa per hari. Di bawah beban seperti itu, tiga puluh kolektor bekerja dengan sedikit margin. Masing-masing mengkonsumsi lebih sedikit inti prosesor dan sedikit lebih dari satu gigabyte memori.

Perutean acara

Pengirim acara dapat berupa proyek yang hidup di dalam atau di luar cluster kami. Di dalam cluster, ini adalah backend layanan, mahkota, daemon, proyek infrastruktur, dan intranet. Di luar, acara berasal dari ujung proyek publik, dari aplikasi seluler dan proyek mitra.

Untuk menerima acara di luar cluster, kami menggunakan proxy. Titik masuk umum dengan penyaringan kecil dari aliran peristiwa, dengan kemungkinan pengayaannya. Pengiriman lebih lanjut untuk transportasi sesuai dengan skema umum.

Skema perutean umum: setiap peristiwa dapat memiliki satu set penerima. Kemungkinan penerima termasuk repositori analitik bersama (DWH), rebbits atau proyek monga yang tertarik pada peristiwa tertentu. Kasing terakhir, misalnya, digunakan untuk melatih ulang model moderasi otomatis iklan. Model mendengarkan acara tertentu, mendapatkan umpan balik yang diperlukan.

Dari sisi proyek tidak ada pengetahuan tentang routing. Mereka mengirim acara menggunakan langpacks di mana alamat kolektor umum dijahit.

Penyimpanan

Repositori acara utama adalah HP Vertica, beberapa lusin terabyte. Basis kolom dengan fitur yang sesuai untuk analis kami. Antarmuka - Tablo untuk pelaporan.

Lebih efisien untuk merekam acara di penyimpanan kami dalam jumlah besar. Di depan penyimpanan adalah penyangga dalam bentuk Mongo. Koleksi penghapusan otomatis yang dibuat secara otomatis untuk setiap jam. Koleksi disimpan selama beberapa hari agar dapat memulai ulang proofreading di Vertica jika terjadi kesalahan.

Pembacaan dari buffer Mongo pada skrip peliharaan. Skrip dipandu oleh referensi, kami mencoba untuk tidak menjaga logika bisnis di sini. Pada tahap ini, pengayaan acara dimungkinkan.

Evolusi

Menari dengan tangan dalam gelap

Kebutuhan untuk mencatat peristiwa muncul jauh lebih awal daripada kesadaran akan perlunya mempertahankan direktori. Pengembang di masing-masing proyek datang dengan cara mengirim acara, mencari transportasi. Ini menghasilkan banyak kode dalam bahasa yang berbeda, berbohong di proyek yang berbeda, tetapi menyelesaikan satu masalah.

Seringkali di dalam kode pengiriman acara, bit logika bisnis tetap hidup. Kode dengan pengetahuan ini tidak dapat diangkut ke proyek lain. Saat refactoring, logika bisnis perlu dikembalikan ke proyek, hanya menyisakan kode acara sesuai dengan format data yang ditentukan.

Pada tahap ini, tidak ada direktori acara. Untuk memahami peristiwa apa yang sudah dicatat, bidang apa yang dimiliki peristiwa, itu hanya mungkin dengan melihat ke dalam kode. Untuk mengetahui bahwa pengembang secara tidak sengaja berhenti menulis data di bidang yang diperlukan, dimungkinkan saat membuat laporan, jika Anda secara khusus memperhatikan hal ini.

Tidak banyak acara. Koleksi penyangga dalam mongo ditambahkan sesuai kebutuhan. Ketika jumlah acara bertambah, perlu untuk mengarahkan kembali acara secara manual ke koleksi lain, untuk membuat koleksi yang diperlukan. Keputusan untuk menempatkan acara dalam kumpulan penyangga tertentu dibuat pada saat pengiriman, di sisi proyek. Transportasinya lancar, klien untuk itu adalah agen td.

Sadar Asinkron

Diputuskan untuk membuat direktori semua acara yang ada. Kami mengurai kode backends, mengeluarkan beberapa informasi dari sana. Kami mewajibkan pengembang untuk mencatat ini di direktori dengan setiap perubahan dalam kode acara.

Acara yang tiba dari frontend dan dari aplikasi seluler dijelaskan secara manual, kadang-kadang menangkap informasi yang diperlukan dari aliran acara di tingkat transportasi.

Pengembang tahu bagaimana melupakan. Ini menyebabkan desinkronisasi direktori dan kode, tetapi direktori menunjukkan gambaran umum.

Jumlah koleksi buffer telah meningkat secara signifikan, pekerjaan manual untuk mempertahankannya telah meningkat secara signifikan. Seseorang yang tak tergantikan muncul dengan banyak pengetahuan rahasia tentang penyimpanan buffer.

Transportasi baru

Mereka menciptakan transportasi bersama, ESP, menyadari semua titik pengiriman acara. Mereka menjadikannya satu titik penerimaan. Ini memungkinkan untuk mengontrol semua aliran acara. Proyek secara langsung berhenti mengakses penyimpanan buffer.

Clickstreamism yang Tercerahkan

Berdasarkan direktori, langpacks dihasilkan. Mereka tidak mengizinkan pembuatan acara yang tidak valid.

Diperkenalkan pemeriksaan otomatis untuk kebenaran acara yang tiba dari aplikasi frontend dan mobile. Dalam hal ini, kami tidak berhenti menulis acara agar tidak kehilangan data, tetapi kami mencatat kesalahan dan memberi sinyal kepada pengembang.

Peristiwa langka pada backend yang sulit untuk diperbaiki dan yang masih belum dikirim melalui langpack divalidasi oleh perpustakaan terpisah sesuai dengan aturan dari direktori. Pada kesalahan, lempar pengecualian yang memblokir peluncuran.

Punya sistem yang cenderung cocok dengan direktori. Bonus: transparansi, pengelolaan, kecepatan pembuatan dan perubahan acara.

Kata penutup

Kesulitan dan pelajaran utama adalah organisasi. Sulit untuk menghubungkan prakarsa yang melibatkan beberapa tim. Tidak mudah untuk mengubah kode proyek lama yang besar. Keterampilan berkomunikasi dengan tim lain, membagi tugas menjadi integrasi yang relatif independen dan dipikirkan sebelumnya dengan kemungkinan bantuan peluncuran independen. Pengembang Clickstream tidak lagi menyukai tim produk ketika fase integrasi solusi baru dimulai. Jika antarmuka berubah, pekerjaan ditambahkan ke semua orang.

Membuat direktori adalah ide yang sangat bagus. Dia menjadi satu-satunya sumber kebenaran, Anda selalu bisa memohon padanya jika ada perbedaan dalam kode. Banyak otomatisasi terkait dengan direktori: cek, perutean acara, pembuatan kode.

Infrastruktur tidak perlu tahu tentang logika bisnis. Tanda-tanda munculnya logika bisnis: peristiwa berubah sepanjang jalan dari proyek ke repositori; mengubah transportasi tanpa mengubah proyek menjadi tidak mungkin. Di sisi infrastruktur, harus ada pengetahuan tentang komposisi acara, jenis bidang, dan kewajibannya. Di sisi produk, makna logis dari bidang ini.

Selalu ada ruang untuk tumbuh. Secara teknis, ini merupakan peningkatan jumlah acara, penurunan waktu dari pembuatan acara hingga awal perekaman data, penghapusan pekerjaan manual di semua tahap.

Ada beberapa ide yang berani. Dapatkan grafik terperinci tentang transisi pengguna, mengonfigurasi acara dengan cepat tanpa meluncurkan layanan. Tetapi lebih banyak tentang itu dalam artikel berikut.

PS Saya berbicara tentang topik ini pada pertemuan Backend United # 1. Vinaigrette. Bisa melihat
presentasi atau video dari rapat.