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 menjadi 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 Anda 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 keterukuran
• Integrasi pipeline Anda dengan sumber data, tujuan, 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 alur kerja Anda memenuhi persyaratan bisnis Anda. Tujuan tingkat layanan (SLO) memberikan definisi performa yang nyata yang dapat Anda bandingkan dengan nilai minimum yang dapat diterima. Misalnya, Anda dapat menentukan SLO contoh berikut untuk sistem Anda:

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

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

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

Anda dapat menggunakan indikator tingkat layanan (SLI) untuk mengukur kepatuhan SLO. SLI adalah metrik terukur yang menunjukkan seberapa baik sistem Anda memenuhi SLO tertentu. Misalnya, Anda dapat mengukur SLO keaktualan data contoh dengan menggunakan usia aktivitas pengguna yang baru-baru ini diproses sebagai SLI. Jika pipeline Anda membuat rekomendasi dari peristiwa aktivitas pengguna, dan jika SLI melaporkan penundaan 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 melampaui latensi sistem 4 menit, Anda tahu bahwa SLO tidak terpenuhi.

Karena komponen sistem di luar pipeline memengaruhi SLO Anda, penting untuk mencatat berbagai SLI yang menjelaskan performa keseluruhan sistem di luar performa pipeline itu sendiri, termasuk metrik yang menjelaskan kondisi end-to-end sistem Anda. Misalnya, pipeline Dataflow Anda mungkin menghitung hasil dengan penundaan yang dapat diterima, tetapi masalah performa mungkin terjadi pada sistem hilir yang memengaruhi SLO yang lebih luas.

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

Keaktualan data

Keaktualan data mengacu pada kegunaan data dalam kaitannya 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. Biasanya digunakan untuk pipeline batch yang memproses sumber data terbatas. Metrik untuk jenis SLO ini adalah ukuran data input dan output pada langkah-langkah pemrosesan utama yang relatif terhadap durasi pipeline yang telah 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 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. Biasanya digunakan untuk pipeline streaming yang memproses data dari sumber yang tidak terbatas. Untuk jenis SLO ini, gunakan metrik yang menunjukkan berapa lama pipeline Anda memproses data. Dua kemungkinan metrik adalah usia item yang belum diproses paling lama, yaitu berapa lama item yang belum diproses berada dalam antrean, atau usia item yang baru-baru ini diproses. Contoh SLO adalah "Rekomendasi produk dibuat 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 biasanya digunakan untuk pipeline batch yang memproses data dari sumber data terbatas. SLO ini memerlukan total waktu yang berlalu di 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 pada hari berikutnya".

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

Kebenaran data

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

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

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

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

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

• Berdasarkan per tugas, kurang dari X% item input berisi kesalahan data. Anda dapat menggunakan SLO ini untuk mengukur kebenaran data untuk pipeline batch. Contoh SLO adalah "Untuk setiap tugas batch harian yang memproses pembacaan meteran listrik, kurang dari 3% pembacaan berisi kesalahan entri data."
• Selama periode 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 meteran listrik selama satu jam terakhir berisi nilai negatif".

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

Untuk mengetahui 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 penyeimbangan beban. 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 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. 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 prioritas standar dan prioritas tinggi.
• Mengisolasi dan menyeimbangkan beban 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, aplikasi akan segera memproses pembayaran dan menulis peristiwa ke BigQuery menggunakan streaming insert.

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

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

Menggunakan beberapa pipeline yang disesuaikan untuk SLO tertentu

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

Pembayaran 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 dalam pipeline yang berbeda memiliki keuntungan. Untuk melakukan pembayaran prioritas tinggi dengan SLO yang lebih ketat, Anda dapat mempersingkat waktu pemrosesan dengan menetapkan lebih banyak resource ke pipeline yang dikhususkan untuk pembayaran prioritas tinggi. Konfigurasi resource mencakup penambahan worker Dataflow, penggunaan mesin yang lebih besar, dan pengaktifan penskalaan otomatis. Mengisolasi item prioritas tinggi ke antrean pemrosesan terpisah juga dapat mengurangi jeda pemrosesan jika terjadi lonjakan pembayaran prioritas standar secara tiba-tiba.

Saat Anda menggunakan beberapa pipeline untuk mengisolasi dan menyeimbangkan beban data dari sumber batch dan streaming, model pemrograman Apache Beam memungkinkan pipeline berprioritas tinggi (streaming) dan berprioritas standar (batch) 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 dan tujuan data

Untuk memproses data, pipeline data perlu diintegrasikan dengan sistem lain. Sistem tersebut disebut sumber dan tujuan. Pipeline data membaca data dari sumber dan menulis data ke tujuan. Selain sumber dan tujuan, pipeline data dapat 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-faktor di luar kode pipeline dan layanan Dataflow juga memengaruhi skalabilitas pipeline Anda. Faktor-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 butuhkan dapat memengaruhi performa pipeline Anda. 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 mengetahui informasi selengkapnya, lihat Menggunakan sumber dan tujuan yang dikelola Google Cloud di halaman ini.

• Pilihan format data: format data tertentu mungkin lebih cepat dibaca daripada format lainnya. Misalnya, menggunakan format data yang mendukung pembacaan yang dapat diparalelkan, seperti Avro, biasanya lebih cepat daripada menggunakan file CSV yang memiliki karakter baris baru yang disematkan di kolom, dan lebih cepat daripada menggunakan file terkompresi.

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

