Get best of the week

Tarantool: Analyst Look

Halo semuanya! Nama saya Andrey Kapustin. Saya bekerja sebagai analis sistem di Mail.ru Group. Produk kami membentuk ekosistem tunggal untuk pengguna, di mana data menghasilkan banyak infrastruktur independen: layanan pemesanan taksi dan makanan, layanan pos, jejaring sosial. Hari ini, semakin cepat dan lebih akurat kita dapat memprediksi kebutuhan pelanggan, semakin cepat dan lebih akurat kita dapat menawarkan produk kita kepadanya.

Banyak analis dan insinyur sistem sekarang mengajukan pertanyaan:

  1. Bagaimana merancang arsitektur platform pemicu untuk pemasaran waktu nyata?
  2. Bagaimana cara mengatur struktur data yang memenuhi persyaratan strategi pemasaran untuk berinteraksi dengan pelanggan?
  3. Bagaimana memastikan operasi yang stabil dari sistem seperti itu di bawah beban yang sangat tinggi?

Sistem ini didasarkan pada pemrosesan dan analisis big data yang besar. Kami telah memperoleh banyak pengalaman dalam bidang-bidang ini. Dan sebagai contoh satu kisah nyata, saya akan memberi tahu Anda tentang pendekatan kami terhadap analitik dan pengembangan solusi di bidang Pemasaran Real-time menggunakan Tarantool.

Suatu kali operator telekomunikasi besar mendatangi kami untuk meminta bantuan.

Tugasnya adalah ini:

Kami memiliki lebih dari 100 juta pelanggan. Kami tahu banyak tentang mereka: saldo saat ini, volume lalu lintas, layanan terhubung, perjalanan, tempat favorit. Kami menggunakan informasi sebanyak yang kami bisa: kami mengumpulkan data di siang hari, menaruh sejumlah besar informasi di repositori (DataLake). Kami memulai penangan di malam hari, di pagi hari kami membuat kampanye iklan dan mengirimkan penawaran.

Dan kami ingin melakukan hal yang sama dalam waktu nyata!

Mengapa? Karena semakin cepat operator telekomunikasi memproses informasi, semakin banyak uang yang dapat mereka peroleh. Misalnya, pada pembelian impulsif: pengguna berjalan melewati kafe saat makan siang, dan kemudian diskon datang ke teleponnya sehingga ia memilih kafe khusus ini. Artinya, Anda perlu "hanya" menawarkan produk yang tepat pada waktu yang tepat dan membantu segera menanggapi penawaran dengan cara yang mudah.



Apa yang Anda butuhkan untuk menyelesaikan masalah bisnis:

  • Anda dapat menentukan kebutuhan melalui profil pelanggan.
  • Tentukan momen - sesuai dengan peristiwa kehidupan manusia.
  • Merangsang umpan balik - memilih saluran komunikasi yang optimal.

Ini disebut Pemasaran Real-Time. Berkenaan dengan sektor telekomunikasi, mengirimkan pesan pribadi yang relevan kepada pelanggan pada waktu yang tepat dengan kemampuan SEGERA menanggapi penawaran. Proposal dapat dibentuk baik untuk kelompok sasaran dan untuk pengguna tertentu, sementara permintaan harus diproses secara waktu nyata.

Dari sudut pandang teknis, kita harus menyelesaikan masalah berikut:

  • Menyimpan data terbaru dari lebih dari 100 juta pelanggan;
  • Pemrosesan aliran peristiwa waktu-nyata dengan beban 30.000 RPS;
  • Pembentukan dan perutean penawaran yang ditargetkan ke pelanggan dengan pemenuhan persyaratan non-fungsional (waktu respons, ketersediaan, dll.);
  • Koneksi tanpa batas dari sumber baru data heterogen oleh pelanggan.

"Waktu nyata" dalam hal ini berarti memproses informasi dalam 30 detik. Tidak ada gunanya lagi, saat ini terlewatkan, klien hilang. Dan hal yang paling menyedihkan adalah bahwa dalam situasi seperti itu tidak akan jelas mengapa (?) - Apakah kita mengusulkan hal yang salah atau tidak mengatur waktu?

