Transformation'lar

Özet

• Bir transformation, bir akışı diğerine yeniden şekillendirir: iki alanı bir record'a paketle, bir tuple'ın üçüncü öğesini düşür, bir listeyi düzleştir, bir değer akışını bir yüklem akışına karşı filtrele, bir değeri sayılı bir kez tekrarla, iki akışı bire dahil et.
• Transformation'lar component'lerle aynı tipli sözleşmeye sahiptir (pozisyonel tipli input'lar, pozisyonel tipli output'lar, tipli vertex başına parametreler), böylece backend'in tip çıkarımı tüm grafı düzenleme zamanında hâlâ doğrular.
• Yerleşikler inline edilmiş, yerleşik bir graf işlemidir — container yok, imaj build'i yok, requirements.txt yok, zamanlama yok, ağ atlaması yok. Platform onları graf tesisatı olarak inline çalıştırır.
• Backend, bir connect köprülenebilir ama aynı olmayan iki yuvayı içerdiğinde bir transformation'ı otomatik ekleyebilir. Yalnızca transformation'ları ekler, asla bir component'i ekler ve yanıt, yazarın inenı inceleyebilmesi veya kaldırabilmesi için her örtük eklemeyi listeler.
• transform, kodunuzu çalıştıran tek istisnadır: vertex config'ine Python veya C++ worker kaynağı yapıştırın, platform onu deploy zamanında kendi container'ına derlesin — yayımlanacak component yok, imaj kaynak içeriğine göre önbelleklenir.
• sketch, deploy-engelleyen yer tutucudur: variadic tipli I/O artı serbest biçimli notlar için bir readme parametresi. Çevreleyen graf anında kablolanabilir ve tip-kontrolünden geçirilebilir; her sketch değiştirilene kadar deploy reddeder.

Transformation'lar neden kendi ilkelleridir

Bir transformation, bir akışı diğerine yeniden şekillendirir — iki alanı bir record'a paketle, bir tuple'ın üçüncü öğesini düşür, bir değeri sayılı bir kez tekrarla. Platform onu, yazıp deploy ettiğiniz bir component olarak değil, inline edilmiş yerleşik bir graf işlemi olarak ele alır.

Pipelogic, iki ilgi alanını tek bir çizgi boyunca ayırır. Kod çalıştıran her şey bir container'da çalışır. ML çıkarımı, harici API çağrıları, iş kuralları — işin "input'a dayalı bir şey hesapla" olduğu her şey — izolasyon, yaşam döngüsü ve gözlemlenebilirlik için tam container muamelesi alır. "Aynı veri, farklı şekil" olan her şey yerleşik bir transformation'dır. Container yok, imaj yok; platform işlemi tanır ve inline çalıştırır. transform adımı, bir transformation'ın yayımlamasız ergonomisini korurken bilinçli olarak o çizginin kod tarafında durur: yazılmış kaynak, deploy zamanında kendi container'ına derlenir.

Ayrımın mimari nedeni, saf bir şekil değişikliğinin, bir container'ın var olma amacı olan özelliklerin hiçbirine sahip olmamasıdır. İzole edilecek kod yok, yönetilecek bir süreç yaşam döngüsü yok, açığa çıkarılacak log yok — yalnızca tipli verinin deterministik bir yeniden şekillendirilmesi var. Bu yüzden platform onu inline eder: build edilecek container yok, push edilecek imaj yok, zamanlanacak hiçbir şey yok, vertex'ler arası ağ atlaması yok. Tipleme etkilenmez, çünkü transformation'lar component'lerle aynı tipli sözleşmeyi taşır, böylece graf uçtan uca doğrulanmış kalır.

Zihinsel model — transformation vs component

   Component                          Transformation
   ┌────────────────────────────┐     ┌────────────────────────────┐
   │ input  (positional, typed) │     │ input  (positional, typed) │
   │ output (positional, typed) │     │ output (positional, typed) │
   │ config (typed)             │     │ config (typed)             │
   │                            │     │                            │
   │ runs in its own container  │     │ runs inline                │
   │ has a container lifecycle  │     │ built-in graph operation   │
   └────────────────────────────┘     └────────────────────────────┘

Sözleşmenin şekli aynıdır — aynı pozisyonel tipli yuvalar, aynı tipli parametreler, bir backend grafında bir vertex olarak görünmenin aynı yolu. Fark operasyoneldir: bir component deploy zamanında bir container olarak materyalize edilir, bir transformation runtime'da komşu component'leri arasına dokunur. Grafın bakış açısından her ikisi de vertex'tir; runtime'ın bakış açısından yalnızca component'lerin container yaşam döngüleri vardır.

Her iki türden vertex'i ekleyen ve kablolayan fiiller için Backend işlemleri sayfasına bakın.

Bir transformation ne zaman doğru araçtır

Sonraki adım "bundan bir şey hesapla" yerine "bu tipli akışı yeniden şekillendir" olduğunda bu çerçeveyi kullanın.

