Wawancara data engineering: Bagaimana Anda menggunakan etcd 3.7 RangeStream tanpa menghabiskan memori?

Pertanyaan

Anda harus membaca jutaan key ber-prefix dari etcd untuk ekspor konfigurasi. Bagaimana Anda menggunakan RangeStream untuk menurunkan lonjakan memori server dan client, menjaga hasil yang konsisten, memulihkan dari kegagalan, dan menangani opsi kueri yang tidak didukung?

Konteks dan batasan

etcd v3.7 dirilis pada 8 Juli 2026 dan menambahkan RangeStream. Proyek resmi menyatakan fitur ini membagi hasil range yang besar menjadi chunk-chunk sehingga baik server maupun client tidak perlu melakukan buffer pada seluruh respons. Pertanyaan ini mengenai pembacaan hasil besar yang terbatas (finite), bukan Watch, dan tidak berasumsi bahwa RangeStream mendukung pengurutan (sorting), filter revisi, atau etcd gRPC proxy.

Klarifikasi terlebih dahulu: Apakah ekspor memerlukan satu tampilan yang konsisten? Bisakah konsumen memproses chunk saat tiba? Setelah kegagalan, apakah percobaan ulang penuh dapat diterima atau progres harus dicatat? Apakah client terhubung langsung ke etcd atau melalui gRPC proxy?

Apa yang sedang diuji oleh pewawancara

Pewawancara sedang menguji apakah Anda memahami semantik streaming-RPC: mengonsumsi chunk secara bertahap, mengenali metadata akhir, membuang output yang tidak lengkap saat terjadi kesalahan, mempertahankan batasan revisi yang sama, dan merancang alternatif untuk pengurutan dan pemfilteran yang tidak didukung.

Jawaban 30 detik

Konfirmasikan persyaratan konsistensi dan pemulihan terlebih dahulu. Konsumsi chunk RangeStream dan tulis key ke file sementara atau downstream alih-alih mengumpulkannya di memori. Baca header, more, dan count hanya dari chunk terakhir setelah penyelesaian yang bersih. Catat range, revisi, dan jumlah chunk; buang output yang tidak lengkap dan coba lagi jika terjadi kegagalan stream. Jika pengurutan atau pemfilteran revisi diperlukan, gunakan pemrosesan aplikasi yang terkontrol atau bagi tugas tersebut alih-alih meneruskan opsi yang tidak didukung.

Pembahasan mendalam langkah demi langkah

1. Pilihan API: RangeStream menerima RangeRequest yang sama seperti Range tetapi mengembalikan beberapa pesan RangeStreamResponse. Ini ditujukan untuk kumpulan hasil yang besar, bukan langganan perubahan (subscription).
2. Konsistensi: jika permintaan tidak menetapkan revisi, server akan mengambil revisi terkomit terbaru saat stream dimulai dan melayani setiap chunk dari revisi tersebut. Catat ini untuk kebutuhan auditabilitas.
3. Konsumsi bertahap: setiap chunk berisi irisan kvs yang terpisah (disjoint). Tulis chunk sesuai urutan kedatangan ke file sementara, object store, atau pemroses downstream; batasi byte, rekaman, dan waktu pemrosesan agar backpressure tidak memicu kembali lonjakan memori.
4. Metadata akhir: header, more, dan count hanya diisi pada chunk terakhir ketika stream selesai dengan bersih. Chunk sebelumnya membiarkannya bernilai nol, sehingga tidak dapat memberikan total lebih awal.
5. Pemulihan kesalahan: pada kesalahan stream, tidak ada chunk yang membawa header, more, atau count yang valid. Tandai output sementara sebagai tidak valid, coba lagi dengan revisi dan range yang sama, dan publikasikan ekspor secara atomik hanya setelah berhasil.
6. Batasan kemampuan: RangeStream tidak mendukung pengurutan kustom, filter revisi, atau etcd gRPC proxy. Gunakan endpoint langsung yang kompatibel, persempit range, atau terapkan pengurutan dan pemeriksaan versi di sisi aplikasi secara terkontrol.
7. Kebijakan upgrade: sebelum beralih dari v3.6 ke v3.7, jalankan setidaknya v3.6.11, ikuti jalur upgrade adjacent-minor yang didukung, dan lakukan canary pada client, proxy, serta job ekspor.

