KNIME czy Pentaho?

Do przetestowania KNIME zabierałem się od dłuższego czasu - nawet trochę dłużej. Kiedyś nawet zainstalowałem to oprogramowanie na swoim PC ale zraził mnie siermiężny interfejs, brak responsywności, złe skalowanie, nachodzące na siebie elementy okien dialogowych - nie wyglądało to profesjonalnie. Oprogramowanie zajmowało wiele miejsca na dysku i wyglądało na ciężkie - jego uruchomienie wymagało czasu. Nie pamiętam już gdzie ale niedawno gdzieś w Internecie przed moimi oczami pojawiła się reklama KNIME „Sophisticated analytics, intuitive interface. Our promise: to build the most intuitive and widely‑used environment for data science”. Dajmy zatem KNIME jeszcze jedną szansę.

Jeśli wpiszemy w Google "most popular etl tools" to nie zobaczymy żadnego linku do strony wymieniającej KNIME na pierwszej stronie. Dużo wiekszy optymizm jeśli wpiszemy "most popular Data Analytics / Data Science Platform" - wtedy duża szansa że link do informacji o tym oprogramowaniu będzie na pierwszej stronie rezultatów wyszukiwania. I to mówi nam jak to oprogramowanie jest postrzegane na rynku, jak jest użytkownane. KNIME samo o sobie mówi że jest oprogramowaniem "ETL, analityka danych, predykcyjna sztuczna inteligencja i tworzenie agentów świadomych danych". Rynek wykorzystuje to oprogramowanie właśnie głownie do "analizy i eksploracji danych", rzadziej jako typowy ETL.

Pierwsze wrażenie - instalacja i interfejs KNIME

Dużym plusem jest to, że oprogramowanie nie wymaga 'instalacji' - wystarczy po prostu rozpakować pobrany plik do dowolnego katalogu PC. Możemy pobrać z ich strony zip lub exe ktory sam rozpakuje się wskazanego katalogu. W przypadku 'self-extracting archive' dla Windows (można też pobrać wersję dla Linux) będzie to plik 634 MB. Po rozpakowaniu na dysku komputera, zajmie on około 1.2GB. Oprogramowanie do działania nie wymaga żadnej bazy danych.

Oprogramownie napisane zostało w Java (Eclipse) i dlatego bardzo lubi pamięć - możesz uruchomić go mając 4GB RAM ale optymalnie twój komputer powinien posiadać nie mniej niż 8GB RAM dla programu. Przed uruchomieniem wejdz do pliku knime.ini (ten sam katalog w ktorym uruchamiasz knime.exe) i ustaw zmienną '-Xmx' (np. -Xmx10g).

Nowy KNIME wygląda ładnie. Nie razi już siermieżny wygląd ikon wezłów ('nodes') i połączeń miedzy nimi. Widać że programiści włożyli w poprawę wyglądu dużo pracy. Niestety, nadal jest problem ze skalowaniem okien dialogowym i np. po otwarciu właściwości węzłów trzeba okna powiekszać ręcznie by ujrzeć wszystkie informacje. Niektóre pola są zbyt wąskie i trzeba je rozciągać myszką, czcionki mikroskopijne i nieczytelne. Pentaho Kettle/PDI prezentuje się w tej kategorii nieco lepiej.

Przepływy, węzły - podstawowe komponenty KNIME

Jak w każdym narzędziu ETL i podobnym mamy workflow (w Pentaho jest to 'Transformation') na którym umieszczamy węzły (nazwane 'nodes') które sterują przepływem lub wykonują pewną pracę w przepływie. W Pentaho te węzły nazywają się 'steps'. Dokumentację KNIME znajdziemy na stronie producenta oprogramowania.

W Pentaho PDI/Kettle mamy pojęcie 'jobs' których używamy do organizacji bardziej złożonych struktur, uruchamiania warunkowego, definicji zmiennych dla przepływów... W KNIME nie mamy jobs - możemy uzyskać podobną fukcjonalność stosując komponenty, parametry, warunki. - wszystko osadzone na poziomie workflow. Wydaje się że Pentaho zapewnia lepszą czytelność i logiczność podziału tej struktury na Transformacje i Zadania, szczególnie jeśli budujemy przepływy ETL. 

