Platforma analityczno-predykcyjna na TimescaleDB
Nasz produkt na produkcji: monitorowane kolektory danych, baza szeregów czasowych, dashboardy i cykliczne raporty. Zbudowaliśmy go u siebie.
TimescaleDB · PostgreSQL · Python · FastAPI · Next.js · React · VPS · Discord
To nasz własny produkt — zbudowaliśmy go u siebie i sami go utrzymujemy. Nie jest to zlecenie klienta ani demo do prezentacji: platforma działa na produkcji, na naszym VPS, z realnymi użytkownikami. Pokazujemy ją, bo w obszarze danych to mocniejszy argument niż deklaracja.
Co to jest
Platforma, która zbiera dane w sposób ciągły, przechowuje je jako szeregi czasowe i zamienia w metryki, prognozy i raporty.
- Kolektory uruchomione jako usługi ciągłe — pobierają dane, normalizują je i zapisują do bazy, a monitoring ujawnia przerwy.
- Baza szeregów czasowych (TimescaleDB na PostgreSQL) jako jedno miejsce prawdy o całej historii pomiarów.
- Warstwa analityczna i predykcyjna — statystyka i modele liczone na tych samych danych, bez ręcznego eksportu do arkusza.
- Interfejs z dashboardami, roadmapą i zakładką audytów — stan projektu jest widoczny, nie opowiadany.
- Raportowanie cykliczne, w tym raporty dla inwestorów, oraz ogłoszenia o wdrożeniach publikowane na Discorda.
- Społeczność użytkowników na Discordzie — najkrótsza pętla zwrotna, jaką znamy: zgłoszenie trafia do nas od razu, a nie w kwartalnym przeglądzie.
Jaki problem rozwiązuje
Trzy sytuacje, które znamy z praktyki i które ta platforma zamyka:
- Dane są w kilku miejscach i nie ma obrazu całości. Raport składa się ręcznie, więc powstaje rzadko i zawsze po fakcie.
- Pomiar bez historii nie odpowiada na pytanie „czy jest lepiej niż miesiąc temu”. Szeregi czasowe odpowiadają, bo trzymają każdy stan, a nie tylko ostatni.
- Pilotaż na laptopie nie odpowiada na pytanie „co się dzieje w środku nocy”. Kolektor jako usługa na serwerze odpowiada — i sam zgłasza, kiedy przestaje zbierać.
Jak to zbudowaliśmy
Kolektory to usługi w Pythonie działające na VPS w sposób ciągły i pilnowane przez monitoring. Kluczowa decyzja projektowa: awaria kolektora musi być widoczna, nie cicha — luka w danych jest gorsza niż brak danych, bo wygląda jak wynik.
Dane trafiają do TimescaleDB, czyli PostgreSQL z partycjonowaniem po czasie i agregacjami dla szeregów czasowych. To samo da się zbudować w czystym Postgresie, ale nie za darmo — tu dostajemy to jako właściwość bazy, a nie jako kod, który trzeba utrzymywać.
Logika i API są w Pythonie (FastAPI), warstwa widoku w Next.js i React. Migracje bazy leżą w repozytorium i są weryfikowane przed przekazaniem na serwer. Codzienny audyt sprawdza trzy rzeczy: czy migracje się zgadzają, co mówią logi i czy kolektory realnie zbierają dane — a rozbieżności zapisuje jako plan naprawy.
Wdrożenie: VPS, usługi systemowe, monitoring i kopie zapasowe. Świadomie bez „magicznego deployu” z chmury — środowisko da się opisać, odtworzyć i przekazać razem z kodem.
Czego to dowodzi
Że umiemy dowieźć system danych na produkcję i przy nim zostać — z kolektorami, monitoringiem, migracjami i raportowaniem, a nie tylko z dashboardem na screenshocie. To bezpośredni dowód dla usługi dane i analityka, a same kolektory są produkcyjnym przykładem automatyzacji procesów.
Nie pokazujemy tu cudzych danych — to nasza własna platforma, więc możemy mówić otwarcie o architekturze i mechanice. Jak pracujemy: proces. Czym budujemy: stack.
