
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Įvadas: Tylūs schemos naikintojai Paskirstytoje architektūroje dažniausia duomenų perdavimo proceso trikdžių priežastis nėra serverio gedimas, o pasikeitusi duomenų struktūra. Kai „microservice“ komanda pakeičia JSON laukelį arba pakeičia duomenų tipą Java aplikacijoje, vėlesnė duomenų saugykla (data lake) dažniausiai sugenda tyliai. Kaip skaitmeninės sveikatos architektas, mačiau, kad tradicinio „stebėjimo“ (tikrinimo, ar darbas baigtas) nebepakanka. Mums reikia  . Duomenų sutartis yra oficialus susitarimas tarp paslaugos gamintojo ir duomenų vartotojo, užtikrinantis, kad schemos neatitikimai būtų aptikti prieš pasiekiant produkcijos aplinką. duomenų sutarčių Sutartimis pagrįstos sistemos architektūra Tvirta sutarties sistema perkelia duomenų validavimą iš „imtuvo“ (kur duomenys galiausiai atsiduria) į „šaltinį“ (iš kur duomenys atsiranda). Kai duomenys pasiekia „Snowflake“ arba „Databricks“, jie jau turėtų būti patvirtinti pagal versijuotą schemą. 1 žingsnis: Sutarties apibrėžimas (YAML/Protobuf) Užuot pasikliaujant išvestomis schemomis, sutartį apibrėžiame nuo kalbos nepriklausomu formatu, tokiu kaip YAML ar „Protocol Buffers“. Ši sutartis nustato ne tik duomenų tipą, bet ir verslo apribojimus (pvz., nario ID turi būti 12 simbolių). # customer_contract_v1.yaml
dataset: customer_registration
owner: identity_team
schema:
  - column: user_id
    type: string
    constraints:
      not_null: true
      primary_key: true
  - column: email_address
    type: string
    constraints:
      pattern: "^[a-zA-Z0-9+_.-]+@[a-zA-Z0-9.-]+$"
 2 žingsnis: Taikymas Java gamintojo lygiu Java aplikacijoje mes galime naudoti „Spring Boot“ ir „Bean Validation“ (JSR 380), kad sutartis būtų taikoma duomenims, kuriuos API gauna. Tai užtikrina, kad „šiukšlių“ duomenys net nepatektų į jūsų „Kafka“ temas. import javax.validation.constraints.*;
 
public class UserRegistrationDTO {
 
    @NotNull(message = "User ID cannot be null")
    private String userId;
 
    @Email(message = "Invalid email format")
    @NotBlank
    private String emailAddress;
 
    // Standard Getters and Setters
}
 Naudodami „@Valid“ savo valdiklyje (Controller), paversite savo Java aplikaciją pirmąja duomenų kokybės gynybos linija. 3 žingsnis: Schemos registras ir evoliucija Kai „microservice“ skelbia duomenis žinučių magistralėje (pvz., „Kafka“), žinutė turėtų būti serializuota naudojant   arba  . Schemos saugomos  . Jei programuotojas bando atlikti laužiančius pakeitimus (pvz., ištrinti privalomą laukelį), „Schema Registry“ atmestų gaminimo užklausą, jei įgalinta „Backward Compatibility“ (suderinamumas atgal). „Avro“ „Protobuf“ „Confluent Schema Registry“ 4 žingsnis: Vėlesnis validavimas naudojant „Python“ ir „Great Expectations“ Kai duomenys patenka į jūsų „Databricks Lakehouse“ „Bronzos“ sluoksnį, mes naudojame metaduomenimis valdomą metodą (panašų į jūsų ankstesnius darbus), kad patvirtintume paketą pagal sutartį. 
import great_expectations as gx
 
def validate_batch_against_contract(df, contract_path):
    context = gx.get_context()
    # Programmatically build expectations from the YAML contract
    suite = context.create_expectation_suite("contract_suite")
    
    # Logic to map YAML 'not_null' to GE 'expect_column_values_to_not_be_null'
    for field in contract['schema']:
        if field['constraints']['not_null']:
            suite.add_expectation(
                gx.core.ExpectationConfiguration(
                    expectation_type="expect_column_values_to_not_be_null",
                    kwargs={"column": field['column']}
                )
            )
    
    # Execute validation
    return context.run_checkpoint(batch_request=df, expectation_suite=suite)
 5 žingsnis: Išplėstinė atminties profiliavimo analizė validavimo varikliams Sudėtingų reguliariųjų išraiškų (regex) validavimas milijonams eilutės „Spark“ gali sukelti „GC Pressure“ (surinkimo šiukšles). Kai JVM daugiau laiko praleidžia valydama eilutes, nei jas apdorodama, jūsų validavimo darbai sustos.  Naudokite   sutarčių metaduomenims. Vieną kartą transliuodami schemos sutartį į visus darbuotojų mazgus, išvengsite serializuotų objektų perdavimo per tinklą kiekvienam užduočiai. Architekto rekomendacija: transliuojamus kintamuosius (Broadcast Variables) 
