Arhitectura data lake-ului militar: tipare de proiectare pentru analiză multidomeniu clasificată

Un data lake militar și un data lake comercial împărtășesc aceeași idee de bază (stocarea de obiecte ieftină și scalabilă drept fundament pentru analiză), dar diverg puternic în privința fiecărei constrângeri care contează din punct de vedere operațional. Impunerea clasificării, accesul care ține cont de compartimente, funcționarea în regim air-gap și SLA-urile de interogare critice pentru misiune nu sunt funcționalități suplimentare pentru o implementare din domeniul apărării; sunt cerințe structurale care modelează fiecare strat al arhitecturii, de la denumirea bucket-urilor de stocare până la configurarea motorului de interogare. O arhitectură care le tratează ca pe un aspect secundar, adăugat ulterior — prin simpla adăugare a unei etichete de clasificare la tiparele existente ale data lake-urilor comerciale — va pica, în cel mai bun caz, auditurile de securitate și va genera, în cel mai rău caz, încălcări ale conformității.

Acest articol parcurge proiectarea completă a unui data lake militar de producție: stratul de stocare, pipeline-ul de ingestie din surse C2, ISR și de logistică, gestionarea metadatelor catalogului de date militar, controlul compartimentat al accesului și tiparele sarcinilor de analiză. Fiecare secțiune abordează deciziile de proiectare care diferențiază un sistem implementabil în condiții operaționale de o arhitectură de referință care pare corectă într-un whitepaper, dar cedează la contactul cu date clasificate reale.

Ce trebuie să facă un data lake militar și ce nu face unul comercial — impunerea clasificării, accesul care ține cont de compartimente, funcționarea în regim air-gap, SLA-uri critice pentru misiune

Cea mai fundamentală deosebire dintre un data lake comercial și unul militar nu este o alegere tehnologică — este un model de amenințare. Un data lake comercial protejează împotriva atacatorilor externi și a exfiltrării datelor de către persoane din interior. Un data lake militar trebuie să protejeze și împotriva unui tip de eșec mai subtil: un utilizator autorizat care accesează date pentru care deține autorizare de securitate, dar pe care nu are dreptul să le vadă în contextul curent. Un analist de semnale cu autorizare de securitate Top Secret nu trebuie să poată interoga un set de date HUMINT compartimentat decât dacă deține codul de compartiment specific. Un ofițer de logistică autorizat pentru nivelul Secret nu trebuie să poată vedea informații ISR chiar dacă și acestea sunt clasificate Secret. Nivelul de clasificare și apartenența la un compartiment sunt dimensiuni de acces ortogonale, iar ambele trebuie impuse la fiecare strat al sistemului.

Funcționarea în regim air-gap elimină orice dependență de servicii gestionate în cloud. Nu există Kafka gestionat, catalog găzduit în cloud sau serviciu de gestionare a cheilor operat de un furnizor. Fiecare componentă — stocarea de obiecte, brokerul de streaming, motorul de interogare, catalogul de metadate, hardware-ul de gestionare a cheilor — trebuie să poată fi implementată local (on-premises), din pachete care pot fi transferate în mediul izolat fizic (air-gapped) prin suporturi aprobate. Această constrângere exclude arhitecturile care presupun puncte de actualizare accesibile din internet, servere de validare a licențelor sau servicii de colectare a telemetriei. De asemenea, înseamnă că echipa de operațiuni își asumă întregul ciclu de actualizare și aplicare de patch-uri pentru fiecare componentă, fără o cale gestionată de furnizor.

SLA-urile critice pentru misiune se aplică atât prospețimii datelor, cât și latenței interogărilor. Un analist de fuziune ISR care interoghează cea mai recentă ingestie de la senzori nu poate accepta o fereastră de mai multe ore pentru un job batch Spark. Un ofițer de logistică ce construiește un model de reaprovizionare are nevoie de rezultatele interogărilor în minute, nu în zile. Aceste cerințe impun alegeri arhitecturale pe care data lake-urile comerciale le amână adesea: motoare de interogare mereu active, care au deja planurile de interogare compilate pe baza unor statistici de catalog actualizate, stocare pe nivelul hot pentru datele recente și ingestie în flux continuu (streaming), care face datele noi interogabile la câteva secunde după primire — nu în următoarea fereastră batch. Pentru mai multe informații de fundal despre tiparele fundamentale folosite în straturile descrise aici, consultați ghidul nostru despre tiparele de integrare a datelor în domeniul apărării.