Często nasz przepływ zawiera tak wiele węzłów że umieszczenie ich na jednym workflow powoduje iż nie jest on czytelny - dużo lepszym pomysłem jest rozbicie takiego przepływu na kilka i połączenie ich strukturą nadrzędną. To co w KNIME nie zachwyca to przechowywanie ustawień Workflows. W Pentaho zarówno transformacje jak i jobs sa przechowywane W JEDNYM pliku, w formacie XML. Plikom można nadać logiczne nazwy, ważą trywialnie mało, są łatwe do przenoszenia między użytkownikami, platformami. Tymczasem KNIME przechowuje ustawienia każdego workflow w katalogu i wielu plików. Każdy z węzłów ma swoj podkatalog. Mogą się tam także znaleźć dane jeśli są buforowane. Wiele plików zajmujących całkiem sporo miejsca na dysku. W tej kategorii zdecydowanym zwycięzcą jest Pentaho.

Potęga (funkcjonalność) węzłów

Dość szybko odkryjemy że o ile w Pentaho i KNIME zrealizować możemy to samo, w KNIME będziemy musieli użyć wiekszej ilości węzłów by zrealizować zadanie. Węzły KNIME zazwyczaj mają mniejszą ilość ustawień i możliwości, np. zapisując dane do pliku w Pentaho możemy wykluczyć pewne kolumny, zmienić typ danych. Tego nie zrobimy w KNIME - trzeba użyć dodatkowych dwóch węzłów przed zapisem. Paradoksalnie może to być łatwiejsze dla niedoświadczonych użytkowników - widzą w graficznej reprezentacji przepływu co dzieje się z danymi. Warto też wziąć pod uwagę że KNIME nie oferuje zmiany nazwy etykiety węzła - często używa się tej opcji by jeszcze jaśniej opisać co robi dany węzeł w przepływie. Za to w KNIME możemy użyć komentarza dla każdego węzła, w Pentaho nie mamy takiej możliwości (trzeba umieszczać etykiety nie powiązane bezpośrednio z węzłami).

Przykład ograniczonej funkcjonalności węzła KNIME (po prawej) na przykładzie 'Excel Writer'.

Połaczenia między węzłami

W Pentaho mamy po prostu połączenie między węzłami (krokami) nazwane 'hops'. Te połączenia są używane zarówno do przekazywania zmiennych jak i danych. W KNIME transfer zmiennych zostały odzielony od przesyłania danych i tak mamy 'data links' do transferu danych i 'variable links' do transferu zmiennych między węzłami. Używając ich musimy wyprowadzić je z przeznaczonego do tego portu na węźle wyjściowym i podłączyć do określonego portu na węźle docelowym. Wydaje się to niepotrzebną komplikacją w programie; powinno to być obsłużone przez logikę programu bez absorbowania tym użytkownika.

Raportowanie błędów - logi

Pentaho PDI/Kettle dostarcza bardzo szczegółowe, dostępne z poziomu GUI, logi wykonania każdego z kroków transformacji. Poziom tej szegołowości można ustawić przed każdym uruchomieniem transformacji. Możliwe jest także używanie dedykowanego kroku 'Write to log' w ktorego właściwościach określamy jakie informacje nas interesują i ile ostatnich zdarzeń będzie logowanych. Bardzo łatwo jest pobrać część informacji z logu by np. na tej podstawie znaleźć rozwiązanie w Internecie.

KNIME ustępuje pod tym względem Pentaho. Nie widzimy logów w czasie rzeczywistym w konsoli programu, często błędy powodują pojawianie się okien dialogowych z których niemożliwością jest skopiowanie błędu do schowka. Logi z wykonania węzłów flow KNIME dostępne są w pliku <ścieżka_do_workspace>/.metadata/knime/knime.log

Pentaho ma gotową obsługę błędów dla kroków ('węzłów' - jak powiedzielibyśmy w KNIME) dla części z nich - takie mechanizmy też istnieją też na poziomie zadań. To pozwala Pentho kontynuowac wykonanie transformacji mimo błędu, daje możliwość łatwego, intuicyjnego zarządzania błędami. W KNIME takie mechanizmy nie istnieją. Trzeba taką logikę oprogramować ręcznie.

KNIME, Pentaho - dwa różne sposoby przetwarzania danych