# Broadcast the contract to all Spark Executors
broadcast_contract = sc.broadcast(load_contract_yaml())
 
def process_partition(iterator):
    contract = broadcast_contract.value
    # Apply logic...
 6 žingsnis: Automatinis „Grandinių pertraukiklis“ Gamybinėje sistemoje, jei duomenų sutartis pažeidžiama, duomenų perdavimo procesas turėtų ne tik registruoti klaidą, bet ir  . atidaryti grandinę Naudodami   (panašų į „Resilience4j“ logiką), galime automatiškai sustabdyti duomenų priėmimą, jei „Duomenų klaidų norma“ viršija 5%. Tai neleidžia užteršti jūsų „Aukso“ sluoksnio lentelių neteisingais duomenimis ir generuoti neteisingas finansines ar klinikines ataskaitas. „Grandinių pertraukiklio“ modelį Palyginimas: Rankinis stebėjimas vs. Duomenų sutartys 
 
 
 
 
 
 
 
 
 
 
 Funkcija 
 Senas stebėjimas 
 Duomenų sutarčių inžinerija 
 
 
 
 
 Aptikimas 
 Reaktyvus (po gedimo) 
 Proaktyvus (prieš priėmimą) 
 
 
 
 
 Atsakomybė 
 Tik duomenų komanda 
 Gamintojas + Vartotojas bendrai 
 
 
 
 
 Schemos evoliucija 
 Rankinis / Laužiantis 
 Versijuotas / Suderinamas 
 
 
 
 
 Duomenų kokybė 
 Vėlesnis valymas 
 Garantuojama šaltinyje Galutinė santrauka: Šiuolaikinio duomenų architekto manifestas Perėjimas nuo monolitinių senų sistemų prie paskirstyto, debesų pagrindu veikiančio kraštovaizdžio yra ne tik įrankių pakeitimas – tai esminis   poslinkis. Kaip tyrinėjome šioje techninių straipsnių serijoje, kuriant gamybos lygio duomenų ekosistemą reikia daugiasluoksnio stabilumo, našumo ir valdymo požiūrio. patikimumo inžinerijos Pagrindiniai architektūros ramstukai: 
 
 
 
 
 
 
  Atsisakydami sinchroninių, blokuojančių iškvietimų ir naudodami   bei  , kuriame „pagal projektą“ atsparius gedimams „microservice“. Naudodami   užtikriname, kad mūsų Java aplikacijos išliktų lengvos ir itin mastelio keičiamos konteinerizuotose aplinkose, tokiose kaip „Kubernetes“. Atsparus ryšys (Java sluoksnis): „CompletableFuture“ „Resilience4j“ „GraalVM“ 
 
  „Duomenų sandėlio“ (Data Warehouse) mirtis reiškia ne saugojimo pabaigą, o centralizuotų kliūčių pabaigą. Pereinant prie   su  , domenų komandoms leidžiama atsakyti už savo kokybės logiką, o platformos komanda teikia mastelio keičiamą infrastruktūrą („Databricks“/„Snowflake“). Atsietas valdymas (Data Mesh): „Data Mesh“ metaduomenimis valdomais sistemų komponentais 
 
  Vyresniojo inžinieriaus bruožas yra „Saugi pakartotinė užklausa“. Kuriant sistemą, kuri užtikrina   (per atominius mainus ir deterministinį maišavimą), mes užtikriname, kad sistemos gedimai nesukeltų duomenų sugadinimo. Be to, įgyvendindami  , mes išsprendžiame „schemos dreifo“ problemą šaltinyje, paversdami tylius gedimus proaktyviais perspėjimais. Operacinis vientisumas (Idempotencija ir sutartys): idempotenciją duomenų sutartis 
 
  Vien logika nesikeičia; fizika. Valdant pagrindinį failų sluoksnį per  , išvengiama „mažų failų“ problemos, užtikrinant, kad „Lakehouse“ išliktų našus ir ekonomiškas net didėjant duomenų apimtims iki petabaitų. Fizinis optimizavimas (Lakehouse našumas): kompaktavimą, Z-tvarkymą ir valymą

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Read My Stories

Šis garso įrašas sukurtas originalia istorijos kalba!

Be beyond Monitoring: Įgyvendinant duomenų sutartis atsparioms mikropaslaugoms

About Author

KOMENTARAI

PABAIGTI ŽYMES

ŠIS STRAIPSNIS BUVO PRISTATYMAS

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps