Aurora uczy się DuckDB, 16-latek wchodzi do Titana, Tigris ucieka z FoundationDB

Organizacje sportowe siedzą na tej samej instalacji co wszyscy inni: magazyny obiektów pełne plików Parquet, hurtownia, baza transakcyjna i kolejka, która utrzymuje to wszystko w zgodzie. Trzy teksty opublikowane w ciągu ostatnich 72 godzin opisują, jak ta instalacja jest rozbierana i składana na nowo. Stawka jest jedna: klub, liga albo nadawca szybciej albo wolniej zamienia mecz w liczbę.

Aurora dodaje DuckDB i krok ETL znika

AWS poinformowało 30 września, że Aurora PostgreSQL może teraz odpytywać dane operacyjne razem z danymi w formatach Apache Iceberg i Parquet. Klienci korzystają przy tym z istniejących aplikacji i narzędzi PostgreSQL, bez potoków extract, transform, load i bez duplikowania danych. Tworzą tabele obce PostgreSQL, które odwołują się do danych Iceberg lub Parquet w Amazon S3, Amazon S3 Tables albo AWS Glue Data Catalog. Aurora wykonuje te zapytania silnikiem DuckDB osadzonym w PostgreSQL, jak podano we wpisie AWS What's New. Funkcja jest ogólnie dostępna w Aurora PostgreSQL 17.11 i 18.6 oraz nowszych, we wszystkich komercyjnych regionach AWS i regionach GovCloud (US), bez dodatkowych opłat.

Dla stosu analityki sportowej to różnica między nocnym wsadem a zapytaniem, które działa, gdy mecz wciąż trwa.

Znika też znany tryb awarii. „Dostęp do nich zwykle wymagał potoków kopiujących dane z jeziora danych do Aurory, co podnosiło koszty i nakład pracy inżynierskiej w miarę zmian schematów” — napisało AWS. Firma podaje, że zewnętrzne katalogi zgodne z Iceberg REST Catalog, sfederowane przez Glue Data Catalog, też działają. Obciążenia wrażliwe na opóźnienia mogą z kolei zmaterializować dane Iceberg lub Parquet do natywnych tabel Aurora PostgreSQL zwykłym SQL, bez potoku ETL.

Kafka i migracja, której nikt nie chce robić dwa razy

Dostawca pamięci obiektowej Tigris opisał 30 września, dlaczego przeniósł zadania asynchroniczne z FoundationDB, jedynej bazy, której używa, na Kafkę. Wpis jest nietypowo szczery w kwestii kompromisów. Bardzo przypomina obciążenia danych sportowych, w których strumień śledzenia nie może zgubić zdarzenia tylko dlatego, że padł proces roboczy.

Tigris zaimplementował na FoundationDB system kolejek z artykułu o QuiCK, tego samego, którego Apple używa w CloudKit. Działało, ale planowanie wymagało wielu zapisów i skanów, konkurujących z zapytaniami użytkowników. Każde zadanie potrzebowało kilku zapisów, żeby się zakończyć. Nowi inżynierowie musieli uczyć się własnego kodu, który nie miał standardowej implementacji.

Zastrzeżenie firmy wobec Kafki warto przytoczyć w całości, bo to samo zastrzeżenie rozpozna większość zespołów danych sportowych. „Czy zdarzyło ci się czuć jak plastikowa torba dryfująca na wietrze, ale niezdolna ruszyć dalej z powodu czystego szaleństwa, jakie wiąże się z miesiącami permutowania flag JVM, żeby wycisnąć widmową wydajność i nie mieć serwerów nieustannie w ogniu?” — pyta wpis Tigrisa. Dalej przyznaje, że migracja nie była czystą wymianą: kolejki zostały w FoundationDB, a zadania takie jak odśmiecanie przeniosły się na Kafkę. „Przenieśliśmy zadania asynchroniczne, jak odśmiecanie, na Kafkę, możemy zmniejszyć obciążenie odczytu i zapisu w FDB i zrzucić spory kawałek tego nieznośnego własnego kodu” — czytamy.

Kto prowadzi strumień danych sportowych na wzorcu baza jako kolejka, powinien to przeczytać.

17,3 biliona wierszy, 16-latek i brakujący podpis

Najchętniej czytaną historią o danych w tym tygodniu nie jest premiera produktu. The Register podał 30 września, że 16-letni badacz bezpieczeństwa o imieniu Faav znalazł błąd uwierzytelniania w wewnętrznej usłudze analitycznej Microsoftu o nazwie Titan. Uzyskał dostęp administratora i uruchomił SQL bez ważnych poświadczeń. Baza, do której dotarł, zawierała szacunkowo 17,3 biliona zapisanych wierszy.