O a patra cerință, pe care data lake-urile comerciale o acoperă la rândul lor insuficient, este integrarea datelor multidomeniu — îmbinarea datelor de track C2, a datelor de la senzorii ISR, a înregistrărilor logistice și a straturilor geospațiale de referință într-o singură interogare, peste granițele de clasificare (cu controale adecvate). Într-un data lake comercial, join-urile între domenii sunt o comoditate de inginerie a datelor. Într-un data lake militar, ele reprezintă principalul caz de utilizare analitică — și trebuie să fie posibile fără a relaxa impunerea clasificării. Motorul de interogare trebuie să poată îmbina tabele din domenii de date diferite, aplicând transparent filtre de clasificare per tabel fiecărei părți a join-ului.

Proiectarea stratului de stocare — stocare de obiecte (MinIO/Ceph pentru implementări on-premises), stocare pe niveluri (hot/warm/cold), denumirea și partiționarea obiectelor pentru domeniile de date militare

Stocarea de obiecte este fundamentul oricărei arhitecturi moderne de data lake, iar pentru implementările militare izolate fizic (air-gapped) alegerea se restrânge la două platforme verificate în producție: MinIO și Ceph. MinIO implementează integral API-ul AWS S3, cu criptare AES-256 în repaus, politici IAM la nivel de bucket și versionare și blocare la nivel de obiect — toate fără nicio dependență de cloud. Performanța sa pe hardware NVMe modern depășește stocarea de obiecte comercială din cloud pentru sarcinile de scriere secvențială, care reprezintă tiparul dominant la ingestia datelor de la senzori. Ceph oferă stocare de obiecte, de blocuri și de fișiere dintr-un singur cluster, prin RADOS Gateway, ceea ce îl face potrivit pentru mediile în care aceeași infrastructură fizică de stocare trebuie să deservească atât sarcina de obiecte a data lake-ului, cât și volumele de blocuri pentru mașinile virtuale. Pentru o implementare dedicată de data lake, MinIO este mai simplu din punct de vedere operațional; Ceph este alegerea corectă atunci când clusterul de stocare trebuie să deservească și interfețe de blocuri și de fișiere.

Izolarea clasificării se implementează la nivel de bucket, nu la nivel de obiect. Fiecare nivel de clasificare are propriul spațiu de nume pentru bucket-uri:

Structura de zone — raw, structured, curated — partiționează datele în funcție de etapa de procesare, în cadrul fiecărui nivel de clasificare. Zona raw conține datele exact așa cum au fost primite de la sistemele-sursă, în format nativ (CoT XML, NIEM XML, fluxuri binare de la senzori, exporturi CSV de logistică). Nimic din zona raw nu este modificat după scriere; ea reprezintă o evidență de audit imuabilă a ceea ce a fost primit. Zona structured conține datele după normalizarea în Parquet cu formatul de tabel Delta Lake — schemă impusă, câmpuri mapate pe denumiri canonice, metadate de proveniență adăugate. Zona curated conține agregate pregătite pentru analiști, vizualizări multidomeniu pre-îmbinate și tabele de sinteză care permit interogări interactive rapide, fără a obliga fiecare analist să execute independent aceeași logică de join.

Proiectarea cheilor de obiect pentru zona structured codifică toate dimensiunile de partiționare necesare pentru un query pushdown eficient:

Stocarea pe niveluri este gestionată prin politicile de ciclu de viață ale MinIO. Nivelul hot utilizează noduri cu stocare NVMe și păstrează datele din ultimele 30 de zile — suficient de recente pentru ca analiștii să le interogheze frecvent în analiza operațională curentă. După 30 de zile, obiectele trec în nivelul warm, pe discuri rotative de înaltă densitate, unde rămân interogabile, dar cu o latență mai mare. După 180 de zile, obiectele trec în nivelul cold, pe stocare de arhivare de înaltă densitate, cu latență de recuperare configurabilă. Pragurile nivelurilor sunt configurabile pentru fiecare domeniu și fiecare nivel de clasificare — datele de la senzorii ISR din zonele operaționale active pot avea o perioadă mai scurtă până la trecerea din nivelul warm în nivelul cold decât datele de arhivă de logistică.

