🎯 Definicja
DQ Firewall to usługa w Ataccama ONE, która wystawia reguły jakości danych jako API. Pozwala to aplikacjom zewnętrznym (np. formularzom webowym, systemom ETL) sprawdzać jakość rekordu zanim zostanie on zapisany w bazie. To realizacja zasady “Prevention is better than Cure”.
🔑 Kluczowe punkty
- Real-Time DQ: Ocena jakości odbywa się w milisekundach, w locie.
- Centralizacja: Używasz tych samych reguł, co w batchowym monitoringu (np.
Valid Email). Nie musisz kodować walidacji dwa razy (raz w Java Script na frontendzie, drugi raz w SQL w hurtowni). - API: Dostęp przez REST lub GraphQL.
📚 Szczegółowe wyjaśnienie
Jak to działa?
- Tworzysz projekt “DQ Firewall”.
- Wybierasz atrybuty (np.
Name,Email,Phone). - Podpinasz reguły walidacyjne (np.
Namenie może być puste,Emailmusi mieć @). - Publikujesz projekt. System generuje endpoint HTTP.
- Twój developer frontendu, gdy użytkownik klika “Wyślij”, wysyła JSON-a do Ataccamy.
- Ataccama odpowiada:
{"status": "INVALID", "errors": ["Email format is wrong"]}. - Aplikacja blokuje zapis i pokazuje błąd użytkownikowi.
💡 Przykład zastosowania
Formularz rejestracji nowego klienta w banku. Zamiast pisać logikę walidacji PESEL-u w kodzie strony www (gdzie łatwo o błąd lub zmianę przepisów), strona wysyła PESEL do DQ Firewalla. Firewall sprawdza sumę kontrolną, datę urodzenia i płeć. Jeśli jest błędny, odrzuca go. Jeśli bank zmieni reguły (np. obsługa PESELi dla obcokrajowców), zmienia je w jednym miejscu (Ataccama), a wszystkie formularze od razu działają wg nowych zasad.
📌 Źródła
- Ataccama ONE Documentation - DQ Firewalls.
👽 Brudnopis
- DQ Firewall zapobiega efektowi “Garbage In, Garbage Out”.
- Może być też używany w procesie ETL (np. Apache NiFi strzela do Firewalla i odrzuca błędne rekordy na bok).