Sistem analitik server

Ini adalah bagian kedua dari rangkaian artikel tentang sistem analitik (tautan ke bagian 1).

Saat ini tidak ada keraguan lagi bahwa pemrosesan data yang cermat dan interpretasi hasil dapat membantu hampir semua jenis bisnis. Dalam hal ini, sistem analitis menjadi semakin sarat dengan parameter, dan jumlah pemicu dan kejadian pengguna dalam aplikasi semakin bertambah.
Oleh karena itu, perusahaan memberikan lebih banyak informasi mentah kepada analisnya untuk dianalisis dan dijadikan keputusan yang tepat. Pentingnya sistem analitik bagi perusahaan tidak boleh diremehkan, dan sistem itu sendiri harus dapat diandalkan dan stabil.

Analis klien

Analisis pelanggan adalah layanan yang dihubungkan oleh perusahaan ke situs web atau aplikasinya melalui SDK resmi, diintegrasikan ke dalam basis kodenya sendiri, dan memilih pemicu peristiwa. Pendekatan ini jelas memiliki kelemahan: semua data yang dikumpulkan mungkin tidak diproses persis seperti yang Anda inginkan karena keterbatasan layanan yang Anda pilih. Misalnya, di satu sistem tidak akan mudah menjalankan tugas MapReduce, di sistem lain Anda tidak akan bisa menjalankan model Anda. Kerugian lainnya adalah tagihan layanan yang reguler (mengesankan).
Ada banyak solusi analisis pelanggan di pasar, namun cepat atau lambat analis dihadapkan pada kenyataan bahwa tidak ada satu layanan universal yang cocok untuk setiap tugas (sementara harga untuk semua layanan ini terus meningkat). Dalam situasi seperti ini, perusahaan sering kali memutuskan untuk membuat sistem analitik mereka sendiri dengan semua pengaturan dan kemampuan khusus yang diperlukan.

Analis server

Analisis sisi server adalah layanan yang dapat diterapkan dalam perusahaan di servernya sendiri dan (biasanya) dengan usahanya sendiri. Dalam model ini, semua peristiwa pengguna disimpan di server internal, memungkinkan pengembang untuk mencoba database penyimpanan yang berbeda dan memilih arsitektur yang paling nyaman. Dan meskipun Anda masih ingin menggunakan analitik klien pihak ketiga untuk beberapa tugas, hal itu masih dapat dilakukan.
Analisis sisi server dapat diterapkan dengan dua cara. Pertama: pilih beberapa utilitas sumber terbuka, terapkan pada mesin Anda dan kembangkan logika bisnis.

Kelebihan:
Kontra

Anda dapat menyesuaikan apa pun yang Anda inginkan
Hal ini seringkali sangat sulit dan memerlukan pengembang terpisah

Kedua: gunakan layanan SaaS (Amazon, Google, Azure) daripada menerapkannya sendiri. Kami akan membicarakan SaaS lebih detail di bagian ketiga.

Kelebihan:
Kontra

Harganya mungkin lebih murah pada volume menengah, namun dengan pertumbuhan yang besar masih akan menjadi terlalu mahal
Tidak mungkin mengontrol semua parameter

Administrasi sepenuhnya diserahkan ke pundak penyedia layanan
Tidak selalu diketahui apa yang ada di dalam layanan (mungkin tidak diperlukan)

Cara mengumpulkan analisis server

Jika kita ingin beralih dari penggunaan analisis klien dan membangun analisis kita sendiri, pertama-tama kita perlu memikirkan arsitektur sistem baru. Di bawah ini saya akan memberi tahu Anda langkah demi langkah apa yang perlu Anda pertimbangkan, mengapa setiap langkah diperlukan dan alat apa yang dapat Anda gunakan.

1. Menerima data

Seperti halnya analisis pelanggan, pertama-tama, analis perusahaan memilih jenis peristiwa yang ingin mereka pelajari di masa depan dan mengumpulkannya ke dalam daftar. Biasanya, peristiwa-peristiwa ini terjadi dalam urutan tertentu, yang disebut “pola peristiwa”.
Selanjutnya, bayangkan sebuah aplikasi seluler (situs web) memiliki pengguna (perangkat) biasa dan banyak server. Untuk mentransfer peristiwa dengan aman dari perangkat ke server, diperlukan lapisan perantara. Tergantung pada arsitekturnya, mungkin ada beberapa antrian acara yang berbeda.
Apache Kafka - Apakah antrian pub/sub, yang digunakan sebagai antrian pengumpulan acara.

