Apa itu registri skema?

Registri skema adalah layanan terpusat yang menyimpan, mengelola, dan memvalidasi skema yang digunakan untuk membuat serialisasi dan melakukan deserialisasi data yang dipertukarkan melalui Apache Kafka. Alih-alih mengizinkan setiap produsen dan aplikasi konsumen untuk menentukan format pesan secara independen, registri skema menyediakan “sumber kebenaran” bersama untuk bagaimana data peristiwa disusun.

Di Kafka, peristiwa sering diserialisasikan menggunakan format seperti Apache Avro, JSON Schema, atau Protocol Buffers, sering disingkat menjadi protobuf. Registri skema menyimpan definisi untuk format-format ini dan memberikan setiap skema pengenal unik. Hal ini disebut ID skema.

Ketika produsen menulis pesan ke topik Kafka, biasanya menyertakan ID skema di samping data serial, daripada menanamkan seluruh skema di setiap pesan. Konsumen pesan kemudian mengambil skema yang sesuai dari registri dan menggunakannya untuk melakukan deserialisasi dan menafsirkan data dengan benar.

Registri skema penting dalam sistem berbasis peristiwa karena membantu memastikan bahwa produsen dan konsumen menyepakati struktur data yang dipertukarkan. Ini mendukung kualitas data dan integritas data.

Tanpa registri terpusat, aplikasi perlu mengelola skema pesan secara independen. Hal ini meningkatkan risiko perubahan yang tidak kompatibel yang dapat menyebabkan konsumen peristiwa gagal atau salah menafsirkan data.

Registri skema juga mendukung apa yang disebut evolusi skema. Hal ini memungkinkan pengembang memodifikasi struktur peristiwa dari waktu ke waktu sambil mempertahankan kompatibilitas dengan aplikasi yang ada.

Misalnya, bidang opsional baru sering kali dapat ditambahkan tanpa melanggar format yang diharapkan konsumen Kafka yang ada. Aturan kompatibilitas membantu menegakkan perubahan skema yang aman sebelum diterapkan.

Manfaat penting lainnya adalah peningkatan tata kelola data. Skema disimpan dalam repositori pusat, yang berarti bahwa organisasi dapat mendokumentasikan, meninjau, membuat versi, dan mengaudit struktur data peristiwa mereka.

Pendekatan ini memudahkan tim pengembangan untuk:

• Temukan jenis acara yang tersedia
• Memahami format data
• Ulasan skema versi
• Pertahankan konsistensi di seluruh sistem terdistribusi.

Dalam platform data modern, registri skema juga dapat memungkinkan kontrak data antara produsen Kafka dan konsumen Kafka. Kontrak ini tidak hanya menentukan struktur data, tetapi juga harapan tentang bagaimana data tersebut harus berkembang dari waktu ke waktu.

Dengan memvalidasi perubahan skema sebelum dipublikasikan, registri skema dapat membantu mencegah perubahan yang merusak mencapai produksi dan meningkatkan keandalan arsitektur berbasis peristiwa.

Registri skema menyediakan mekanisme terpusat untuk mengelola skema peristiwa, menegakkan kompatibilitas antar-skema tersebut, dan mendukung perubahan pada skema tersebut.

Registri juga dapat memungkinkan pengembang untuk membangun skema baru berdasarkan skema yang lebih lama, membuat komposisi terstruktur dalam skema, dan menstandarkan nama peristiwa dengan strategi penamaan subjek.

Metode ini membantu aplikasi bertukar data saat sistem dan persyaratan berubah.

Registri skema bekerja dengan menyimpan dan mengelola skema yang menentukan struktur data peristiwa yang dipertukarkan antara produsen dan konsumen. Ketika produsen mengirim data ke topik Kafka, produsen membuat serialisasi pesan sesuai dengan skema yang terdaftar dan menyertakan informasi yang memungkinkan skema yang sesuai untuk diidentifikasi. Konsumen kemudian dapat menggunakan skema tersebut untuk melakukan deserialisasi dan menafsirkan pesan dengan benar. Seiring perubahan skema dari waktu ke waktu, registri juga dapat menerapkan pemeriksaan kompatibilitas pada versi skema baru sebelum didaftarkan, sehingga membantu produsen dan konsumen terus bekerja dengan struktur data yang berkembang.

Bayangkan retailer online besar yang memiliki beberapa sistem yang menghasilkan dan mengonsumsi data: situs web e-commerce, aplikasi mobile, mesin rekomendasi, sistem manajemen inventaris, platform pengiriman, dan platform analisis pelanggan. Masing-masing sistem ini berkomunikasi dengan menerbitkan dan mengonsumsi peristiwa melalui klaster Apache Kafka menggunakan Confluent Cloud dan mengalirkan peristiwa tersebut ke gudang data menggunakan Kafka Connect dalam pipeline datanya.

Setiap tindakan di situs web menghasilkan banyak peristiwa di seluruh sistem retailer. Setiap kali pelanggan melakukan pemesanan, situs web menerbitkan acara OrderCreated dengan topik Kafka.

Beberapa aplikasi hilir mengonsumsi peristiwa yang sama. Sistem inventaris menyimpan barang yang dibeli, sistem pembayaran mengonfirmasi transaksi, dan gudang memulai pemenuhan. Mesin rekomendasi memperbarui preferensi pelanggan, platform analitik mencatat penjualan, dan layanan pemberitahuan pelanggan mengirimkan konfirmasi email.

Awalnya, OrderCreated acara berisi bidang seperti order_id , customer_id , product_id , quantity dan total_price . Semua aplikasi yang memakan waktu dibangun untuk mengharapkan struktur ini.

Sekarang bayangkan beberapa bulan kemudian, bisnis memutuskan untuk mendukung penjualan internasional. Pengembang memperbarui situs web sehingga setiap pesanan sekarang menyertakan dua bidang baru: currency dan exchange_rate .

Tanpa registri skema, tidak ada mekanisme terpusat untuk mengoordinasikan perubahan ini. Beberapa konsumen data peristiwa mengharapkan bidang baru, sementara yang lain tidak. Jika pengembang secara tidak sengaja mengganti nama total_price menjadi order_total atau mengubah tipe datanya dari desimal menjadi string, layanan hilir mungkin mulai gagal secara tak terduga. Gudang mungkin berhenti menerima pesanan, dasbor analitik mungkin menghasilkan laporan yang salah, atau pemberitahuan pelanggan dapat gagal karena tidak dapat menguraikan peristiwa tersebut.

Jadi, bagaimana skenario yang sama terlihat dengan Confluent Schema Registry untuk membantu manajemen skema?

Sebelum menerapkan produsen yang diperbarui, tim pengembangan mendaftarkan skema OrderCreated dengan versi baru. Ini menghasilkan ID skema baru yang terkait dengan skema tersebut. Registri skema memeriksa perubahan yang diusulkan berdasarkan pengaturan kompatibilitas organisasi.

Jika perubahan yang diusulkan sesuai dengan aturan kompatibilitas tersebut, versi skema baru dapat didaftarkan. Jika perubahan melanggar kebijakan kompatibilitas yang dikonfigurasi, registri dapat menolaknya sebelum aplikasi mulai menggunakan skema yang tidak kompatibel.

Ini berarti pengembang dapat menemukan perubahan skema yang merusak selama pengembangan, bukan setelah penerapan. Konsumen yang ada dapat terus berfungsi dengan perubahan yang kompatibel, sementara tim pengembangan dapat secara bertahap memperbarui aplikasi mereka untuk menggunakan bidang baru ketika mereka siap.

Manfaat registri skema menjadi semakin signifikan seiring pertumbuhan perusahaan. Ratusan aplikasi yang dikembangkan oleh puluhan tim teknik dapat bertukar data melalui ribuan jenis peristiwa yang berbeda.

Tanpa registri skema, setiap tim perlu mengoordinasikan perubahan skema secara manual menggunakan dokumentasi tertulis, rapat, atau trial and error. Proses manual ini dapat memperlambat pengembangan dan meningkatkan kemungkinan perubahan yang tidak kompatibel mencapai produksi.

Dengan registri skema yang ada, skema peristiwa menjadi aset yang dikelola secara terpusat. Produsen dapat memublikasikan data sesuai dengan skema terdaftar, konsumen dapat menggunakan definisi skema tersebut untuk menafsirkan peristiwa yang masuk, dan pemeriksaan kompatibilitas dapat mengidentifikasi perubahan skema yang tidak kompatibel.

Tim baru juga dapat menemukan definisi peristiwa yang ada alih-alih merekayasa balik format pesan, sehingga lebih mudah untuk membangun aplikasi baru dan mengintegrasikan sistem baru.

