Kafka Tiered Storage: Bagaimanakah Anda Mereka Bentuk Pengekalan Tempatan dan Jauh?

Gesaan dan skop

Penemu duga mungkin bertanya: “Jika sesebuah topik Kafka mesti mengekalkan sejarah selama bertahun-tahun, bagaimanakah anda akan mereka bentuk dasar pengekalan tempatan dan jauh bagi Tiered Storage?”

Terasnya bukanlah menghafal nama konfigurasi. Ia adalah menerangkan kitaran hayat segmen log merentas peringkat tempatan dan jauh. KIP-405 mengekalkan peringkat tempatan pada broker Kafka sambil memuat naik segmen log yang telah selesai ke storan luaran; pengekalan tempatan boleh menjadi lebih pendek daripada pengekalan jauh untuk mengurangkan tekanan cakera broker. Jawapan yang lengkap juga merangkumi kegagalan object-store, pendaman bacaan sejarah, pemilikan pemadaman, dan pemulihan.

Perkara yang diuji oleh penemu duga

Sama ada anda memahami storan bertingkat (tiered storage) sebagai penempatan panas/sejuk bagi segmen log, bukannya Kafka menjadi object store.
Sama ada anda boleh memisahkan keupayaan kluster, remote.storage.enable peringkat topik, dan dasar pengekalan.
Sama ada anda boleh menganggarkan kapasiti cakera panas, kapasiti jauh, kelengahan muat naik (upload lag), dan lebar jalur main semula (replay bandwidth).
Sama ada anda mempertimbangkan gangguan jauh, ketekalan metadata, pergerakan partisi, dan main semula pengguna (consumer replay).
Sama ada anda menetapkan pemilikan yang jelas untuk pemadaman jauh tanpa pertumbuhan yang tidak disengajakan atau tanpa batasan.

Soalan penjelasan

Topik manakah yang memerlukan storan sejarah, dan patutkah setiap topik didayakan?
Apakah sasaran pendaman bacaan panas dan daya pemprosesan main semula sejarah?
Apakah belanjawan cakera tempatan, kelas storan jauh, keperluan wilayah, dan pematuhan?
Semasa gangguan object-store, bagaimanakah pengeluaran, pengguna masa nyata, dan pembaca sejarah mengalami penurunan prestasi (degrade)?
Adakah pemadaman didorong oleh masa, saiz, peristiwa pematuhan, atau dasar penyewa (tenant policy)?

Jawapan 30 saat

Anda boleh berkata:

Saya akan menganggap peringkat tempatan Kafka sebagai cache panas berpendaman rendah, memuat naik segmen yang lengkap ke peringkat jauh, dan mentakrifkan pengekalan tempatan dan jauh secara berasingan. Dayakan remote.storage.enable hanya untuk topik yang memerlukannya; gunakan pengekalan tempatan untuk mengawal cakera broker dan pengekalan jauh untuk memenuhi keperluan audit dan main semula. Saya akan mengukur kelengahan muat naik, pendaman bacaan jauh, kegagalan object-store, dan pergerakan partisi, kemudian menetapkan pemilik untuk pembersihan jauh. Pengguna masa nyata kekal pada laluan tempatan; main semula sejarah menerima pendaman tambahan dengan pendikit (throttling) dan pemantauan.

Penaakulan langkah demi langkah

Wujudkan kitaran hayat dua peringkat

Kafka masih menggunakan segmen log partisi sebagai unit asas. Segmen aktif ditulis secara tempatan; selepas rolling, komponen log jauh memuat naik segmen dan maklumat indeks ke storan jauh yang dikonfigurasikan. Klien tidak boleh menganggap setiap bait sejarah kekal pada cakera broker:

text

producer -> leader broker local segment
                    | segment roll
                    v
             remote object store
consumer <---- local cache or remote fetch

Peringkat tempatan menyediakan penggunaan berpendaman rendah dan peringkat jauh menampung pengekalan yang lebih lama. Kekalkan tetingkap keselamatan yang boleh diperhatikan antara penyiapan muat naik dan pemadaman tempatan; penciptaan objek semata-mata bukanlah bukti bahawa indeks dan metadata boleh digunakan.

Skopkan ciri mengikut topik

Dokumentasi Apache Kafka menyatakan bahawa selepas konfigurasi sebelah broker, topik masih perlu memilih untuk menyertai (opt-in) dengan remote.storage.enable. Nyatakan sama ada model tadbir urus adalah opt-in atau aktif secara lalai, kerana mendayakan setiap topik boleh menggandakan kos dan permukaan kegagalan.

Asingkan pengekalan tempatan dan jauh