Menurut posting di Quora pada tahun 2014, pencipta Apache Kafka memutuskan untuk menamai perangkat lunak tersebut dengan nama Franz Kafka karena “ini adalah sistem yang dioptimalkan untuk menulis” dan karena dia menyukai karya Kafka. — Wikipedia

Dalam contoh kita, terdapat banyak produsen data dan konsumen data (perangkat dan server), dan Kafka membantu menghubungkan mereka satu sama lain. Konsumen akan dijelaskan lebih detail pada langkah-langkah berikut ini, dimana mereka akan menjadi subjek utamanya. Sekarang kita hanya akan mempertimbangkan produsen data (peristiwa).
Kafka merangkum konsep antrian dan partisi; lebih baik membaca lebih spesifik tentang hal ini di tempat lain (misalnya, di dokumentasi). Tanpa menjelaskan secara detail, bayangkan sebuah aplikasi seluler diluncurkan untuk dua OS berbeda. Kemudian setiap versi membuat aliran acaranya sendiri-sendiri. Produser mengirimkan acara ke Kafka, acara tersebut dicatat dalam antrian yang sesuai.

(gambar karenanya)

Pada saat yang sama, Kafka memungkinkan Anda membaca dalam beberapa bagian dan memproses aliran peristiwa dalam batch kecil. Kafka adalah alat yang sangat nyaman dan dapat disesuaikan dengan kebutuhan yang terus meningkat (misalnya, berdasarkan geolokasi acara).
Biasanya satu shard sudah cukup, tetapi segalanya menjadi lebih rumit saat melakukan penskalaan (seperti yang selalu terjadi). Mungkin tidak ada yang mau hanya menggunakan satu pecahan fisik dalam produksi, karena arsitekturnya harus toleran terhadap kesalahan. Selain Kafka, ada solusi terkenal lainnya - RabbitMQ. Kami tidak menggunakannya dalam produksi sebagai antrean untuk analisis peristiwa (jika Anda memiliki pengalaman seperti itu, beri tahu kami di komentar!). Namun, kami menggunakan AWS Kinesis.

Sebelum melanjutkan ke langkah berikutnya, kita perlu menyebutkan satu lapisan tambahan lagi pada sistem - penyimpanan log mentah. Ini bukan lapisan wajib, tetapi akan berguna jika terjadi kesalahan dan antrian acara di Kafka disetel ulang. Menyimpan log mentah tidak memerlukan solusi yang rumit dan mahal; Anda cukup menuliskannya di suatu tempat dengan urutan yang benar (bahkan di hard drive).

2. Memproses aliran acara

Setelah kami menyiapkan semua acara dan menempatkannya di antrian yang sesuai, kami melanjutkan ke langkah pemrosesan. Di sini saya akan memberi tahu Anda tentang dua opsi pemrosesan yang paling umum.
Opsi pertama adalah mengaktifkan Spark Streaming di sistem Apache. Semua produk Apache hidup di HDFS, sistem file aman dengan replika file. Spark Streaming adalah alat yang mudah digunakan yang menangani streaming data dan menskalakannya dengan baik. Namun, mungkin sulit untuk mempertahankannya.
Pilihan lainnya adalah membuat event handler Anda sendiri. Untuk melakukan ini, Anda perlu, misalnya, menulis aplikasi Python, membangunnya di Docker, dan berlangganan antrian Kafka. Ketika pemicu tiba di pengendali buruh pelabuhan, pemrosesan akan dimulai. Dengan metode ini, Anda harus menjaga aplikasi tetap berjalan setiap saat.
Misalkan kita telah memilih salah satu opsi yang dijelaskan di atas dan melanjutkan ke pemrosesan itu sendiri. Pemroses harus memulai dengan memeriksa validitas data, memfilter sampah, dan kejadian “rusak”. Untuk validasi biasanya kami menggunakan Cerberus. Setelah ini, Anda dapat melakukan pemetaan data: data dari berbagai sumber dinormalisasi dan distandarisasi untuk ditambahkan ke tabel umum.

