Merencanakan pipeline Dataflow

Halaman ini menjelaskan pertimbangan penting untuk merencanakan pipeline data sebelum Anda memulai pengembangan kode. Pipeline data memindahkan data dari satu sistem ke sistem lain dan sering kali merupakan komponen penting dari sistem informasi bisnis. Performa dan keandalan pipeline data Anda dapat memengaruhi sistem yang lebih luas ini dan seberapa efektif persyaratan bisnis Anda terpenuhi.

Jika merencanakan pipeline data sebelum mengembangkannya, Anda dapat meningkatkan performa dan keandalannya. Halaman ini menjelaskan berbagai pertimbangan perencanaan untuk pipeline Dataflow, termasuk:

• Ekspektasi performa untuk pipeline Anda, termasuk standar untuk pengukuran
• Integrasi pipeline Anda dengan sumber data, sink, dan sistem terhubung lainnya
• Regionalisasi pipeline, sumber, dan sink
• Keamanan, seperti enkripsi data dan jaringan pribadi

Menentukan dan mengukur SLO

Ukuran performa yang penting adalah seberapa baik pipeline Anda memenuhi persyaratan bisnis. Tujuan tingkat layanan (SLO) memberikan definisi performa yang nyata yang dapat Anda bandingkan dengan nilai minimum yang dapat diterima. Misalnya, Anda dapat menentukan contoh SLO berikut untuk sistem Anda:

• Keaktualan data: menghasilkan 90% rekomendasi produk dari aktivitas situs pengguna yang terjadi paling lambat 3 menit yang lalu.

• Keakuratan data: dalam satu bulan kalender, kurang dari 0,5% invoice pelanggan berisi error.

• Isolasi data/load balancing: dalam satu hari kerja, proses semua pembayaran prioritas tinggi dalam waktu 10 menit sejak pengajuan, dan selesaikan pembayaran prioritas standar pada hari kerja berikutnya.

Anda dapat menggunakan indikator tingkat layanan (SLI) untuk mengukur kepatuhan SLO. SLI adalah metrik yang dapat diukur yang menunjukkan seberapa baik sistem Anda memenuhi SLO tertentu. Misalnya, Anda dapat mengukur contoh SLO keaktualan data dengan menggunakan usia aktivitas pengguna yang terakhir diproses sebagai SLI. Jika pipeline Anda menghasilkan rekomendasi dari peristiwa aktivitas pengguna, dan jika SLI melaporkan keterlambatan 4 menit antara waktu peristiwa dan waktu peristiwa diproses, rekomendasi tidak mempertimbangkan aktivitas situs pengguna dari lebih awal dari 4 menit. Jika pipeline yang memproses data streaming melebihi latensi sistem selama 4 menit, Anda tahu bahwa SLO tidak terpenuhi.

Karena komponen sistem di luar pipeline memengaruhi SLO, Anda harus mengambil berbagai SLI yang menjelaskan performa sistem secara keseluruhan di luar performa pipeline itu sendiri, termasuk metrik yang menjelaskan kondisi menyeluruh sistem Anda. Misalnya, pipeline Dataflow Anda mungkin menghitung hasil dengan penundaan yang dapat diterima, tetapi masalah performa mungkin terjadi dengan sistem downstream yang memengaruhi SLO yang lebih luas.

Untuk informasi selengkapnya tentang SLO penting yang perlu dipertimbangkan, lihat buku Site Reliability Engineering.

Keaktualan data

Keaktualan data mengacu pada kegunaan data sehubungan dengan usianya. SLO keaktualan data berikut disebutkan dalam buku Site Reliability Engineering sebagai format SLO keaktualan data pipeline yang paling umum:

• X% data diproses dalam Y [detik, hari, menit]. SLO ini mengacu pada persentase data yang diproses dalam jangka waktu tertentu. Fungsi ini umumnya digunakan untuk pipeline batch yang memproses sumber data terbatas. Metrik untuk jenis SLO ini adalah ukuran data input dan output pada langkah pemrosesan utama dibandingkan dengan runtime pipeline yang berlalu. Anda dapat memilih langkah yang membaca set data input dan langkah lain yang memproses setiap item input. Contoh SLO adalah "Untuk game Shave the Yak, 99% aktivitas pengguna yang memengaruhi skor pemain diperhitungkan dalam waktu 30 menit setelah pertandingan selesai".