Arhitectura pipeline-ului de ingestie — fluxuri din sisteme C2 (CoT/NIEM), ingestia datelor de la senzori ISR, ETL pentru sistemele de logistică, tipare de ingestie streaming versus batch

Stratul de ingestie trebuie să gestioneze simultan trei profiluri de viteză a datelor fundamental diferite: fluxuri de streaming de viteză mare din sistemele C2 și ISR, care produc mii de evenimente pe minut; fluxuri structurate de viteză medie din sistemele de logistică și planificare, care produc sute de înregistrări pe oră; și exporturi batch de viteză mică din sisteme moștenite (legacy), care livrează zilnic sau săptămânal dump-uri de fișiere. Aceste profiluri necesită tipare de ingestie diferite, care trebuie să interopereze fără probleme la limita zonei de aterizare (landing zone).

Apache Kafka este coloana vertebrală de streaming pentru fluxurile în timp real. Proiectarea topic-urilor urmează aceeași convenție legată de nivelul de clasificare ca și stocarea — fiecare topic are ca prefix nivelul său de clasificare, iar ACL-urile Kafka restricționează accesul producătorilor și al consumatorilor în funcție de nivelul de clasificare. Convenția de denumire a topic-urilor codifică tipul sursei și identitatea sistemului:

Serviciile adaptoare CoT/NIEM se abonează la topic-urile C2 raw, parsează XML-ul, mapează câmpurile pe schema canonică de ingestie, atașează metadate de proveniență (ID-ul sistemului-sursă, marcajul temporal al colectării, nivelul de clasificare, unitatea de origine) și publică în topic-ul normalizat. Parsarea CoT trebuie să gestioneze atât câmpurile CoT standard, cât și extensiile elementului Detail utilizate de anumite sisteme C2 — adaptorul nu trebuie să elimine în tăcere conținutul extensiilor; el trebuie fie să mapeze extensiile cunoscute pe câmpuri canonice, fie să le păstreze într-o coloană structurată de extensii. Adaptoarele NIEM gestionează scheme semnificativ mai complexe — designul modular al NIEM face ca o instanță de schimb NIEM să poată referi tipuri din mai multe scheme NIEM core și de domeniu, iar adaptorul trebuie să rezolve toate referințele înainte de maparea câmpurilor. Adaptorul produce o structură aplatizată, cu un rând per raport, potrivită pentru stocarea în Parquet.

Ingestia datelor de la senzorii ISR variază în funcție de tipul senzorului. Fluxurile de analiză video UAV produc înregistrări de evenimente de detecție — casetă de încadrare (bounding box), clasă de detecție, scor de încredere, marcaj temporal al cadrului, poziția senzorului — cu viteze care pot depăși 10 000 de înregistrări pe minut pentru o platformă cu fluxuri multiple. Acestea trebuie ingerate prin Kafka, cu impunerea schemei Avro sau Protobuf de partea producătorului, nu doar de partea consumatorului. Receptoarele SIGINT produc înregistrări de interceptare a emițătoarelor, cu frecvență, modulație, parametri ai impulsurilor, azimut și date TDOA. Fluxurile radar produc rapoarte de track cu poziție, viteză și indicatori ai calității track-ului. Fiecare tip de senzor are un adaptor dedicat care își normalizează formatul nativ la schema canonică de observații ISR înainte ca înregistrarea să ajungă în zona de aterizare. Pentru o tratare aprofundată a arhitecturii de fuziune a informațiilor în timp real, consultați articolul nostru complementar despre procesarea fluxurilor multisursă.

ETL-ul pentru logistică funcționează de regulă în mod batch — majoritatea sistemelor ERP de logistică produc exporturi periodice, nu fluxuri de modificări în timp real. Pipeline-ul ETL extrage datele din interfața de export a sistemului-sursă (depunere de fișiere prin SFTP, interogare de bază de date sau preluare prin REST API), validează schema, aplică maparea câmpurilor pe schema logistică canonică și scrie fișiere Parquet în zona de aterizare raw. Un job Spark procesează apoi fișierele raw în zona structured, conform unui program sincronizat cu cadența de export a sistemului-sursă. Pentru sistemele de logistică care acceptă captarea modificărilor datelor (change data capture, CDC) prin streaming al jurnalului bazei de date, se preferă calea de streaming — aceasta reduce de la ore la minute timpul dintre un eveniment logistic și disponibilitatea sa pentru interogările analitice.