Seiring skala retailer bertambah, registri skema menyediakan cara terpusat untuk mengelola skema peristiwa yang berkembang di seluruh produsen dan konsumen.

Kompatibilitas skema menentukan apakah aplikasi yang menggunakan versi skema yang berbeda dapat terus bertukar dan menafsirkan data dengan benar saat skema berkembang. Mode kompatibilitas utama adalah kompatibilitas mundur, kompatibilitas maju, dan kompatibilitas penuh.

• Kompatibilitas mundur berarti bahwa konsumen yang lebih baru dapat membaca data yang ditulis dengan skema yang lebih lama. Pendekatan ini berguna ketika konsumen diperbarui setelah produsen atau ketika aplikasi harus terus memproses data historis yang ditulis dengan versi skema sebelumnya.
• Kompatibilitas ke depan berarti bahwa konsumen yang lebih lama dapat membaca data yang ditulis dengan skema yang lebih baru. Ini bisa menjadi penting ketika produsen diperbarui sebelum semua konsumen dan aplikasi lama harus terus memproses peristiwa yang baru diproduksi.
• Kompatibilitas penuh menggabungkan kompatibilitas mundur dan maju, sehingga perubahan skema harus tetap kompatibel di kedua arah.

Beberapa registri skema juga mendukung versi transitif dari mode kompatibilitas ini. Alih-alih memeriksa versi skema baru hanya terhadap versi sebelumnya, pemeriksaan kompatibilitas transitif membandingkannya dengan semua versi sebelumnya yang relevan. Aturan kompatibilitas yang tepat dan perubahan skema yang diizinkan bergantung pada format skema dan pengaturan kompatibilitas registri.

Kompatibilitas ke depan berguna ketika produsen yang lebih lama harus terus beroperasi sementara konsumen yang lebih baru perlu memproses data dari produsen yang lebih lama tanpa gangguan. Dalam situasi ini, prioritasnya adalah memastikan bahwa aplikasi yang baru digunakan tetap kompatibel dengan pesan yang masih dihasilkan oleh versi perangkat lunak produsen yang lebih lama.

Bayangkan sebuah utilitas listrik nasional yang mengoperasikan smart grid. Grid tersebut terdiri dari jutaan meter pintar yang dipasang di rumah dan bisnis. Masing-masing menerbitkan peristiwa penggunaan listrik ke Apache Kafka. Meteran ini tetap beroperasi selama bertahun-tahun dan hanya dapat menerima pembaruan firmware selama jendela pemeliharaan terjadwal. Ini berarti bahwa banyak meter terus menghasilkan peristiwa menggunakan skema yang lebih lama, jauh setelah versi perangkat lunak yang lebih baru dirilis.

Sementara itu, utilitas secara teratur meningkatkan aplikasi monitoring and analytics pusatnya. Versi baru platform analitik memperkenalkan dukungan untuk informasi tambahan, seperti metrik kualitas daya dan pembangkit energi terbarukan. Bidang baru ini berguna jika tersedia, tetapi platform harus terus memproses data dari meter lama yang tidak mengirimkannya.

Dalam skenario ini, kompatibilitas maju lebih penting daripada kompatibilitas dengan versi sebelumnya karena konsumen diperbarui terlebih dahulu, sementara banyak produsen tetap menggunakan versi skema yang lebih lama. Perangkat lunak konsumen baru harus dapat membaca peristiwa yang ditulis dengan skema lama dengan benar, meskipun peristiwa tersebut tidak memiliki bidang yang baru diperkenalkan. Aplikasi dapat memperlakukan bidang yang hilang sebagai opsional atau menetapkan nilai default, sambil terus menjalankan fungsi utamanya.

Jika kompatibilitas mundur menjadi perhatian utama, pengembang akan fokus untuk memastikan bahwa konsumen yang lebih baru dapat membaca data yang ditulis dengan skema produsen yang lebih lama. Namun, tantangan langsung organisasi adalah mendukung armada perangkat lama yang berumur panjang sambil memodernisasi sistem pemrosesan pusat.

Menggunakan registri skema dengan aturan kompatibilitas yang sesuai memungkinkan utilitas untuk mengembangkan skema kejadiannya tanpa memerlukan pembaruan firmware secara simultan pada jutaan meter yang digunakan. Ini memungkinkan peluncuran bertahap, di mana produsen dan konsumen dapat diperbarui pada waktu yang berbeda sambil tetap memenuhi persyaratan kompatibilitas yang dikonfigurasi organisasi.