• Data terlama tidak lebih lama dari X [detik, hari, menit]. SLO ini mengacu pada usia data yang dihasilkan oleh pipeline. Fungsi ini biasanya digunakan untuk pipeline streaming yang memproses data dari sumber yang tidak terbatas. Untuk jenis SLO ini, gunakan metrik yang menunjukkan berapa lama waktu yang diperlukan pipeline Anda untuk memproses data. Dua kemungkinan metrik adalah usia item terlama yang belum diproses, yaitu, berapa lama item yang belum diproses berada dalam antrean, atau usia item yang terakhir diproses. Contoh SLO adalah "Rekomendasi produk dihasilkan dari aktivitas pengguna yang tidak lebih dari 5 menit."

• Tugas pipeline berhasil diselesaikan dalam X [detik, hari, menit]. SLO ini menetapkan batas waktu untuk penyelesaian yang berhasil dan umumnya digunakan untuk pipeline batch yang memproses data dari sumber data terbatas. SLO ini memerlukan total waktu berlalunya pipeline dan status penyelesaian tugas, selain sinyal lain yang menunjukkan keberhasilan tugas, seperti persentase elemen yang diproses yang menghasilkan error. Contoh SLO adalah "Pesanan pelanggan dari hari kerja saat ini diproses paling lambat pukul 09.00 hari berikutnya".

Untuk informasi tentang cara menggunakan Cloud Monitoring untuk mengukur keaktualan data, lihat Metrik tugas Dataflow.

Keakuratan data

Kebenaran data mengacu pada data yang bebas dari error. Anda dapat menentukan ketepatan data melalui berbagai cara, termasuk:

• Pengujian unit dan pengujian integrasi, yang dapat Anda otomatisasi menggunakan continuous integration.

• Pengujian pipeline menyeluruh, yang dapat Anda jalankan di lingkungan praproduksi setelah pipeline berhasil lulus pengujian unit dan integrasi. Anda dapat mengotomatiskan pengujian pipeline menyeluruh menggunakan continuous delivery.

• Pipeline yang berjalan dalam produksi, saat Anda menggunakan pemantauan untuk mengamati metrik yang terkait dengan kebenaran data.

Untuk menjalankan pipeline, menentukan target ketepatan data biasanya melibatkan pengukuran ketepatan selama jangka waktu tertentu. Contoh:

• Per tugas, kurang dari X% item input berisi error data. Anda dapat menggunakan SLO ini untuk mengukur kebenaran data untuk pipeline batch. Contoh SLO adalah "Untuk setiap tugas batch harian guna memproses pembacaan meteran listrik, kurang dari 3% pembacaan berisi error entri data".
• Selama periode berpindah X menit, kurang dari Y% item input berisi error data. Anda dapat menggunakan SLO ini untuk mengukur kebenaran data untuk pipeline streaming. Contoh SLO adalah "Kurang dari 2% pembacaan meter listrik selama satu jam terakhir berisi nilai negatif".

Untuk mengukur SLO ini, gunakan metrik selama jangka waktu yang sesuai untuk mengumpulkan jumlah error menurut jenisnya. Contoh jenis error adalah data salah karena skema salah format, atau data berada di luar rentang yang valid.

Untuk informasi tentang cara menggunakan Cloud Monitoring untuk mengukur kebenaran data, lihat Metrik tugas Dataflow.

Isolasi data dan load balancing

Isolasi data melibatkan segmentasi data menurut atribut, yang dapat mempermudah load balancing. Misalnya, di platform pemrosesan pembayaran online, Anda dapat menyegmentasikan data sehingga setiap pembayaran memiliki prioritas standar atau prioritas tinggi. Pipeline Anda kemudian dapat menggunakan load balancing untuk memastikan bahwa pembayaran prioritas tinggi diproses sebelum pembayaran prioritas standar.