KNIME i Pentaho przetwarzają dane różny sposób. KNIME wykorzystuje przetwarzanie wsadowe, co oznacza, że dane są przetwarzane partiami - każdy node w KNIME wykonuje się dopiero, gdy cały poprzedni node zakończy działanie. Dane są przekazywane całymi tabelami (batch), a nie rekord po rekordzie.

Pentaho obsługuje przetwarzanie strumieniowe, gdzie każdy rekord przepływa przez kolejne kroki w czasie rzeczywistym. Takie przetwarzanie może być szybsze – zwłaszcza przy dużych ilościach danych, które nie wymagają całościowej analizy jednocześnie.

KNIME przechowuje w pamięci określoną ilość danych przetwarzanych przez każdy z węzłów (ten ilość można określić w konfiguracji) ale zawsze przechowa wszystkie dane, skompresowane, każdego z węzłów ktory przetwarza dane na dysku, w tabeli, w pliku. A to oznacza, że im większa ilość węzłów workflow, tym więcej miejsca zajętego na dysku (prosty workflow potrzebował aż 88MB przestrzeni na dysku!). Pentaho nie przechowuje danych przetwarzanych przez kroki transformacji.

Podgląd przetworzonych danych w każdym z węzłów widoczny jest w KNIME dopiero po przetworzeniu całości podczas gdy w Pentaho prztworzone rekordy pojawiają się natychmiast w podglądzie po przetworzeniu. Także przewijanie próbki danych dla każdego z węzłow jest zdecydowanie szybsze w Pentaho.

Zdalne uruchamianie workflows - web server

Możliwe jest wykonywanie transformacji i zadań Pentaho PDI/Kettle z pomocą usługi Carte. Carte to prosty serwer webowy, który umożliwia zdalne uruchamianie transformacji i zadań. Odbiera dane w formacie XML (za pomocą niewielkiego serwletu), które zawierają transformację do wykonania oraz konfigurację uruchomienia. Umożliwia zdalne monitorowanie, uruchamianie i zatrzymywanie transformacji oraz zadań działających na serwerze Carte. Obsługuje zapytania REST i jest wspaniałym pomysłem jeśli chcesz komunikować się transformacjami Pentaho np. z poziomu aplikacji webowych. To rozwiązanie jest darmowe.

KNIME także daje taką możliwość za pomocą swojego KNIME Business Hub ale jest to rozwiązanie płatne.

Wydajność

Od momentu uruchomienia knime.exe do czasu kiedy pojawi się na ekranie GUI programu upływa jedna minuta i 30 sekund (KNIME miało do dyspozycji 12G RAM). Pentaho PDI/Kettle uruchomi się w mniej niż 30 sekund. Różnica jest ogromna.

KNIME nie pokaże nam domyślnie czasu wykonania każdego z węzłów ani też ile zajeło przetworzenie danych przez wszystkie węzły workflow. Jest to możliwe po dodaniu specjalnego węzła do workflow. Ten niestety raportuje czas wykonania dla węzłów w milisekundach i by uzyskać sekundy czy minuty trzeba wykonać operację matematyczną. Podsumowanie wykonania całego flow prezentowane jest w sekundach.

Skoro KNIME przetwarza dane węzeł po węźle a nie strumieniowo jednocześnie we wszystkich węzłach, tak jak to jest w Pentaho, to czy jest to oprogramowanie wolniejsze? By to sprawdzić zbudowałem testowy workflow który odczytuje ustrukturyzowany plik tekstowy z 877 tysiącami linii i kilkunastoma kolumnami. Pomiędzy odczytem a zapisem do formatu XLSX (Excel) manipulujemy stringiem jednej z kolumn - usuwamy wszystkie cyfry ze sringu, zamieniamy pierwsze 10 znaków do dużych liter i zamieniamy każdą z liter 'a' na 'X'. Dość trywialne.

Wykonanie tej transformacji w Pentaho zajeło 46 sekund. Najdłużej trwało zapisywanie danych do pliku Excela bo odczyt pliku zakończył się już po 23 sekundach a manipulacje na stringu po 24 sekundach. W rzeczywistości operacje te zajeły dużo mniej czasu - Pentaho przetwarza dane strumieniowo i najwolniejszy krok (w tym przypadku zapis do formatu Excela) blokuje cały przepływ.