Mendapatkan jawaban untuk pertanyaan ini sangat penting untuk pengembangan produk:

  1. Promosi pemasaran produk Anda: uji hipotesis, tingkatkan pendapatan.
  2. Kami menarik pelanggan potensial: kami berinvestasi dalam iklan, kami menangkap pasar.
  3. Kami menghubungkan layanan atau layanan tambahan: kami memperluas lini produk.

Mudah untuk membuat kesalahan di setiap tahap. Dan harga kesalahannya besar. Kita harus mengalahkan dengan cepat dan akurat! Dan untuk ini, informasi pelanggan harus lengkap dan terkini. Dalam hal ini, informasinya benar-benar bernilai uang!

Lagi pula, semakin kita tahu tentang pelanggan, semakin banyak yang akan kita hasilkan. Ini berarti bahwa menambahkan setiap parameter baru ke profil klien meningkatkan akurasi penargetan. Tetapi ini adalah proses yang berkelanjutan karena:

  1. Basis pelanggan terus tumbuh.
  2. Berbagai layanan berkembang.

Dalam kondisi seperti itu, sangat efektif untuk melakukan segmentasi basis pelanggan. Dalam hal ini, diputuskan untuk menggunakan mekanisme stratifikasi - klasifikasi multivariat pelanggan.

Sederhananya, kami membedakan kelompok pelanggan tertentu (strata) dengan rentang nilai atribut yang jumlahnya tidak terbatas. Dalam hal ini, pelanggan harus secara otomatis mengubah strata segera setelah transisi dari nilai atribut ke rentang yang sesuai.

Gambar di bawah ini adalah contoh model tiga dimensi stratifikasi sejak kecil. Bola adalah pelanggan.



Untuk setiap klien, kita dapat menghitung berapa banyak yang mereka habiskan untuk menariknya, berapa banyak yang mereka hasilkan dan bagaimana. Artinya, kita tahu berapa biaya informasi , dan seberapa besar kerugian yang kita peroleh jika kita tidak memperbaruinya.

Mereka menghitung dan memutuskan - perlu memperbarui! Dan segera timbul masalah: selalu ada sesuatu yang hilang. Di setiap proyek, persyaratan baru datang dari pelanggan yang bertentangan dengan TK, arsitektur, satu sama lain dan ... akal sehat. Menjaga integritas dan relevansi data menjadi semakin sulit setiap hari. Sumber-sumber informasi baru muncul dengan atribut-atribut baru yang tidak jelas di mana menyimpan dan bagaimana memproses.

Harus diingat bahwa semakin normaldata, semakin banyak pembatasan, direktori, periksa di dalamnya. Siapa pun yang mencoba menambahkan beberapa bidang ke tabel "saat bepergian" tahu seperti apa "pelukis" ini: tidak cocok dengan model data saat ini! Dan bagaimana pelanggan dapat menjelaskan bahwa jika Anda menambahkan bidang baru, Anda harus menulis ulang setengah dari kode proyek ?! Kami “runtuh” atau “membuang” analitik “ekstra” di pintu masuk, dan akibatnya kami tidak dapat membentuk penawaran yang relevan.

Rekan Barat menyebut efek ini "Sial - Sial."

Akibatnya, data membutuhkan lebih banyak ruang dan lebih sulit untuk diproses. Dengan meningkatnya jumlah informasi, ini menjadi penting, karena kecepatan pemrosesan transaksi menurun. Dan tujuan kami adalah untuk memproses setiap permintaan tidak lebih dari satu menit dengan beban 30.000 permintaan per detik.

Kesimpulan: untuk pemasaran real-time, normalisasitidak cocok untuk 100+ juta pelanggan.

Kami tiba di solusi dalam bentuk profil pelanggan universal. Itu terletak pada penyimpanan nilai kunci, jadi kami tidak dapat memperbaiki struktur data. Setiap kolom adalah kunci dan nilai, yang bisa berupa apa saja.

Kami mendapat kombinasi:

  • Atribut statis yang jarang diperbarui (nama, paspor, alamat). Blok wajib dengan ID.
  • Dan ekor dinamis yang panjangnya sewenang-wenang - sering diperbarui data yang tergantung pada sumbernya. Beberapa blok independen untuk setiap sumber.