Bir transformation'ın işlediği en yaygın şekiller, kabaca sıklık sırasına göre:

• Pack ve unpack — pack_record birkaç tipli akışı tek bir record-tipli akışa birleştirir; unpack_record tersini yapar. Aynısı tuple'lar (pack_tuple / unpack_tuple), adlandırılmış tipler (pack_named / unpack_named) ve toplam tipler (pack_union / unpack_union) için. Yukarı-akış birkaç parça ürettiğinde ve aşağı-akış bunları tek bir bileşik olarak istediğinde (veya tersi) doğru ilkel.
• Kardinaliteyi yeniden şekillendirme — flatten bir liste akışını bir öğe akışına dönüştürür; lift_unroll bir liste-tipli akışı bir boyut akışı artı bir öğe akışına böler (ve lift_reroll tersidir, öğeleri verilen boyutlardaki listelere geri toplar); list_length gelen bir listenin sayısını üretir; repeat bir input'ta bir sayı n ve bir başkasında bir değer okur, o değeri tık başına n kez yayar. "Bir tane var, birçok lazım" veya "birçok var, bir tane lazım" için doğru ilkeller.
• Akışları birleştirme — join, iki akışın anahtarla eşleştirilmiş bir iç birleşimidir, ikisi de aynı anahtarı ürettiğinde bir tuple yayar; merge_streams birkaç aynı tipli akışı varış sırasına göre bire birleştirir; select_stream sayısal bir indeksle seçilen input'u geçirir; shuffle anahtar-değer çiftlerini anahtara göre gruplar, her anahtarı onu paylaşan değerlerin listesiyle yayar. Fan-in kalıpları için doğru ilkeller.
• Tip dönüşümü — convert_value bir atomik değeri tık-için-tık başka bir atomik tipe dönüştürür; constant grafa sabit yapılandırılmış bir değer enjekte eder. Şekiller eşleştiğinde ama belirli tip eşleşmediğinde doğru ilkeller.
• Akış kontrolü — filter, bir değer akışını bir Bool yüklem akışıyla eşleştirir ve yüklem tıkı false olan değerleri düşürür; delay_by_one önce yapılandırılmış bir başlangıç değeri yayar, sonra her tıkta bir önceki tıkta görülen değeri yeniden yayar. Akışları inceltmek, kapılamak veya hizalamak için doğru ilkeller.
• Yazılmış kod — transform, vertex config'ine yapıştırdığınız kaynağı çalıştırır, deploy zamanında kendi container'ına derlenir; aşağıya bakın.
• Yer tutucu — sketch, henüz inşa edilmemiş bir adımın yerine geçer; aşağıya bakın.

Yukarıdaki gruplama bir okuma yardımıdır, sorgulanabilir bir kategori değil. Canlı küme, diğer herhangi bir katalog girdisi gibi ppl component list --query=<name> ile keşfedilebilir.

Otomatik ekleme, connect fiilini daha akıllı yapar

ppl backend connect ilk kez başarılı olduğunda ve yanıt eklemediğiniz vertex'lerden bahsettiğinde bu çerçeveyi kullanın.

ppl backend connect, şekilleri zorlamayla-uyumlu ama aynı olmayan bir yukarı-akış yuvası ve bir aşağı-akış yuvasıyla çağrıldığında — (Double,) bekleyen bir yuvaya bir Double, liste akışı bekleyen bir yuvaya bir değer akışı — platform otomatik olarak köprüleyen bir transformation ekleyebilir. Yanıt, her örtük eklemeyi listeleyen bir created_vertices ve created_connections alanı içerir.

Platform, tip-kontrolünden geçiremeyeceği bağlantıları icat etmez ve yalnızca transformation'ları ekler, asla bir component'i. Bir connect'ten sonra yanıtı incelemek, neyin eklendiğini görmenin yoludur; istenmeyen bir otomatik eklemeyi kaldırmak, normal ppl backend disconnect artı ppl backend delete-vertex çiftidir.

Bunun sağladığı disiplin, backend yazarlarının grafları kavramsal düzeyde kablolayabilmesidir — "A'nın output 0'ı B'nin input 0'ına gider" — her şekil adaptörünü elle yazmadan. Platform şablonu halleder; yazar tasarımı halleder.

transform — bir graf adımı olarak kodunuz, component gerekmez

Bunu, bir adım gerçek mesaj başına mantık gerektirdiğinde ama mantık yayımlanmış bir component'i hak etmeyecek kadar küçük, yerel veya deneysel olduğunda kullanın.