Misalkan Anda menentukan SLO berikut untuk pemrosesan pembayaran:

• Pembayaran dengan prioritas tinggi diproses dalam waktu 10 menit.
• Pembayaran prioritas standar diproses paling lambat pukul 09.00 pada hari kerja berikutnya.

Jika platform pembayaran mematuhi SLO ini, pelanggan dapat melihat pembayaran prioritas tinggi yang telah diselesaikan di dasbor pelaporan saat pembayaran selesai. Sebaliknya, pembayaran standar mungkin tidak muncul di dasbor hingga hari berikutnya.

Dalam contoh skenario ini, Anda memiliki opsi berikut:

• Jalankan satu pipeline untuk memproses pembayaran dengan prioritas standar dan prioritas tinggi.
• Isolasi dan lakukan load balancing data berdasarkan prioritas di beberapa pipeline.

Bagian berikut menjelaskan setiap opsi secara mendetail.

Menggunakan satu pipeline untuk memenuhi SLO campuran

Diagram berikut mengilustrasikan satu pipeline yang digunakan untuk memproses pembayaran prioritas tinggi dan prioritas standar. Pipeline menerima notifikasi pembayaran baru dari sumber data streaming, seperti topik Pub/Sub atau topik Apache Kafka. Kemudian, sistem ini akan langsung memproses pembayaran dan menulis peristiwa ke BigQuery menggunakan streaming insert.

Keuntungan dari satu pipeline adalah menyederhanakan persyaratan operasional, karena Anda hanya perlu mengelola satu sumber data dan pipeline. Dataflow menggunakan fitur penyesuaian otomatis untuk membantu menjalankan tugas Anda secepat dan seefisien mungkin.

Kelemahan dari satu pipeline adalah pipeline bersama tidak dapat memprioritaskan pembayaran prioritas tinggi daripada pembayaran prioritas standar, dan resource pipeline dibagikan di kedua jenis pembayaran. Dalam skenario bisnis yang dijelaskan sebelumnya, pipeline Anda harus mempertahankan SLO yang lebih ketat dari dua SLO tersebut. Artinya, pipeline harus menggunakan SLO untuk pembayaran prioritas tinggi, terlepas dari prioritas pembayaran yang diproses. Kerugian lainnya adalah jika terjadi backlog pekerjaan, pipeline streaming tidak dapat memprioritaskan pemrosesan backlog sesuai dengan urgensi pekerjaan.

Menggunakan beberapa pipeline yang disesuaikan untuk SLO tertentu

Anda dapat menggunakan dua pipeline untuk mengisolasi resource dan mengirimkannya berdasarkan SLO tertentu. Diagram berikut mengilustrasikan pendekatan ini.

Pembayaran dengan prioritas tinggi diisolasi ke pipeline streaming untuk pemrosesan yang diprioritaskan. Pembayaran prioritas standar diproses oleh pipeline batch yang berjalan setiap hari dan menggunakan tugas pemuatan BigQuery untuk menulis hasil yang diproses.

Mengisolasi data di pipeline yang berbeda memiliki keunggulan. Untuk mengirimkan pembayaran prioritas tinggi dengan SLO yang lebih ketat, Anda dapat mempersingkat waktu pemrosesan dengan menetapkan lebih banyak resource ke pipeline yang didedikasikan untuk pembayaran prioritas tinggi. Konfigurasi resource mencakup penambahan pekerja Dataflow, penggunaan mesin yang lebih besar, dan pengaktifan penskalaan otomatis. Mengisolasi item prioritas tinggi ke antrean pemrosesan terpisah juga dapat memitigasi keterlambatan pemrosesan jika terjadi lonjakan pembayaran prioritas standar secara tiba-tiba.

Saat Anda menggunakan beberapa pipeline untuk mengisolasi dan melakukan load balancing data dari sumber batch dan streaming, model pemrograman Apache Beam memungkinkan pipeline prioritas tinggi (streaming) dan prioritas standar (batch) untuk berbagi kode yang sama. Satu-satunya pengecualian adalah transformasi baca awal, yang membaca dari sumber terbatas untuk pipeline batch. Untuk mengetahui informasi selengkapnya, lihat Membuat library transformasi yang dapat digunakan kembali.