Pendekatan ini disebut denormalisasi. Seberapa nyaman itu?

  1. "Ekor" mungkin tidak divalidasi.
  2. Kami menyimpan data "mentah" sebagaimana adanya tanpa diproses.
  3. Kami menyimpan semua informasi yang masuk, kami tidak kehilangan apa-apa.
  4. ID , .
  5. ( 2-3 ), .
  6. : .


Sekarang Anda perlu memilih alat untuk implementasi. Ini biasanya dilakukan oleh arsitek sesuai dengan persyaratan yang dikumpulkan analis. Sangat penting untuk mengetahui NFT - jumlah data yang diharapkan dan tingkat beban. Itu tergantung pada metode penyimpanan dan pemrosesan data apa yang akan kita gunakan.

Judul bab ini mengisyaratkan bahwa layanan kami akan memproses banyak data. Dan banyak - berapa banyak? Mari kita cari tahu.

Data dapat dianggap besar jika hubungan mereka tidak terlihat dengan mata telanjang.

Kami memproses lebih dari 100 juta profil pelanggan yang berbeda yang mengandung informasi yang tidak terstruktur, sering diperbarui dan digunakan - ini adalah data besar yang nyata.

Anda perlu membuat cache profil pelanggan saat ini. Tanpa menyimpan data panas dalam RAM, pemrosesan waktu nyata tidak dapat dicapai.

Beban tinggi


Sekarang kita akan berurusan dengan intensitas beban, yaitu jumlah permintaan. Istilah "beban tinggi" digunakan untuk menggambarkan situasi ketika peralatan berhenti menahan beban.

Kami memproses berbagai jenis peristiwa yang terjadi terus menerus dengan intensitas 10 hingga 30 ribu permintaan per detik. Dalam hal ini, logika bisnis yang kompleks digunakan, dan kecepatan reaksi sangat penting. Jelas, kami sedang merancang layanan yang sangat dimuat, yang harus secara dinamis skala tergantung pada beban instan.

Tarantool sebagai akselerator


Kami di Mail.ru Group menggunakan Tarantool untuk menyelesaikan masalah tersebut. Di Habré banyak yang telah dikatakan tentang bagaimana itu dibangun "di bawah tenda", saya tidak akan mengulanginya, saya hanya akan mengingat poin utama:

Tarantool adalah DBMS dalam memori dan server aplikasi dalam satu botol.

Ketika bekerja dengan sejumlah besar data, disarankan untuk menggunakannya dalam dua cara:

  1. Sebagai showcase data untuk menyimpan informasi dalam RAM demi mempercepat akses.
  2. Sebagai server aplikasi untuk memproses data sesuai dengan aturan yang ditentukan.

Artinya, logika bisnis disimpan di sebelah data, yang sangat penting untuk layanan yang sangat dimuat. Dalam proyek kami, kami menggunakan Tarantool sebagai etalase data "pintar" dengan logika bisnis bawaan, yang dengannya proses on-the-fly dari arus peristiwa yang masuk dan informasi terjadi.

Mengapa Tarantool efektif untuk RTM:

  1. Caching data panas. Profil klien di-cache dalam memori, sehingga selalu terkini.
  2. Komputasi real-time yang kompleks. Penawaran pribadi kepada klien dibentuk secara real time untuk setiap acara.
  3. Solusi yang toleran dan terukur kesalahan:

Ada dua risiko yang jelas dalam proyek kami:

  1. , . — Tarantool c , .
  2. , . , . , . , . , yaitu mendistribusikan 100 juta catatan tabel profil klien antara beberapa pecahan untuk memparalelkan pemrosesan kueri dan dengan demikian mengurangi beban pada catatan. Contoh paling sederhana adalah membagi tabel profil pelanggan dengan rentang nilai ID. Untuk mengatasi masalah ini, Tarantool menyediakan alat penskalaan horizontal, lebih banyak tentang yang dapat ditemukan di, misalnya, artikel " Tarantool Cartridge: sharding backend Lua dalam tiga baris ".

Kesimpulan


Tarantool tidak menggantikan Oracle atau repositori analitik lainnya. Pada saat yang sama, ini efektif untuk memproses sejumlah besar data secara real time. Kami telah berhasil menyelesaikan tugas pelanggan dalam ketentuan yang disepakati dan anggaran proyek, jadi saya sarankan untuk bereksperimen dengan alat ini ketika membuat layanan yang sangat dimuat.

More articles:


All Articles