Validarea calității datelor la momentul ingestiei nu este opțională — este mecanismul care împiedică datele malformate să ajungă în zona structured și să corupă analizele. Fiecare adaptor de ingestie trebuie să efectueze cel puțin: validarea conformității cu schema, verificări ale completitudinii provenienței, verificări de plauzibilitate temporală (marcaje temporale ale evenimentelor în limite plauzibile) și, pentru datele geospațiale, validarea intervalului coordonatelor. Eșecurile de validare sunt direcționate către o coadă dead-letter, împreună cu corpul original complet al mesajului și o înregistrare de eroare structurată care identifică verificarea specifică ce a eșuat.

Catalogul de metadate și descoperirea datelor — etichetarea clasificării și a caveat-urilor în metadate, registrul de scheme, urmărirea lineage-ului datelor, UX-ul de căutare și descoperire pentru analiști

Catalogul de metadate este componenta care face data lake-ul utilizabil de către analiștii care nu l-au construit. Fără un catalog, data lake-ul este o colecție de fișiere Parquet opace în stocarea de obiecte, pe care doar inginerii care au scris adaptoarele de ingestie știu să le interogheze. Cu un catalog bine populat, orice analist cu autorizare de securitate adecvată poate descoperi seturile de date disponibile, le poate înțelege schemele și proveniența și poate construi interogări asupra lor — fără a necesita sprijin din partea inginerilor pentru fiecare întrebare analitică nouă. Ghidul privind gestionarea metadatelor catalogului de date militar tratează în detaliu proiectarea catalogului; această secțiune abordează integrarea acestuia cu arhitectura data lake-ului.

Apache Atlas este catalogul open-source verificat în producție pentru mediile care necesită tipuri de metadate extensibile, urmărirea lineage-ului și integrare cu instrumentele ecosistemului Hadoop. Sistemul de tipuri al Atlas permite definirea unor tipuri personalizate de entități de metadate ca obiecte de schemă de prim rang (first-class) — nu ca adnotări în text liber — ceea ce este esențial pentru câmpurile specifice apărării, care trebuie să fie obligatorii la înregistrarea setului de date:

• ClassificationLevel — tip enumerat: UNCLASSIFIED, CONFIDENTIAL, SECRET, TOP_SECRET. Obligatoriu pentru fiecare entitate de tip set de date. Determină direcționarea către bucket-ul de stocare și evaluarea politicilor de control al accesului.
• CaveatCodes — listă de șiruri cu valori multiple. Înregistrează caveat-urile aplicabile, precum NOFORN, identificatorii de compartiment și instrucțiunile de manipulare. Trebuie completat la ingestie sau lăsat ca declarație explicită goală — null nu este permis.
• DataOwnerUnit — referință de tip șir către unitatea organizațională responsabilă de setul de date. Utilizat pentru direcționarea către responsabilii cu administrarea datelor (data stewardship) și pentru stabilirea punctului de contact pentru cererile de acces la date.
• RetentionPolicy — referință la regula de retenție aplicabilă, care definește durata maximă de retenție, procedura de ștergere securizată și autoritatea care a aprobat perioada de retenție.
• OriginatingSystem — identificatorul sistemului-sursă care a produs datele. Utilizat pentru trasarea lineage-ului și pentru redirecționarea problemelor de calitate a datelor către operatorul sistemului-sursă.

Integrarea registrului de scheme cu Apache Kafka asigură că schema fiecărui topic este înregistrată și versionată înainte ca orice producător să înceapă să scrie. Confluent Schema Registry (care poate fi implementat on-premises, fără conectivitate la cloud) impune reguli de compatibilitate a schemelor Avro sau Protobuf — compatibilitatea BACKWARD pentru topic-urile orientate spre consumatori înseamnă că versiunile noi ale schemei pot adăuga câmpuri opționale fără a afecta consumatorii existenți. Fiecare versiune a schemei este referențiată din entitatea din catalogul Atlas aferentă setului de date corespunzător, oferind un istoric complet al modului în care structura setului de date a evoluat în timp.