Jawaban model

Saya akan membuat ekspor tersebut sebagai batch yang dapat dipulihkan dengan revisi tetap. etcd v3.7 RangeStream membagi hasil Range menjadi chunk, sehingga baik server maupun client tidak mem-buffer seluruh hasil. Pada awal permintaan, saya mencatat prefix, limit, revisi yang diminta, dan job ID. Konsumen menulis chunk ke penyimpanan sementara alih-alih menyimpan semua kvs dalam sebuah list.

Setiap chunk hanya memproses kvs miliknya sendiri. Saya memperlakukan header, more, dan count sebagai metadata akhir dan menandai penyimpanan sementara selesai hanya ketika stream berakhir dengan bersih dan chunk terakhir menyediakannya. Jika koneksi gagal, saya membuang atau mengarantina output sementara dan mencoba kembali dengan revisi dan range yang sama, sehingga ekspor parsial tidak dapat sampai ke konsumen downstream.

request:
  prefix: /tenant/config/
  revision: 0
  stream: true
consumer:
  process_each_chunk: true
  persist_to: temporary_object
  publish_only_after_clean_eof: true
  max_chunk_bytes: 8388608
failure:
  discard_incomplete_output: true
  retry_same_revision: true

Jika persyaratannya mencakup pengurutan, filter revisi, atau gRPC proxy, saya tidak akan berasumsi RangeStream mendukungnya. Saya akan memindahkan kemampuan tersebut ke dalam aplikasi dengan batas memori dan waktu yang eksplisit, menggunakan endpoint langsung yang kompatibel, atau membagi kueri. Sebelum melakukan upgrade, mulai dari 3.6.11 atau yang lebih baru, lakukan canary satu failure domain pada satu waktu, serta verifikasi output ekspor, perilaku client, dan rollback.

Kesalahan umum

• Memperlakukan RangeStream sebagai Watch dan mengabaikan bahwa ini adalah stream hasil Range yang terbatas (finite).
• Membaca count atau header dari chunk pertama dan melaporkan metadata yang salah.
• Mempublikasikan file parsial yang ditulis sebelum terjadinya kegagalan stream.
• Mengasumsikan RangeStream mendukung pengurutan, filter revisi, dan gRPC proxy.
• Meng-upgrade server tanpa memvalidasi versi client, urutan, dan job pemulihan.

Jawaban yang kuat menjelaskan batasan revisi, siklus hidup chunk, metadata akhir, pemulihan kegagalan, dan batasan API. "Membaca dalam batch untuk menurunkan memori" tidak membuktikan kebenaran implementasi.

Pertanyaan lanjutan dan tanggapan

Mengapa Anda tidak bisa menambahkan count dari setiap chunk?

Semantik resmi hanya mengisi count pada chunk terakhir; nilai sebelumnya bernilai nol, dan nilai akhir mendeskripsikan permintaan secara lengkap. Untuk progres, hitung sendiri key dan byte yang dikonsumsi, lalu rekonsiliasi dengan metadata akhir setelah penyelesaian yang bersih.

Apa yang terjadi pada data object-store yang ditulis sebelum kegagalan stream?

Tulis di bawah job ID dan prefix sementara. Publikasikan versi yang immutable hanya setelah EOF bersih dan validasi metadata akhir. Tandai objek yang gagal untuk pembersihan atau investigasi; jalur pembacaan normal tidak boleh menemukannya.

Bagaimana Anda menangani persyaratan untuk mengurutkan berdasarkan key?

RangeStream tidak mendukung pengurutan kustom. Konsumsi urutan key alami dan lakukan external merge sort dengan batasan memori, disk, dan waktu yang eksplisit; jika pengurutan di sisi server wajib dilakukan, gunakan jalur kueri yang mendukungnya alih-alih mengirimkan opsi palsu.

Bagaimana cara menghindari terlewatnya versi yang tidak didukung selama upgrade etcd?

Ikuti kebijakan resmi: upgrade patch tetap berada dalam versi minor yang sama, dan upgrade minor maju satu versi pada satu waktu. Sebelum 3.6 ke 3.7, capai 3.6.11 atau yang lebih baru dan lakukan canary pada client serta job pemulihan.