| title | author | date | geometry | colorlinks | output |
|---|---|---|---|---|---|
Formaty danych "cloud native" dla danych przestrzennych |
Tomasz Taraś |
2023-12-31 |
margin=2.5cm |
true |
pdf_document |
Spis treści:
- Krótka historia "chmury"
- Definicja formatu natywnego dla "chmury"
- Lista formatów
- Cloud Optimized GeoTiff (COG)
- GeoParquet
- GeoLake
- Havasu
- FlatGeoBuf
- Zarr
- PMTiles
- Cloud Optimized Point Clouds (COPC)
- Cesium 3D Tiles
- Bibliografia
Pojęcie chmury jest ciężkie do zdefiniowania. W skrócie można określić to jako korzystanie z usług innego podmiotu do wynajmu zasobów komputerowych np. do obliczeń lub przechowywania danych. [1]
Kiedyś dominującym modelem był hosting on-premise czyli serwery były własnością organizacji i znajdowały się zazwyczaj na terenie obiektu należącego do niej.
Usługi hostingu czy dedykowanego dla stron internetowych czy w postaci wynajem maszyn wirtualnych lub dedykowanych (fizycznych) istnieją dość długo, ale zaryzykowałbym stwierdzenie, że to co nazywamy chmurą to coś więcej i zaczęło się od oferty firmy Amazon pod nazwą AWS.
Platformy jak Amazon AWS, Microsoft Azure, czy Google Cloud, które są najpopularniejszymi "chmurami" oferują znacznie więcej niż samo wynajęcie maszyn wirtualnych. Można tam definiować sieci wirtualne wraz z regułami firewall, dostępy bazowane na rolach oraz korzystać z usług zarządzanych, czyli korzystać z oprogramowania do konkretnego zastosowania na przykład kolejka, broker wiadomości, hurtownia danych bez konieczności samodzielnej instalacji tego oprogramowania i zarządzania nim, a za to wszystko płacimy tylko za wykorzystane zasoby.
Moim zdaniem pewnego rodzaju rewolucją była usługa Object/Blob Storage nazwana S3 (od Simple Storage Service) stworzona przez AWS. Wcześniej przechowywanie danych odbywało się często na dyskach sieciowych. Rozszerzanie ich było dość kosztowne i wymagało sporo czasu, bo często wiązało się z zakupem nowego kontrolera i całej macierzy dysków. Alternatywą był ekosystem Hadoop z rozproszonym systemem plików HDFS, ale to była raczej domena zastosowań związanych z Big Data.
Usługa S3 w przeciwieństwie do tradycyjnych dysków sieciowych komunikowała się przez protokół HTTP. Jej API definiowało kilka podstawowych operacji jak wysyłanie, pobieranie, listowanie plików oraz sposób autoryzacji. Usługa ta pozwalała też rozdystrybuować pliki w wielu regionach geograficznych dla lepszej redundancji w sposób niewidoczny dla klienta. To co sprawiło, że ta usługa zdominowała rynek to jednak po prostu cena i elastyczność. AWS oferował chmurowe dyski sieciowe, ale wymagało to zadeklarowania konkretnej pojemności za którą się płaciło, niezależnie od wykorzystania. Za S3 płaci się tylko za przechowywane dane (plus liczbę operacji wykonywanych przez API), a ponadto ta cena jest znacznie (kilkukrotnie) niższa.
Usługa ta umożliwiła ewolucję koncepcji takich jak rozdział mocy obliczeniowej od danych (separation of storage and compute) i pozwoliła narzędziom wcześniej przywiązanym do ekosystemu Hadoop na samodzielne wykorzystanie.
Interfejs HTTP użyty jako protokół komunikacji różni się od wielu innych protokołów tym, że jest zaprojektowany do działania na zasadzie wysyłania wiadomości, raczej niż komunikacji ciągłej. Wysyłamy żądanie HTTP i dostajemy od serwera odpowiedź, nie mamy jakiegoś otwartego połączenia. Ma to pewne wady i zalety, ale tutaj nie będziemy się na tym skupiać. Dodam tylko, że jedną ciekawą funkcją jest wysłanie żądania HTTP proszącego o konkretny zakres odpowiedzi [2]. Funkcja niby niepozorna, ale bardzo potężna.
Jak wspominałem w poprzednim rozdziale dane w chmurze często przechowywanie są w usłudze takiej jak AWS S3, do której dostęp jest poprzez protokół HTTP.
Pobieranie za każdym razem całego pliku, żeby go otworzyć gdy go potrzebujemy jest bardzo niepraktyczne i po prostu wolne.
Mądrzy ludzie wymyślili więc, że w sumie jeżeli plik będzie miał w miarę regularną strukturę to można pobrać tylko jego kawałek i tylko ten kawałek odczytać.
Tę właśnie cechę określiłbym jako definiującą format danych jako natywny "chmurowo". Czyli format ten:
- powinien być możliwy do odczytania z sieci przez protokół HTTP
- powinno dać się go odczytywać bez pobierania całego pliku pobierając tylko interesujące nas kawałki
Dodatkowo prawdopodobnie powinien posiadać metadane pozwalające nam określić, które części pliku nas interesują, czyli na przykład jakiś indeks lub statystyki.
Definicja nie jest ścisła i różne podmioty różnie definiują. W kontekście danych przestrzennych organizacja "Cloud-native Geospatial Foundation" opublikowała artykuł [3], krótko tłumaczący ten temat, ale dyskusja na temat definicji dziejąca się na ich repozytorium GitHub nie jest zamknięta [4].
Poniżej opiszę kilka takich formatów, które są obecnie w użyciu.
Prawdopodobnie pierwszy format danych przestrzennych natywny dla chmury. Jest rozszerzeniem formatu GeoTiff, czyli rastrowego formatu danych.
Format jest kompatybilny wstecznie, więc każde oprogramowanie GIS, które jest w stanie otworzyć pliki GeoTiff poradzi sobie również z wersją "chmurową". Jest to możliwe dzięki temu, że oryginalny format nie specyfikował dokładnego ułożenia danych i można tak zapisać dane, żeby były podzielone na bloki, które możemy pobierać niezależnie od reszty pliku. [5]
Poza ułożeniem danych w "kafelki" (zamiast w domyślne "paski") dla ułatwionego dostępu przez HTTP format przewiduje możliwość przechowywania kopii obrazu źródłowego w mniejszych rozmiarach. Dodanie tych kopii co prawda zwiększy rozmiar finalnego pliku, ale mogą być one użyteczne dla klienta, który chce wyświetlić podgląd pliku i nie potrzebuje od razu pełnej rozdzielczości. [6]
Format Parquet [7] jest obecnie jednym z najbardziej popularnych formatów danych tabelarycznych. Jest formatem otwartym zarządzanym przez fundację Apache.
Format dane dzieli kolumnami, a nie wierszami. Dzięki temu możliwa jest lepsza kompresja danych. Pozwala to też wczytywać dane tylko z wybranych kolumn bez konieczności czytania danych wiersz po wierszu. W zastosowaniach analitycznych gdzie często dokonuje się agregacji po wybranych kolumnach pozwala to na dużo wydajniejsze przetwarzanie danych. Dodatkowo dane w pliku dzielone są na grupy wierszy (ang. row groups), które można przetwarzać lub pobierać niezależnie. Na końcu pliku umieszczone są metadane z informacjami o strukturze danych, w tym o kolumnach i ich typach, ile jest grup wierszy w pliku i gdzie się zaczynają i kończą oraz jakie są minimalne i maksymalne wartości dla każdej kolumny w ramach grupy. Informacje te pozwalają klientowi zdecydować czy chce pobrać cały plik czy na przykład jego część co pozwala na wydajne przetwarzanie danych w środowisku w którym obliczenia dokonywane są na innych serwerach niż znajdują się dane.
18 września 2023 r. została opublikowana wersja 1.0.0 standardu GeoParquet [8]. Chociaż już wtedy część narzędzi wspierała ten format, bo 15 grudnia 2022 wydano wersję 1.0.0-beta, a między wersją beta i finalną nie byo zmian. [9]
Standard ten opisuje metadane i sposób zapisu geometrii. W wersji 1.0.0 geometria jest zapisywana w formacie WKB (Well Known Binary). W przyszłych wersjach prawdopodobnie dodane zostaną inne sposoby zapisu geometrii, które pozwolą na lepszą kompresję lub szybszy odczyt.
Z czasem i rozwojem Data Lake [10] okazało się, że operacje na samych plikach mają pewne ograniczenia. W przypadku aktualizacji jakiegoś zbioru danych, jeżeli sam proces aktualizacji trwał długo to była spora szansa, że ktoś kto aktualnie korzysta z danego zbioru danych trafi na błąd, bo pliki, które próbował pobrać zostały usunięte. W tradycyjnych bazach danych, dzięki używaniu tranzakcji nie stanowiło to problemu. Dodatkowo silnik obliczeń, żeby skorzystać z danych najpierw musiał wylistować wszystkie pliki i sprawdzić ich strukturę, co przy większych zbiorach danych przekładało się na dodatkowy czas i koszty związane z wysyłaniem wielu żądań HTTP. Tranzakcyjność dodatkowo ułatwia radzenie sobie ze zmianami w strukturze danych, czy operacjach, które można by określić jako porządkowe takich jak scalanie mniejszych plików w większe itp.
Odpowiedzią na te problemy miały być specjalne formaty, które budowałyby na już używanych technologiach (np. pliki Parquet), ale miałyby właściwości ACID (Atomicity, Consistency, Isolation, Durability) [11], czyli w skrócie właśnie tranzakcyjność. Formaty te zgodnie z trendem na rynku i zapotrzebowaniami użytkowników przyjęły za odpowiedni poziom abstrakcji jako tabele. Tabele definiowałyby strukturę i lokalizację danych, a same dane byłyby zapisane w plikach w Data Lake. Metadane o tym jakie mamy zdefiniowane tabele wraz z informacjami, które pliki należą do danej tabeli miałyby być zapisane np w pliku JSON albo w oddzielnej usłudze udostępniającej API.
Trzy takie popularne formaty, które się wytworzyły to: Databricks Delta [12], Apache Iceberg [13] i Apache Hudi [14].
Początkowo żaden z nich miał rozwiązań dedykowanych dla danych przestrzennych. Żeby wypełnić tę lukę powstały dwa projekty budujące na formacie Iceberg i rozszerzające go o typ danych do przechowywania geometrii oraz możliwości przestrzennego partycjonowania danych. Projekty to GeoLake [15] i Havasu [16].
Format utworzony przez pracowników firmy Beijing Baixingkefu Network Technology Company Ltd. i opisany w pracy naukowej opublikowanej przez dziennik IEEE [17].
Format utworzony przez startup Wherebots, założony przez twórców projektu Apache Sedona (wcześniej GeoSpark), który jest rozszerzeniem dla biblioteki obliczeń rozproszonych Apache Spark.
Ciekawy format open-source zoptymalizowany pod kątem szybkości odczytu i zapisu kosztem braku możliwości modyfikacji już utworzonego pliku.
Strona projektu [18] zawiera opis struktury, porównania szybkości zapisu i odczytu do innych formatów jak Shapefile czy Geopackage oraz przykładowe implementacje pokazujące jak można korzystać z plików w tym formacie.
Specyfikacja projektu nie przewiduje kompresji, co może być istotnym ograniczeniem.
Stosunkowo nowy format otwarto-źródłowy stworzony do przechowywania wielowymiarowych macierzy. Zastosowania przestrzenne nie są jego głównym celem, format został stworzony jako dość uniwersalny dla różnych danych używanych w nauce.
Strona projektu [19] w zakładce "Adopters" wymienia różne praktyczne przypadki użycia tego formatu. W zakładce "Datasets" można znaleźć linki do publicznie dostępnych zbiorów danych w tym formacie.
Dzięki podziale macierzy na kawałki (ang. "chunks") można je odczytywać lub zapisywać wielowątkowo co zapewnia skalowalność. Format od początku projektowany tak by dane można było przechowywać i optymalnie wykorzystywać w chmurze.
Format stworzony i rozwijany przez Brandona Liu w ramach jego projektu Protomaps.
Format stworzony do map internetowych, w których zazwyczaj dane są serwowane w postaci "kafli" co pozwala na optymalną ich dystrybucję i wykorzystanie cache.
Format jest niejako przerobieniem innego formatu MBTiles na wersję, która mogła by być hostowana bezpośrednio przez Web Serwer albo z chmurowego Object Storage jak na przykład AWS S3.
Format może być użyty do przechowywania danych zarówno rastrowych jak i wektorowych. W przypadku danych wektorowych dane są zapisane w standardzie Mapbox Vector Tiles, który jest de facto standardem internetowych map wektorowych.
Na stronie głównej projektu jest demo pokazujące jakie żądania HTTP są wysyłane przez przeglądarkę. Widać dzięki temu, że odwołujemy się do poszczególnych części (zakresów bajtów) jednego pliku. [20]
Projekt zawiera kalkulator prezentujący ile można oszczędzić hostując własne mapy z użyciem tych technologii w porównaniu do korzystania z popularnych usług jak Google Maps API. [21]
Format inspirowany Entwine Point Cloud, ale z danymi zapisanymi w formacie LAZ 1.4 tylko uporządkowanym w sposób pozwalający na dostęp do poszczególnych kawałków danych. [22]
Format dedykowany - jak nazwa wskazuje - do przechowywania chmur punktów. Specyfikacja przewiduje, że dane samej chmury muszą być w jednym z określonych formatów punktów LAS (typy rekordów 6, 7 lub 8). Dodatkowo w pliku muszą być określone metadane o ułożeniu danych.
Strona projektu zawiera także narzędzie do podglądu takich plików wraz z paroma przykładami publicznych danych. [23]
Format dedykowany dla danych 3D w tym: chmur punktów, modeli budynków, drzew i innych. Jest tzw. Standardem Społeczności według OGC. [24]
Dość często kiedy mowa o kafelkach przynajmniej dla danych 2D oznacza to podział typu TMS lub częściej kompatybilny z Google Maps nazywany czasem kafelkami XYZ (podobny do TMS tylko z odwróconą osią "y"). Ten format dopuszcza partycjonowanie danych według różnych rodzajów struktur drzewiastych lub siatek [25]. Kolejna rzecz, która odróżnia ten format od innych "kafelków" to, że w miarę przybliżania lub oddalania mapy nie musimy pobierać nowych danych dla danego poziomu przybliżenia (zoom). W zamian dane mogą być podzielone na pierwsze, drugie, n-te do pobrania [26].
Nowsza wersja standardu, która jest przygotowywana nosi nazwę "3D Tiles Next" [27].
- [1] - https://pl.wikipedia.org/wiki/Chmura_obliczeniowa
- [2] - https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests
- [3] - https://cloudnativegeo.org/blog/2023/10/introducing-the-cloud-optimized-geospatial-formats-guide/
- [4] - cloudnativegeo/cloudnativegeo.org#18
- [5] - https://www.cogeo.org/
- [6] - https://www.cogeo.org/in-depth.html
- [7] - https://parquet.apache.org/
- [8] - https://geoparquet.org/
- [9] - https://github.com/opengeospatial/geoparquet/releases
- [10] - https://azure.microsoft.com/pl-pl/resources/cloud-computing-dictionary/what-is-a-data-lake/
- [11] - https://pl.wikipedia.org/wiki/ACID
- [12] - https://docs.databricks.com/en/delta/index.html
- [13] - https://iceberg.apache.org/
- [14] - https://hudi.apache.org/
- [15] - https://github.com/spatialx-project/geolake
- [16] - https://docs.wherobots.services/1.2.0/references/havasu/introduction/
- [17] - https://ieeexplore.ieee.org/document/10363173 Y. Zhang, B. Peng, Y. Du and J. Su, "GeoLake: Bringing Geospatial Support to Lakehouses," in IEEE Access, vol. 11, pp. 143037-143049, 2023, doi: 10.1109/ACCESS.2023.3343953.
- [18] - https://flatgeobuf.org/
- [19] - https://zarr.dev/
- [20] - https://protomaps.com/
- [21] - https://docs.protomaps.com/deploy/cost
- [22] - https://copc.io/
- [23] - https://viewer.copc.io/?copc=https://s3.amazonaws.com/hobu-lidar/autzen-classified.copc.laz
- [24] - https://cesium.com/why-cesium/3d-tiles/
- [25] - https://cesium.com/blog/2015/08/10/introducing-3d-tiles/#adaptable
- [26] - https://cesium.com/blog/2015/08/10/introducing-3d-tiles/#flexible
- [27] - https://cesium.com/blog/2021/11/10/introducing-3d-tiles-next/