Czas wykonania workflow Knime ktory robi to samo był bardzo podobny. Mamy tu inny sposób przetwarzania danych, każdy z węzłów musi zakończyć swoją pracę i dopiero przekazuje dane do przetworzenia do następnego węzła, ale czas bardzo podobny; 49 sekund.

Spojrzmy na konstrukcję workflow Pentaho i Knime; na pierwszy rzut oka widoczne jest to ze budowa przepływu w KNIME wymaga użycia większej ilości węzłów niż w Pentaho. Z workflow KNIME poniżej moglibyśmy wyrzucić dwa lub nawet trzy węzły jako zbędne ale i tak Pentaho potrzbuje mniej kroków by wykonać to samo.

Przepływ w KNIME

Przepływ w Pentaho

Porównanie Pentaho Kettle z KNIME

Wnioski

W mojej ocenie KNIME ustępuje Pentaho jako narzędzie ETL; jest wolniejsze, przechowuje dane każdego z węzłow na dysku podczas pracy, węzły muszą zakończyć swoją pracę przed przekazaniem danych do następnego węzła, definicje workflow zawierają wiele plików dużych rozmiarów. Ale KNIME się dynamicznie rozwija i choć nie należy się spodziewać że zmieni się core tego systemu (nadal pewnie KNIME bedzie przechowywac dane węzłów na dysku, nadal definicje workflow będą opisane w wielu plikach) to może to być znakomite narzędzie dla szybkich analiz na stososunkowo niewielkiej ilości danych. Nie spodziewam się, że w KNIME można wykonać analizę koszykową retail lub nawet średniej wielkości sklepu e-commerce ale dla mniejszych firm, dla sprawdzenia koncepcji/hipotezy KNIME wydaje się być właściwym narzędziem z racji dużej ilości gotowych komponentów/algorytmów. Te których brakuje w gotowej instalacji są do pobrania jako roszerzenia. KNIME może mieć więc przewagę w 'data mining'.

KNIME, ale też i pozostałe narzędzia low-code, krytykowane jest często za brak 'elastyczności' i powolność działania. Tymczasem dla większosci typowych zadań jak raporty i analizy prędkość nie ma większego znaczenia. Dobrze jeśli dane do raportu zostaną przygotowane w 15 sekund ale jeśli zaczekamy na nie dwie minuty - who cares. Tym bardziej że procesy te są najczęściej oskryptowane, zautomatyzowane, wykonują się w tle, w określonym harmonogramie. Budowanie flow ETL, analitycznych i innych w Python, Java czy innym języku rzeczywiście daje dużą swobode, możliwość wybrania właściwych bibliotek, funkcji, algorytmow. Ale są też tego koszty. Zarządzanie kodem, prawdziwa zmora; kod często nie jest opisany, udokumentowany, ludzie odchodzą z firm a wraz z nimi wszystkie te 'elastyczne rozwiązania'. Wiekszość przepływów ma duży udział standardowych, powtarzalnych operacji. Nie ma sensu tworzyć kodu by odczytać plik, wykonać typowe operacje na danych. Pisanie własnych flow ma sens jeśli mamy nietypowe potrzeby, jeśli rezultaty muszą być dostarczone błyskawicznie (np. na potrzeby aplikacji). Pisanie własnego kodu daje satysfakcję – ale sensu nie mierzy się w linijkach.

Pentaho od kliku lat świadomie wycofuje Pentaho Kettle z rynku - zdali sobie sprawę z tego że w darmowej wersji zaoferowali właściwie to wszystko co może mieć komercyjna. Pentaho Kettle nie otrzymuje właściwie żadnej nowe fukcjonalności. Ale ponieważ rola narzędzia ETL nie podlega dynamicznej ewolucji, nawet w Pentaho Kettle sprzed 5 lat możesz zrobić nadal wszystko czego potrzebujesz. Pentaho PDI/Kettle jest niesamowicie stabilnym narzędziem, kompatybilnym porzez szereg wersji.

Za następcę Pentaho Kettle uznać można Apache Hop. Kod źródłowy Kettle został użyty do rozwoju tego ETL. Świetny produkt ale niestety bardzo widoczne jest że twórcom brakuje specjalistów od UX; GUI reprezentuje wygląd sprzed 20 lat, czuć że okna opcji aplikacji projektują programiści.