Panggilan layanan eksternal

Memanggil layanan eksternal dari pipeline Anda akan menimbulkan overhead per panggilan yang dapat mengurangi performa dan efisiensi pipeline Anda. Jika pipeline data Anda memanggil layanan eksternal, untuk mengurangi overhead, kelompokkan beberapa elemen data ke dalam satu permintaan jika memungkinkan. Banyak transformasi I/O Apache Beam native yang 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 kecepatan panggilan, seperti jumlah permintaan per detik.

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

Menggunakan Google Cloud sumber dan sink terkelola

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

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

Bagian lainnya di bagian ini membahas pengaruh berbagai kuota dan batas terhadap cara Anda mendesain, mengembangkan, dan memantau pipeline. Google CloudPub/Sub dan BigQuery digunakan sebagai contoh sumber dan tujuan pipeline.

Contoh 1: Pub/Sub

Saat Anda menggunakan Pub/Sub dengan Dataflow, Pub/Sub menyediakan layanan penyerapan peristiwa yang dapat diskalakan dan tahan lama untuk mengirimkan pesan ke dan dari pipeline data streaming Anda. Anda dapat menggunakan konsol Google Cloud untuk melihat penggunaan kuota Pub/Sub dan meningkatkan batas kuota. Sebaiknya Anda meminta penambahan kuota jika ada satu pipeline yang melebihi kuota dan batas per project.

Kuota dan batas Pub/Sub dirancang berdasarkan penggunaan tingkat project. Secara khusus, penayang dan pelanggan dalam project yang berbeda diberi kuota throughput data yang terpisah. Jika beberapa pipeline memublikasikan atau berlangganan ke satu topik, Anda bisa mendapatkan throughput maksimum yang diizinkan pada topik tersebut dengan men-deploy setiap pipeline ke projectnya 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 berbagi kuota throughput subscriber dan publisher yang sama yang tersedia untuk Project A. Sebaliknya, Pipeline 3 dapat menggunakan seluruh kuota throughput subscriber dan penayang yang terlampir ke Project B.

Beberapa pipeline dapat membaca dari satu topik Pub/Sub dengan menggunakan langganan terpisah ke topik tersebut, yang memungkinkan pipeline Dataflow menarik dan mengonfirmasi pesan secara terpisah dari pelanggan lain, seperti pipeline lainnya. Fitur ini memudahkan pengkloningan 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 menyediakan fungsi ini. BigQueryIO mendukung dua metode untuk membaca data: EXPORT (ekspor tabel) dan DIRECT_READ. Metode pembacaan 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 menambah waktu proses tugas.

Sebaliknya, pendekatan baca 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 batasan kuota ekspor dan berpotensi mengurangi waktu berjalan 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 baca langsung untuk mendapatkan data dari tabel ke pipeline.

Menulis data ke tabel BigQuery juga memiliki implikasi kuota tersendiri. 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 tepat 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 Google Cloud region Saat memilih region yang akan digunakan untuk menjalankan tugas, pertimbangkan faktor-faktor berikut:

• Lokasi sumber dan tujuan data
• Preferensi atau batasan pada lokasi pemrosesan data
• Fitur Dataflow yang hanya ditawarkan di region 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 mengetahui 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 pemulihan dari bencana. 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. Mereka juga mengontrol perilaku pekerja seperti penskalaan otomatis. Menentukan region membantu Anda memenuhi kebutuhan keamanan dan kepatuhan, lokalitas data, dan penempatan tugas regional. Untuk menghindari dampak performa dari panggilan jaringan lintas region, sebaiknya gunakan region yang sama untuk tugas dan pekerja jika memungkinkan.

Worker Dataflow

Job 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 tujuan 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 Pengacakan Dataflow atau Streaming Engine, data yang diproses oleh tugas (yaitu, data yang disimpan dalam objek PCollection) berada di pekerja tugas, dengan asumsi bahwa tidak ada kode pengguna yang mengirimkan data di luar pekerja. Jika layanan Pengacakan Dataflow atau Streaming Engine diaktifkan, set data terdistribusi yang diwakili oleh objek PCollection dapat ditransmisikan antara pekerja dan layanan ini.

Pertimbangan enkripsi data

Sebagai layanan yang terkelola sepenuhnya, Dataflow otomatis mengenkripsi data yang bergerak melalui pipeline data Anda menggunakan Google-owned and Google-managed encryption keys untuk data dalam transit dan data saat istirahat. Daripada menggunakan Google-owned and Google-managed encryption keys, Anda mungkin lebih memilih untuk 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 menggunakan kunci Cloud KMS Anda untuk mengenkripsi data, kecuali untuk operasi berbasis kunci data seperti windowing, pengelompokan, dan penggabungan. Jika kunci data berisi data sensitif, seperti informasi identitas pribadi (PII), Anda harus melakukan hashing atau mengubah kunci sebelum dimasukkan ke 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 subnetwork 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 subnetwork atau mengakses jaringan VPC peer. Demikian pula, akses jaringan ke pekerja VM dari luar subnetwork atau jaringan VPC peer dicegah.

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

Langkah berikutnya

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