Urmărirea lineage-ului datelor în Atlas surprinde lanțul de transformări de la ingestia raw până la tabelul analitic din zona curated. Hook-ul Atlas al Spark emite automat evenimente de lineage atunci când un job Spark citește dintr-un set de date înregistrat în Atlas și scrie în altul. Integrarea Trino cu Atlas necesită un event listener personalizat, care înregistrează ce tabele-sursă au fost accesate pentru a produce rezultatul unei interogări. Graful de lineage pe care Atlas îl construiește din aceste evenimente permite unui analist să urmărească orice valoare dintr-un tabel analitic din zona curated înapoi, prin fiecare pas de transformare, până la înregistrarea raw originală din zona de aterizare și mai departe până la sistemul-sursă și la evenimentul de colectare inițial. Acest lanț este important din punct de vedere operațional — analiștii trebuie frecvent să evalueze dacă un anumit rezultat analitic poate fi urmărit până la o sursă fiabilă — și reprezintă o cerință de conformitate pentru datele clasificate.

Căutarea și descoperirea orientate către analiști necesită ca catalogul să poată fi interogat după atributele pe care analiștii le folosesc efectiv: domeniul de date (C2, ISR, logistică, geospațial), intervalul de timp acoperit, nivelul de clasificare și caveat-urile (filtrate la ceea ce utilizatorul este autorizat să vadă) și căutarea după cuvinte-cheie în descrierile seturilor de date și în denumirile coloanelor. API-ul de căutare al Atlas acceptă toate aceste dimensiuni, dar stratul de control al accesului trebuie să se asigure că rezultatele căutării în catalog sunt ele însele filtrate în funcție de autorizarea de securitate și de apartenența la compartimente ale utilizatorului — un analist nu trebuie să poată descoperi existența unui set de date compartimentat la care nu este autorizat să aibă acces, chiar dacă intrarea din catalog nu expune conținutul setului de date.

Controlul compartimentat al accesului — control al accesului bazat pe atribute (ABAC) pentru impunerea compartimentelor, securitate la nivel de rând/coloană în motoarele de interogare, jurnalizare de audit

Controlul accesului într-un data lake militar nu este o politică unică — este o stivă de impunere pe mai multe straturi, în care fiecare strat prinde ceea ce stratul de deasupra ar putea scăpa. Straturile sunt: politici de bucket la nivelul stocării (cine poate citi și scrie în ce bucket-uri), politici de vizibilitate la nivelul catalogului (cine poate descoperi ce seturi de date), securitate pe rânduri și coloane la nivelul motorului de interogare (ce rânduri și coloane poate vedea un utilizator într-un set de date la care este autorizat să aibă acces) și jurnalizare de audit (ce a fost accesat, de către cine, când și ce a fost returnat). Toate cele patru straturi trebuie să fie active simultan — oricare strat care operează izolat oferă doar o protecție parțială.

Controlul accesului bazat pe atribute (ABAC) este modelul corect pentru dimensiunile de clasificare și de compartimente, deoarece explozia de roluri din RBAC îl face de negestionat la scară largă. O politică ABAC evaluează accesul calculând o funcție de politică peste atributele utilizatorului și atributele resursei:

OPA este implementat ca sidecar al coordonatorului Trino. Când un analist trimite o interogare SQL, pluginul de control al accesului din Trino apelează OPA pentru fiecare referință la tabel din interogare, transmițând atributele de identitate ale utilizatorului autentificat (de la furnizorul de identitate) și atributele de resursă ale tabelului (din catalog). OPA returnează o decizie de permitere/refuz și, pentru tabelele permise, returnează predicatul de filtrare a rândurilor și definițiile măștilor de coloană care trebuie aplicate acelui tabel în sesiunea acestui utilizator. Trino injectează în mod transparent filtrele de rânduri și măștile de coloană — interogarea analistului se execută așa cum a fost scrisă, dar setul de rezultate conține doar rândurile și coloanele pe care analistul este autorizat să le vadă.

