Bazy danych przeznaczone do migracji mogą mieć szeroki zakres reprezentacji danych i zawartości. Od prostych numerycznych pól danych po pola o złożonej strukturze i treści, które mogą zawierać pliki, obrazy, tabele, a nawet złożone obiekty niestandardowe (np. w formatach XML, CLOB, BLOB itp.).

Odkrywanie prostszych danych można łatwo i bardzo efektywnie przeprowadzić przy użyciu tradycyjnych metod, dysponując podstawową wiedzą i zestawami wartości. Jednakże w miarę jak dane stają się coraz bardziej złożone, wydajność ta maleje, aż do momentu, gdy tradycyjne metody nie będą już wystarczające.

Takimi bardziej złożonymi danymi mogą być na przykład nieustrukturyzowane pliki tekstowe lub pliki binarne, których rodzaju i zawartości nie można jednoznacznie zidentyfikować i zinterpretować. Na potrzeby dyskusji pomińmy fakt, że wykorzystanie tego typu danych w bazach danych jest uzasadnione jedynie w kilku konkretnych przypadkach, gdyż problem ten często pojawia się podczas migracji skomplikowanych systemów. Te złożone formaty danych są zazwyczaj nieustrukturyzowane, strukturalnie stanowią jedynie zbiór bajtów w danym polu, o którym użytkownik często nie ma wiarygodnych informacji ze względu na niekompletną dokumentację. Bez metainformacji trudno wyciągnąć wnioski na temat rodzaju treści i jej interpretacji. Zatem naszym pierwszym zadaniem jest określenie, jakie pola zawierają dane.

Najbardziej oczywistym sposobem zidentyfikowania typów plików byłoby sprawdzenie ich rozszerzenia, ale gdy są przechowywane w bazie danych, informacje te zazwyczaj nie są dostępne, a nawet gdyby były, nie można ich wykorzystać z maksymalną pewnością. Zakładając, że dostępna jest tylko wersja binarna danych, czyli Binary Large Object (BLOB), pierwszym krokiem jest jej załadowanie. Wszystkie metadane są zakodowane w tym obiekcie BLOB, zgodnie z formatem pliku.

W zależności od formatu pliku lub rodzaju danych metadane w pliku mogą pojawić się w kilku miejscach pliku: w nagłówku lub na końcu pliku. Oprócz identyfikacji formatu pliku nagłówki plików mogą również zawierać metadane dotyczące pliku i jego zawartości. Pliki znakowe (tekstowe) mają zwykle nagłówki znakowe, podczas gdy formaty binarne zwykle mają nagłówki binarne, chociaż nie jest to standardowa, jedynie praktyka branżowa.

Rozkład wartości bajtów w różnych typach plików przedstawia inny wzór dla każdego typu. Wczesne próby koncentrowały się na rozkładzie bajtów całego pliku, ale nowsze metody wykonują różne próbkowanie, na przykład analizując tylko próbki z początku, końca i środka plików. Próbki te mogą stanowić dobrą podstawę do uczenie maszynowektóry może określić (z pewnym prawdopodobieństwem) typ nieznanych plików przy użyciu modelu zbudowanego na różnych dystrybucjach. W postępowaniu opartym na BFD (Byte Frequency Distribution) nie jest konieczne odczytywanie całego pliku, co oszczędza czas. Wartości wyodrębnione z kilku pozycji w pliku są analizowane statystycznie w celu uzyskania odcisku palca specyficznego dla pliku. Na podstawie tego odcisku palca uczenie maszynowe jest w stanie znaleźć w modelu typ pliku – ten, którego nauczyliśmy go ze znanymi plikami – który najlepiej do niego pasuje.

Poniższy rysunek przedstawia rozkład bajtów niektórych typów plików:

Należy pamiętać, że wszystkie kody i przykłady danych wejściowych/wyjściowych w tym artykule pochodzą z Clarity Consulting MigNon narzędzie. To oprogramowanie asystenta migracji danych jest wynikiem wieloletniego projektu badawczo-rozwojowego, częściowo finansowanego przez Unię Europejską.

Zastosowanie uczenia maszynowego do rozpoznawania formatu plików

Uczenie maszynowe może być skuteczną metodą rozpoznawania formatu plików, szczególnie podczas pracy z dużymi zbiorami danych. Do wykrywania formatu pliku można rozważyć następujące modele:

• Naiwny Bayes: Nadaje się do analizy opartej na bajtach lub sekwencji, gdzie brane są pod uwagę typowe cechy każdego formatu pliku, takie jak rozkład bajtów lub charakterystyczne wzorce.
• Maszyny wektorów nośnych (SVM): Dobry wybór, gdy granice pomiędzy formatami plików, tj. powierzchnie decyzyjne, muszą zostać określone na podstawie częstotliwości bajtów.
• Losowy las: Wśród metod uczenia zespołowego często stosuje się Random Forest, ponieważ obsługuje wiele różnych formatów plików i radzi sobie z zaszumionymi danymi.
• Konwolucyjne sieci neuronowe (CNN): Sieci CNN potrafią rozpoznawać wzorce rozkładu bajtów i mogą traktować pliki jak obrazy, w których częstotliwość bajtów jest interpretowana jako „piksele”, rozpoznając w ten sposób różne formaty plików.
• Autoenkoder: może być używany do uczenia się bez nadzoru, zwłaszcza do wykrywania anomalii, podczas próby wykrycia plików o wzorcu bajtów innym niż zwykle dla danego formatu pliku.
• K-najbliżsi sąsiedzi (KNN): W przypadku małych zbiorów danych może to być prosty, ale skuteczny sposób identyfikowania formatów plików na podstawie podobieństwa ich najbliższych sąsiadów.
• Rekurencyjne sieci neuronowe (RNN): Ponieważ sieci RNN skutecznie obsługują dane sekwencyjne, mogą być przydatne w zadaniach, w których ważne są sekwencje bajtów w pliku.

W celu automatycznego rozpoznawania formatu pliku, Lekki GBM Model (Light Gradient Boosting Machine) może być dobrym wyborem z kilku powodów. Po pierwsze, jest bardzo wydajny w przypadku dużych i różnorodnych zbiorów danych, zoptymalizowany pod kątem szybkiego uczenia się i przewidywania, a zatem dobrze sprawdza się w analizie formatu plików z rozkładem dużych bajtów lub wieloma próbkami. Wymaga niewielkiej ilości pamięci, co może być ważnym czynnikiem przy wykrywaniu i klasyfikowaniu wielu formatów plików w systemie. Jest członkiem rodziny modeli wzmacniających gradient, które mogą skutecznie modelować złożone powierzchnie decyzyjne, a ta dokładność może mieć kluczowe znaczenie przy wykrywaniu formatu pliku, w którym częstotliwość bajtów może mieć rozkład dyskretny.

Rozwiązanie LightGBM opiera się na danych, a ponieważ do zbudowania modelu o odpowiedniej jakości potrzebujemy większej ilości danych, w naszym przykładzie stworzyliśmy do tego quasi-automatyczny system pobierania. Aby zaimplementować nasz automatyczny system pobierania, użyliśmy Selenium w Pythonie do sterowania przeglądarką za pomocą sterownika Firefox. Dzięki temu mogliśmy wyszukiwać linki i elementy HTML, a następnie wykonywać na nich akcje, takie jak klikanie czy wprowadzanie danych. Podczas automatycznego pobierania obsługiwaliśmy typy plików, takie jak CSV, DOC, DOCX, XML, JPG, JSON, PDF, PNG, XLS i XLSX, ale niektóre pliki, takie jak MP3 lub AVI, musiały być gromadzone i przetwarzane ręcznie. Pliki pobrano z różnych źródeł, takich jak kaggle.com w przypadku plików CSV i JSON, natomiast obrazy PNG i JPG pobrano z imgur.com. Filmy z YouTube’a zostały pobrane w formacie MP4 ze strony btclod.com i przekonwertowane do formatu AVI przy użyciu WinFF. W przypadku plików ZIP kompresja i pobieranie były obsługiwane przez osobne skrypty Pythona. Automatyczne pobieranie zostało starannie zorganizowane w odpowiednią strukturę katalogów. Ilość pobieranych plików i jakość danych były kontrolowane za pomocą parametrów programu. Niektóre dane testowe zostały zebrane ręcznie, aby upewnić się, że istnieją różne pliki, ale nie byliśmy w stanie zgromadzić wystarczającej liczby plików każdego typu, dlatego w wielu przypadkach podstawową metodą generowania danych wejściowych pozostawało automatyczne pobieranie.

Uzyskane ilości danych wejściowych przedstawiały się następująco:

