| # Python | # Spark | # Flask | # MySQL | # AWS |
| # SQL | # Hadoop | # Django | # PostgreSQL | # Azure |
| # VBA | # Kafka | # SQLite | # GCP | |
| # Flink | # MongoDB | # cloud on-premises |
| time: | May 2014 – May 2018 |
| role: | Data Scientist |
| company: | KRONOSPAN |
Kronospan is the largest chipboard producer in Europe. The massive scale of production was associated with the large-scale procurement of timber in various forms. All of the manufacturer’s factories in Poland handled around one million timber transactions per month. Each transaction consisted of dozens of variables, including information about carriers, suppliers, loading times, types of raw materials, payment methods, and many other factors crucial to analyzing these transactions.
PROJECT IMPLEMENTATION
The project lasted four years. Initially, I tried to detect fraud in mass transactions using Excel. However, I quickly realized that this approach was insufficient, especially in the context of Big Data. I decided to build infrastructure based on a relational Postgres database. While this solution seemed promising at first, it turned out to be impractical—manually adding each transaction to relational tables was time-consuming and inefficient. Ultimately, I could only generate reports on individual transactions without the ability to detect fraud patterns.
I exported these reports to Excel, allowing me to identify anomalies in time series data. Then, I switched to Python in a Jupyter environment, using Pandas. Initially, Pandas handled the data well, but as the volume of data grew, performance issues arose. At that point, I implemented Apache Hadoop infrastructure, which enabled more efficient management of large datasets.
The next step was introducing Apache Spark for data processing. The system worked well but processed data in large batches, updated once a day. This was insufficient because fraud was detected with a delay—sometimes even several days after the fact. To address this, I created an API that fetched transaction data directly from across Poland, allowing data to be received just a few hours after the actual timber reception.
With access to data streams, I applied Spark Structured Streaming. I also implemented Apache Kafka, which handled data ingestion, while Spark processed the data in real-time. The project was successfully completed after four years, evolving from primitive solutions to advanced real-time data streaming using Apache Spark and Apache Kafka.
PROJEKT: WYKRYWANIE OSZUSTW W TRANSAKCJACH MASOWYCH
Firma Kronospan jest największym w Europie producentem płyt wiórowych. Ogromna skala produkcji wiązała się z masowym pozyskiwaniem surowca drzewnego w różnych formach. Wszystkie fabryki producenta w Polsce realizowały miesięcznie około miliona transakcji związanych z przesyłem surowca. Każda transakcja zawierała dziesiątki zmiennych, takich jak informacje o przewoźnikach, dostawcach, czasach załadunku, rodzajach surowca, formach płatności oraz innych istotnych cechach, które były kluczowe w analizie tych transakcji.
REALIZACJA PROJEKTU
Projekt trwał cztery lata. Początkowo próbowałem wykrywać oszustwa w masowych transakcjach za pomocą Excela. Jednak szybko zdałem sobie sprawę, że to podejście było niewystarczające, szczególnie w kontekście Big Data. Zdecydowałem się na budowę infrastruktury opartej na relacyjnej bazie danych Postgres. Choć początkowo wydawało się to dobrym rozwiązaniem, okazało się niepraktyczne – ręczne dodawanie każdej transakcji do tabel relacyjnych było czasochłonne i nieefektywne. Ostatecznie mogłem jedynie generować raporty dotyczące poszczególnych transakcji, bez możliwości wykrycia wzorców oszustw.
Eksportowałem te raporty do Excela, co pozwalało mi identyfikować anomalie w szeregach czasowych. Następnie przeszedłem na Pythona w środowisku Jupyter, używając Pandas. Początkowo narzędzie dobrze radziło sobie z danymi, ale w miarę wzrostu ich ilości napotkałem problemy z wydajnością. W tym momencie zdecydowałem się na wdrożenie infrastruktury Apache Hadoop, która umożliwiła efektywne zarządzanie ogromnymi zbiorami danych.
Kolejnym krokiem było wdrożenie Apache Spark do przetwarzania danych. System działał dobrze, ale przetwarzał dane w dużych partiach, aktualizowanych raz dziennie. To było niewystarczające, ponieważ oszustwa były wykrywane z opóźnieniem – czasami nawet kilka dni po ich wystąpieniu. Aby to poprawić, stworzyłem API, które pobierało dane transakcyjne bezpośrednio z całej Polski, co pozwalało na otrzymywanie danych kilka godzin po faktycznym przyjęciu surowca.
Dysponując strumieniami danych, zastosowałem Spark Structured Streaming. Wdrożyłem również Apache Kafka, które zbierało dane, natomiast Spark przetwarzał je w czasie rzeczywistym. Projekt zakończył się sukcesem po czterech latach, ewoluując od prostych rozwiązań do zaawansowanego strumieniowego przetwarzania danych z wykorzystaniem Apache Spark i Apache Kafka.