transform, kaynak kodun kendisini yapılandırma olarak alır: source (worker gövdesi, standart worker SDK), language (py veya cpp), build_system (yayımlanmış component'lerin karşı derlendiği build şablonlarının aynısı) ve requirements (birebir sabitlenmiş pip satırları, yalnızca Python). Deploy zamanında platform o kaynağı deployment node'unda bir container imajına derler ve onu normal bir vertex olarak çalıştırır — inline edilmeyen tek transformation. Hiçbir şey yayımlanmaz ve hiçbir şey bir registry'ye push edilmez; kod, backend'in kendi işlem günlüğüyle sürümlenen backend grafının bir parçasıdır.

Derlenen imaj, yapıştırılan kodun tam içeriği, dil, build şablonu ve bağımlılık listesi birlikte tarafından tanımlanır. Aynı olan bir adım imajını deploy'lar arasında yeniden kullanır; yalnızca bunlardan birindeki gerçek bir değişiklik onu yeniden derler. Variadic port'ları çevreleyen kablolama ve açık kısıtlarla sabitlenir, böylece graf yazılmış kodun etrafında tamamen tip-kontrolünden geçirilmiş kalır.

Ayrıca yorumlanan expression component'leriyle başlayan prototipleme döngüsünü kapatır: evaluate_expression veya visualize_expression içinde bir skor ya da bindirme taslağı çizin, sonra oturmuş mantığı aynı graf konumunda derlenmiş bir transform adımına çökertin.

sketch — henüz inşa edilmemiş şey için tipli iskele

Çevreleyen grafın belirli bir adım var olmadan önce kablolanması gerektiğinde bunu kullanın.

sketch yer tutucu transformation'dır. Input'ları ve output'ları variadic'tir (iki taraf da diğerini kısıtlamaz) ve tek parametresi, yazarın gelecekteki uygulayıcı için bırakmak istediği notlar için serbest biçimli bir readme: String'tir. Graf, etrafında tip-kontrolünden geçirilebilir kalır — platform sketch'e giren ve çıkan kablolamaları kabul eder — böylece geri kalan iş, eksik parçanın inşa edilmesini beklemeden ilerleyebilir.

Tasarımı dürüst kılan kısıt şudur: herhangi bir sketch içeren bir backend deploy'da reddedilir. Platform, yer tutucu vertex'lere sahip bir grafı çalıştırmaz; sketch, deployment başarılı olabilmeden önce gerçek bir component veya transformation ile değiştirilmelidir. O reddetme, yük taşıyan güvenlik özelliğidir — sketch'ler, yazarların önceden besteleme yapmasına, sessizce hiçbir şey yapmayan bir deployment'a asla yol açmadan izin verir.

Vertex başına yapılandırma aynı şekilde uygulanır

Bir transformation bir parametre aldığında, onu component'lerle aynı şekilde ppl backend change-parameter ile ayarlarsınız: constant enjekte edilecek değeri alır; delay_by_one ilk gecikmeli tıktan önce yayılan başlangıç değerini alır. Birçok transformation hiç parametre almaz — pack_record alan adlarını bir parametreden değil, aşağı-akış record tipinden türetir ve repeat'in sayısı ile filter'ın yüklemi gibi operandlar yapılandırma olarak değil, input akışlarına gelir. Parametre sözleşmesi, varsa, transformation'ın manifest'inin bir parçasıdır, change-parameter çağrısında tip-kontrolünden geçirilir ve düzenleme zamanında grafın geri kalanına karşı doğrulanır.

Bu tekdüzelik önemlidir çünkü zihinsel modeli küçük tutar. Backend yazarlarının "transformation yapılandırma vs component yapılandırma" için ikinci bir sözcük dağarcığına ihtiyacı yoktur — aynı sözcük dağarcığı, aynı fiiller, aynı işlem günlüğü girdileridir.

Bu nereye oturur

Transformation'lar, platformun saf şekil değişiklikleri için ilkelidir. Tip sistemini bozulmadan tutarken, buna ihtiyaç duymayan işlemlerden container yaşam döngüsünü kaldırırlar — izole edilecek veya gözlemlenecek kod yoktur, bu yüzden platform onları vertex başına bir container materyalize etmek yerine graf tesisatı olarak inline eder. Bedel bir ekstra kavramdır — component olmayan bir tür vertex — ve kazanç, şekil adaptörlerinin deploy edilmiş birimler yerine inline, yerleşik graf işlemleri olarak kalmasıdır.

Onları iyi kullanan disiplin, iş "aynı veri, farklı şekil" olduğunda önce bir transformation'a başvurmak ve yalnızca iş gerçek hesaplama olduğunda bir component'e başvurmaktır. Katalog ayrımı kolaylaştırır: ppl component list --query=<keyword> zaten ihtiyaç duyduğunuz şeyi yapan bir transformation gösteriyorsa, doğru yanıt, aynı iş etrafında bir component yazmak değil, onu kablolamaktır.

İlgili

• Tipler — transformation'ların aralarında köprü kurduğu şekil dili.
• Component'ler — container'laştırılmış karşılığı.
• Backend işlemleri — vertex'leri ekleyen ve kablolayan fiiller.
• Backend'ler — transformation'ların component'lerle birleştirildiği yer.
• Solution'lar — dört ilkelin nasıl sevk edilmiş bir ürüne birleştiği.