Securitatea la nivel de rând din Trino adaugă un predicat la clauza WHERE a fiecărei interogări asupra unui tabel protejat. Pentru un tabel care conține înregistrări de mai multe niveluri de clasificare, filtrul de rânduri restricționează interogarea la rândurile pentru care nivelul de clasificare al înregistrării se încadrează în intervalul autorizat al utilizatorului. Mascarea la nivel de coloană înlocuiește valorile coloanei cu NULL sau cu un literal de tip șir pentru coloanele pe care utilizatorul nu este autorizat să le vadă integral — de exemplu, un câmp care conține un identificator de compartiment poate fi vizibil pentru utilizatorii cu autorizarea de compartiment corespunzătoare și mascat cu NULL pentru cei care nu o au.

Jurnalizarea de audit trebuie să capteze fiecare eveniment de interogare cu suficiente detalii pentru a reconstitui ceea ce a văzut utilizatorul. Câmpurile minime ale unei înregistrări de audit sunt: identitatea utilizatorului autentificat (nu doar numele de utilizator — atributele complete din furnizorul de identitate), marcajul temporal al trimiterii interogării, textul interogării, lista tabelelor accesate cu nivelurile lor de clasificare, numărul de rânduri returnate pentru fiecare tabel, orice politici de filtrare a rândurilor sau de mascare a coloanelor care au fost aplicate și starea de finalizare a interogării. Înregistrările de audit trebuie scrise în stocare de obiecte append-only, cu object lock activat, ceea ce împiedică modificarea sau ștergerea lor chiar și de către administratorii stocării. Depozitul jurnalului de audit trebuie să se afle la cel mai înalt nivel de clasificare care poate apărea în orice interogare, astfel încât înregistrările de audit să nu devină ele însele un canal de date între niveluri de clasificare.

Tipare ale sarcinilor de interogare și de analiză — Trino/Presto pentru SQL ad-hoc peste stocarea de obiecte, Spark pentru analiză batch, medii de tip notebook pentru analiști

Un data lake militar deservește două profiluri distincte de sarcini de interogare, care necesită motoare de execuție diferite, optimizate pentru funcții de cost diferite. Interogările ad-hoc ale analiștilor prioritizează latența scăzută — un analist care elaborează o evaluare de țintire are nevoie de un răspuns în secunde sau minute, nu în ore. Job-urile de analiză batch prioritizează debitul — un pipeline de inginerie a datelor care procesează întregul corpus istoric de înregistrări ale senzorilor pentru analiza tiparelor de viață (pattern-of-life) poate accepta timpi de execuție mai lungi dacă produce rezultate exacte și cuprinzătoare. Implementarea atât a Trino, cât și a Spark pe aceeași stocare de obiecte deservește ambele profiluri fără compromisuri.

Trino este motorul de interogare ad-hoc preferat pentru analiza SQL în data lake. El citește fișierele Parquet și Delta Lake direct din stocarea de obiecte, prin conectorul său Hive — fără etapă de încărcare a datelor, fără ETL într-o bază de date separată. Motorul distribuit de execuție a interogărilor al Trino împarte interogarea în fragmente executate în paralel pe nodurile worker, cu rezultate intermediare schimbate prin rețea. Pentru interogările tipice ale analiștilor — filtrarea înregistrărilor recente ale senzorilor, îmbinarea track-urilor C2 cu straturile geospațiale de referință, agregarea consumului logistic pe unitate și perioadă de timp — Trino oferă rezultate în secunde până la minute pe seturi de date care însumează sute de gigaocteți de fișiere Parquet. Parametrii-cheie de reglare pentru o implementare de data lake militar sunt: configurarea partition pruning (Trino trebuie să împingă predicatele clauzei WHERE pe coloanele de partiționare până la nivelul listării stocării de obiecte, evitând scanările complete ale bucket-urilor), frecvența colectării statisticilor (optimizatorul bazat pe costuri al Trino necesită statistici exacte ale tabelelor pentru a produce planuri de join eficiente) și limitele de memorie ale worker-ilor (interogările mari cu join pot depăși memoria per worker; configurarea spill-to-disk previne erorile de tip out-of-memory, cu prețul unei latențe crescute a interogărilor).

