Przejdź do treści
Condictor Studio
Nasz produkt / R&D, nie zlecenie klienta

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.

Schemat warstw: po lewej trzy kolektory ze strzałkami do walca bazy danych w środku, z bazy strzałki do bloku API, a z niego do dashboardu i do raportów
Architektura: kolektory zapisują do bazy szeregów czasowych, API karmi dashboardy i raporty.

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.