DealerBit — modernizacja hurtowni danych

Przepisanie 10-letniej platformy BI bez zepsucia ani jednej liczby.

Czym jest

DealerBit to wielodostępowa (multi-tenant) hurtownia danych BI/raportowa dla grup dealerów motoryzacyjnych. Pobiera dane operacyjne — zlecenia serwisowe, faktury, stany magazynowe części, CRM sprzedażowy, księgowość, HR/płace — z wielu różnych systemów zarządzania dealerem (DMS) do centralnej hurtowni, a następnie materializuje raporty w podziale na organizacje i lokalizacje.

Wyzwanie

Starsza platforma rozwijała się przez około 10 lat i trzymała logikę biznesową jednocześnie w 3–4 różnych miejscach: w kodzie aplikacji PHP, w triggerach/funkcjach/widokach MySQL, w procedurach składowanych żyjących na serwerach DMS samego klienta (liczonych zdalnie, poza jakimkolwiek repozytorium) oraz w rozproszonych wartościach zakodowanych na sztywno — przy czym formuły raportów były wykonywane przez surowe PHP-owe eval(), a jeszcze więcej logiki było ukryte w JSON-ie. Czerpała z ~8 heterogenicznych źródeł danych (MS SQL, Firebird, MySQL, REST API, systemy księgowe), zasilających ~44 raporty dynamiczne i ~23 raporty listowe. Nikt nie potrafił w pełni wyjaśnić, jak powstają te liczby.

Co zbudowaliśmy

• Silnik Python budowany od zera, który czyta tę samą produkcyjną bazę danych w trybie tylko do odczytu i porównuje swój wynik z wynikami starego systemu komórka po komórce — dokładna zgodność (decimal 15,5 / HALF_UP) jest kryterium sukcesu
• Twarda reguła architektoniczna: cała logika żyje w kodzie — bez triggerów w bazie, bez eval, bez logiki w JSON-ie. Stary system jest referencją co do tego, co liczyć, a nie jak
• Dyscyplina zakresu: odbudowaliśmy tylko to, czego rzeczywiście używa aktywny klient, odrzucając lata wielodostępowego balastu i niedeterminizmu
• “Mapa pokrycia” w postaci UI opartego na FastAPI + Jinja, pokazująca raport po raporcie i komórka po komórce dokładnie, które wartości są odtworzone i zgodne (zielony/czerwony/niezaimplementowany)

Wyniki / wpływ

• Udowodniona zgodność komórka po komórce na najtrudniejszych raportach: flagowa Analiza Działu Serwisu (obejmująca 6 rodzin DMS) osiągnęła 296/296 komórek (100%); inny kluczowy raport 361/361; budząca respekt starsza funkcja składowana zaimplementowana ponownie w Pythonie na poziomie 100/100
• Zestaw testów na zielono (110 przechodzących); historyczne “niezgodności” prześledzone do nieaktualności snapshotów starego systemu, a nie do błędów logiki
• Logika biznesowa skonsolidowana z 3–4 miejsc w jedną bazę kodu, usuwając martwy kod i eliminując niedeterminizm starego systemu
• Przepisanie wspierane przez AI okazało się ~1,6–3× tańsze niż budowa czysto ludzka, co zweryfikowano mierzonymi w czasie próbami pokazującymi, że praca mechaniczna kompresuje się 10–50×

Stack

Przepisanie: Python (FastAPI, Jinja, pytest), czytający hurtownię MariaDB, orkiestrowany przez sterowalne workery. Stary system (referencja): PHP 8 z własnym frameworkiem + komponenty Symfony, RabbitMQ, MariaDB (282 tabele), Vue 2 SPA (~89 tys. LOC), dumpery PowerShell.

Status: Migracja w toku — zgodność udowodniona na raportach pilotażowych; stary system pozostaje nietknięty, dopóki przepisanie jest walidowane.