Merencanakan sumber data dan sink

Untuk memproses data, pipeline data perlu diintegrasikan dengan sistem lain. Sistem tersebut disebut sebagai sumber dan penampung. Pipeline data membaca data dari sumber dan menulis data ke sink. Selain sumber dan sink, pipeline data mungkin berinteraksi dengan sistem eksternal untuk pengayaan data, pemfilteran, atau memanggil logika bisnis eksternal dalam langkah pemrosesan.

Untuk skalabilitas, Dataflow menjalankan tahap pipeline Anda secara paralel di beberapa pekerja. Faktor yang berada di luar kode pipeline dan layanan Dataflow juga memengaruhi skalabilitas pipeline Anda. Faktor ini dapat mencakup hal berikut:

• Skalabilitas sistem eksternal: sistem eksternal yang berinteraksi dengan pipeline Anda dapat membatasi performa dan dapat membentuk batas atas skalabilitas. Misalnya, topik Apache Kafka yang dikonfigurasi dengan jumlah partisi yang tidak memadai untuk throughput baca yang Anda perlukan dapat memengaruhi performa pipeline. Untuk membantu memastikan bahwa pipeline dan komponennya memenuhi target performa Anda, lihat dokumentasi praktik terbaik untuk sistem eksternal yang Anda gunakan. Anda juga dapat menyederhanakan perencanaan kapasitas infrastruktur dengan menggunakan layanan Google Cloud yang menyediakan skalabilitas bawaan. Untuk informasi selengkapnya, lihat Menggunakan sumber dan sink yang dikelola Google Cloud di halaman ini.

• Pilihan format data: format data tertentu mungkin lebih cepat dibaca daripada yang lain. Misalnya, menggunakan format data yang mendukung pembacaan paralel, seperti Avro, biasanya lebih cepat daripada menggunakan file CSV yang memiliki baris baru tersemat di kolom, dan lebih cepat daripada menggunakan file yang dikompresi.

• Lokasi data dan topologi jaringan: kedekatan geografis dan karakteristik jaringan sumber data dan sink sehubungan dengan pipeline data dapat memengaruhi performa. Untuk informasi selengkapnya, lihat Pertimbangan regional di halaman ini.

Panggilan layanan eksternal

Memanggil layanan eksternal dari pipeline akan menimbulkan overhead per panggilan yang dapat menurunkan performa dan efisiensi pipeline Anda. Jika pipeline data Anda memanggil layanan eksternal, untuk mengurangi overhead, gabungkan beberapa elemen data menjadi satu permintaan jika memungkinkan. Banyak transformasi I/O Apache Beam native otomatis melakukan tugas ini, termasuk BigQueryIO dan operasi penyisipan streaming. Selain batas kapasitas, beberapa layanan eksternal juga menerapkan kuota yang membatasi jumlah total panggilan selama jangka waktu tertentu, seperti kuota harian, atau membatasi frekuensi panggilan, seperti jumlah permintaan per detik.

Karena Dataflow melakukan paralelisasi pekerjaan di beberapa pekerja, terlalu banyak traffic dapat membebani layanan eksternal atau menghabiskan kuota yang tersedia. Saat penskalaan otomatis digunakan, Dataflow mungkin mencoba mengimbangi dengan menambahkan pekerja untuk menjalankan langkah lambat seperti panggilan eksternal. Menambahkan pekerja dapat menambah tekanan lebih lanjut pada sistem eksternal. Pastikan sistem eksternal dapat mendukung persyaratan beban yang diperkirakan, atau batasi traffic dari pipeline ke tingkat yang berkelanjutan. Untuk informasi selengkapnya, lihat Membatasi ukuran batch dan panggilan serentak ke layanan eksternal.

Menggunakan sumber dan sink yang dikelola Google Cloud