Registri skema dapat mendukung upaya kepatuhan yang melibatkan peraturan privasi data seperti Peraturan Perlindungan Data Umum (GDPR) dan California Consumer Privacy Act (CCPA).

Meskipun registri skema tidak memberikan kepatuhan dengan sendirinya, ini dapat membantu organisasi menerapkan tata kelola data, konsistensi, dan praktik audit yang digunakan untuk memenuhi persyaratan peraturan.

Salah satu manfaat utama adalah peningkatan visibilitas ke dalam data yang sedang diproses.

Setiap skema peristiwa disimpan dalam repositori terpusat yang mendokumentasikan bidang-bidang yang direpresentasikan dalam skema. Skema ini memberikan sumber informasi tentang data apa yang ada, bidang spesifik apa yang direpresentasikan, dan bagaimana aplikasi menyusun data yang mereka hasilkan atau konsumsi.

Skema ini dapat membantu organisasi mengidentifikasi skema yang berisi informasi identifikasi pribadi (PII), seperti nama, alamat email, atau nomor akun.

Registri skema juga dapat mendukung minimalisasi data, yang merupakan prinsip GDPR.

Sebelum skema disetujui, pengembang dan tim tata kelola data dapat meninjau apakah setiap bidang diperlukan untuk tujuan bisnis yang dimaksudkan. Proses peninjauan ini dapat membantu mencegah aplikasi mengumpulkan atau membagikan informasi pribadi yang tidak diperlukan.

Validasi skema juga dapat membantu mencegah perubahan yang tidak sah atau tidak disengaja yang memperkenalkan data sensitif baru ke dalam sistem produksi.

Misalnya, jika pengembang mencoba menambahkan nomor Jaminan Sosial atau nomor SIM pelanggan ke peristiwa Kafka yang ada, skema yang diusulkan dapat ditinjau sebelum diterapkan.

Pendekatan ini menciptakan pos pemeriksaan tata kelola tambahan selain pengujian aplikasi normal.

Versi dan riwayat skema menyediakan kemampuan audit.

Setiap evolusi skema dicatat, memungkinkan organisasi untuk menentukan kapan bidang ditambahkan, dimodifikasi, atau dihapus.

Selama audit kepatuhan, riwayat ini dapat membantu menunjukkan bahwa struktur data dikelola dengan cara yang terkontrol dan dapat dilacak.

Registri skema juga dapat meningkatkan konsistensi di beberapa sistem.

Karena produsen dan konsumen bergantung pada definisi skema bersama, aplikasi dapat menafsirkan bidang sesuai dengan struktur umum yang telah ditetapkan.

Hal ini dapat mengurangi penanganan data yang tidak konsisten antar aplikasi.

Banyak organisasi menggunakan registri skema sebagai bagian dari penerapan kontrak data.

Kontrak ini tidak hanya mendefinisikan struktur suatu peristiwa, tetapi juga metadata tentang data yang dikandungnya.

• Kontrak data dapat mengidentifikasi:
• Bidang mana yang berisi PII
• Apakah bidang tertentu memiliki persyaratan keamanan
• Siapa yang berwenang untuk mengkonsumsi data tertentu
• Berapa lama data harus disimpan

Validasi otomatis kemudian dapat digunakan untuk memeriksa apakah versi skema baru terus memenuhi persyaratan yang ditentukan.

Skema registri juga dapat diintegrasikan dengan tata kelola data dan alat keamanan yang lebih luas.

Metadata yang disimpan bersama skema dapat digunakan oleh sistem seperti:

• Katalog data
• Sistem kontrol akses
• Alat pelacakan garis keturunan
• Platform kepatuhan

Registri skema karena itu dapat membentuk salah satu komponen dari arsitektur tata kelola yang lebih luas.

Dikombinasikan dengan enkripsi, kontrol akses, kebijakan penyimpanan data, dan pencatatan audit, manajemen skema dapat membantu organisasi mengelola bagaimana data pribadi dikumpulkan, diproses, dan dibagikan.

Beberapa platform menyediakan kemampuan registri skema untuk Kafka dan sistem data terkait.

Confluent Schema Registry adalah registri skema khusus Kafka yang banyak digunakan.

Ini merupakan bagian dari sistem Confluent dan tersedia baik sebagai komponen yang dikelola sendiri dari Confluent Platform maupun sebagai layanan yang dikelola di Confluent Cloud.

