Mengapa ini ada dan bagaimana penggunaannya dalam Komponen Beam Pipeline

ML Metadata (MLMD) adalah perpustakaan untuk merekam dan mengambil metadata yang terkait dengan alur kerja pengembang ML dan ilmuwan data.

"TensorFlow Extended (TFX) adalah platform menyeluruh untuk menerapkan pipeline ML produksi"

Versi Metadata ML saat ini pada saat artikel ini diterbitkan adalah v0.22(tfx juga v0.22). API ini cukup matang untuk memungkinkan penggunaan dan penerapan umum di cloud publik. Tensorflow Extended menggunakan ini secara ekstensif untuk komunikasi komponen, pelacakan garis keturunan, dan tugas lainnya.

Kita akan menjalankan pipeline yang sangat sederhana yang hanya akan menghasilkan statistik dan skema untuk contoh csv dari kumpulan data Chicago Taxi Trips yang terkenal. Ini adalah file kecil ~10MB dan pipeline dapat berjalan secara lokal.

Jalankan sekali dan buka file metadata_store.db untuk diperiksa.

Metadata ML menyimpan informasi mengenai 3 hal:

  • Metadata tentang artefak yang dihasilkan
  • Metadata tentang eksekusi komponen ini — langkah-langkah
  • Metadata tentang pipeline dan informasi silsilah terkait

Komponen TFX Apache Beam Pipeline tidak meneruskan seluruh artefak biner (untuk diproses oleh ParDo dengan beberapa IO) oleh node berikutnya. Sebaliknya, URI artefak diedarkan. Artefak biasanya disimpan di semacam sistem file cloud seperti ember penyimpanan cloud.

Bahkan TFRecord tf.Examplefile yang disimpan dianggap sebagai artefak tingkat menengah. File-file tersebut di-gzip untuk menghemat ruang.

> SELECT * FROM `Artifact`;

Anda dapat melihat bahwa semua direktori induk artefak yang dihasilkan ini disimpan, bersama dengan nomor (lebih lanjut tentang nomornya nanti), waktu pembuatan dan pembaruan.

Dalam kasus CsvExampleGen/examples/1 , kami mendapat 2 subdirektori, train dan eval , disimpan sebagai artefak yang sama. Bagian /examples dari jalur ini adalah nama artefak yang example_gen hasilkan (lihat kode saluran pipa), yang diambil statistics_gen sebagai masukan.

Nilai NULL mungkin sedang dalam proses karena penyimpanan dalam versi v0.xx. Anda dapat melihat di deklarasi buffer protokol kode sumbern bisa berupa UNKNOWN — PENDING — LIVE — MARKED_FOR_DELETION — DELETED dan namanya juga, selain type_id .

Tabel Types setara dengan type_id seperti yang diharapkan:

Artefak juga mendukung peta properti. Hal ini dirangkum dalam Tabel ArtifactProperty. (Misalnya, checksum untuk file TFRecord yang disimpan. Ini digunakan melalui TFX untuk menyimpan langkah-langkah perantara dalam cache.)

  • Konteksberisi beberapa Artefak, Eksekusi, dan Peristiwa
  • Sebuah Peristiwa berisi Artefak dan Eksekusi
  • Eksekusi biasanya merupakan langkah pipeline yang berdiri sendiri

Untuk pelacakan eksekusi artefak dan kemampuan pelacakan silsilah (misalnya, menentukan model atau statistik mana yang sesuai dengan kumpulan data atau alur yang dijalankan), kita harus menangani Peristiwa, Konteks, dan Eksekusi.

  • Peristiwa mengaitkan artifact_ids dengan execution_ids
  • Eksekusihanya melacak type_ids dan stempel waktu
  • Konteksberkorelasi type_ids dengan proses Pipeline dan informasi stempel waktu

Tabel EksekusiProperti dan KonteksProperti berisi data tambahan dalam bentuk kunci — nilai.

  • ExecutionPropertiesberisi konfigurasi input dan output yang diteruskan ke setiap komponen, bersama dengan direktori pipeline dan root langkah, serta lokasi artefak IO.
  • ContextPropertieskaitkan context_ids dengan nama dan stempel waktu komponen saluran

Artefak yang dihasilkan hadir dalam format yang kurang lebih sama untuk langkah-langkah lain dari saluran yang lebih besar, seperti validasi model dan pemberkatan.

Mengakses Data

Ada banyak sekali informasi yang tersedia, hanya untuk pipeline 3 langkah sederhana yang berjalan secara lokal. Pipeline ini dapat berjalan di cloud pada runner Dataflow, misalnya, dengan perubahan konfigurasi yang minimal.

Dalam skenario ini, akan jauh lebih mudah untuk menggunakan data yang disimpan dalam database, daripada menjelajahi bucket penyimpanan cloud dan VM di server farm.

Mulai saat ini, Anda dapat terhubung ke penyimpanan Metadata ML baik dari koneksi SQL langsung, atau dengan gRPC (melalui stub atau panggilan lama biasa). Lalu, tinggal memilih jenis data yang ingin Anda periksa secara manual. Ini bisa berupa skema atau protobuf statistik, misalnya.

Biasanya, Anda hanya perlu mengakses pengidentifikasi sumber daya. Anda seharusnya dapat mengaksesnya hanya melalui URI jika Anda berada di lingkungan yang sama (mis. notebook di dalam VM Project GCP).

Contoh Kasus Penggunaan

Asumsikan Anda menjalankan alur dalam interval tertentu (atau pemicuan berbasis peristiwa) dan, terkadang, Anda ingin melihat statistik data dari alur terbaru yang dijalankan dibandingkan dengan proses sebelumnya.

  • Anda memerlukan artefak StatisticsGen/statistics dari 2 alur yang berbeda (ini adalah jenis ExampleStatistics, dengan type_id 8). Ini dapat ditemukan di tabel Artifact.
  • Anda juga memerlukan akses ke artefak dari alur yang berjalan dengan benar. Tabel Attribution mengasosiasikan context_id dengan artifact_id . Satu-satunya hal yang hilang adalah menentukan 2 context_id yang Anda perlukan untuk membuat kueri pemilihan sederhana.
  • Tabel Context juga berisi informasi stempel waktu. Misalnya, baris Pipeline .2020–07–14T23:45:00.508181.StatisticsGen mendapat context_id 5.

Id Konteks 5, sesuai dengan Id Artefak 3 dari tabel Atribusi. Artifact Id 3 memang merupakan Artefak Statistik yang kita perlukan.

Untungnya, pipeline kubeflow sudah melakukan visualisasi ini secara otomatis

Kesimpulan

Anda sekarang seharusnya memiliki pemahaman yang kuat tentang apa sebenarnya isi penyimpanan Metadata ML dan mengapa itu merupakan komponen yang berguna dalam ekosistem TFX.

Terima kasih telah membaca sampai akhir!

Artefak Khusus

Artefak khusus didukung. Kami tidak akan membahasnya lebih dalam di sini, karena ini berfokus pada ekosistem TFX. Untuk informasi lebih lanjut lihat di sini.