Menggunakan layanan terkelola Google Cloud dengan pipeline Dataflow Anda akan menghilangkan kompleksitas pengelolaan kapasitas dengan menyediakan skalabilitas bawaan, performa yang konsisten, serta kuota dan batas yang mengakomodasi sebagian besar persyaratan. Anda tetap perlu mengetahui berbagai kuota dan batas untuk operasi pipeline. Dataflow itu sendiri menerapkan kuota dan batas. Anda dapat meningkatkan beberapa hal ini dengan menghubungi dukungan Google Cloud.

Dataflow menggunakan instance VM Compute Engine untuk menjalankan tugas, sehingga Anda memerlukan kuota Compute Engine yang memadai. Kuota Compute Engine yang tidak memadai dapat menghambat penskalaan otomatis pipeline atau mencegah tugas dimulai.

Bagian lain dari bagian ini akan membahas pengaruh berbagai kuota dan batas Google Cloud terhadap cara Anda mendesain, mengembangkan, dan memantau pipeline. Pub/Sub dan BigQuery digunakan sebagai contoh sumber dan sink pipeline.

Contoh 1: Pub/Sub

Saat Anda menggunakan Pub/Sub dengan Dataflow, Pub/Sub menyediakan layanan penyerapan peristiwa yang skalabel dan andal untuk mengirimkan pesan ke dan dari pipeline data streaming Anda. Anda dapat menggunakan konsol Google Cloud untuk melihat konsumsi kuota Pub/Sub dan meningkatkan batas kuota. Sebaiknya minta peningkatan kuota jika Anda memiliki satu pipeline yang melebihi kuota dan batas per project.

Kuota dan batas Pub/Sub dirancang berdasarkan penggunaan tingkat project. Secara khusus, penayang dan pelanggan di project yang berbeda diberi kuota throughput data independen. Jika beberapa pipeline memublikasikan atau berlangganan satu topik, Anda bisa mendapatkan throughput maksimum yang diizinkan pada topik tersebut dengan men-deploy setiap pipeline ke project-nya sendiri. Dalam konfigurasi ini, setiap pipeline menggunakan akun layanan berbasis project yang berbeda untuk menggunakan dan memublikasikan pesan.

Dalam diagram berikut, Pipeline 1 dan Pipeline 2 memiliki kuota throughput subscriber dan penayang yang sama yang tersedia untuk Project A. Sebaliknya, Pipeline 3 dapat menggunakan seluruh kuota throughput subscriber dan penayang yang dilampirkan ke Project B.

Beberapa pipeline dapat membaca dari satu topik Pub/Sub menggunakan langganan terpisah ke topik, yang memungkinkan pipeline Dataflow mengambil dan mengonfirmasi pesan secara terpisah dari pelanggan lain, seperti pipeline lainnya. Fitur ini memudahkan untuk meng-clone pipeline dengan membuat langganan Pub/Sub tambahan. Membuat langganan tambahan berguna untuk membuat pipeline replika untuk ketersediaan tinggi (biasanya untuk kasus penggunaan streaming), untuk menjalankan pipeline pengujian tambahan terhadap data yang sama, dan untuk mengaktifkan update pipeline.

Contoh 2: BigQuery

Membaca dan menulis data BigQuery didukung oleh Apache Beam SDK untuk beberapa bahasa, termasuk Java, Python, dan Go. Saat Anda menggunakan Java, class BigQueryIO akan menyediakan fungsi ini. BigQueryIO mendukung dua metode untuk membaca data: EXPORT (ekspor tabel) dan DIRECT_READ. Metode baca yang berbeda menggunakan kuota BigQuery yang berbeda.

Ekspor tabel adalah metode baca default. Cara kerjanya seperti yang ditunjukkan dalam diagram berikut:

Diagram menunjukkan alur berikut:

1. BigQueryIO memanggil permintaan ekspor BigQuery untuk mengekspor data tabel. Data tabel yang diekspor ditulis ke lokasi Cloud Storage sementara.
2. BigQueryIO membaca data tabel dari lokasi Cloud Storage sementara.