3. Basis Data

Langkah ketiga adalah mempertahankan kejadian yang dinormalisasi. Saat bekerja dengan sistem analitik yang sudah jadi, kita harus sering mengaksesnya, jadi penting untuk memilih database yang nyaman.
Jika datanya cocok dengan skema tetap, Anda dapat memilih clickhouse atau database kolom lainnya. Dengan cara ini agregasi akan bekerja dengan sangat cepat. Kelemahannya adalah skema ini bersifat tetap dan oleh karena itu tidak mungkin menambahkan objek sembarangan tanpa modifikasi (misalnya, ketika peristiwa non-standar terjadi). Tapi Anda bisa menghitung dengan sangat cepat.
Untuk data tidak terstruktur, Anda dapat menggunakan NoSQL, misalnya, Apache Cassandra. Ini berjalan pada HDFS, mereplikasi dengan baik, Anda dapat meningkatkan banyak instance, dan toleran terhadap kesalahan.
Anda juga bisa mengemukakan sesuatu yang lebih sederhana, misalnya, MongoDB. Ini cukup lambat dan untuk volume kecil. Namun kelebihannya adalah sangat sederhana sehingga cocok untuk memulai.

4. Agregasi

Setelah menyimpan semua acara dengan hati-hati, kami ingin mengumpulkan semua informasi penting dari kumpulan yang tiba dan memperbarui database. Secara global, kami ingin mendapatkan dasbor dan metrik yang relevan. Misalnya, kumpulkan profil pengguna dari peristiwa dan ukur perilakunya. Peristiwa dikumpulkan, dikumpulkan, dan disimpan lagi (dalam tabel pengguna). Pada saat yang sama, Anda dapat membangun sistem sehingga Anda juga dapat menghubungkan filter ke koordinator-agregator: kumpulkan pengguna hanya dari jenis peristiwa tertentu.
Setelah itu, jika seseorang dalam tim hanya memerlukan analisis tingkat tinggi, sistem analisis eksternal dapat dihubungkan. Anda dapat mengambil Mixpanel lagi. tapi karena harganya yang cukup mahal, tidak semua event pengguna dikirim kesana, melainkan hanya yang dibutuhkan saja. Untuk melakukan ini, kita perlu membuat koordinator yang akan mentransfer beberapa peristiwa mentah atau sesuatu yang kita kumpulkan sendiri sebelumnya ke sistem eksternal, API, atau platform periklanan.

5. Bagian depan

Anda perlu menghubungkan frontend ke sistem yang dibuat. Contoh yang baik adalah pelayanan kemerahan, adalah GUI database yang membantu membangun dasbor. Cara kerja interaksi:

1. Pengguna membuat kueri SQL.
2. Sebagai tanggapan, dia menerima sebuah tanda.
3. Ini menciptakan 'visualisasi baru' untuknya dan mendapatkan grafik indah yang dapat Anda simpan sendiri.

Visualisasi dalam layanan diperbarui secara otomatis, Anda dapat menyesuaikan dan melacak pemantauan Anda. Redash gratis jika dihosting sendiri, tetapi untuk SaaS biayanya $50 per bulan.

Kesimpulan

Setelah menyelesaikan semua langkah di atas, Anda akan membuat analisis server Anda. Harap dicatat bahwa ini tidak sesederhana hanya menghubungkan analitik pelanggan, karena semuanya perlu dikonfigurasi sendiri. Oleh karena itu, sebelum membuat sistem Anda sendiri, ada baiknya membandingkan kebutuhan akan sistem analisis yang serius dengan sumber daya yang ingin Anda alokasikan untuk sistem tersebut.
Jika Anda telah menghitungnya dan menemukan bahwa biayanya terlalu tinggi, di bagian selanjutnya saya akan membahas tentang cara membuat versi analisis sisi server yang lebih murah.

Terima kasih sudah membaca! Saya akan dengan senang hati mengajukan pertanyaan di komentar.

Sumber: www.habr.com