Rozpoznanie szczegółów wzorca rozkładu częstotliwości bajtów wspomnianego we wstępie jest podstawą do zbudowania modelu LightGBM na zebranych danych. Przetwarzanie pełnej listy bajtów jest kosztowne, dlatego w celu ustalenia rozszerzenia pliku dane są filtrowane przez BFD, co można postrzegać jako rodzaj „częściowego odcisku palca”. Wykorzystując je jako dane wejściowe, jesteśmy w stanie określić typ niektórych plików modelu. Odbywa się to poprzez utworzenie częstotliwości HASH-MAP z tablicy bajtów, gdzie klucze to bajty, a wartości to liczba wystąpień. Ponieważ klucze są liczbami dodatnimi (0 do 255), tę HASH-MAP można łatwo przekonwertować na tablicę, co przyspiesza proces normalizacji. Normalizacja w tym przypadku oznacza skonstruowanie rozkładu prawdopodobieństwa na podstawie wartości częstotliwości. W rezultacie suma znormalizowanych częstotliwości da wartość 1. Ta znormalizowana postać będzie BFD.

Testowanie i tuning modelu

Podstawowym problemem przy definiowaniu rozszerzeń plików było to, że początkowy model, który działał z 256 bajtami, nie był w stanie rozróżnić podobnych formatów, takich jak XML, JSON, ZIP, DOCX i XLSX. Spośród nich format ZIP był szczególnie zagmatwany, ponieważ zarówno DOCX, jak i XLSX zawierają XML zawinięty w plik ZIP. Powszechne było również zamieszanie między XML i JSON, ponieważ mają one bardzo podobną strukturę. Ze względu na te czynniki dokładność modelu dla tych typów plików pozostała niska, co spowodowało konieczność udoskonalenia modelu i wprowadzenia nowych funkcji.

Aby poprawić dokładność, dodano następujące funkcje

• Szybkość bajtów 60, 62
• Szybkość bajtów 123, 125
• seria bajtów udostępnionychStrings

Aby udoskonalić model, wprowadziliśmy kilka funkcji specyficznych dla bajtów, umożliwiających identyfikację różnych typów plików. Na przykład bajty 60 i 62, które odpowiadają symbolom „<” i „>”, odegrały kluczową rolę w dokładnej identyfikacji plików XML. Podobnie bajty 123 i 125, które reprezentują znaki „{” i „}”, były przydatne w identyfikacji plików JSON. Do rozpoznawania plików DOCX zastosowaliśmy stosunek sekwencji bajtów „

W przypadku wykrywania plików XLSX sekwencja bajtów „sharedStrings” sprawdziła się bardzo dobrze, ponieważ wszystkie pliki XLSX zawierają plik udostępnionyStrings.xml, który nie jest analizowany w formacie ZIP. Jednak ostatecznie odrzucono tę funkcję, ponieważ ze względu na długość była zbyt wrażliwa na nawet najmniejsze zmiany. Chociaż te cechy poprawiły wydajność modelu, dokładna identyfikacja plików ZIP pozostała problematyczna i musieliśmy zastosować inną metodę, aby je zidentyfikować.

Ponieważ nie wiedzieliśmy dokładnie, jakie funkcje będą potrzebne do niezawodnej identyfikacji plików ZIP, postanowiliśmy uwzględnić w modelu wszystkie możliwe kombinacje 2-bajtowe, aby zwiększyć dokładność. Jednak takie podejście wymagało ogromnego zaangażowania pamięci, czasu i procesora, ponieważ proces uczenia się musiał obsłużyć ogromną ilość danych. Aby to zoptymalizować, planowaliśmy wykorzystać tylko 500 najważniejszych funkcji 2-bajtowych, znacznie zmniejszając w ten sposób obciążenie zasobów obliczeniowych bez uszczerbku dla wydajności modelu.

Na podstawie naszych wstępnych analiz uzyskaliśmy ponad 90% dokładności dla wszystkich klas z osobna, z wyjątkiem plików XML, gdzie osiągnęliśmy jedynie 49%. Wskazywało to, że model może mieć problem z nadmiernym dopasowaniem. Do nadmiernego dopasowania może dojść, gdy model wykorzystuje zbyt wiele funkcji, co powoduje szybsze podejmowanie decyzji, na przykład w punktach końcowych drzew decyzyjnych. Może to skutkować wysoką dokładnością zbioru uczącego, ale gorszą generalizacją na rzeczywistych danych. Jednym z najskuteczniejszych sposobów radzenia sobie z nadmiernym dopasowaniem jest zmniejszenie liczby używanych funkcji.