Tetapkan pengekalan tempatan mengikut masa atau saiz untuk memelihara data panas dan kapasiti bacaan yang diperlukan untuk penugasan semula (reassignment); tetapkan pengekalan jauh untuk audit, main semula, dan pematuhan. Invariannya ialah satu-satunya salinan tempatan tidak dipadamkan sehingga objek jauh, indeks, metadata, dan ujian pemulihan disahkan. Pemadaman jauh memerlukan audit bebas dan pengendalian percubaan semula (retry).

Reka bentuk bacaan dan penurunan prestasi

Pengguna masa nyata membaca peringkat tempatan terlebih dahulu; offset di luar tetingkap tempatan mencetuskan bacaan jauh. Apabila storan jauh menjadi perlahan, pendikitkan main semula sejarah untuk melindungi trafik langsung. Apabila ia tidak tersedia, nyatakan offset mana yang tidak boleh dibaca buat sementara waktu, bagaimana amaran dicetuskan, dan bagaimana pemulihan berfungsi. Uji masa pembinaan semula metadata dan cache semasa pergerakan partisi, pertukaran ketua (leader changes), dan permulaan semula broker.

Model jawapan berkualiti tinggi

Saya akan mengesahkan tetingkap bacaan panas topik, daya pemprosesan main semula, tempoh pengekalan, dan keperluan pematuhan terlebih dahulu. Mengikuti KIP-405, peringkat tempatan broker ialah cache panas dan segmen yang telah di-roll dimuat naik ke storan objek jauh; hanya topik yang memerlukan sejarah yang mendayakan remote.storage.enable. Pengekalan tempatan mengikut belanjawan cakera dan keperluan main semula masa nyata, manakala pengekalan jauh mengikut tempoh audit. Pintu pemadaman ialah objek jauh, indeks, dan metadata yang disahkan, bukan sekadar permintaan muat naik. Pengguna mengekalkan pendaman rendah di dalam tetingkap tempatan; main semula yang lebih lama menggunakan bacaan jauh dengan pendikit. Saya akan memantau kelengahan muat naik, pendaman bacaan jauh, ketepatan cache (cache hits), ketidakpadanan objek/metadata, kegagalan pemadaman, dan offset yang tidak boleh dibaca, serta mempraktikkan pemulihan gangguan object-store, permulaan semula broker, dan pergerakan partisi. Pembersihan jauh memerlukan pemilik, jejak audit, dan prosedur pemulihan; memadamkan fail broker tidak menghilangkan tanggungjawab tersebut.

Kesilapan lazim

Mendakwa bahawa tiered storage menstrim setiap rekod Kafka terus ke storan objek dan mengabaikan segment rolling.
Hanya memberikan suis kluster dan meninggalkan remote.storage.enable peringkat topik.
Mengira kos objek sambil mengabaikan pendaman bacaan jauh, kelengahan muat naik, dan lebar jalur main semula.
Menganggap bahawa memadamkan fail broker memadamkan objek jauh secara automatik.
Membiarkan main semula sejarah menggunakan sumber yang diperlukan oleh trafik langsung semasa kegagalan jauh.
Meninggalkan pemantauan dan latihan pemulihan untuk ketekalan objek, indeks, dan metadata.

Soalan susulan dan jawapan

1. Bagaimanakah anda memilih masa pengekalan tempatan?

Kira ke belakang daripada tetingkap undur masa nyata terbesar, belanjawan cakera, masa pemulihan penugasan semula, dan margin keselamatan tempoh kegagalan. Sertakan puncak main semula dan tetingkap penyelenggaraan berbanding hanya purata consumer lag.

2. Bagaimana jika storan objek jauh tidak tersedia buat sementara waktu?

Jeda atau pendikitkan bacaan di luar tetingkap tempatan, kekalkan julat tempatan yang disahkan, dan beri amaran tentang kegagalan muat naik dan bacaan. Pengeluaran dan penggunaan masa nyata diteruskan dalam kapasiti tempatan yang disahkan; bacaan sejarah akan mengejar semula selepas pemulihan. Dedahkan keadaan eksplisit bagi offset yang tidak boleh dibaca dan bukannya mengembalikan data kosong.

3. Bagaimanakah anda membuktikan bahawa pemadaman adalah selamat?

Sebelum memadamkan segmen tempatan, sahkan bahawa objek jauh, indeks, dan metadatanya boleh dibaca dan rekodkan julat segmen tersebut. Untuk pemadaman jauh, audit dasar pengekalan, lakukan pensampelan bacaan, dan jalankan latihan pemulihan; beri amaran tentang pemadaman yang gagal, objek yatim (orphan objects), dan jurang metadata.