Halaman ini memberikan praktik terbaik untuk mengembangkan dan menguji pipeline Dataflow Anda.
Ringkasan
Cara kode untuk pipeline Anda diimplementasikan memiliki pengaruh yang signifikan terhadap seberapa baik performa pipeline dalam produksi. Untuk membantu Anda membuat kode pipeline yang berfungsi dengan benar dan efisien, dokumen ini menjelaskan hal-hal berikut:
- Runner pipeline untuk mendukung eksekusi kode di berbagai tahap pengembangan dan deployment.
- Lingkungan deployment yang memungkinkan Anda menjalankan pipeline selama pengembangan, pengujian, praproduksi, dan produksi.
- Template dan kode pipeline open source yang dapat Anda gunakan apa adanya, atau sebagai dasar untuk pipeline baru guna mempercepat pengembangan kode.
- Pendekatan praktik terbaik untuk menguji kode pipeline. Pertama, dokumen ini memberikan ringkasan yang mencakup cakupan dan hubungan berbagai jenis pengujian, seperti pengujian unit, pengujian integrasi, dan pengujian end-to-end. Kedua, setiap jenis pengujian dijelaskan secara mendetail, termasuk metode untuk membuat dan berintegrasi dengan data pengujian, serta pelari pipeline yang akan digunakan untuk setiap pengujian.
Pelaksana pipeline
Selama pengembangan dan pengujian, Anda menggunakan runner Apache Beam yang berbeda untuk menjalankan kode pipeline. Apache Beam SDK menyediakan Direct Runner untuk pengembangan dan pengujian lokal. Alat otomatisasi rilis Anda juga dapat menggunakan Peluncur Langsung untuk pengujian unit dan pengujian integrasi. Misalnya, Anda dapat menggunakan Direct Runner dalam pipeline continuous integration (CI).
Pipeline yang di-deploy ke Dataflow menggunakan Dataflow Runner, yang menjalankan pipeline Anda di lingkungan seperti produksi. Selain itu, Anda dapat menggunakan Runner Dataflow untuk pengujian pengembangan ad hoc dan untuk pengujian pipeline menyeluruh.
Meskipun halaman ini berfokus pada menjalankan pipeline yang dibangun menggunakan Apache Beam Java SDK, Dataflow juga mendukung pipeline Apache Beam yang dikembangkan menggunakan Python dan Go. Apache Beam Java, Python, dan Go SDK tersedia secara umum untuk Dataflow. Developer SQL juga dapat menggunakan Apache Beam SQL untuk membuat pipeline yang menggunakan dialek SQL yang sudah dikenal.
Menyiapkan lingkungan deployment
Untuk memisahkan pengguna, data, kode, dan resource lainnya di berbagai tahap pengembangan, buat lingkungan deployment. Jika memungkinkan, untuk menyediakan lingkungan yang terisolasi untuk berbagai tahap pengembangan pipeline, gunakan Google Cloud project terpisah.
Bagian berikut menjelaskan serangkaian lingkungan deployment yang umum.
Lingkungan lokal
Lingkungan lokal adalah workstation developer. Untuk pengembangan dan pengujian cepat, gunakan Direct Runner untuk menjalankan kode pipeline secara lokal.
Pipeline yang dijalankan secara lokal menggunakan Direct Runner dapat berinteraksi dengan resource Google Cloud jarak jauh, seperti topik Pub/Sub atau tabel BigQuery. Berikan projectGoogle Cloud terpisah kepada setiap developer agar mereka memiliki sandbox untuk pengujian ad hoc dengan layananGoogle Cloud .
Beberapa layanan, seperti Pub/Sub dan Bigtable, menyediakan emulator untuk pengembangan lokal. Google Cloud Anda dapat menggunakan emulator ini dengan Direct Runner untuk mengaktifkan pengembangan dan pengujian lokal end-to-end.
Lingkungan sandbox
Lingkungan sandbox adalah Google Cloud project yang memberi developer akses ke layanan selama pengembangan kode. Google Cloud Developer pipeline dapat membagikan project Google Cloud kepada developer lain, atau menggunakan project individual mereka sendiri. Penggunaan project individual mengurangi kompleksitas perencanaan yang terkait dengan penggunaan resource bersama dan pengelolaan kuota.
Developer menggunakan lingkungan sandbox untuk melakukan eksekusi pipeline ad hoc dengan Dataflow Runner. Lingkungan sandbox berguna untuk men-debug dan menguji kode terhadap runner produksi selama fase pengembangan kode. Misalnya, eksekusi pipeline ad hoc memungkinkan developer melakukan hal berikut:
- Amati efek perubahan kode pada perilaku penskalaan.
- Pahami potensi perbedaan antara perilaku Direct Runner dan Dataflow Runner.
- Pahami cara Dataflow menerapkan pengoptimalan grafik.
Untuk pengujian ad-hoc, developer dapat men-deploy kode dari lingkungan lokal mereka untuk menjalankan Dataflow dalam lingkungan sandbox mereka.
Lingkungan praproduksi
Lingkungan praproduksi ditujukan untuk fase pengembangan yang perlu dijalankan dalam kondisi seperti produksi, seperti pengujian end-to-end. Gunakan project terpisah untuk lingkungan praproduksi dan konfigurasikan agar semirip mungkin dengan produksi. Demikian pula, untuk mengizinkan pengujian menyeluruh dengan skala seperti produksi, buat kuota project untuk Dataflow dan layanan lainnya semirip mungkin dengan lingkungan produksi. Google Cloud
Bergantung pada persyaratan Anda, Anda dapat memisahkan praproduksi lebih lanjut ke dalam beberapa lingkungan. Misalnya, lingkungan kontrol kualitas dapat mendukung pekerjaan analis kualitas untuk menguji tujuan tingkat layanan (SLO) seperti kebenaran, keaktualan, dan performa data dalam berbagai kondisi beban kerja.
Pengujian end-to-end mencakup integrasi dengan sumber dan tujuan data dalam cakupan pengujian. Pertimbangkan cara membuatnya tersedia dalam lingkungan praproduksi. Anda dapat menyimpan data pengujian di lingkungan praproduksi itu sendiri. Misalnya, data pengujian disimpan di bucket Cloud Storage dengan data input Anda. Dalam kasus lain, data pengujian mungkin berasal dari luar lingkungan praproduksi, seperti topik Pub/Sub melalui langganan terpisah yang ada di lingkungan produksi. Untuk pipeline streaming, Anda juga dapat menjalankan pengujian end-to-end menggunakan data yang dihasilkan, misalnya, menggunakan Generator Data Streaming Dataflow untuk meniru karakteristik dan volume data seperti produksi.
Untuk pipeline streaming, gunakan lingkungan praproduksi untuk menguji update pipeline sebelum perubahan dilakukan pada produksi. Penting untuk menguji dan memverifikasi prosedur update untuk pipeline streaming, terutama jika Anda perlu mengoordinasikan beberapa langkah, seperti saat menjalankan pipeline paralel untuk menghindari periode nonaktif.
Lingkungan produksi
Lingkungan produksi adalah project Google Cloud khusus. Continuous delivery menyalin artefak deployment ke lingkungan produksi setelah semua pengujian end-to-end lulus.
Praktik terbaik pengembangan
Lihat praktik terbaik pipeline Dataflow.
Menguji pipeline
Dalam pengembangan software, pengujian unit, pengujian integrasi, dan pengujian end-to-end adalah jenis pengujian software yang umum. Jenis pengujian ini juga berlaku untuk pipeline data.
Apache Beam SDK menyediakan fungsi untuk mengaktifkan pengujian ini. Idealnya, setiap jenis pengujian menargetkan lingkungan deployment yang berbeda. Diagram berikut mengilustrasikan cara penerapan pengujian unit, pengujian integrasi, dan pengujian menyeluruh ke berbagai bagian pipeline dan data Anda.
Diagram ini menunjukkan cakupan berbagai pengujian dan hubungannya dengan
transformasi (subkelas DoFn dan PTransform), pipeline, sumber data, dan
sink data.
Bagian berikut menjelaskan cara berbagai pengujian software formal diterapkan pada pipeline data menggunakan Dataflow. Saat membaca bagian ini, lihat kembali diagram untuk memahami hubungan antara berbagai jenis pengujian.
Sampling data
Untuk mengamati data di setiap langkah pipeline Dataflow, aktifkan sampling data selama pengujian. Hal ini memungkinkan Anda melihat output transformasi, untuk memastikan outputnya benar.
Pengujian unit
Pengujian unit menilai fungsi yang benar dari subkelas DoFn dan
transformasi komposit
(subkelas PTransform) dengan membandingkan output transformasi tersebut dengan
kumpulan input dan output data yang terverifikasi. Biasanya, developer dapat menjalankan pengujian ini di lingkungan lokal. Pengujian juga dapat dijalankan secara otomatis melalui
otomatisasi pengujian unit menggunakan continuous integration (CI) di lingkungan
build.
Direct Runner menjalankan pengujian unit menggunakan subset data pengujian referensi yang lebih kecil yang berfokus pada pengujian logika bisnis transformasi Anda. Data pengujian harus cukup kecil agar muat ke dalam memori lokal di mesin yang menjalankan pengujian.
SDK Apache Beam menyediakan aturan JUnit yang disebut
TestPipeline
untuk pengujian unit transformasi individual (subclass DoFn), transformasi komposit
(subclass PTransform), dan seluruh pipeline. Anda dapat menggunakan TestPipeline di runner pipeline Apache Beam seperti Direct Runner atau Dataflow Runner untuk menerapkan pernyataan pada konten objek PCollection menggunakan PAssert, seperti yang ditunjukkan dalam cuplikan kode berikut dari class pengujian JUnit:
@Rule
public final transient TestPipeline p = TestPipeline.create();
@Test
@Category(NeedsRunner.class)
public void myPipelineTest() throws Exception {
final PCollection<String> pcol = p.apply(...)
PAssert.that(pcol).containsInAnyOrder(...);
p.run();
}
Pengujian unit untuk setiap transformasi
Dengan memfaktorkan kode Anda ke dalam transformasi yang dapat digunakan kembali, misalnya, sebagai class bertingkat statis atau tingkat teratas, Anda dapat membuat pengujian yang ditargetkan untuk berbagai bagian pipeline. Selain manfaat pengujian, transformasi yang dapat digunakan kembali meningkatkan kemudahan pemeliharaan dan penggunaan kembali kode dengan secara alami merangkum logika bisnis pipeline Anda ke dalam bagian komponen. Sebaliknya, pengujian setiap bagian pipeline mungkin sulit dilakukan jika pipeline menggunakan class dalam anonim untuk menerapkan transformasi.
Cuplikan Java berikut menunjukkan penerapan transformasi sebagai class dalam anonim, yang tidak memungkinkan pengujian dengan mudah.
PipelineOptions options = PipelineOptionsFactory.create();
Pipeline p = Pipeline.create(options)
PCollection<Integer> output =
p.apply("Read from text", TextIO.Read.from(...))
.apply("Split words", ParDo.of(new DoFn() {
// Untestable anonymous transform 1
}))
.apply("Generate anagrams", ParDo.of(new DoFn() {
// Untestable anonymous transform 2
}))
.apply("Count words", Count.perElement());
Bandingkan contoh sebelumnya dengan contoh berikut, di mana class dalam anonim
difaktorkan ulang menjadi subclass DoFn konkret bernama. Anda dapat membuat
pengujian unit individual untuk setiap subclass DoFn konkret yang membentuk
pipeline end-to-end.
PipelineOptions options = PipelineOptionsFactory.create();
Pipeline p = Pipeline.create(options)
PCollection<Integer> output =
p.apply("Read from text", TextIO.Read.from(...))
.apply("Split words", ParDo.of(new SplitIntoWordsFn()))
.apply("Generate anagrams", ParDo.of(new GenerateAnagramsFn()))
.apply("Count words", Count.perElement());
Menguji setiap subclass DoFn mirip dengan pengujian unit pipeline
batch yang berisi satu transformasi. Gunakan transformasi Create untuk
membuat objek PCollection dari data pengujian, lalu teruskan ke objek DoFn. Gunakan PAssert untuk menyatakan bahwa konten objek PCollection sudah benar. Contoh kode Java berikut menggunakan class PAssert untuk
memeriksa bentuk output yang benar.
@Rule
public final transient TestPipeline p = TestPipeline.create();
@Test
@Category(NeedsRunner.class)
public void testGenerateAnagramsFn() {
// Create the test input
PCollection<String> words = p.apply(Create.of("friend"));
// Test a single DoFn using the test input
PCollection<String> anagrams =
words.apply("Generate anagrams", ParDo.of(new GenerateAnagramsFn()));
// Assert correct output from
PAssert.that(anagrams).containsInAnyOrder(
"finder", "friend", "redfin", "refind");
p.run();
}
Pengujian integrasi
Pengujian integrasi memverifikasi fungsi yang benar dari seluruh pipeline Anda. Pertimbangkan jenis pengujian integrasi berikut:
- Pengujian integrasi transformasi yang menilai fungsi terintegrasi dari semua transformasi individual yang membentuk pipeline data Anda. Anggap pengujian integrasi transformasi sebagai pengujian unit untuk seluruh pipeline Anda, tidak termasuk integrasi dengan sumber dan tujuan data eksternal. Apache Beam SDK menyediakan metode untuk memasok data pengujian ke pipeline data Anda dan untuk memverifikasi hasil pemrosesan. Runner Langsung digunakan untuk menjalankan pengujian integrasi transformasi.
Pengujian integrasi sistem yang menilai integrasi pipeline data Anda dengan sumber dan tujuan data aktif. Agar pipeline Anda dapat berkomunikasi dengan sistem eksternal, Anda harus mengonfigurasi pengujian dengan kredensial yang sesuai untuk mengakses layanan eksternal. Pipeline streaming berjalan tanpa batas waktu, jadi Anda perlu memutuskan kapan dan bagaimana cara menghentikan pipeline yang sedang berjalan. Dengan menggunakan Direct Runner untuk menjalankan pengujian integrasi sistem, Anda dapat dengan cepat memverifikasi integrasi antara pipeline dan sistem lain tanpa perlu mengirimkan tugas Dataflow dan menunggu hingga selesai.
Merancang pengujian transformasi dan integrasi sistem untuk memberikan deteksi dan masukan cacat yang cepat tanpa memperlambat produktivitas developer. Untuk pengujian yang berjalan lebih lama, seperti pengujian yang berjalan sebagai tugas Dataflow, Anda mungkin ingin menggunakan pengujian end-to-end yang berjalan lebih jarang.
Anggap pipeline data sebagai satu atau beberapa transformasi terkait. Anda
dapat membuat transformasi komposit yang mencakup untuk pipeline dan
menggunakan
TestPipeline
untuk melakukan pengujian integrasi seluruh pipeline. Bergantung pada apakah Anda ingin menguji pipeline dalam mode batch atau streaming, Anda menyediakan data pengujian menggunakan transformasi
Create
atau
TestStream.
Menggunakan data pengujian untuk pengujian integrasi
Di lingkungan produksi, pipeline Anda kemungkinan terintegrasi dengan berbagai sumber dan tujuan data. Namun, untuk pengujian unit dan pengujian integrasi transformasi, fokuslah untuk memverifikasi logika bisnis kode pipeline Anda dengan memberikan input pengujian dan memverifikasi output secara langsung. Selain menyederhanakan pengujian, pendekatan ini memungkinkan Anda mengisolasi masalah khusus pipeline dari masalah yang mungkin disebabkan oleh sumber dan tujuan data.
Menguji pipeline batch
Untuk pipeline batch, gunakan transformasi Create untuk membuat objek PCollection
dari data pengujian input Anda dari koleksi dalam memori standar, seperti
objek List Java. Penggunaan transformasi Create tepat jika data pengujian Anda cukup kecil untuk disertakan dalam kode. Kemudian, Anda dapat menggunakan PAssert pada
objek PCollection output untuk menentukan kebenaran kode pipeline Anda.
Pendekatan ini didukung oleh Direct Runner dan Dataflow Runner.
Cuplikan kode Java berikut menunjukkan pernyataan terhadap objek PCollection
output dari transformasi komposit yang mencakup beberapa atau semua transformasi
individu yang membentuk pipeline (WeatherStatsPipeline). Pendekatannya
mirip dengan pengujian unit transformasi individu dalam pipeline.
private class WeatherStatsPipeline extends
PTransform<PCollection<Integer>, PCollection<WeatherSummary>> {
@Override
public PCollection<WeatherSummary> expand(PCollection<Integer> input) {
// Pipeline transforms …
}
}
@Rule
public final transient TestPipeline p = TestPipeline.create();
@Test
@Category(NeedsRunner.class)
public void testWeatherPipeline() {
// Create test input consisting of temperature readings
PCollection<Integer> tempCelsius =
p.apply(Create.of(24, 22, 20, 22, 21, 21, 20));
// CalculateWeatherStats calculates the min, max, and average temperature
PCollection<WeatherSummary> result =
tempCelsius.apply("Calculate weather statistics", new WeatherStatsPipeline());
// Assert correct output from CalculateWeatherStats
PAssert.thatSingleton(result).isEqualTo(new WeatherSummary.Builder()
.withAverageTemp(21)
.withMaxTemp(24)
.withMinTemp(20)
.build());
p.run();
}
Untuk menguji perilaku windowing, Anda juga dapat menggunakan transformasi Create untuk membuat
elemen dengan stempel waktu, seperti yang ditunjukkan dalam cuplikan kode berikut:
private static final Duration WINDOW_DURATION = Duration.standardMinutes(3);
@Rule
public final transient TestPipeline p = TestPipeline.create();
@Test
@Category(NeedsRunner.class)
public void testWindowedData() {
PCollection<String> input =
p.apply(
Create.timestamped(
TimestampedValue.of("a", new Instant(0L)),
TimestampedValue.of("a", new Instant(0L)),
TimestampedValue.of("b", new Instant(0L)),
TimestampedValue.of("c", new Instant(0L)),
TimestampedValue.of("c", new Instant(0L).plus(WINDOW_DURATION)))
.withCoder(StringUtf8Coder.of()));
PCollection<KV<String, Long>> windowedCount =
input
.apply(Window.into(FixedWindows.of(WINDOW_DURATION)))
.apply(Count.perElement());
PAssert.that(windowedCount)
.containsInAnyOrder(
// Output from first window
KV.of("a", 2L),
KV.of("b", 1L),
KV.of("c", 1L),
// Output from second window
KV.of("c", 1L));
p.run();
}
Menguji pipeline streaming
Pipeline streaming berisi asumsi yang menentukan cara menangani data tanpa batas. Asumsi ini sering kali terkait dengan ketepatan waktu data dalam kondisi dunia nyata, dan oleh karena itu berdampak pada kebenaran, bergantung pada apakah asumsi tersebut terbukti benar atau salah. Pengujian integrasi untuk pipeline streaming idealnya mencakup pengujian yang menyimulasikan sifat non-deterministik dari kedatangan data streaming.
Untuk
mengaktifkan pengujian tersebut,
Apache Beam SDK menyediakan
TestStream
class untuk memodelkan efek pengaturan waktu elemen (data awal, tepat waktu, atau terlambat) pada
hasil pipeline data Anda. Gunakan pengujian ini bersama dengan class
PAssert
untuk memverifikasi hasil yang diharapkan.
TestStream didukung oleh Direct Runner dan
Dataflow Runner. Contoh kode berikut membuat transformasi TestStream:
final Duration WINDOW_DURATION = Duration.standardMinutes(3);
@Rule
public final transient TestPipeline p = TestPipeline.create();
@Test
@Category(NeedsRunner.class)
public void testDroppedLateData() {
TestStream<String> input = TestStream.create(StringUtf8Coder.of())
// Add elements arriving before the watermark
.addElements(
TimestampedValue.of("a", new Instant(0L)),
TimestampedValue.of("a", new Instant(0L)),
TimestampedValue.of("b", new Instant(0L)),
TimestampedValue.of("c", new Instant(0L).plus(Duration.standardMinutes(3))))
// Advance the watermark past the end of the window
.advanceWatermarkTo(new Instant(0L).plus(WINDOW_DURATION).plus(Duration.standardMinutes(1)))
// Add elements which will be dropped due to lateness
.addElements(
TimestampedValue.of("c", new Instant(0L)))
// Advance the watermark to infinity which will close all windows
.advanceWatermarkToInfinity();
PCollection<KV<String, Long>> windowedCount =
p.apply(input)
.apply(Window.into(FixedWindows.of(WINDOW_DURATION)))
.apply(Count.perElement());
PAssert.that(windowedCount)
.containsInAnyOrder(
// Output from first window
KV.of("a", 2L),
KV.of("b", 1L),
KV.of("c", 1L));
p.run();
}
Untuk mengetahui informasi selengkapnya tentang TestStream, lihat
Menguji Pipeline Tanpa Batas di Apache Beam.
Untuk mengetahui informasi selengkapnya tentang cara menggunakan Apache Beam SDK untuk pengujian unit, lihat
dokumentasi Apache Beam.
Menggunakan Google Cloud layanan dalam pengujian integrasi
Direct Runner dapat terintegrasi dengan layanan Google Cloud , sehingga pengujian ad hoc di lingkungan lokal dan pengujian integrasi sistem dapat menggunakan Pub/Sub, BigQuery, dan layanan lainnya sesuai kebutuhan. Saat Anda menggunakan Direct Runner, pipeline Anda menggunakan Kredensial Default Aplikasi (ADC) untuk mendapatkan kredensial. Cara Anda menyiapkan ADC bergantung pada tempat pipeline Anda berjalan. Untuk mengetahui informasi selengkapnya, lihat Menyiapkan Kredensial Default Aplikasi.
Anda harus memberikan izin yang memadai ke akun yang digunakan pipeline untuk semua resource yang diperlukan sebelum menjalankan pipeline. Untuk mengetahui detail selengkapnya, lihat Keamanan dan izin Dataflow.
Untuk pengujian integrasi yang sepenuhnya lokal, Anda dapat menggunakan emulator lokal untuk beberapa layananGoogle Cloud . Emulator lokal tersedia untuk Pub/Sub dan Bigtable.
Untuk pengujian integrasi sistem pipeline streaming, Anda dapat menggunakan metode
setBlockOnRun (ditentukan dalam antarmuka DirectOptions) agar Direct Runner menjalankan pipeline Anda secara asinkron.
Jika tidak, eksekusi pipeline akan memblokir proses induk yang memanggil (misalnya, skrip di pipeline build Anda) hingga pipeline dihentikan secara manual. Jika menjalankan pipeline secara asinkron, Anda dapat menggunakan instance
PipelineResult yang ditampilkan untuk membatalkan eksekusi pipeline, seperti yang ditunjukkan dalam contoh kode berikut:
public interface StreamingIntegrationTestOptions extends
DirectOptions, StreamingOptions, MyOtherPipelineOptions {
...
}
@Rule
public final transient TestPipeline p = TestPipeline.create();
@Test
@Category(NeedsRunner.class)
public void testNonBlockingPipeline() {
StreamingIntegrationTestOptions options =
p.getOptions().as(StreamingIntegrationOptions.class);
options.setBlockOnRun(false); // Set non-blocking pipeline execution
options.setStreaming(true); // Set streaming mode
p.apply(...); // Apply pipeline transformations
PipelineResult result = p.run(); // Run the pipeline
// Generate input, verify output, etc
...
// Later on, cancel the pipeline using the previously returned
result.cancel();
}
Pengujian menyeluruh
Pengujian menyeluruh memverifikasi operasi yang benar dari pipeline menyeluruh Anda dengan menjalankannya di Runner Dataflow dalam kondisi yang sangat menyerupai produksi. Pengujian ini memverifikasi bahwa fungsi logika bisnis berjalan dengan benar menggunakan Runner Dataflow dan menguji apakah pipeline berperforma seperti yang diharapkan di bawah beban seperti produksi. Anda biasanya menjalankan pengujian end-to-end dalam project Google Cloud khusus yang ditetapkan sebagai lingkungan praproduksi.
Untuk menguji pipeline Anda pada skala yang berbeda, gunakan berbagai jenis pengujian end-to-end, misalnya:
- Jalankan pengujian menyeluruh skala kecil menggunakan sebagian kecil (seperti satu persen) dari set data pengujian Anda untuk memvalidasi fungsi pipeline dengan cepat di lingkungan praproduksi.
- Jalankan pengujian menyeluruh skala besar menggunakan set data pengujian lengkap untuk memvalidasi fungsi pipeline dalam volume dan kondisi data yang mirip dengan produksi.
Untuk pipeline streaming, sebaiknya jalankan pipeline pengujian secara paralel dengan pipeline produksi jika keduanya dapat menggunakan data yang sama. Proses ini memungkinkan Anda membandingkan hasil dan perilaku operasional, seperti penskalaan otomatis dan performa.
Pengujian menyeluruh membantu memprediksi seberapa baik pipeline Anda akan memenuhi SLO produksi. Lingkungan praproduksi menguji pipeline Anda dalam kondisi yang mirip dengan produksi. Dalam pengujian menyeluruh, pipeline berjalan menggunakan Runner Dataflow untuk memproses set data referensi lengkap yang cocok atau sangat mirip dengan set data dalam produksi.
Data sintetis untuk pengujian yang secara akurat menyimulasikan data nyata mungkin tidak dapat dibuat. Untuk mengatasi masalah ini, salah satu pendekatan adalah menggunakan ekstrak yang telah dibersihkan dari sumber data produksi untuk membuat set data referensi, yang di dalamnya semua data sensitif dianonimkan melalui transformasi yang sesuai. Sebaiknya gunakan Sensitive Data Protection untuk tujuan ini. Sensitive Data Protection dapat mendeteksi data sensitif dari berbagai jenis konten dan sumber data serta menerapkan berbagai teknik de-identifikasi, termasuk penghapusan, penyamaran, enkripsi yang mempertahankan format, dan pengubahan tanggal.
Perbedaan dalam pengujian menyeluruh untuk pipeline batch dan streaming
Sebelum menjalankan pengujian end-to-end lengkap terhadap set data pengujian yang besar, Anda
mungkin ingin menjalankan pengujian dengan persentase data pengujian yang lebih kecil (seperti
satu persen) dan memverifikasi perilaku yang diharapkan dalam waktu yang lebih singkat. Seperti
pada pengujian integrasi menggunakan Direct Runner, Anda dapat menggunakan PAssert pada
objek PCollection saat menjalankan pipeline menggunakan
Dataflow Runner. Untuk mengetahui informasi selengkapnya tentang PAssert, lihat bagian
Pengujian unit di halaman ini.
Bergantung pada kasus penggunaan Anda, memverifikasi output yang sangat besar dari pengujian end-to-end mungkin tidak praktis, mahal, atau sulit. Dalam hal ini, Anda dapat memverifikasi sampel representatif dari set hasil output. Misalnya, Anda dapat menggunakan BigQuery untuk mengambil sampel dan membandingkan baris output dengan set data referensi hasil yang diharapkan.
Untuk pipeline streaming, mensimulasikan kondisi streaming yang realistis dengan data sintetis mungkin sulit. Cara umum untuk menyediakan data streaming untuk pengujian menyeluruh adalah mengintegrasikan pengujian dengan sumber data produksi. Jika menggunakan Pub/Sub sebagai sumber data, Anda dapat mengaktifkan datastream terpisah untuk pengujian end-to-end melalui langganan tambahan ke topik yang ada. Kemudian, Anda dapat membandingkan hasil dari berbagai pipeline yang menggunakan data yang sama, yang berguna untuk memverifikasi pipeline kandidat terhadap pipeline praproduksi dan produksi lainnya.
Diagram berikut menunjukkan cara metode ini memungkinkan pipeline produksi dan pipeline pengujian berjalan secara paralel di lingkungan deployment yang berbeda.
Dalam diagram, kedua pipeline membaca dari topik Pub/Sub yang sama, tetapi menggunakan langganan terpisah. Penyiapan ini memungkinkan kedua pipeline memproses data yang sama secara independen dan memungkinkan Anda membandingkan hasilnya. Pipeline pengujian menggunakan akun layanan terpisah dari project produksi, dan oleh karena itu tidak menggunakan kuota pelanggan Pub/Sub untuk project produksi.
Tidak seperti pipeline batch, pipeline streaming akan terus berjalan hingga dibatalkan secara eksplisit. Dalam pengujian menyeluruh, Anda harus memutuskan apakah akan membiarkan pipeline berjalan, mungkin hingga pengujian menyeluruh berikutnya dijalankan, atau membatalkan pipeline pada titik yang menunjukkan penyelesaian pengujian sehingga Anda dapat memeriksa hasilnya.
Jenis data pengujian yang Anda gunakan memengaruhi keputusan ini. Misalnya, jika Anda menggunakan kumpulan data pengujian terbatas yang disediakan ke pipeline streaming, Anda dapat membatalkan pipeline saat semua elemen telah selesai diproses. Atau, jika Anda menggunakan sumber data nyata, seperti topik Pub/Sub yang ada dan digunakan dalam produksi, atau jika Anda terus-menerus membuat data pengujian, sebaiknya jalankan pipeline pengujian selama jangka waktu yang lebih lama. Yang terakhir memungkinkan Anda membandingkan perilaku dengan lingkungan produksi, atau bahkan dengan pipeline pengujian lainnya.