Pemodelan Data dengan Kafka? Topik dan Partisi

Salah satu hal pertama yang saya pikirkan ketika menggunakan layanan baru (seperti penyimpanan data non-RDBMS atau antrian pesan) adalah: "Bagaimana saya harus menyusun data saya?".

Saya sudah membaca dan menonton beberapa materi pengantar. Secara khusus, ambil, misalnya, Kafka: Sistem Pesan Terdistribusi untuk Pemrosesan Log , yang menulis:

• "Topik adalah wadah yang terkait dengan pesan"
• "unit paralelisme terkecil adalah partisi dari suatu topik. Ini menyiratkan bahwa semua pesan yang ... termasuk bagian tertentu dari suatu topik akan dikonsumsi oleh konsumen dalam kelompok konsumen."

Mengetahui hal ini, apa yang akan menjadi contoh bagus yang menggambarkan cara menggunakan topik dan partisi? Kapan sesuatu menjadi topik? Kapan seharusnya sesuatu menjadi partisi?

Sebagai contoh, katakanlah data (Clojure) saya terlihat seperti:

{:user-id 101 :viewed "/page1.html" :at #inst "2013-04-12T23:20:50.22Z"}
{:user-id 102 :viewed "/page2.html" :at #inst "2013-04-12T23:20:55.50Z"}

Haruskah berdasarkan topik user-id? viewed? at? Bagaimana dengan partisi?

Bagaimana saya memutuskan?

Ketika menyusun data Anda untuk Kafka, itu benar-benar tergantung pada bagaimana data itu dikonsumsi.

Dalam pikiran saya, topik adalah pengelompokan pesan dari jenis yang sama yang akan dikonsumsi oleh konsumen yang sama sehingga dalam contoh di atas, saya hanya akan memiliki satu topik dan jika Anda akan memutuskan untuk mendorong beberapa jenis lain dari data melalui Kafka, Anda bisa menambahkan topik baru untuk itu nanti.

Topik terdaftar di ZooKeeper yang berarti Anda mungkin mengalami masalah jika mencoba menambahkan terlalu banyak, misalnya kasus di mana Anda memiliki sejuta pengguna dan telah memutuskan untuk membuat topik per pengguna.

Partisi di sisi lain adalah cara untuk memparalelkan konsumsi pesan dan jumlah total partisi dalam cluster broker harus setidaknya sama dengan jumlah konsumen dalam kelompok konsumen untuk memahami fitur partisi. Konsumen dalam kelompok konsumen akan membagi beban pemrosesan topik di antara mereka sendiri sesuai dengan partisi sehingga satu konsumen hanya akan peduli dengan pesan di partisi itu sendiri "ditugaskan untuk".

Partisi dapat diatur secara eksplisit menggunakan kunci partisi di sisi produsen atau jika tidak disediakan, partisi acak akan dipilih untuk setiap pesan.

Setelah Anda tahu cara mempartisi aliran acara Anda, nama topik akan mudah, jadi mari kita jawab pertanyaan itu terlebih dahulu.

@Udd benar - struktur partisi yang Anda pilih akan sangat tergantung pada bagaimana Anda ingin memproses aliran acara. Idealnya Anda menginginkan kunci partisi yang berarti bahwa pemrosesan acara Anda adalah partisi-lokal .

Sebagai contoh:

1. Jika Anda peduli dengan waktu rata-rata pengguna di tempat, maka Anda harus mempartisi :user-id. Dengan begitu, semua peristiwa yang terkait dengan aktivitas situs pengguna tunggal akan tersedia dalam partisi yang sama. Ini berarti bahwa mesin pengolah aliran seperti Apache Samza dapat menghitung waktu rata-rata di tempat untuk pengguna tertentu hanya dengan melihat peristiwa dalam satu partisi. Ini menghindari keharusan melakukan segala jenis pemrosesan global-partisi yang mahal
2. Jika Anda peduli dengan halaman paling populer di situs web Anda, Anda harus mempartisi berdasarkan :viewedhalaman tersebut. Sekali lagi, Samza akan dapat menghitung jumlah tampilan halaman tertentu hanya dengan melihat peristiwa dalam satu partisi

Secara umum, kami berusaha menghindari keharusan bergantung pada negara global (seperti menjaga penghitungan di basis data jarak jauh seperti DynamoDB atau Cassandra), dan alih-alih dapat bekerja menggunakan partisi-lokal. Ini karena keadaan lokal adalah primitif mendasar dalam pemrosesan aliran .

Jika Anda membutuhkan kedua kasus penggunaan di atas, maka pola umum dengan Kafka adalah mempartisi terlebih dahulu dengan mengatakan :user-id, dan kemudian mempartisi ulang dengan :viewedsiap untuk tahap pemrosesan selanjutnya.

Pada nama topik - yang jelas di sini adalah eventsatau user-events. Untuk lebih spesifik Anda bisa pergi dengan events-by-user-iddan / atau events-by-viewed.

Ini tidak persis terkait dengan pertanyaan, tetapi jika Anda sudah memutuskan pemisahan logis berdasarkan topik, dan ingin mengoptimalkan jumlah topik / partisi di Kafka, blog ini mungkin berguna.

Singkatnya, singkatnya:

• Secara umum, semakin banyak partisi yang ada di cluster Kafka, semakin tinggi throughput yang bisa dicapai. Biarkan maks dicapai di satu partisi tunggal untuk produksi menjadi p dan konsumsi menjadi c . Katakanlah throughput target Anda adalah t . Maka Anda harus memiliki setidaknya partisi max ( t / p , t / c ).

• Saat ini, di Kafka, setiap broker membuka pegangan file indeks dan file data dari setiap segmen log. Jadi, semakin banyak partisi, semakin tinggi yang diperlukan untuk mengkonfigurasi batas pegangan file terbuka di sistem operasi yang mendasarinya. Misalnya dalam sistem produksi kami, kami pernah melihat kesalahan mengatakan too many files are open, sementara kami memiliki sekitar 3600 partisi topik.

• Ketika seorang broker dimatikan secara tidak jelas (misalnya, membunuh -9), ketidaktersediaan yang diamati dapat sebanding dengan jumlah partisi.

• Latensi ujung-ke-ujung dalam Kafka ditentukan oleh waktu dari saat pesan dipublikasikan oleh produsen hingga saat pesan dibaca oleh konsumen. Sebagai aturan praktis, jika Anda peduli tentang latensi, mungkin ide yang baik untuk membatasi jumlah partisi per broker hingga 100 x b x r , di mana b adalah jumlah broker dalam cluster Kafka dan r adalah faktor replikasi.

Saya pikir nama topik adalah kesimpulan dari jenis pesan, dan produser mempublikasikan pesan ke topik dan konsumen berlangganan pesan melalui topik berlangganan.

Sebuah topik dapat memiliki banyak partisi. partisi bagus untuk paralelisme. partisi juga merupakan unit replikasi, sehingga dalam Kafka, pemimpin dan pengikut juga dikatakan di tingkat partisi. Sebenarnya sebuah partisi adalah antrian yang dipesan dimana urutan pesannya tiba. Dan topik tersebut disusun oleh satu atau lebih antrian dalam satu kata sederhana. Ini berguna bagi kita untuk memodelkan struktur kita.

Kafka dikembangkan oleh LinkedIn untuk pengumpulan dan pengiriman log. adegan ini sangat bagus sebagai contoh.

Acara pengguna di web atau aplikasi Anda dapat dicatat oleh server Web Anda dan kemudian dikirim ke broker Kafka melalui produser. Di produser, Anda dapat menentukan metode partisi, misalnya: jenis acara (acara yang berbeda disimpan di partisi yang berbeda) atau waktu acara (partisi sehari ke periode yang berbeda sesuai dengan logika aplikasi Anda) atau jenis pengguna atau hanya tanpa logika dan menyeimbangkan semua log menjadi banyak partisi.

Tentang kasus Anda yang dimaksud, Anda dapat membuat satu topik yang disebut "page-view-event", dan membuat partisi N melalui kunci hash untuk mendistribusikan log ke semua partisi secara merata. Atau Anda dapat memilih logika partisi untuk membuat distribusi log dengan semangat Anda.