Wojskowy data lake i komercyjny data lake opierają się na tej samej podstawowej idei — taniego, skalowalnego magazynu obiektów jako fundamentu analityki — ale diametralnie różnią się w każdym ograniczeniu, które ma znaczenie operacyjne. Egzekwowanie klasyfikacji, dostęp uwzględniający kompartmenty, praca w trybie air-gap i krytyczne dla misji umowy SLA dotyczące zapytań nie są dodatkowymi funkcjami wdrożenia obronnego; są kluczowymi wymaganiami konstrukcyjnymi, które kształtują każdą warstwę architektury — od nazewnictwa bucketów po konfigurację silnika zapytań. Architektura, która traktuje je jako dodatki wprowadzane na końcu — dopisując znacznik klasyfikacji do istniejących komercyjnych wzorców data lake — w najlepszym razie nie przejdzie audytów bezpieczeństwa, a w najgorszym doprowadzi do naruszeń zgodności.
Ten artykuł przedstawia krok po kroku kompletny projekt produkcyjnego wojskowego data lake: warstwę magazynowania, potok ingestu ze źródeł C2, ISR i logistycznych, zarządzanie metadanymi wojskowego katalogu danych, kompartmentową kontrolę dostępu oraz wzorce obciążeń analitycznych. Każda sekcja omawia decyzje projektowe, które odróżniają system nadający się do wdrożenia operacyjnego od architektury referencyjnej, która w białej księdze wygląda poprawnie, ale zawodzi w kontakcie z rzeczywistymi danymi niejawnymi.
Co musi robić wojskowy data lake, czego nie musi komercyjny — egzekwowanie klasyfikacji, dostęp uwzględniający kompartmenty, praca w trybie air-gap, krytyczne dla misji umowy SLA
Najbardziej fundamentalna różnica między komercyjnym a wojskowym data lake nie jest wyborem technologii — jest modelem zagrożeń. Komercyjny data lake chroni przed atakującymi z zewnątrz i eksfiltracją danych przez osoby wewnętrzne. Wojskowy data lake musi chronić także przed subtelniejszą awarią: uprawnionym użytkownikiem uzyskującym dostęp do danych, do których ma poświadczenie, ale których w bieżącym kontekście nie jest upoważniony oglądać. Analityk wywiadu sygnałowego z poświadczeniem Top Secret nie może mieć możliwości odpytywania skompartmentowanego zbioru danych HUMINT, o ile nie posiada określonego kodu kompartmentu. Oficer logistyki z poświadczeniem Secret nie może widzieć informacji wywiadowczych ISR, nawet jeśli także mają one klasyfikację Secret. Poziom klasyfikacji i przynależność do kompartmentów są ortogonalnymi wymiarami dostępu i oba muszą być egzekwowane w każdej warstwie systemu.
Praca w trybie air-gap eliminuje wszelkie zależności od usług zarządzanych w chmurze. Nie ma zarządzanego Kafka, katalogu hostowanego w chmurze ani usługi zarządzania kluczami obsługiwanej przez dostawcę. Każdy komponent — magazyn obiektów, broker strumieniowy, silnik zapytań, katalog metadanych, sprzęt do zarządzania kluczami — musi dać się wdrożyć lokalnie (on-premises) z pakietów, które można przenieść do środowiska air-gap za pośrednictwem zatwierdzonych nośników. To ograniczenie wyklucza architektury zakładające punkty końcowe aktualizacji osiągalne z internetu, serwery walidacji licencji lub usługi zbierania telemetrii. Oznacza też, że zespół operacyjny odpowiada za pełny cykl aktualizacji i łatania każdego komponentu, bez ścieżki zarządzanej przez dostawcę.
Krytyczne dla misji umowy SLA dotyczą zarówno aktualności danych, jak i opóźnień zapytań. Analityk fuzji danych ISR, który odpytuje najświeższe dane z sensorów, nie może zaakceptować wielogodzinnego okna zadania wsadowego Spark. Oficer logistyki budujący model uzupełnienia zaopatrzenia potrzebuje wyników zapytań w ciągu minut, a nie dni. Wymagania te wymuszają decyzje architektoniczne, które komercyjne data lake często odkładają na później: stale działające silniki zapytań, które dysponują już skompilowanymi planami zapytań opartymi na aktualnych statystykach katalogu, magazyn warstwy gorącej dla świeżych danych oraz ingest strumieniowy, dzięki któremu nowe dane można odpytywać w ciągu kilku sekund od odbioru — a nie dopiero w następnym oknie wsadowym. Więcej o podstawowych wzorcach stosowanych w opisanych tu warstwach znajdą Państwo w naszym przewodniku po wzorcach integracji danych w obronności.
Czwartym wymaganiem, które komercyjne data lake również realizują niedostatecznie, jest integracja danych wielodomenowych — łączenie danych o śladach C2, danych z sensorów ISR, rekordów logistycznych i referencyjnych warstw geoprzestrzennych w jednym zapytaniu ponad granicami klasyfikacji (z odpowiednimi mechanizmami kontroli). W komercyjnym data lake złączenia międzydomenowe są wygodą inżynierii danych. W wojskowym data lake są one podstawowym przypadkiem użycia analitycznego — i muszą być możliwe bez osłabiania egzekwowania klasyfikacji. Silnik zapytań musi umieć łączyć tabele z różnych domen danych, stosując przy tym w sposób przezroczysty filtry klasyfikacyjne dla każdej tabeli po obu stronach złączenia.
Projekt warstwy magazynowania — magazyn obiektów (MinIO/Ceph dla wdrożeń on-prem), magazynowanie warstwowe (hot/warm/cold), nazewnictwo i partycjonowanie obiektów dla wojskowych domen danych
Magazyn obiektów jest fundamentem każdej nowoczesnej architektury data lake, a w przypadku wojskowych wdrożeń w trybie air-gap wybór zawęża się do dwóch sprawdzonych produkcyjnie platform: MinIO i Ceph. MinIO implementuje pełne API AWS S3 z szyfrowaniem AES-256 w spoczynku, politykami IAM na poziomie bucketów oraz wersjonowaniem i blokowaniem na poziomie obiektów — wszystko bez jakiejkolwiek zależności od chmury. Jego wydajność na nowoczesnym sprzęcie NVMe przewyższa komercyjne chmurowe magazyny obiektów w obciążeniach opartych na zapisie sekwencyjnym, będącym dominującym wzorcem ingestu danych z sensorów. Ceph zapewnia magazyn obiektowy, blokowy i plikowy z jednego klastra za pośrednictwem RADOS Gateway, co czyni go odpowiednim dla środowisk, w których ta sama fizyczna infrastruktura magazynowa musi obsługiwać zarówno obciążenie obiektowe data lake, jak i woluminy blokowe maszyn wirtualnych. W przypadku dedykowanego wdrożenia data lake MinIO jest prostszy operacyjnie; Ceph jest właściwym wyborem, gdy klaster magazynowy musi obsługiwać także interfejsy blokowe i plikowe.
Izolacja klasyfikacji jest realizowana na poziomie bucketa, a nie obiektu. Każdy poziom klasyfikacji ma własną przestrzeń nazw bucketów:
Struktura stref — raw, structured, curated — dzieli dane według etapu przetwarzania w obrębie każdego poziomu klasyfikacji. Strefa raw przechowuje dane dokładnie w takiej postaci, w jakiej napłynęły z systemów źródłowych, w formacie natywnym (XML CoT, XML NIEM, binarne strumienie z sensorów, eksporty logistyczne CSV). Nic w strefie raw nie jest modyfikowane po zapisie; stanowi ona niezmienny zapis audytowy tego, co zostało odebrane. Strefa structured przechowuje dane po normalizacji do Parquet w formacie tabel Delta Lake — z wymuszonym schematem, polami zmapowanymi na nazwy kanoniczne i dołączonymi metadanymi proweniencji. Strefa curated przechowuje agregaty gotowe dla analityków, wstępnie połączone widoki wielodomenowe oraz tabele podsumowujące, które umożliwiają szybkie interaktywne zapytania bez konieczności samodzielnego wykonywania tej samej logiki złączeń przez każdego analityka.
Projekt kluczy obiektów dla strefy structured koduje wszystkie wymiary partycjonowania potrzebne do wydajnego pushdownu zapytań:
Magazynowanie warstwowe jest zarządzane za pomocą polityk cyklu życia (lifecycle) MinIO. Warstwa gorąca wykorzystuje węzły oparte na NVMe i przechowuje dane z ostatnich 30 dni — na tyle świeże, że analitycy często odpytują je na potrzeby bieżącej analizy operacyjnej. Po 30 dniach obiekty przechodzą do warstwy ciepłej na dyskach talerzowych o dużej gęstości, gdzie pozostają dostępne dla zapytań, ale z wyższym opóźnieniem. Po 180 dniach obiekty przechodzą do warstwy zimnej w archiwalnym magazynie o dużej gęstości z konfigurowalnym opóźnieniem odczytu. Progi warstw są konfigurowalne dla każdej domeny i każdego poziomu klasyfikacji — dane z sensorów ISR z aktywnych obszarów operacyjnych mogą mieć krótszy czas przejścia z warstwy ciepłej do zimnej niż dane archiwalne logistyki.
Architektura potoku ingestu — strumienie danych z systemów C2 (CoT/NIEM), ingest danych z sensorów ISR, ETL systemów logistycznych, wzorce ingestu strumieniowego i wsadowego
Warstwa ingestu musi jednocześnie obsługiwać trzy zasadniczo różne profile szybkości danych: szybkie strumienie danych z systemów C2 i ISR, generujące tysiące zdarzeń na minutę; strumienie ustrukturyzowane o średniej szybkości z systemów logistycznych i planistycznych, generujące setki rekordów na godzinę; oraz wolne eksporty wsadowe z systemów starszej generacji, które dostarczają codzienne lub cotygodniowe zrzuty plików. Profile te wymagają różnych wzorców ingestu, które muszą bezkolizyjnie współpracować na granicy strefy lądowania.
Apache Kafka jest szkieletem strumieniowym dla kanałów danych czasu rzeczywistego. Projekt tematów (topics) stosuje tę samą konwencję podziału według klasyfikacji co magazyn — każdy temat ma prefiks z poziomem klasyfikacji, a listy ACL w Kafka ograniczają dostęp producentów i konsumentów według poziomu klasyfikacji. Konwencja nazewnictwa tematów koduje typ źródła i tożsamość systemu:
Usługi adapterów CoT/NIEM subskrybują surowe tematy C2, parsują XML, mapują pola na kanoniczny schemat ingestu, dołączają metadane proweniencji (identyfikator systemu źródłowego, znacznik czasu pozyskania, poziom klasyfikacji, jednostka pochodzenia) i publikują do tematu znormalizowanego. Parsowanie CoT musi obsługiwać zarówno standardowe pola CoT, jak i rozszerzenia elementu Detail stosowane przez konkretne systemy C2 — adapter nie może po cichu odrzucać zawartości rozszerzeń; musi albo mapować znane rozszerzenia na pola kanoniczne, albo zachowywać je w ustrukturyzowanej kolumnie rozszerzeń. Adaptery NIEM obsługują znacznie bardziej złożone schematy — modułowa konstrukcja NIEM oznacza, że instancja wymiany NIEM może odwoływać się do typów z wielu rdzeniowych i domenowych schematów NIEM, a adapter musi rozwiązać wszystkie odwołania przed mapowaniem pól. Adapter zwraca spłaszczoną strukturę „jeden wiersz na raport”, nadającą się do magazynowania w Parquet.
Ingest danych z sensorów ISR różni się w zależności od typu sensora. Strumienie analityki wideo z UAV generują rekordy zdarzeń detekcji — ramkę ograniczającą (bounding box), klasę detekcji, wynik pewności, znacznik czasu klatki, pozycję sensora — w tempie mogącym przekraczać 10 000 rekordów na minutę dla platformy wielostrumieniowej. Muszą one być wczytywane za pośrednictwem Kafka z wymuszaniem schematu Avro lub Protobuf po stronie producenta, a nie tylko konsumenta. Odbiorniki SIGINT generują rekordy przechwyceń emiterów z częstotliwością, modulacją, parametrami impulsów, namiarem i danymi TDOA. Strumienie radarowe generują raporty o śladach z pozycją, prędkością i metrykami jakości śladu. Każdy typ sensora ma dedykowany adapter, który normalizuje jego natywny format do kanonicznego schematu obserwacji ISR, zanim rekord trafi do strefy lądowania. Szczegółowe omówienie architektury fuzji informacji wywiadowczych w czasie rzeczywistym znajduje się w naszym uzupełniającym artykule o przetwarzaniu strumieni z wielu źródeł.
ETL logistyczny działa zazwyczaj w trybie wsadowym — większość systemów ERP logistyki generuje okresowe eksporty, a nie strumienie zmian w czasie rzeczywistym. Potok ETL pobiera dane z interfejsu eksportu systemu źródłowego (zrzut plików przez SFTP, zapytanie do bazy danych lub pobranie przez REST API), waliduje schemat, stosuje mapowanie pól na kanoniczny schemat logistyczny i zapisuje pliki Parquet w surowej strefie lądowania. Zadanie Spark przetwarza następnie surowe pliki do strefy structured według harmonogramu zsynchronizowanego z rytmem eksportu systemu źródłowego. W przypadku systemów logistycznych, które obsługują przechwytywanie zmian danych (CDC) przez strumieniowanie logów bazy danych, preferowana jest ścieżka strumieniowa — skraca ona czas między zdarzeniem logistycznym a jego dostępnością dla zapytań analitycznych z godzin do minut.
Walidacja jakości danych w momencie ingestu nie jest opcjonalna — to mechanizm, który zapobiega przedostawaniu się wadliwych danych do strefy structured i zakłócaniu analityki. Każdy adapter ingestu musi wykonywać co najmniej: walidację zgodności ze schematem, kontrole kompletności proweniencji, kontrole poprawności czasowej (znaczniki czasu zdarzeń w wiarygodnych granicach), a dla danych geoprzestrzennych — walidację zakresu współrzędnych. Niepowodzenia walidacji trafiają do kolejki dead-letter wraz z pełną oryginalną treścią komunikatu i ustrukturyzowanym rekordem błędu wskazującym konkretną kontrolę, która zawiodła.
Katalog metadanych i odkrywanie danych — etykietowanie klasyfikacji i zastrzeżeń w metadanych, rejestr schematów (schema registry), śledzenie linii pochodzenia danych, wyszukiwanie i UX odkrywania danych dla analityków
Katalog metadanych jest komponentem, który sprawia, że data lake nadaje się do użytku przez analityków, którzy go nie budowali. Bez katalogu data lake jest zbiorem nieprzezroczystych plików Parquet w magazynie obiektów, które potrafią odpytywać tylko inżynierowie, którzy napisali adaptery ingestu. Z dobrze zasilonym katalogiem każdy analityk z odpowiednim poświadczeniem może odkrywać dostępne zbiory danych, rozumieć ich schematy i proweniencję oraz konstruować zapytania, bez angażowania wsparcia inżynieryjnego przy każdym nowym pytaniu analitycznym. Przewodnik po zarządzaniu metadanymi wojskowego katalogu danych szczegółowo omawia projekt katalogu; ta sekcja dotyczy jego integracji z architekturą data lake.
Apache Atlas to sprawdzony produkcyjnie katalog open source dla środowisk wymagających rozszerzalnych typów metadanych, śledzenia linii pochodzenia danych i integracji z narzędziami ekosystemu Hadoop. System typów Atlas pozwala definiować niestandardowe typy encji metadanych jako pełnoprawne obiekty schematu — a nie adnotacje w postaci wolnego tekstu — co jest kluczowe dla pól specyficznych dla obronności, które muszą być obowiązkowe w momencie rejestracji zbioru danych:
- ClassificationLevel — typ wyliczeniowy: UNCLASSIFIED, CONFIDENTIAL, SECRET, TOP_SECRET. Obowiązkowy dla każdej encji zbioru danych. Steruje routingiem do bucketów magazynu i oceną polityk kontroli dostępu.
- CaveatCodes — wielowartościowa lista ciągów znaków. Rejestruje obowiązujące zastrzeżenia, takie jak NOFORN, identyfikatory kompartmentów i instrukcje postępowania. Musi być wypełniona przy ingeście lub pozostawiona jako jawna pusta deklaracja — wartość null jest niedozwolona.
- DataOwnerUnit — odwołanie tekstowe do jednostki organizacyjnej odpowiedzialnej za zbiór danych. Wykorzystywane do kierowania spraw data stewardship oraz do wskazywania punktu kontaktowego dla wniosków o dostęp do danych.
- RetentionPolicy — odwołanie do obowiązującej reguły retencji określającej maksymalny czas przechowywania, procedurę bezpiecznego usuwania oraz organ, który zatwierdził okres retencji.
- OriginatingSystem — identyfikator systemu źródłowego, który wytworzył dane. Wykorzystywany do śledzenia linii pochodzenia oraz do kierowania problemów z jakością danych z powrotem do operatora systemu źródłowego.
Integracja rejestru schematów (schema registry) z Apache Kafka gwarantuje, że schemat każdego tematu jest zarejestrowany i wersjonowany, zanim jakikolwiek producent zacznie zapisywać dane. Confluent Schema Registry (możliwy do wdrożenia lokalnie, bez łączności z chmurą) wymusza reguły zgodności schematów Avro lub Protobuf — zgodność BACKWARD dla tematów obsługujących konsumentów oznacza, że nowe wersje schematu mogą dodawać pola opcjonalne bez psucia działania istniejących konsumentów. Każda wersja schematu jest powiązana z encją katalogu Atlas odpowiedniego zbioru danych, co zapewnia pełną historię zmian struktury zbioru danych w czasie.
Śledzenie linii pochodzenia danych w Atlas rejestruje łańcuch transformacji od surowego ingestu do wyselekcjonowanej tabeli analitycznej. Hook Atlas w Spark automatycznie emituje zdarzenia lineage, gdy zadanie Spark odczytuje z jednego zbioru danych zarejestrowanego w Atlas i zapisuje do innego. Integracja Trino z Atlas wymaga niestandardowego nasłuchiwacza zdarzeń (event listener), który rejestruje, które tabele źródłowe zostały użyte do uzyskania wyniku zapytania. Graf lineage budowany przez Atlas na podstawie tych zdarzeń pozwala analitykowi prześledzić dowolną wartość w wyselekcjonowanej tabeli analitycznej wstecz przez każdy krok transformacji do pierwotnego surowego rekordu w strefie lądowania, a dalej do systemu źródłowego i pierwotnego zdarzenia pozyskania. Łańcuch ten ma znaczenie operacyjne — analitycy często muszą oceniać, czy dany wynik analityczny da się powiązać z wiarygodnym źródłem — i jest wymogiem zgodności dla danych niejawnych.
Wyszukiwanie i odkrywanie danych dla analityków wymaga, aby katalog dało się odpytywać według atrybutów, z których analitycy faktycznie korzystają: domeny danych (C2, ISR, logistyka, dane geoprzestrzenne), zakresu czasowego, który obejmuje zbiór danych, poziomu klasyfikacji i zastrzeżeń (przefiltrowanych do tego, co użytkownik jest upoważniony widzieć) oraz wyszukiwania słów kluczowych w opisach zbiorów danych i nazwach kolumn. API wyszukiwania Atlas obsługuje wszystkie te wymiary, ale warstwa kontroli dostępu musi zapewnić, że wyniki wyszukiwania w katalogu są same filtrowane według poświadczenia i przynależności do kompartmentów użytkownika — analityk nie może mieć możliwości odkrycia istnienia skompartmentowanego zbioru danych, do którego nie ma upoważnienia, nawet jeśli wpis w katalogu nie ujawnia zawartości zbioru.
Kompartmentowa kontrola dostępu — kontrola dostępu oparta na atrybutach (ABAC) do egzekwowania kompartmentów, zabezpieczenia na poziomie wierszy/kolumn w silnikach zapytań, rejestrowanie audytowe
Kontrola dostępu w wojskowym data lake nie jest pojedynczą polityką — jest warstwowym stosem egzekwowania, w którym każda warstwa wychwytuje to, co mogła przeoczyć warstwa nad nią. Warstwy to: polityki bucketów na poziomie magazynu (kto może czytać i zapisywać które buckety), polityki widoczności na poziomie katalogu (kto może odkrywać które zbiory danych), zabezpieczenia wierszy i kolumn na poziomie silnika zapytań (jakie wiersze i kolumny użytkownik może zobaczyć w zbiorze danych, do którego ma dostęp) oraz rejestrowanie audytowe (do czego uzyskano dostęp, przez kogo, kiedy i co zostało zwrócone). Wszystkie cztery warstwy muszą być aktywne jednocześnie — każda pojedyncza warstwa działająca w izolacji zapewnia jedynie częściową ochronę.
Kontrola dostępu oparta na atrybutach (ABAC) jest właściwym modelem dla wymiarów klasyfikacji i kompartmentów, ponieważ eksplozja ról sprawia, że RBAC jest nie do opanowania w dużej skali. Polityka ABAC ocenia dostęp, obliczając funkcję polityki na atrybutach użytkownika i atrybutach zasobu:
OPA jest wdrażany jako sidecar koordynatora Trino. Gdy analityk przesyła zapytanie SQL, wtyczka kontroli dostępu Trino wywołuje OPA dla każdego odwołania do tabeli w zapytaniu, przekazując atrybuty tożsamości uwierzytelnionego użytkownika (od dostawcy tożsamości) oraz atrybuty zasobu tabeli (z katalogu). OPA zwraca decyzję o zezwoleniu lub odmowie, a dla tabel dozwolonych zwraca predykat filtra wierszy i definicje masek kolumn, które muszą zostać zastosowane do tej tabeli w sesji tego użytkownika. Trino wstrzykuje filtry wierszy i maski kolumn w sposób przezroczysty — zapytanie analityka działa tak, jak zostało napisane, ale zbiór wyników zawiera wyłącznie wiersze i kolumny, które analityk jest upoważniony widzieć.
Zabezpieczenia na poziomie wierszy w Trino dołączają predykat do klauzuli WHERE każdego zapytania do chronionej tabeli. W przypadku tabeli zawierającej rekordy o różnych poziomach klasyfikacji filtr wierszy ogranicza zapytanie do wierszy, w których poziom klasyfikacji rekordu mieści się w zakresie upoważnienia użytkownika. Maskowanie na poziomie kolumn zastępuje wartości kolumn wartością NULL lub literałem tekstowym w kolumnach, których użytkownik nie jest upoważniony oglądać w całości — na przykład pole zawierające identyfikator kompartmentu może być widoczne dla użytkowników z odpowiednim upoważnieniem do kompartmentu i maskowane do NULL dla użytkowników bez takiego upoważnienia.
Rejestrowanie audytowe musi obejmować każde zdarzenie zapytania z dostateczną szczegółowością, aby można było odtworzyć, co użytkownik zobaczył. Minimalne pola rekordu audytowego to: tożsamość uwierzytelnionego użytkownika (nie tylko nazwa użytkownika — pełne atrybuty od dostawcy tożsamości), znacznik czasu przesłania zapytania, tekst zapytania, lista tabel, do których uzyskano dostęp, wraz z ich poziomami klasyfikacji, liczba wierszy zwróconych dla każdej tabeli, wszelkie zastosowane polityki filtrów wierszy lub masek kolumn oraz status zakończenia zapytania. Rekordy audytowe muszą być zapisywane w magazynie obiektów typu append-only z włączoną blokadą obiektów (object lock), co uniemożliwia modyfikację lub usunięcie rekordów audytowych nawet administratorom magazynu. Magazyn dziennika audytowego musi mieć najwyższy poziom klasyfikacji, jaki może pojawić się w jakimkolwiek zapytaniu, aby rekordy audytowe nie stały się same kanałem przepływu danych między poziomami klasyfikacji.
Wzorce obciążeń zapytań i analityki — Trino/Presto do zapytań SQL ad hoc nad magazynem obiektów, Spark do analityki wsadowej, środowiska notebooków dla analityków
Wojskowy data lake obsługuje dwa odrębne profile obciążeń zapytań, które wymagają różnych silników wykonawczych zoptymalizowanych pod różne funkcje kosztu. Zapytania ad hoc analityków stawiają na niskie opóźnienie — analityk przygotowujący ocenę w procesie wyznaczania celów (targeting) potrzebuje odpowiedzi w ciągu sekund lub minut, a nie godzin. Zadania analityki wsadowej stawiają na przepustowość — potok inżynierii danych przetwarzający pełny historyczny korpus rekordów z sensorów na potrzeby analizy wzorców życia (pattern-of-life) może zaakceptować dłuższy czas działania, jeśli dostarcza dokładne, wyczerpujące wyniki. Wdrożenie zarówno Trino, jak i Spark nad tym samym magazynem obiektów obsługuje oba profile bez kompromisów.
Trino jest silnikiem zapytań ad hoc z wyboru dla analityki SQL w data lake. Odczytuje pliki Parquet i Delta Lake bezpośrednio z magazynu obiektów za pośrednictwem konektora Hive — bez etapu ładowania danych, bez ETL do osobnej bazy danych. Rozproszony silnik wykonywania zapytań Trino dzieli zapytanie na fragmenty wykonywane równolegle na węzłach roboczych, a wyniki pośrednie są wymieniane przez sieć. W typowych zapytaniach analityków — filtrowaniu ostatnich rekordów z sensorów, złączaniu śladów C2 z referencyjnymi warstwami geoprzestrzennymi, agregowaniu zużycia logistycznego według jednostki i okresu — Trino dostarcza wyniki w ciągu sekund lub minut na zbiorach danych obejmujących setki gigabajtów plików Parquet. Kluczowe parametry strojenia dla wdrożenia wojskowego data lake to: konfiguracja przycinania partycji (Trino musi przekazywać predykaty klauzuli WHERE dla kolumn partycji w dół do listowania magazynu obiektów, unikając pełnego skanowania bucketów), częstotliwość zbierania statystyk (optymalizator kosztowy Trino wymaga dokładnych statystyk tabel, aby tworzyć wydajne plany złączeń) oraz limity pamięci węzłów roboczych (duże zapytania ze złączeniami mogą przekraczać pamięć przypadającą na węzeł; skonfigurowanie spill-to-disk zapobiega awariom z powodu braku pamięci kosztem zwiększonego opóźnienia zapytań).
Apache Spark jest silnikiem analityki wsadowej dla obciążeń wymagających przetwarzania całego korpusu danych lub złożonych obliczeń iteracyjnych. Integracja Spark z Delta Lake zapewnia semantykę zapisu ACID — zadania wsadowe mogą zapisywać do tabel Delta Lake z gwarancjami exactly-once, a równoległe odczyty ze Spark i Trino widzą w każdej chwili spójną migawkę tabeli dzięki protokołowi MVCC Delta Lake. Typowe obciążenia Spark w wojskowym data lake obejmują:
- Nocne zadania ETL przetwarzające pliki surowej strefy lądowania z poprzednich 24 godzin do strefy structured — parsowanie, walidacja, normalizacja i zapis Parquet z metadanymi partycji
- Analiza wzorców życia (pattern-of-life) na podstawie historycznych danych o śladach z tygodni lub miesięcy — identyfikowanie regularnych wzorców przemieszczania się, częstych zdarzeń współwystępowania w tej samej lokalizacji i zmian zachowań w czasie
- Wsadowe zadania uzgadniania encji (entity resolution), które konsolidują zduplikowane rekordy z różnych źródeł w wyselekcjonowanej głównej tabeli encji (entity master)
- Potoki przygotowania danych treningowych dla modeli ML — ekstrakcja cech z surowych danych z sensorów, dołączanie etykiet, eksport zbioru danych do formatu oczekiwanego przez framework treningowy
- Przeglądy jakości danych (data quality sweeps), które uruchamiają profilowanie statystyczne w całej strefie structured w celu wykrywania dryfu schematu, anomalii rozkładu wartości i luk w metadanych proweniencji
JupyterHub zapewnia środowisko notebooków przeznaczone dla analityków. Notebooki łączą się z Trino w celu wykonywania zapytań SQL oraz ze Spark do programistycznej manipulacji danymi, łącząc eksploracyjną elastyczność Pythona ze strukturalnymi możliwościami zapytań obu silników. We wdrożeniu niejawnym serwer JupyterHub musi być odizolowany w odpowiednim segmencie sieci właściwym dla danego poziomu klasyfikacji — każdy poziom klasyfikacji wymaga własnej instancji JupyterHub połączonej z klastrami Trino i Spark w obrębie tego poziomu. Notebooki tworzone przez analityków muszą być przechowywane w strefie curated data lake (a nie na lokalnym dysku serwera JupyterHub), aby podlegały tym samym politykom retencji i audytu co pozostała zawartość data lake. Gotowe szablony notebooków dla typowych wzorców złączeń wielodomenowych — ślady C2 złączone z detekcjami z sensorów ISR, zużycie logistyczne złączone z raportami operacyjnymi — skracają czas, który analityk musi poświęcić na schematyczne konstruowanie zapytań, zanim dotrze do swojego pytania analitycznego.
Jakość danych i data governance — kontrole jakości danych przy ingeście, zarządzanie danymi podstawowymi dla odwołań do encji, polityki retencji i usuwania danych niejawnych
Data governance w wojskowym data lake nie jest ćwiczeniem dokumentacyjnym — jest dyscypliną operacyjną, która decyduje o tym, czy analityce wytwarzanej przez data lake można ufać przy podejmowaniu decyzji. Analityk, który odkryje, że ocena w procesie wyznaczania celów (targeting) została oparta na danych, które nie przeszły kontroli jakości, a mimo to mogły przedostać się do strefy curated, traci zaufanie do całej platformy analitycznej. Mechanizmy data governance muszą być egzekwowane automatycznie, bez polegania na świadomości analityków co do stanu jakości danych.
Kontrole jakości danych w momencie ingestu (opisane w sekcji o potoku ingestu) są pierwszą bramką data governance. Drugą bramką jest codzienny przegląd jakości danych w całej strefie structured z użyciem Apache Spark. Przegląd uruchamia konfigurowalny zestaw kontroli względem każdego zarejestrowanego zbioru danych:
- Kontrole kompletności — odsetek wartości niepustych (non-null) dla pól obowiązkowych; każdy zbiór danych, w którym pole obowiązkowe spada poniżej 95% kompletności, wyzwala alert do opiekuna danych (data steward)
- Kontrole rozkładu wartości — profilowanie statystyczne kolumn liczbowych wykrywa nagłe zmiany rozkładu, które mogą wskazywać na błędną kalibrację sensora, zmiany układu współrzędnych lub błędy ETL
- Kontrole integralności referencyjnej — relacje kluczy obcych między zbiorami danych (np. identyfikatory encji śladów, do których odwołują się rekordy z sensorów, muszą istnieć w głównej tabeli encji C2) są walidowane codziennie w celu wykrywania osieroconych odwołań powstających wskutek problemów z kolejnością ingestu
- Kontrole aktualności — każdy zbiór danych ma maksymalne oczekiwane opóźnienie ingestu; zbiory, które nie otrzymały nowych rekordów w tym oknie, wyzwalają alert, który może wskazywać na awarię systemu źródłowego lub podział sieci (network partition)
Zarządzanie danymi podstawowymi (MDM) dla odwołań do encji to mechanizm data governance, który zapobiega mnożeniu się niespójnych identyfikatorów encji w poszczególnych domenach danych. W kontekście wojskowym podstawowe encje wymagające MDM to: jednostki i formacje (wraz z ich relacjami hierarchicznymi i bieżącą organizacją zadaniową), elementy wyposażenia (z modelem, wariantem i przypisaną jednostką), obiekty geograficzne i instalacje (z nazwami niejawnymi i jawnymi) oraz personel (z rekordami poświadczeń i przydziałów). Każdy z tych typów encji wymaga rekordu golden record w głównej tabeli encji (entity master table), który pełni rolę autorytatywnego odniesienia dla złączeń między domenami danych. Bez utrzymywanej tabeli głównej encji analitycy łączący rekordy z sensorów ISR z rekordami jednostek C2 będą napotykać błędy złączeń lub nieprawidłowe wyniki za każdym razem, gdy ta sama jednostka jest identyfikowana różnymi identyfikatorami w różnych systemach źródłowych — co jest częstym problemem w wielozródłowych wojskowych środowiskach danych.
Retencja i usuwanie danych niejawnych wykorzystują kasowanie kryptograficzne jako standardowy mechanizm. Klucz szyfrowania danych (DEK) każdego poziomu klasyfikacji jest przechowywany w sprzętowym module bezpieczeństwa (HSM). Gdy polityka retencji wyzwala usunięcie zbioru danych, HSM niszczy klucz DEK dla objętych obiektów, zamiast wykonywać nadpisywanie na poziomie obiektów w potencjalnie petabajtach zaszyfrowanych danych. Po zniszczeniu DEK zaszyfrowane obiekty są obliczeniowo nieodzyskiwalne — wymóg bezpiecznego usuwania zostaje spełniony bez operacyjnego obciążenia wieloprzebiegowymi procedurami nadpisywania w skali petabajtów. Usługa usuwania, która wykonuje zniszczenie DEK, musi rejestrować każde zdarzenie usunięcia w niezmiennym śladzie audytowym, który zapisuje:
- Identyfikator zbioru danych i prefiks ścieżki objętych obiektów
- Liczbę obiektów, których klucz szyfrowania został zniszczony
- Regułę polityki retencji, która wyzwoliła usunięcie (według identyfikatora i wersji reguły)
- Tożsamość zautomatyzowanej usługi lub osoby (principal), która autoryzowała usunięcie
- Kryptograficzny skrót klucza DEK w momencie zniszczenia (dowodzący, że klucz istniał przed zniszczeniem, bez zachowywania samego klucza)
- Znacznik czasu zniszczenia DEK oraz rekord atestacji HSM potwierdzający zdarzenie zniszczenia
Ramy data governance są skuteczne tylko wtedy, gdy ich wyniki są widoczne dla osób odpowiedzialnych za jakość danych. Codzienny pulpit data governance — zbudowany na podstawie wyników przeglądu jakości danych, metryk kompletności rejestracji w katalogu, statusu zgodności z politykami retencji oraz podsumowań dzienników audytowych — daje opiekunom danych (data stewards) widoczność potrzebną do wykrywania i rozwiązywania problemów, zanim przedostaną się one do zbiorów curated udostępnianych analitykom. Sam pulpit musi być wdrożony w odpowiednim segmencie sieci właściwym dla danego poziomu klasyfikacji, a jego dane muszą pochodzić wyłącznie z tego segmentu — pulpit data governance dla danych o klasyfikacji Secret nie może pobierać metryk z infrastruktury monitoringu o klasyfikacji Unclassified. Traktowanie data governance jako sprawy drugiej kategorii, która może dzielić infrastrukturę z usługami o niższej klasyfikacji, jest częstym błędem architektonicznym, który tworzy zarówno ekspozycję na ryzyko niezgodności, jak i operacyjny ślepy punkt w zakresie jakości danych najbardziej wrażliwych zasobów data lake.