Ini mendukung Avro, Protobuf, dan JSON Schema serta menyediakan versi skema, aturan kompatibilitas, validasi, dan integrasi dengan produsen dan konsumen Kafka.

Amazon Web Services menyediakan AWS Glue Schema Registry.

Ini adalah registri skema terkelola yang terintegrasi dengan Apache Kafka, Amazon Managed Streaming for Apache Kafka (MSK), Amazon Kinesis, Amazon Managed Service for Apache Flink, dan AWS Lambda.

Ini mendukung Avro, JSON Schema, dan Protobuf.

Apicurio Registry adalah registri skema sumber terbuka dan artefak API yang dapat digunakan dengan Kafka.

Skema ini mendukung format termasuk Avro, JSON Schema, dan Protobuf serta dapat diterapkan di lingkungan seperti Kubernetes.

Apicurio juga menyediakan kompatibilitas dengan Confluent Schema Registry API, yang dapat membuatnya lebih mudah digunakan dengan aplikasi Kafka yang dirancang di sekitar antarmuka registri skema Confluent.

Redpanda juga menyertakan layanan yang kompatibel dengan Schema Registry sebagai bagian dari platform streaming yang kompatibel dengan Kafka.

Pendekatan ini dapat berguna ketika organisasi menggunakan Redpanda daripada Apache Kafka secara langsung karena manajemen skema dapat disediakan sebagai bagian dari platform streaming itu sendiri.

Registri Redpanda lebih terintegrasi ke dalam platform streaming alternatif yang kompatibel dengan Kafka.

Tidak, registri skema bukan bagian dari perangkat lunak inti Apache Kafka. Kafka menyimpan dan mengangkut catatan. Registri skema adalah layanan terpisah yang menyimpan dan mengelola skema untuk data yang terkandung dalam catatan tersebut. Registri skema umumnya digunakan bersama Kafka untuk membantu produsen dan konsumen menafsirkan data peristiwa terstruktur secara konsisten.

ID skema adalah pengidentifikasi untuk definisi skema tertentu. Versi skema menunjukkan posisi skema tersebut dalam urutan versi yang dipertahankan untuk skema atau subjek tertentu. Implementasi yang tepat bervariasi menurut registri. Di Confluent Schema Registry, misalnya, ID skema secara unik mengidentifikasi skema dalam registri, sedangkan versi terkait dengan subjek. Oleh karena itu, skema yang sama dapat memiliki ID skema yang sama saat dikaitkan dengan versi yang berbeda di bawah subjek yang berbeda.

Registri skema terutama menyimpan dan mengelola skema yang dapat dibaca mesin dan digunakan oleh aplikasi untuk memahami struktur data. Registri skema juga dapat menyediakan kemampuan seperti pembuatan versi skema dan pemeriksaan kompatibilitas.

Katalog data memiliki fokus yang lebih luas untuk membantu orang dan sistem menemukan, memahami, dan mengatur aset data di seluruh organisasi. Katalog dapat berisi deskripsi bisnis, informasi kepemilikan, klasifikasi, dan metadata lainnya tentang kumpulan data dan sistem data. Oleh karena itu, registri skema dan katalog data dapat saling melengkapi. Registri mengelola skema yang digunakan oleh aplikasi, sementara katalog memberikan informasi yang lebih luas tentang aset data organisasi.

Skema mendefinisikan struktur data, termasuk elemen seperti bidang dan tipe data. Kontrak data dapat mencakup skema, tetapi juga menentukan harapan yang lebih luas antara produsen data dan konsumen. Skema mungkin merupakan salah satu komponen dari kontrak data, di samping batasan integritas, metadata, dan kebijakan.

Registri skema yang tepat bergantung pada persyaratan teknis organisasi dan arsitektur data yang ada. Faktor-faktor yang perlu dipertimbangkan termasuk format skema yang didukung registri, aturan kompatibilitasnya, integrasi dengan Apache Kafka dan sistem data lainnya, API dan dukungan klien, kemampuan keamanan dan autentikasi, serta apakah layanan dikelola atau dikelola sendiri.

Organisasi juga dapat mempertimbangkan bagaimana registri mendukung evolusi skema, tata kelola data, metadata dan kontrak data, serta kompatibilitasnya dengan produsen, konsumen, dan jalur pipa data yang ada. Produk registri yang berbeda menyediakan kombinasi kemampuan yang berbeda, sehingga pemilihan umumnya bergantung pada sistem dan persyaratan yang perlu didukung oleh registri.