Apache Spark este motorul de analiză batch pentru sarcinile care necesită procesarea întregului corpus sau calcule iterative complexe. Integrarea Spark cu Delta Lake oferă semantică de scriere ACID — job-urile batch pot scrie în tabelele Delta Lake cu garanții exactly-once, iar cititorii Spark și Trino concurenți văd în orice moment un instantaneu consistent al tabelului, prin protocolul MVCC al Delta Lake. Sarcinile Spark frecvente într-un data lake militar includ:

• Job-uri ETL nocturne care procesează fișierele din zona de aterizare raw din cele 24 de ore anterioare în zona structured — parsare, validare, normalizare și scriere de Parquet cu metadate de partiționare
• Analiza tiparelor de viață (pattern-of-life) pe săptămâni sau luni de date istorice de track — identificarea tiparelor regulate de deplasare, a evenimentelor frecvente de co-locare și a schimbărilor de comportament în timp
• Job-uri batch de rezoluție a entităților (entity resolution) care consolidează înregistrările duplicate din mai multe surse pentru tabelul master curated al entităților
• Pipeline-uri de pregătire a datelor de antrenare pentru modele ML — extragerea de caracteristici (feature extraction) din datele brute ale senzorilor, asocierea etichetelor, exportul setului de date în formatul așteptat de framework-ul de antrenare
• Treceri de verificare a calității datelor care rulează profilare statistică pe întreaga zonă structured pentru a detecta deriva schemei (schema drift), anomalii ale distribuției valorilor și lacune în metadatele de proveniență

JupyterHub oferă mediul de tip notebook destinat analiștilor. Notebook-urile se conectează la Trino pentru interogări SQL și la Spark pentru manipularea programatică a datelor, combinând flexibilitatea exploratorie a Python cu capabilitățile de interogare structurată ale ambelor motoare. Într-o implementare clasificată, serverul JupyterHub trebuie izolat în segmentul de rețea corespunzător nivelului de clasificare — fiecare nivel de clasificare necesită propria instanță JupyterHub, conectată la clusterele Trino și Spark din cadrul acelui nivel. Notebook-urile create de analiști trebuie stocate în zona curated a data lake-ului (nu pe discul local al serverului JupyterHub), astfel încât să fie supuse acelorași politici de retenție și audit ca restul conținutului data lake-ului. Șabloanele de notebook predefinite pentru tiparele frecvente de join multidomeniu — track-uri C2 îmbinate cu detecțiile senzorilor ISR, consum logistic îmbinat cu rapoarte operaționale — reduc timpul pe care un analist trebuie să îl petreacă pentru construirea de interogări standard (boilerplate) înainte de a ajunge la întrebarea sa analitică.

Calitatea și guvernanța datelor — verificări ale calității datelor la ingestie, gestionarea datelor master pentru referințele de entități, politici de retenție și eliminare a datelor clasificate

Guvernanța datelor într-un data lake militar nu este un exercițiu de documentare — este o disciplină operațională care determină dacă analizele produse de data lake pot fi considerate de încredere în procesul decizional. Un analist care descoperă că o evaluare de țintire s-a bazat pe date care nu au trecut verificările de calitate, dar au fost lăsate să se propage în zona curated, și-a pierdut încrederea în întreaga platformă de analiză. Mecanismele de guvernanță trebuie aplicate automat, fără a se baza pe cunoașterea de către analist a stării calității datelor.

Verificările calității datelor la momentul ingestiei (descrise în secțiunea despre pipeline-ul de ingestie) reprezintă prima barieră de guvernanță. A doua barieră este o trecere zilnică de verificare a calității datelor pe întreaga zonă structured, folosind Apache Spark. Trecerea rulează un set configurabil de verificări asupra fiecărui set de date înregistrat:

• Verificări de completitudine — procentul valorilor nenule pentru câmpurile obligatorii; orice set de date în care un câmp obligatoriu scade sub 95% completitudine declanșează o alertă către responsabilul cu administrarea datelor (data steward)
• Verificări ale distribuției valorilor — profilarea statistică a coloanelor numerice detectează schimbări bruște de distribuție care pot indica o calibrare greșită a senzorilor, modificări ale sistemului de coordonate sau erori ETL
• Verificări de integritate referențială — relațiile de tip cheie externă dintre seturile de date (de exemplu, ID-urile entităților de track referite în înregistrările senzorilor trebuie să existe în entity master-ul C2) sunt validate zilnic pentru a detecta referințele orfane produse de probleme de secvențiere a ingestiei
• Verificări de prospețime — fiecare set de date are o latență maximă așteptată de ingestie; seturile de date care nu au primit înregistrări noi în acea fereastră declanșează o alertă care poate indica o defecțiune a sistemului-sursă sau o partiționare a rețelei

