Git dla analityków danych – dlaczego Excel nie wystarcza do kontroli wersji?

Większość analityków danych przynajmniej raz w życiu pracowała na plikach o nazwach podobnych do:

• Raport_Sprzedaz.xlsx
• Raport_Sprzedaz_v2.xlsx
• Raport_Sprzedaz_poprawiony.xlsx
• Raport_Sprzedaz_final.xlsx
• Raport_Sprzedaz_final_final.xlsx
• Raport_Sprzedaz_ostateczny.xlsx

Choć brzmi to zabawnie, w rzeczywistości jest to jeden z najczęstszych problemów występujących w zespołach analitycznych. Wraz ze wzrostem liczby raportów, modeli danych, skryptów SQL czy procesów ETL coraz trudniej odpowiedzieć na podstawowe pytania:

Która wersja pliku jest aktualna? Kto wprowadził zmianę? Kiedy została ona wykonana? Jak przywrócić raport sprzed tygodnia?

Przez lata Excel był podstawowym narzędziem pracy analityków i nadal pozostaje niezwykle ważnym elementem wielu procesów biznesowych. Problem pojawia się jednak wtedy, gdy zaczynamy traktować go jako system kontroli wersji.

W świecie nowoczesnej analityki danych tę rolę przejął Git – narzędzie od lat wykorzystywane przez programistów, które coraz częściej staje się standardem również w zespołach BI, Data Engineering i Data Science.

Na początku większość projektów analitycznych jest stosunkowo prosta. Jeden analityk tworzy raport, zapisuje go na dysku sieciowym i regularnie aktualizuje.

Sytuacja komplikuje się wraz z rozwojem organizacji.

Raport zaczyna wykorzystywać kilka działów. Do projektu dołącza kolejny analityk. Pojawiają się skrypty SQL, procesy Power Query, modele Power BI oraz automatyzacje napisane w Pythonie. W pewnym momencie kilka osób jednocześnie pracuje nad tym samym rozwiązaniem.

Wtedy zaczynają pojawiać się typowe problemy:

• przypadkowe nadpisanie zmian,
• utrata wcześniejszych wersji raportu,
• brak wiedzy kto zmodyfikował dane,
• trudności z testowaniem nowych funkcjonalności,
• konieczność ręcznego kopiowania plików.

Excel nie został zaprojektowany do rozwiązywania takich problemów. Jest doskonałym narzędziem analitycznym, ale nie jest systemem zarządzania wersjami.

To trochę tak, jakby próbować zarządzać projektem informatycznym przy pomocy folderów nazwanych „Nowe”, „Nowe2” i „Nowe_final”.

Przez pewien czas działa, ale wraz ze wzrostem skali szybko prowadzi do chaosu.

Git to rozproszony system kontroli wersji stworzony przez Linusa Torvaldsa, autora systemu Linux.

Najprościej mówiąc, Git pozwala śledzić wszystkie zmiany zachodzące w projekcie.

Za każdym razem, gdy zapisujemy nową wersję projektu, Git tworzy tzw. commit – punkt kontrolny zawierający informacje:

• co zostało zmienione,
• kto wykonał zmianę,
• kiedy została wykonana,
• dlaczego została wykonana.

Dzięki temu możemy w dowolnym momencie cofnąć się do wcześniejszej wersji projektu.

W praktyce oznacza to koniec problemów z plikami typu „Raport_final_v7_poprawiony.xlsx”.

Zamiast przechowywać dziesiątki kopii, Git przechowuje historię zmian w jednym repozytorium.

Jeszcze kilka lat temu Git był kojarzony głównie z programistami tworzącymi aplikacje.

Dzisiaj sytuacja wygląda zupełnie inaczej.

Nowoczesny analityk danych coraz częściej pracuje nie tylko z Excelem, ale również z:

• SQL,
• Power BI,
• Pythonem,
• Jupyter Notebook,
• dbt,
• Azure Data Factory,
• Apache Spark.

Wszystkie te technologie opierają się na plikach tekstowych, które idealnie współpracują z systemami kontroli wersji.

Git pozwala śledzić każdą zmianę w kodzie SQL, modelach danych czy procesach ETL.

Co więcej, umożliwia jednoczesną pracę wielu osób nad tym samym projektem bez ryzyka wzajemnego nadpisywania zmian.

To ogromna przewaga nad tradycyjnym podejściem opartym na przesyłaniu plików przez e-mail lub przechowywaniu ich na dyskach sieciowych.

Excel posiada mechanizmy współpracy oraz historię wersji dostępną w środowisku Microsoft 365.

Nie oznacza to jednak, że zastępuje Git.

