Kontrakty Danych to umowy w stylu interfejsu pomiędzy inżynierami oprogramowania/danych, którzy zarządzają usługami, a konsumentami danych, którzy rozumieją, jak działa biznes. Celem jest generowanie dobrze zaprojektowanych, wysokiej jakości, godnych zaufania danych w czasie rzeczywistym.
Jest to abstrakcja, która pozwala inżynierom odseparować ich bazy danych i usługi od wymagań analityki i uczenia maszynowego. Unika to incydentów niszczenia produkcji przy modyfikacji schematu, ponieważ są one weryfikowane i egzekwowane.
Ilustracja autorstwa Chada Sandersona w artykule The Rise of Data Contracts - by Chad Sanderson
Chad Sanderson powiedział, że w Convoy używają Protobuf i [Kafka](Apache Kafka), aby abstrahować transakcje CRUD. Określają schemat na podstawie tego, czego potrzebują, a nie tego, co dostają ze źródła. Podobnie jak Zasoby Zdefiniowane Programowo (Software-Defined Assets) opisują Data Assets w sposób deklaratywny i ustalają oczekiwania.
Confluent również zbudował podobne funkcje na wierzchu Kafki przy użyciu ich Rejestru Schematów, a terminy takie jak Warstwa Semantyczna i API Analityczne (z GraphQL) dążą do osiągnięcia podobnych celów.
Kontrakty Danych nie mają zastępować potoków danych i Nowoczesnego Stosu Danych (Modern Data Stack), bardziej rozwiązania wsadowego. Są dobre do szybkiego prototypowania. Możesz zacząć definiować kontrakty danych, gdy masz pewną wiedzę o danych.
Ciekawie jest porównać to z Siatką Danych (Data Mesh), która jest organizacyjną strukturą z mikroserwisowym podejściem do danych. Siatka Danych nie określa, które dane powinny być wysyłane ani nie waliduje danych wysyłanych z produkcji pod kątem poprawności lub zgodności z oczekiwaniami konsumenta.
Kontrakty Danych są również formą [Gospodarki Danych (Data Governance)]. Ten termin jest bardzo ogólny i staje się bardziej konkretne dzięki wyraźnym kontraktom. Możesz także użyć Great Expectations, aby określić oczekiwania dotyczące swoich danych, co moim zdaniem jest świetnym sposobem na rozpoczęcie.
Dyskusja na YouTube z Chadem Sandersonem i Ethanem Aaronem
Chad Sanderson mówi w Data Contract Battle Royale w/ Chad Sanderson vs Ethan Aaron - YouTube:
- To po prostu wersja bazy danych prawdziwej umowy.
- Prawdziwa umowa to tylko porozumienie między dwiema stronami, gdzie:
- Istnieje jakiś mechanizm egzekwowania tego.
- Umowa danych to podobne porozumienie, ale dotyczy ono osoby produkującej dane i osoby konsumującej dane, aby dostarczyć określony zestaw danych, który zwykle obejmuje schemat i jakiś mechanizm egzekwowania.
- Różnica między kontraktem danych a produktem danych:
- Kontrakt danych, który mówi co to są dane i jak zapewnimy ich jakość.
- Produkt Danych (Data Product), który mówi dlaczego potrzebujemy tych danych.
Ethan Aaron twierdzi, że jego problem z kontraktami danych polega na tym, że skupiasz się na zbyt wczesnym definiowaniu interfejsu/kontraktu. Na przykład, jeśli dużo zadań jest wykonywanych przez kilka zespołów lub osób, mamy kontrakt w celu uzgodnienia interfejsu. Argumentowałbym, że to dokładnie są produkty danych, a zamiast uzgadniać jakiś sztuczny kontrakt, decydujemy się na produkt, aby narzędzia i zespoły mogły być odrębne.
Podsumowanie artykułów na blogach
Doskonałe podsumowanie autorstwa Mehdi Ouazza na temat kontraktów danych From Zero To Hero. Ilustruje, jak Apache Kafka może być interfejsem definiującym kontrakt.
Ilustracja z artykułu Data Contracts — From Zero To Hero
Zobacz także Semaforowe Magazynowanie (Semantic Warehouse).