Gestionarea datelor master (MDM) pentru referințele de entități este mecanismul de guvernanță care previne proliferarea identificatorilor de entități inconsistenți între domeniile de date. În context militar, principalele entități care necesită MDM sunt: unitățile și formațiunile (cu relațiile lor ierarhice și structura curentă pe misiune, task organization), echipamentele (cu model, variantă și unitate de repartiție), elementele geografice și instalațiile (cu denumiri clasificate și neclasificate) și personalul (cu evidențe de autorizare de securitate și de încadrare). Fiecare dintre aceste tipuri de entități necesită o înregistrare de referință (golden record) în tabelul entity master, care servește drept referință autoritară pentru join-urile între domeniile de date. Fără un entity master întreținut, analiștii care îmbină înregistrările senzorilor ISR cu înregistrările unităților C2 vor obține eșecuri de join sau rezultate incorecte ori de câte ori aceeași unitate este identificată prin identificatori diferiți în sisteme-sursă diferite — o problemă frecventă în mediile militare de date multisursă.

Retenția și eliminarea datelor clasificate recurg la ștergerea criptografică drept mecanism standard. Cheia de criptare a datelor (DEK) a fiecărui nivel de clasificare este stocată într-un modul de securitate hardware (HSM). Când o politică de retenție declanșează eliminarea unui set de date, HSM-ul distruge DEK-ul obiectelor afectate, în loc să efectueze o suprascriere la nivel de obiect pe date criptate care pot totaliza petaocteți. După distrugerea DEK-ului, obiectele criptate sunt irecuperabile din punct de vedere computațional — cerința de ștergere securizată este satisfăcută fără povara operațională a procedurilor de suprascriere în mai multe treceri la scară de petaocteți. Serviciul de epurare care execută distrugerea DEK-ului trebuie să înregistreze fiecare eveniment de epurare într-un jurnal de audit imuabil care consemnează:

• Identificatorul setului de date și prefixul căii obiectelor afectate
• Numărul de obiecte a căror cheie de criptare a fost distrusă
• Regula politicii de retenție care a declanșat eliminarea (după ID-ul și versiunea regulii)
• Identitatea serviciului automat sau a entității umane (principal) care a autorizat eliminarea
• Un hash criptografic al DEK-ului de la momentul distrugerii (care dovedește că cheia a existat înainte de distrugere, fără a păstra cheia propriu-zisă)
• Marcajul temporal al distrugerii DEK-ului și înregistrarea de atestare HSM care confirmă evenimentul de distrugere

Cadrul de guvernanță este eficient doar dacă rezultatele sale sunt vizibile pentru persoanele responsabile de calitatea datelor. Un tablou de bord zilnic de guvernanță — construit din rezultatele trecerilor de verificare a calității datelor, din indicatorii de completitudine a înregistrării în catalog, din starea conformității cu politicile de retenție și din rezumatele jurnalelor de audit — oferă administratorilor de date (data stewards) vizibilitatea necesară pentru a identifica și a remedia problemele înainte ca acestea să se propage în seturile de date curated destinate analiștilor. Tabloul de bord în sine trebuie implementat în segmentul de rețea corespunzător nivelului de clasificare, iar datele sale trebuie să provină exclusiv din interiorul acelui segment — un tablou de bord de guvernanță pentru datele clasificate Secret nu trebuie să preia metrici din infrastructura de monitorizare de nivel Neclasificat. A trata guvernanța ca pe o preocupare de rang secundar, care poate partaja infrastructura cu servicii de nivel de clasificare inferior, este o greșeală arhitecturală frecventă, care creează atât o expunere la riscuri de conformitate, cât și un punct orb operațional pentru calitatea datelor din conținutul cel mai sensibil al data lake-ului.