Największa różnica polega na sposobie przechowywania zmian.

Plik Excel jest plikiem binarnym. Git nie potrafi łatwo pokazać, że użytkownik zmienił formułę w konkretnej komórce lub usunął jeden wykres.

W przypadku plików tekstowych sytuacja wygląda zupełnie inaczej.

Jeżeli zmienimy jedno zapytanie SQL, Git pokaże dokładnie, która linia została usunięta, a która dodana.

Dla zespołów analitycznych oznacza to pełną transparentność zmian.

W praktyce łatwiej jest odpowiedzieć na pytania:

Dlaczego raport zaczął zwracać inne wyniki?

Która zmiana wpłynęła na KPI?

Kiedy zmodyfikowano logikę biznesową?

Kto zmienił sposób liczenia marży?

Przy pracy wyłącznie na plikach Excel często znalezienie odpowiedzi na takie pytania przypomina pracę detektywa.

Wyobraźmy sobie firmę handlową posiadającą trzech analityków.

Każdy z nich pracuje nad tym samym raportem sprzedażowym.

Pierwszy dodaje nowe KPI.

Drugi modyfikuje model danych.

Trzeci poprawia wizualizacje.

Jeżeli wszyscy pracują na lokalnych kopiach pliku Excel, po kilku dniach pojawia się klasyczny problem.

Którą wersję należy uznać za aktualną?

Zazwyczaj kończy się ręcznym porównywaniem plików lub scalaniem zmian metodą „kopiuj-wklej”.

To proces czasochłonny i podatny na błędy.

Gdyby logika raportu znajdowała się w repozytorium Git, każdy analityk mógłby pracować na własnej gałęzi projektu, a następnie połączyć zmiany w sposób kontrolowany.

Tak właśnie od lat pracują zespoły programistyczne.

Coraz częściej identyczne podejście wdrażają również organizacje budujące nowoczesne środowiska analityczne.

Szczególnie duże znaczenie Git zyskuje w projektach związanych z Business Intelligence.

Przykładowo:

Zapytania SQL przechowywane są w repozytorium.

Procesy ETL zapisane w kodzie mogą być wersjonowane.

Modele dbt są śledzone linia po linii.

Skrypty Python odpowiedzialne za transformację danych posiadają pełną historię zmian.

Coraz więcej organizacji integruje również Git z Power BI.

Pozwala to zarządzać raportami podobnie jak klasycznym kodem źródłowym.

W praktyce oznacza to większą kontrolę nad wdrożeniami, łatwiejsze testowanie zmian oraz możliwość szybkiego przywrócenia wcześniejszej wersji raportu.

To szczególnie istotne w środowiskach produkcyjnych, gdzie błędna zmiana może wpłynąć na decyzje biznesowe podejmowane przez zarząd.

Wielu analityków uważa, że Git jest narzędziem przeznaczonym wyłącznie dla programistów.

To coraz mniej aktualne podejście.

Oczywiście analityk nie musi znać wszystkich zaawansowanych funkcji związanych z branchami, rebase czy rozwiązywaniem konfliktów.

W praktyce wystarczy opanować kilka podstawowych operacji:

• pobieranie projektu,
• zapisywanie zmian,
• wysyłanie zmian do repozytorium,
• przeglądanie historii,
• przywracanie wcześniejszych wersji.

Już taka wiedza znacząco zwiększa bezpieczeństwo pracy i pozwala efektywniej współpracować z zespołami Data Engineering oraz IT.

Co więcej, znajomość Git coraz częściej pojawia się w wymaganiach rekrutacyjnych dla analityków danych, specjalistów BI i Data Scientistów.

Excel pozostaje jednym z najważniejszych narzędzi pracy analityka danych. Doskonale sprawdza się w analizach, raportowaniu oraz przygotowywaniu zestawień biznesowych.

Problem pojawia się jednak wtedy, gdy próbujemy wykorzystać go jako system kontroli wersji.

W nowoczesnych projektach analitycznych liczba zmian, użytkowników i procesów rośnie zbyt szybko, aby zarządzać nimi przy pomocy plików o nazwach „final_v3_ostateczny.xlsx”.

Git rozwiązuje ten problem, zapewniając pełną historię zmian, możliwość współpracy wielu osób oraz bezpieczeństwo projektów opartych na danych.

Dlatego coraz częściej staje się nie tylko narzędziem programistów, ale również standardowym elementem warsztatu nowoczesnego analityka danych. W świecie SQL, Power BI, Python i Data Engineering umiejętność korzystania z Git przestaje być dodatkowym atutem, a zaczyna być naturalnym elementem profesjonalnej pracy z danymi.