Permintaan ekspor BigQuery dibatasi oleh kuota ekspor. Permintaan ekspor juga harus selesai sebelum pipeline dapat mulai memproses data, yang akan menambahkan waktu proses tambahan untuk tugas.

Sebaliknya, pendekatan pembacaan langsung menggunakan BigQuery Storage API untuk membaca data tabel langsung dari BigQuery. BigQuery Storage API memberikan performa baca throughput tinggi untuk data baris tabel menggunakan gRPC. Penggunaan BigQuery Storage API membuat langkah ekspor tidak diperlukan, sehingga menghindari pembatasan kuota ekspor dan berpotensi mengurangi waktu proses tugas.

Diagram berikut menunjukkan alur jika Anda menggunakan BigQuery Storage API. Berbeda dengan alur yang menggunakan permintaan ekspor BigQuery, alur ini lebih sederhana, karena hanya memiliki satu langkah pembacaan langsung untuk mendapatkan data dari tabel ke pipeline.

Menulis data ke tabel BigQuery juga memiliki implikasi kuota sendiri. Pipeline batch yang menggunakan tugas pemuatan BigQuery menggunakan kuota tugas pemuatan BigQuery yang berbeda yang berlaku di tingkat tabel dan project. Demikian pula, pipeline streaming yang menggunakan streaming insert BigQuery akan menggunakan kuota streaming insert BigQuery.

Untuk menentukan metode yang paling sesuai untuk membaca dan menulis data, pertimbangkan kasus penggunaan Anda. Misalnya, hindari penggunaan tugas pemuatan BigQuery untuk menambahkan data ribuan kali per hari ke dalam tabel. Gunakan pipeline streaming untuk menulis data mendekati real-time ke BigQuery. Pipeline streaming Anda harus menggunakan penyisipan streaming atau Storage Write API untuk tujuan ini.

Pertimbangan regional

Dataflow ditawarkan sebagai layanan terkelola di beberapa region Google Cloud. Saat memilih region yang akan digunakan untuk menjalankan tugas, pertimbangkan faktor berikut:

• Lokasi sumber data dan sink
• Preferensi atau batasan pada lokasi pemrosesan data
• Fitur Dataflow yang hanya ditawarkan di wilayah tertentu
• Wilayah yang digunakan untuk mengelola eksekusi tugas tertentu
• Zona yang digunakan untuk pekerja tugas

Untuk tugas tertentu, setelan wilayah yang Anda gunakan untuk tugas dan pekerja dapat berbeda. Untuk informasi selengkapnya, termasuk kapan harus menentukan region dan zona, lihat Dokumentasi region dataflow.

Dengan menentukan region untuk menjalankan tugas Dataflow, Anda dapat merencanakan pertimbangan regional untuk ketersediaan tinggi dan disaster recovery. Untuk mengetahui informasi selengkapnya, lihat Ketersediaan tinggi dan redundansi geografis.

Region

Region Dataflow menyimpan dan menangani metadata yang terkait dengan tugas Anda, seperti informasi tentang grafik Apache Beam itu sendiri, seperti nama transformasi. Node ini juga mengontrol perilaku pekerja seperti penskalaan otomatis. Menentukan region membantu Anda memenuhi kebutuhan keamanan dan kepatuhan, lokalitas data, dan penempatan regional tugas. Untuk menghindari dampak performa dari panggilan jaringan lintas region, sebaiknya gunakan region yang sama untuk tugas dan pekerja jika memungkinkan.

Pekerja Dataflow

Tugas Dataflow menggunakan instance VM Compute Engine, yang disebut pekerja Dataflow, untuk menjalankan pipeline Anda. Tugas Dataflow dapat menggunakan zona Compute Engine apa pun untuk pekerja, termasuk region yang tidak memiliki lokasi Dataflow. Dengan menentukan region pekerja untuk tugas, Anda dapat mengontrol penempatan regional pekerja. Untuk menentukan region atau zona pekerja, lakukan hal berikut:

• Jika Anda menggunakan gcloud CLI untuk membuat tugas dari template Dataflow, gunakan flag --worker-region untuk mengganti region pekerja, atau gunakan flag --worker-zone untuk mengganti zona pekerja.
• Jika Anda menggunakan Apache Beam Java SDK untuk membuat tugas, tetapkan region dan zona untuk pekerja menggunakan opsi pipeline. Gunakan workerRegion untuk mengganti region pekerja atau workerZone untuk mengganti zona pekerja.

Untuk meningkatkan latensi dan throughput jaringan, sebaiknya buat pekerja di region yang secara geografis dekat dengan sumber dan sink data Anda. Jika Anda tidak menentukan region atau zona untuk pekerja saat membuat tugas, Dataflow akan otomatis menggunakan zona default yang berada di region yang sama dengan tugas.

Jika Anda tidak menggunakan layanan Dataflow Shuffle atau Streaming Engine, data yang diproses oleh tugas (yaitu, data yang disimpan dalam objek PCollection) akan berada di pekerja tugas, dengan asumsi bahwa tidak ada kode pengguna yang mengirimkan data di luar pekerja. Jika layanan Dataflow Shuffle atau Streaming Engine diaktifkan, set data terdistribusi yang direpresentasikan oleh objek PCollection dapat dikirimkan antara pekerja dan layanan ini.

Pertimbangan enkripsi data

Sebagai layanan terkelola sepenuhnya, Dataflow otomatis mengenkripsi data yang bergerak melalui pipeline data Anda menggunakan kunci milik dan dikelola Google untuk data dalam pengiriman dan data dalam penyimpanan. Daripada menggunakan kunci yang dimiliki dan dikelola Google, Anda mungkin lebih suka mengelola kunci enkripsi Anda sendiri. Untuk kasus tersebut, Dataflow mendukung kunci enkripsi yang dikelola pelanggan (CMEK) menggunakan Cloud Key Management Service (KMS). Anda juga dapat menggunakan Cloud HSM, layanan modul keamanan hardware (HSM) yang dihosting di cloud, yang memungkinkan Anda menghosting kunci enkripsi dan melakukan operasi kriptografi di cluster HSM bersertifikasi FIPS 140-2 Level 3.

Saat Anda menggunakan CMEK, Dataflow akan menggunakan kunci Cloud KMS untuk mengenkripsi data, kecuali untuk operasi berbasis kunci data seperti pembuatan periode, pengelompokan, dan penggabungan. Jika kunci data berisi data sensitif, seperti informasi identitas pribadi (PII), Anda harus melakukan hashing atau mengubah kunci sebelum kunci tersebut memasuki pipeline Dataflow.

Pertimbangan jaringan pribadi

Persyaratan jaringan dan keamanan Anda mungkin mewajibkan beban kerja berbasis VM seperti tugas Dataflow hanya menggunakan alamat IP pribadi. Dataflow memungkinkan Anda menentukan bahwa pekerja menggunakan alamat IP pribadi untuk semua komunikasi jaringan. Jika IP publik dinonaktifkan, Anda harus mengaktifkan Akses Google Pribadi di subjaringan agar pekerja Dataflow dapat menjangkau API dan layanan Google.

Sebaiknya nonaktifkan IP publik untuk pekerja Dataflow, kecuali jika tugas Dataflow Anda memerlukan IP publik untuk mengakses resource jaringan di luar Google Cloud. Menonaktifkan IP publik akan mencegah pekerja Dataflow mengakses resource yang berada di luar subjaringan atau mengakses jaringan VPC peer. Demikian pula, akses jaringan ke pekerja VM dari luar subjaringan atau jaringan VPC peer akan dicegah.

Untuk informasi selengkapnya tentang cara menggunakan opsi pipeline --usePublicIps untuk menentukan apakah pekerja hanya boleh memiliki IP pribadi, lihat Opsi pipeline.

Langkah selanjutnya

• Kembangkan dan uji pipeline Anda.
• Pelajari cara mendesain alur kerja pipeline lengkap.
• Baca selengkapnya tentang praktik Site Reliability Engineering (SRE) Google untuk pipeline pemrosesan data.