Ocena popularnych narzędzi klasy DataCatalog dostępnych jako open-source
Wstęp
Wraz ze wzrostem złożoności architektur danych i intensyfikacją wymagań regulacyjnych, organizacje coraz częściej poszukują rozwiązań umożliwiających spójne zarządzanie metadanymi, jednolite opisywanie zasobów informacyjnych, automatyzację procesów kontrolnych i zapewnienie przejrzystości przepływu danych.
W wielu środowiskach dojrzałość operacyjna wymaga dziś nie tylko rejestracji zasobów i ich klasyfikacji, ale również powiązania ich z procesami ETL/ELT, zewnętrznymi słownikami referencyjnymi, modelami hurtowni czy narzędziami raportowymi.
W tym kontekście, narzędzia klasy Data Catalog stanowią ważny element ekosystemu danych: umożliwiają uporządkowanie definicji biznesowych, budowę centralnego słownika pojęć, zwiększenie transparentności przepływów, skrócenie czasu odnajdywania danych oraz ograniczenie ryzyka błędów wynikających z niespójności. Dla organizacji wdrażających lub modernizujących hurtownie danych i platformy analityczne kluczowe jest także realne TCO takich rozwiązań – obejmujące zarówno koszty wdrożenia i utrzymania, jak i nakład pracy zespołów DevOps i Data Engineering.
Zabrzmiało trochę jak korpomowa i marketing bez realnego pokrycia? I tak trochę jest z narzędziami DataCatalog wdrażanymi w wielkich korporacjach finansowych. Uruchamiane są wielkie projekty, które mają spełnić wyśrubowane wymagania regulacyjne i objąć swoim zakresem wszystkie dane oraz przepływy, które funkcjonują w organizacji.
Po wielu miesiącach wysiłku ogłaszany jest sukces wdrożeniowy, wszyscy świętują. Problem tylko w tym, że po kolejnych tygodniach okazuje się, że mało który potencjalny użytkownik korzysta realnie z takiego narzędzia, gdyż… jest po prostu zbyt złożone i nieprzystępne.
W Sanmargar Team zadaliśmy sobie pytanie: czy można to zrobić prościej i skuteczniej? Postanowiliśmy poszukać rozwiązania, w którym narzędzie typu open-source pozwoli wprowadzić DataCatalog tak, by ten praktycznie wspierał procesy biznesowe.
Wybór aplikacji do testów
W poszukiwaniu rozwiązania, które wychodziłoby przede wszystkim naprzeciw potrzebom użytkowników biznesowych (a nie formalnym wymaganiom), postanowiliśmy się przyjrzeć stosunkowo prostym narzędziom, które dostępne są jako oprogramowanie otwarte. Spośród kilku najbardziej popularnych, po wstępnej selekcji, wybraliśmy dwa rozwiązania, które trafiły „na warsztat”:
- Open Metadata https://open-metadata.org/
- Data Hub https://datahub.com/
Oba te narzędzia uruchomiliśmy we własnej dedykowanej infrastrukturze, podłączyliśmy do różnych źródeł danych, nakarmiliśmy zestawem pojęć biznesowych, reguł walidacji oraz parametrów jakości danych.
Cechy idealnego narzędzia Data Catalog
W celu porównania najważniejszych cech narzędzi, zdefiniowaliśmy subiektywne wymagania modelowe, które spełniałyby podstawowe przyjęte przez nas założenie, tj.: stosunkowo łatwą wdrażalność oraz możliwie dużą użyteczność dla odbiorców po stronie biznesu.
Wymagania te ujęte zostały w 10 kategoriach funkcjonalnych, które nakreślę poniżej, wraz z definicją dla narzędzia „idealnego”:
- Przyjazność interfejsu i łatwość poruszania się w aplikacji, bez konieczności szkolenia:
- Prosty interfejs przy wyszukiwaniu głównych funkcjonalności, umożliwiający jednocześnie przejście do szczegółów. Przykładowo wyszukujemy interesujący nas termin finansowy, znajdujemy zasoby (najczęściej dane), które są z nim powiązane, możemy w łatwy sposób nawigować do najniższego szczegółu, czyli np. kolumny w określonej tabeli.
- Możliwość dostosowania interfejsu do roli zalogowanego w systemie użytkownika. Jak to rozumieć: użytkownik z rolą administratora ma dostęp do wszystkich funkcjonalności narzędzia, w tym możliwość definiowania nowych źródeł danych, przepływów, parametrów sterujących mechanizmami wyszukiwania, etc. Z kolei rola autora, eksponuje funkcjonalności związane z opisaniem zarejestrowanych zasobów, tworzeniem pojęć biznesowych czy definiowaniem powiązań pomiędzy pojęciami a zasobami. Rola zaś ogólnie pojętego „czytelnika” pozwala na łatwy dostęp do wyszukiwania, przeglądania czy komentowania i oceny przydatności.
- Przeglądanie i prezentacja zasobów: uporządkowana i zrozumiała prezentacja zarejestrowanych zasobów, gdzie istotna jest zarówno estetyka interfejsu jak również jego responsywność czy intuicyjne poruszanie się po kolejnych poziomach powiązań pomiędzy zasobami (przykładowo: domena 🡪 źródło 🡪 baza danych 🡪 schemat 🡪 kolumna 🡪 szczegóły dot. kolumny).
- Wyszukiwanie: idealnym rozwiązaniem jest pojedyncze okno wyszukiwania, w któreą można wprowadzić tekst w dowolnej konfiguracji gramatycznej, na podstawie którego wyszukiwane są obiekty, a wyniki wyszukiwania grupowane są w kategorie (definicje, słowniki, pola, etc.). Jeżeli w wyniku wyszukiwania mamy określoną definicję biznesową, to od razu prezentowane są powiązane z nią zasoby: słowniki, tabele, kolumny.
- Statystyki tabel i pól: zebrane w jednym miejscu wszystkie główne statystyki dotyczące zasobu, z możliwością drążenia do szczegółów, typu:
- rozkłady wartości (histogram oparty o wartości pola),
- przykładowe dane,
- informacje do poziomu pola o dacie występowania pierwszej niepustej wartości,
- na poziomie tabeli pierwsza i ostatnia data danych, oraz sposób partycjonowania.
- Metryczki Data Governance: przy każdym obiekcie bazodanowym wyświetlona informacja dot. ról i właścicielstwa, wraz z możliwością dowiązania dokumentacji, takiej jak konfiguracja dostępu do zasobu poprzez narzędzie klienckie (SQL Developer, MIIS czy DBeaver), co znacząco upraszcza uzyskanie dostępu do danych.
- Interfejs do przeglądania zawartości słowników: dość nieoczywiste wymaganie dla narzędzia katalogującego de facto metadane zasobów. A jednak wymaganie wynikające bezpośrednio z praktyki użycia. Bardzo często, znajdując interesujące nas dane w gąszczu zinwentaryzowanych zasobów, otrzymujemy w wyniku interesującą nas kolumnę tabeli, ale zamiast deskryptywnych danych, przechowywane są tam numeryczne kody. Aby je odpowiednio zinterpretować i przetworzyć w użyteczną informację, potrzebujemy powiązanego słownika, który umożliwi nam wykonanie tej operacji. I w tym właśnie celu potrzebna jest funkcjonalność przeglądania zawartości słowników.
- Tworzenie definicji biznesowych:
- elastyczny edytor do wprowadzania tekstu, włącznie z podstawowym formatowaniem (czcionki, kolory, tabelki),
- szybkie powiązanie do tabel i pól,
- rozdzielone informacje o dacie wprowadzenia definicji jak i dacie jej aktualizacji.
- Data lineage i impact analysis:
- data lineage z wyborem daty, na którą chcemy prowadzić obserwację,
- impact analysis dla bieżących przetwarzań,
- zejście z poziomu tabeli na poziom kolumny,
- podgląd kodów przekształcających dane na poziomie kolumny.
- Data Quality:
- generacja kodów testów z poziomu interfejsu,
- prezentacja wyników z formatowaniem warunkowym oraz pokazywaniem wyniku na osi czasu,
- metryczka Data Governance dla właścicieli KPI jakości danych,
- miejsce na pokazanie opisu czego dotyczy konkretny test.
- Integracja z innymi narzędziami czy serwisami:
- możliwość osadzania (np. w oknach) elementów innych narzędzi – przykładowo Text2SQL, raporty BI, logi przetwarzań,
- dwukierunkowe interfejsy (API) do metadanych, umożliwiające zarówno odczyt jak i automatyzację aktualizacji ich zawartości.
- Łatwość instalacji, konfiguracji oraz aktualizacji:
- możliwość instalacji w różnych architekturach, w tym zwirtualizowanych takich jak docker czy kubernetes,
- przystająca do architektury przejrzysta instrukcja instalacji,
- dostępność aktualizacji oraz prostota ich aplikacji na działającym narzędziu,.
- dostęp do praktycznej bazy wiedzy: fora, kanały komunikacji ze społecznością etc.
Mając już za sobą przedstawienie wymagań funkcjonalnych dla „narzędzia marzeń” przejdźmy teraz do analizy tego, co oferują wybrane przez nas do testów narzędzia.
Open Metadata
Według twórców rozwiązania, Open Metadata to platforma klasy Data Catalog zaprojektowana jako centralny hub zarządzania metadanymi, łączący w jednym modelu informacje techniczne, biznesowe i operacyjne. Narzędzie oferuje rozbudowane możliwości automatycznego skanowania źródeł danych, integrację z popularnymi hurtowniami, systemami ETL oraz narzędziami BI, a także wsparcie dla data lineage, jakości danych i zarządzania definicjami biznesowymi.
Architektura rozwiązania opiera się na spójnym modelu metadanych oraz jasno zdefiniowanych interfejsach API, co ułatwia rozszerzanie funkcjonalności i integrację z innymi elementami ekosystemu danych. Open Metadata kładzie duży nacisk na użyteczność interfejsu użytkownika oraz na uproszczenie procesów operacyjnych. Dzięki temu może pełnić rolę wspólnego punktu odniesienia zarówno dla zespołów technicznych, jak i użytkowników biznesowych.
Rozpoczynając testy Open Metadata uruchomiliśmy go w środowisku docker’owym, w wersji 1.9.4. W trakcie testowania funkcjonalności kilkukrotnie aktualizowaliśmy wersje, kończąc testy z wersją 1.10.2.
Jak przedstawia się nasza ocena rozwiązania w poszczególnych kategoriach?
Przyjazność interfejsu
- wyraźnych kartach: Overview, Schema, Lineage, Profiler, Properties
- prostym układzie opartym o zakładki/karty.
Role są wyraźnie oddzielone (Admin, Steward, Consumer).
Open Metadata ma również bardzo dobrze zorganizowaną nawigację:
- źródło danych → schemat → tabela → kolumny,
- każde miejsce ma przejrzyste zakładki (metadata, profiling, lineage, queries),
- wizualizacja jest czysta i przewidywalna.
Wyszukiwanie
Z jednej strony Open Metadata ma bardzo szeroką funkcjonalność definiowania sposobu działania mechanizmów wyszukiwania (ElasticSearch) z poziomu interfejsu. Z drugiej strony część z dostępnych opcji nie działa, lub działa inaczej niż można by się spodziewać.
Bardzo ciężko ustawić wyszukiwanie po fragmentach opisów lub nazw. Działa dla definicji, nie działa dla pól. Wyszukiwanie kończy się na poziomie tabeli, bez przejścia do pola. Nie ma łatwego przejścia od definicji do pola jak i od słownika do pola.
Pomimo bardzo obiecujących możliwości konfiguracyjnych mechanizmu wyszukiwania z poziomu interfejsu administracyjnego, nasza ocena w tej kategorii to jedynie 4/10.
Statystyki
- SQL Profiler z granulacją na poziomie kolumny,
- automatyczne: count, null %, distinct %, min, max, quantile, sample values,
- automatyczne wykrywanie anomalii (w połączeniu z DQ),
- wykresy, heatmapy, historia profili,
- pełny historyczny profil (line chart w czasie).
W praktyce nie wygląda już to tak idealnie:
- kastomizacja prezentowanych informacji jest praktycznie zerowa,
- wyniki zapytań interpretowane są w dziwny sposób.
Metryczki Data Governance
- wspiera workflow w zakresie zatwierdzania zmian,
- umożliwia interakcję między użytkownikami.
Brakuje jednak takiej „modelowej” metryczki, jak została określona w „narzędziu marzeń”.
Interfejs do przeglądania zawartości słowników
Brak możliwości wyszukiwania zestawu pojedynczych wartości wraz z opisem (np. trzech kodów walut jednocześnie). Brak możliwości eksportu zawartości słownika np. do Excela.
Na plus: szybki podgląd w postaci dymku, ale do zmiany rozmiar dymku.
Tworzenie definicji biznesowych
- opisy w Markdown,
- data utworzenia, data modyfikacji, autorzy,
- edytowalne wersje,
- rejestr zmian definicji biznesowych.
Brakuje jednak powiązania z polami, do których definicja jest przypisana. Jest opcja Request Update Description, ale musi być wyklikana ręcznie. Brak możliwości stworzenia mechanizmu/trigera wykrywającego np. że definicja się dezaktualizuje i wysyłającego do autora automatycznego maila.
Data Lineage i Impact Analisys
- ładna, czytelna wizualizacja,
- węzły klikane, szybkie przechodzenie,
- impact analysis,
- lineage history.
Z drugiej strony funkcjonalność ma sporo minusów:
- ograniczony do kodów bieżących,
- brak możliwości sprawdzania jak kod wykonywał się w przeszłości.
Data Quality
- testy jakości danych wbudowane natywnie,
- reguły na: wartości, statystyki, dystrybucje, anomalii,
- automatyczne testy z profilerem,
- historia wyników testów (wykresy),
- alerty (Slack, Teams, email),
- definicja kontraktów danych (Data Contracts).
W porównaniu z oczekiwaniami w zakresie narzędzia idealnego – ma spore braki, np.:
- brak możliwości wyników działających na zakresach typu: Excellent, Good, Medium, Weak, Bad,.
- odpowiedzi wyłącznie typu TAK lub NIE.
Integracja
Najsłabszy element narzędzia w kontekście integracji zdefiniowanej wg. naszych oczekiwań, tj. możliwości osadzania własnych komponentów w narzędziu.
Posiada API/SDK, które umożliwia integrację z innymi narzędziami, jednak nie jest to ten kierunek, którego byśmy oczekiwali od tego narzędzia.
Instalacja, konfiguracja i aktualizacja
Z perspektywy uruchomienia środowiska testowego, instalacja i konfiguracja jest stosunkowo prosta. Dokumentacja przygotowana jest w czytelny sposób, umożliwiający szybkie uruchomienie środowiska, szczególnie w skonteneryzowanym środowisku.
Aktualizacja do nowszych wersji przebiega bezproblemowo:
- backup bazy danych,
- pobranie aktualnego pliku .yaml i dostosowanie konfiguracji,
- położenie kontenerów,
- ponowne uruchomienie w zaktualizowanej konfiguracji.
Dodatkowo warto nadmienić szerokie grono użytkowników, wsparcie np. poprzez kanał Slack oraz częste aktualizacje obejmujące nowe funkcje oraz poprawę zgłoszonych błędów.
Data Hub
DataHub to dojrzała platforma open-source do zarządzania metadanymi, rozwijana pierwotnie na potrzeby dużych, rozproszonych środowisk danych i silnie osadzona w paradygmacie data mesh. Narzędzie zapewnia bogaty model metadanych, zaawansowane mechanizmy data lineage oraz szerokie możliwości integracji z systemami przetwarzania danych, hurtowniami i narzędziami analitycznymi.
Istotnym elementem DataHub jest rozbudowany ekosystem konektorów oraz mechanizmów ingestion, umożliwiających pozyskiwanie metadanych zarówno w trybie wsadowym, jak i zdarzeniowym.
Platforma została zaprojektowana z myślą o skalowalności i elastyczności, co czyni ją atrakcyjną dla organizacji o wysokim stopniu złożoności architektury danych, jednak wiąże się również z większymi wymaganiami w zakresie konfiguracji, utrzymania i zarządzania środowiskiem.
Testy aplikacji – podobnie jak w przypadku Open Metadata – prowadziliśmy w środowisku docker’owym. Przez cały okres trwania testów, realizowaliśmy je na najnowszej dostępnej na ówczas wersji 1.3.0.
Przyjazność interfejsu
DataHub od wersji v1.0 ma całkiem zgrabny i intuicyjny interfejs z hierarchicznym przeglądaniem baz / schematów / datasetów. Jednak DOMYŚLNIE jest raczej techniczny – ukierunkowany do użytkowników z wiedzą o danych (data engineers, data practitioners). Wg dokumentacji, dla lepszej użyteczności dla użytkowników biznesowych często używa się zewnętrznych nakładek/portali (np. PortalJS). Dostępne „z pudełka” role ograniczają się jedynie do okrojenia funkcjonalności, a nie zróżnicowania interfejsu względem przydzielonej roli.
Jeżeli chodzi o przeglądanie i prezentację obiektów, to interfejs na pierwszy rzut oka sprawia wrażenie bardziej czytelnego i przejrzystego. Czytelne ikonografiki, szybkie przełączanie się pomiędzy funkcjonalnościami, animacje przy przeglądaniu schematów data lineage sprawiają, że odbiór narzędzia jest bardzo pozytywny.
Podobnie jak w OpenMetadata problemem jest np. prezentacja zawartości tagów w formie etykiet (po najechaniu na nie kursorem myszy), jeżeli zawartość ta jest sformatowana w HTML (a na to pozwala edytor).
Wyszukiwanie
DataHub oferuje funkcję „Search and Discovery”, która indeksuje cały ekosystem danych (bazy, tabele, dashboards, ML modele, pliki itp.) i pozwala na wyszukiwanie. Można przeszukiwać metadane, nazwy, opisy, pojęcia biznesowe, etc.
Co do łączenia wyników w różnych kategoriach (definicje, słowniki, pola) – DataHub ma silny metadata-graph, gdzie różne typy encji (dataset, schemaField, glossaryTerm, chart, job itp.) są częścią tej samej przestrzeni.
Natomiast jeśli chodzi o „wyszukiwanie wartości słowników” (czyli same dane, rekordy słowników, a nie metadane) – DataHub to katalog metadanych, nie baza danych użytkowych, wiec takiej natywnej funkcji brak. Można (podobnie jak w OpenMetadata) wrzucić zawartość słowników do tagów, ale:
- aktualizacja wartości jest problematyczna,
- prezentacja zawartości tagu w formie etykiety jest mocno niedopracowana.
Statystyki
DataHub oferuje mechanizm profilingu (SQL Profiling) dla źródeł SQL – jeśli profilowanie zostanie włączone w konfiguracji ingestu. Profilowanie zbiera: liczby wierszy, null-counts, distinct values, min/max/średnia, histogramy, częstotliwości wartości, procenty wartości null, rozkłady itp.
W UI DataHub istnieje zakładka „Statystyki” – ale pojawia się tylko jeśli profilowanie było poprawnie przeprowadzone. Co ważne: użytkownicy narzekają, że profilowanie narzędziem jest bardzo kosztowne i mocno obciąża zasoby, jeżeli profilowane tabele są bardzo duże – chociaż na naszym środowisku testowym nie mogliśmy tego potwierdzić ze względu na niewielką liczbę danych. Natywnie brak informacji takich jak „pierwsza/ostatnia data nienullowa” albo „data dodania pierwszego/ostatniego rekordu”.
Dodatkowo brakuje możliwości podejrzenia próbki danych – informacja o rzeczywistych danych w źródle widoczna jest jedynie na poziomie kolumny tabeli.
Metryczki Data Governance
DataHub pozwala przypisać do encji metadata: właścicieli (owner), domain, tagi czy pojęcia biznesowe.
Możliwe jest zarządzanie użytkownikami, grupami, politykami dostępu (permissions) – ale funkcjonalność w tym zakresie jest mało rozwinięta.
Interfejs do przeglądania zawartości słowników
Podobnie jak w Open Metadata brak jest natywnej funkcjonalności do przeglądania wartości słowników. Można zasymulować tę funkcjonalność w postaci wyświetlania wartości jako etykiety, ale sama prezentacja zawartości jest jeszcze gorsza aniżeli w Open Metadata.
Tworzenie definicji biznesowych
DataHub Business Glossary pozwala zdefiniować pojęcia biznesowe, opisy, hierarchie, relacje, a następnie powiązać je z encjami (tabele, kolumny itp.).
Można edytować definicję, zapisać ją, przypisać właściciela, a UI Glossary oferuje nawigację, wyszukiwanie, edycję -> sam „wygląd” sprawia znacząco lepsze wrażenie niż w Open Metadata.
Patrząc jednak na wymagania modelowe, to GlossaryTerm (czyli definicja biznesowa) nie wspiera „sformatowanych opisów” typu HTML z tabelkami, kolorami, stylami.
Dodatkowo brak jest automatycznego zapisywania daty utworzenia/aktualizacji definicji przy edycji (np. audyt zmian), jak również brak jest analogicznego jak w Open Metadata workflow zatwierdzania zmian.
Brakuje również automatów do wysyłania maili o dezaktualizowaniu się definicji.
Data Lineage i Impact Analisys
W DataHub jest to jedna z kluczowych funkcji. Obsługuje zarówno lineage na poziomie datasetów, jak i – jeśli dostępne źródło wspiera – lineage na poziomie kolumn. Mamy możliwość wizualizacji zależności upstream/downstream, możliwość analizy wpływu zmian („impact analysis”), zarówno dla datasetów jak i (tam gdzie możliwe) kolumn.
Jeśli źródło nie wspiera automatycznej ekstrakcji lineage – jest możliwość ręcznego dodawania albo przez UI, albo przez API/SDK, co daje sporą elastyczność.
Minus: wsparcie kolumnowego lineage jest ograniczone do niektórych źródeł (np. BigQuery, Snowflake, Databricks, itd.).
Dla pierwotnych/metadanych źródeł lub mniej popularnych systemów nie gwarantuje się automatycznej detekcji.
Brakuje również automatycznego przechowywania “historycznych” lineage (np. zmiany między wersjami schematów), tj. lineage time-travel /wersjonowanie lineage.
Data Quality
W standardowej (community/open-source) wersji DataHub definiowanie testów jakości danych z poziomu GUI jest bardzo ograniczone. Nie wspominając już o warunkowym formatowaniu wyników czy śledzenia ich wyników w czasie.
Wydaje się, że jedynym rozwiązaniem jest użycie zewnętrznych wtyczek/narzędzi rozszerzających tę funkcjonalność.
Integracja
Architektura DataHub jest „schema-first” + „stream-based real-time metadata platform” + „federated metadata serving”, co daje dobrą podstawę integracji z różnymi systemami.
DataHub oferuje wiele prebudowanych konektorów do źródeł danych: bazy SQL (Oracle, MSSQL, Postgres, MySQL, itp.), data warehouses, BI narzędzia, pipeline tools, etc.
Interfejsy: REST API, GraphQL API, SDK, możliwość emitowania metadanych, możliwość subskrypcji zmian – to daje możliwość integracji z zewnętrznymi serwisami i automatyzacją.
Instalacja, konfiguracja i aktualizacja
Proces instalacji i konfiguracji środowiska Data Hub jest znacząco bardziej złożony aniżeli w przypadku Open Metadata.
Dodatkowo DataHub CLI i ingestion są silnie powiązane z Pythonem, więc aktualizacja DataHub w praktyce równa się aktualizacji paczek pythonowych plus rekonfiguracja środowiska.
Podsumowanie
Jak Open Metadata wypadło w testach?
Podsumowując testy OpenMetadata, można stwierdzić, że narzędzie dobrze realizuje założenia podstawowej funkcjonalności Data Catalog, oferując przejrzysty interfejs użytkownika, wsparcie dla zarządzania definicjami biznesowymi oraz mechanizmy data lineage i profilowania danych. Platforma sprawdza się w kontekście prostych i średnio złożonych środowisk danych. Jej instalacja, konfiguracja oraz aktualizacje są stosunkowo łatwe do przeprowadzenia, szczególnie w środowisku konteneryzowanym.
OpenMetadata umożliwia szybki podgląd metadanych, przejrzystą nawigację w strukturach danych oraz obsługę ról, co czyni ją użytecznym narzędziem zarówno dla zespołów technicznych, jak i użytkowników biznesowych.
Z drugiej strony, narzędzie ujawnia pewne ograniczenia w obszarach wyszukiwania, zaawansowanej analizy jakości danych, integracji z innymi komponentami oraz przeglądania słowników wartości. Wyszukiwanie nie zawsze pozwala na efektywne odnalezienie powiązanych pól czy wartości słowników, a wizualizacje i metryki jakości danych działają w ograniczonym zakresie. Integracja z zewnętrznymi systemami jest możliwa przez API/SDK, jednak nie odpowiada w pełni oczekiwaniom „narzędzia idealnego”.
Pomimo tych ograniczeń, Open Metadata cechuje wysoka stabilność, aktywna społeczność oraz częste aktualizacje, co w połączeniu z intuicyjnym UI i dobrym wsparciem administracyjnym czyni ją solidnym wyborem dla organizacji poszukujących open-source’owego Data Catalog o relatywnie niskim TCO.
Jak DataHub wypadło w testach?
DataHub to rozbudowana platforma open-source klasy Data Catalog, skierowana przede wszystkim do dużych, rozproszonych środowisk danych i użytkowników z doświadczeniem technicznym.
Narzędzie oferuje bogaty model metadanych, zaawansowane mechanizmy data lineage, wsparcie dla Business Glossary oraz szeroki zestaw konektorów i mechanizmów ingestion. To pozwala na integrację z hurtowniami danych, systemami ETL oraz narzędziami analitycznymi.
Interfejs użytkownika jest czytelny i hierarchiczny, umożliwia szybkie przeglądanie baz, schematów i datasetów, a wizualizacja zależności i analiza wpływu zmian („impact analysis”) działają sprawnie i intuicyjnie.
DataHub sprawdza się zwłaszcza w środowiskach o dużym stopniu złożoności architektury danych, oferując skalowalność i elastyczność w zarządzaniu metadanymi.
Jednocześnie DataHub ujawnia pewne ograniczenia, szczególnie w obszarach natywnego wyszukiwania wartości słowników, profilowania dużych zbiorów danych oraz automatyzacji procesów związanych z definicjami biznesowymi. Narzędzie wymaga większego nakładu pracy przy instalacji i konfiguracji, w tym utrzymania środowiska Pythonowego i znajomości DataHub CLI, co zwiększa złożoność operacyjną w porównaniu do prostszych rozwiązań. Funkcjonalności związane z Data Quality są ograniczone w wersji open-source i często wymagają stosowania dodatkowych wtyczek.
Mimo tych wyzwań, DataHub wyróżnia się rozbudowanymi mechanizmami integracji, zaawansowanym lineage zarówno na poziomie datasetów, jak i kolumn w obsługiwanych źródłach oraz aktywnym ekosystemem konektorów, co sprawia, że platforma jest atrakcyjnym rozwiązaniem dla organizacji potrzebujących pełnej kontroli nad metadanymi w złożonym, rozproszonym środowisku danych.
Wnioski z testów
Testy narzędzi OpenMetadata oraz DataHub pokazują, że oba projekty open-source dobrze spełniają podstawowe funkcje katalogowania danych, choć różnią się zakresem funkcjonalności, złożonością operacyjną i wymaganiami dotyczącymi utrzymania.
OpenMetadata wyróżnia się prostym i intuicyjnym interfejsem, łatwością instalacji oraz sprawnym zarządzaniem definicjami biznesowymi i metadanymi. Platforma ta jest odpowiednia dla organizacji o średniej lub umiarkowanej złożoności środowiska danych, które poszukują narzędzia gotowego do użycia „z pudełka”, z relatywnie niskim kosztem operacyjnym i szybkim onboardingiem użytkowników biznesowych.
DataHub natomiast kierowany jest do organizacji o dużej skali i rozproszonej architekturze danych, które wymagają zaawansowanego lineage, elastycznej integracji z różnymi źródłami oraz rozbudowanego ekosystemu konektorów i mechanizmów ingestion. Narzędzie cechuje się większą złożonością instalacji i konfiguracji, ograniczeniami w obszarach wyszukiwania wartości słowników oraz wbudowanej jakości danych, ale rekompensuje to mocnymi funkcjami integracyjnymi, wsparciem dla data lineage na poziomie kolumn i możliwością dostosowania do skomplikowanych środowisk data mesh.
Wybór pomiędzy OpenMetadata a DataHub powinien być zatem uzależniony od wielkości środowiska danych, dojrzałości zespołów technicznych oraz potrzeb w zakresie zaawansowanego zarządzania metadanymi i integracji z ekosystemem danych.
Rozwiązania open-source coraz częściej stanowią realną alternatywę dla dużych, skomplikowanych wdrożeniowo i kosztownych platform. Chociaż „narzędzie marzeń” nie istnieje, rozwiązania te są wystarczająco funkcjonalne, a jednocześnie bardziej elastyczne i efektywne kosztowo.