Ostateczny model zawiera kombinację trzech funkcji. Po pierwsze, 256 funkcji jednobajtowych sprawdzających częstotliwość występowania każdego bajtu. Następnie następuje dodatkowa funkcja, która mierzy proporcje symboli „<” i „>” (bajty 60 i 62), które są szczególnie przydatne do rozpoznawania plików XML. Wreszcie model zawiera 42 wybrane cechy dwubajtowe, które na podstawie wcześniejszej analizy są najbardziej istotne dla identyfikacji typu pliku. Te połączone funkcje pomagają zwiększyć dokładność modelu w identyfikowaniu różnych typów plików.

Po sfinalizowaniu modelu na stosie testowym znaleziono następujące dokładności, w podziale na typ pliku.

Ponieważ elementy kolumny w tabeli są tego samego typu, dokładność można zwiększyć, klasyfikując te binarne punkty danych jednocześnie w zestawie, ponieważ nawet jeśli w zestawie znajduje się jeden błędnie sklasyfikowany punkt danych, pozostałe punkty danych spowodują wypchnięcie średniej w stronę właściwej klasyfikacji.

Powyższy rysunek przedstawia progresję dokładności dla 3 najniższych klas dokładności (XLSX, XLS, XML) dla różnych rozmiarów zestawów. Wybrano trzy najniższe klasy dokładności, ponieważ wymagają one największego rozmiaru zestawu, aby osiągnąć 100% ogólnej dokładności. Metoda pozwala określić minimalny rozmiar zestawu wymagany w najgorszym przypadku. Można zauważyć, że nawet w najgorszym przypadku średnia dokładność modelu wzrasta do niemal 100% przy jednoczesnej klasyfikacji 7 plików.

Pomiary czasu wykonania API dla różnych rozmiarów zestawu dla modelu dały następujące wyniki (średni rozmiar pliku wyniósł 5 MB, a testy przeprowadzono na maszynie z procesorem Intel Core i7-2600 3,4 GHz i pamięcią RAM 1333 MHz).

W zależności od wykorzystania pamięci zmierzono następujące czasy działania:

– 89,428 sekund przy maksymalnym wykorzystaniu pamięci RAM wynoszącym 7,28 GB

– 56,451 sekund przy maksymalnym wykorzystaniu pamięci RAM wynoszącym 4,55 GB

– 30,186 sekundy przy maksymalnym wykorzystaniu pamięci RAM wynoszącym 2,58 GB

Implementacja rozpoznawania plików oparta na mikroserwisach

Usługa jest konteneryzowana przy użyciu Dockera, w oparciu o moduły Python fastAPI i uvicorn. W procesie wywołania API system najpierw odbiera żądanie, następnie konwertuje otrzymane dane do formatu binarnego (Base64). Dane binarne są następnie wykorzystywane do generowania wartości rozkładu częstotliwości bajtów (BFD) punktu danych. Po wygenerowaniu BFD, BFD powiązany z punktem danych i model typu lightGBM są wykorzystywane do klasyfikacji wykrywania typu pliku. System rejestruje zdarzenia i obsługuje ewentualne błędy. Wreszcie, pod koniec procesu, system wysyła odpowiedź do użytkownika.

Obraz Dockera składa się z następujących plików:

• log, lokalizacja plikuresults.log.
• models, folder ten będzie zawierał zapisane modele
• main.py, to jest główny moduł, na nim działa uvicorn
• logger.py, jest to moduł odpowiedzialny za rejestrowanie
• bfd.py, kod BFD
• model.py, kod modelu
• plik dokowany, skrypt dokera
• module_list.txt, lista modułów do pobrania w pliku dockerfile

Struktura pliku dockerfile jest następująca:

W wywołaniu usługi struktura Body zawiera tylko dwa pola „data”, atrybutem tym jest lista obiektów JSON oraz „id”. Te obiekty JSON mają pole „bit” (będące ciągiem znaków zawierającym wersję pliku zakodowaną w formacie base64).

Odpowiedź z punktu końcowego /predict to obiekt JSON zawierający kod stanu. Struktura obiektu JSON jest podobna do treści żądania. Odpowiedź będzie zawierać pole „data”, którego wartość będzie listą. Ta lista zawiera dodatkowe obiekty JSON, które zawierają pola „id” i „pred”. Wartością pola „id” może być identyfikator przypisany do przesłanego towaru lub wygenerowany identyfikator, jeśli nie został pierwotnie określony dla pola „bit”. Pole przewidywania („pred”) zawiera również obiekt JSON, który zawiera pary klucz-wartość rozszerzenia i prawdopodobieństwa.