Titan jest dostępny wyłącznie dla pracowników Microsoftu przez interfejs webowy. Faav, pracując z zbudowanym przez siebie hackbotem AI o nazwie Antares, dotarł do API Titana przez host Azure Cloud Services, ponieważ Titan nie sprawdzał podpisu tokenu logowania. Microsoft od tego czasu zablokował API i wypłacił 5 000 dolarów nagrody za błąd. „Była 2 w nocy” — napisał Faav na blogu o ustaleniach. „Chciałem krzyknąć albo przynajmniej powiedzieć coś na głos, ale rodzice spali. Więc siedziałem i patrzyłem na 17 333 335 124 315, i jeszcze raz sprawdziłem rachunek”.

The Register zauważa, że Faav przepisał swój wpis na prośbę Microsoftu, wycinając fragmenty i liczby oraz przeformułowując opis skutków przed publikacją. Oświadczenie Microsoftu dla Faava, przytoczone w tym samym tekście, brzmi: „Ich zgłoszenie i skoordynowane ujawnienie luki pomogły nam lepiej chronić klientów przez wzmocnienie naszych usług”.

Dla organizacji sportowych istotnym ustaleniem nie jest liczba wierszy. Jest nim lekcja, którą wyciągnął Faav: „Titan sprawdzał zawartość JWT (dzierżawcę, odbiorcę, identyfikator aplikacji, użytkownika), ale nigdy nie weryfikował podpisu, najważniejszej części każdego sprawdzenia uwierzytelniania”. Każda platforma analityczna, która przyjmuje dane zawodników, medyczne albo kibiców, opiera się na tym samym sprawdzeniu tokenu. Ta sama awaria nie dałaby o sobie znać.

Kto jest właścicielem potoku i kto może zajrzeć do środka

Trzy inne teksty z tego tygodnia pokazują, że warstwa zarządzania wokół danych sportowych staje się trudniejsza, nie łatwiejsza. The Guardian podał 29 września, że amerykański sekretarz zdrowia Robert F. Kennedy Jr. przedstawił plany połączenia danych medycznych i dotyczących stylu życia oraz przeszukiwania ich za pomocą AI. Wskazał Medicaid jako „naprawdę użyteczne narzędzie” z „setkami milionów istnień w środku”. Medycyna sportowa i dane z wearables leżą obok tego potoku, a te same pytania o zgodę i wtórne wykorzystanie pozostają aktualne.

The Guardian podał też 30 września, że ponad 44 000 osób złożyło sprzeciwy prawne na podstawie artykułu 21 unijnego RODO wobec obsługiwanej przez Palantira Federated Data Platform należącej do NHS England. Sprzeciwy dotyczą przetwarzania ich danych osobowych. Wiceprezes Palantira na Wielką Brytanię i Europę, Louis Mosley, oskarżył krytyków o „syndrom szaleństwa na punkcie Palantira”. Firma twierdzi, że jej oprogramowanie pomogło trustom odnotować 117 000 dodatkowych operacji i 14,3% spadek opóźnień w wypisach pacjentów długoterminowych.

Tego samego dnia 404 Media podało, że Biuro Polityki Kontroli Narkotyków Białego Domu wykorzystuje program grantowy HIDTA, żeby ściągać lokalne dane z czytników tablic rejestracyjnych od Flock, Axon i innych dostawców na serwery federalne. W niektórych przypadkach przekazuje je do National License Plate Reader Program w DEA. Jeramie Scott z Electronic Privacy Information Center powiedział 404 Media: „Jeśli wkurza cię Flock, to powinno wkurzać cię też to”.

NL Times podał z kolei 30 września, że większość europejskich centrów danych trzyma w tajemnicy swój wpływ na środowisko. Mniej niż jedna czwarta większych holenderskich obiektów publikuje dane o zużyciu prądu i wody pitnej, mimo obowiązku z europejskiej dyrektywy o efektywności energetycznej, który obowiązuje od trzech lat. Centra danych sportu podlegają tej samej luce w raportowaniu.

Co z tego wynika

Kierunek techniczny jest jasny. Silniki zapytań przenoszą się tam, gdzie już leżą dane, kolejki oddzielają się od baz, a kopia ETL, którą zespoły analityki sportowej budowały od dekady, jest wycofywana przez samych dostawców. Kierunek zarządzania jest bardziej chaotyczny: więcej danych połączonych, więcej złożonych sprzeciwów, więcej nieujawnionej infrastruktury pod spodem.

Oba trendy spotykają się w tym samym miejscu. Klub, który potrafi odpytać swoje jezioro z Aurory w kilka sekund, to też klub trzymający dane, które regulatorzy, aktywiści i atakujący traktują teraz jako cel. Potok w tym tygodniu przyspieszył. Spory wokół niego prostsze się nie stały.