leeper / data-versioning

(C) Thomas J. Leeper (2015), licencjonowany CC-BY

Kontrola wersji to ogromna część powtarzalnych badań i rozwoju oprogramowania open source. Wersjonowanie zapewnia pełną historię jakiegoś obiektu cyfrowego (np. programu, projektu badawczego itp.) i, co ważne, pozwala prześledzić, jakie zmiany zostały wprowadzone do tego obiektu, kiedy te zmiany zostały wprowadzone i (z odpowiednimi metadanymi) dlaczego te zmiany zostały wprowadzone. Ten dokument zawiera część mojego obecnego myślenia o kontroli wersji danych.

kontekst tła

szczególnie w naukach społecznych, naukowcy zależą od dużych, publicznych zbiorów danych(np.) jako materiał źródłowy do badań ilościowych. Te zbiory danych zazwyczaj ewoluują (nowe dane są dodawane w czasie, wprowadzane są korekty wartości danych itp.), a nowe wydania są okresowo upubliczniane. Czasami dane te są złożonymi wysiłkami współpracy (patrz na przykład Jakość rządu), a inne są publicznymi publikacjami wysiłków w zakresie gromadzenia danych przez jedną instytucję (np. ANES). Podczas gdy zestawy danych oparte na współpracy tworzą bardziej oczywisty przypadek użycia kontroli wersji, zestawy danych z pojedynczą instytucją mogą również zostać ulepszone przez kontrolę wersji. Jest to szczególnie ważne, ponieważ stare wydania tych ważnych zbiorów danych często nie są archiwizowane (np. ANES), co oznacza, że zasadniczo niemożliwe jest odzyskanie wcześniejszej wersji danego zestawu danych ANES po wystąpieniu nowego wydania. Ten post ma sterować myśleniem o tym, jak zarządzać tworzeniem, kuratorowaniem, rewizją i rozpowszechnianiem tego rodzaju zbiorów danych. Podczas gdy pomysły tutaj może również zastosowanie do tego, jak ktoś myśli o zarządzaniu własnymi danymi, prawdopodobnie stosuje się więcej na etapie tworzenia danych niż w późniejszym wykorzystaniu danych po zestaw danych jest zasadniczo kompletne lub zamrożone.

przegląd istniejących narzędzi i podejść

Open Data Institute ma ładny post przedstawiający wyzwania związane z używaniem standardowego oprogramowania do kontroli wersji (a mianowicie git) do kontroli wersji danych. Głównym problemem jest to, że git, jak prawie wszystkie VCS, został zaprojektowany do monitorowania zmian w liniach w plikach tekstowych. Ma to sens zarówno dla kodu, jak i dla artykułów, tekstu itp. Ale zaczyna to mieć mniej sensu dla obiektów cyfrowych, w których linia nie jest znaczącą jednostką. Staje się to bardzo jasne, gdy zaczynamy wersję czegoś w rodzaju pliku CSV (oddzielonego przecinkami) (jak opisuje post ODI). Zmiana pojedynczego pola danych prowadzi do zmiany pełnej linii, nawet jeśli tylko jedna komórka faktycznie się zmieniła. Podobny problem pojawia się w formatach XML, JSON lub innych formatach rozdzielanych tekstem (należy jednak pamiętać, że Open Knowledge Foundation wydaje się faworyzować JSON jako tryb przechowywania).

używanie linii \n jako ogranicznika do śledzenia zmian w obiekcie działa dla danych. daff to narzędzie javascript, które próbuje nadrobić tę słabość. Zapewnia diff (porównanie dwóch wersji plików), które respektuje tabelaryczną strukturę wielu plików danych poprzez podkreślenie zmian specyficznych dla komórek. Nie jest to jednak pełny system kontroli wersji, jest to po prostu narzędzie różnicujące, które może służyć jako przydatny dodatek do Gita.

post na blogu Open Knowledge Foundation twierdzi, że istnieje pewna logika zestawów zmian opartych na wierszach, ponieważ standardowy plik CSV (lub dowolny plik danych tabelarycznych) zazwyczaj rejestruje pojedynczą obserwację na własnej linii. Kontrola wersji oparta na linii ma sens do rejestrowania zmian w obserwacjach (w ten sposób uprzywilejowanie wierszy/obserwacji nad kolumnami/zmiennymi).

dat stara się być „git dla danych”, ale status projektu jest trochę niejasny, biorąc pod uwagę, że nie było zbyt aktywnego rozwoju na Githubie. Q/A na Open Data StackExchange wskazuje na kilka dalszych zasobów dla odpowiednich do danych alternatyw git, ale nie ma nic kompleksowego.

Universal Numeric Fingerprint (UNF) zapewnia potencjalną strategię kontroli wersji danych. W rzeczy samej, właśnie do tego został zaprojektowany. Nie jest to system kontroli wersji per se, ale zapewnia hash, który może być przydatny do określania, kiedy zestaw danych się zmienił. Ma kilka fajnych funkcji:

  • niezależny format pliku (więc lepszy niż MD5)
  • niezależny od kolejności kolumn (zbiór danych, w którym kolumny zostały przetasowane, daje ten sam skrót UNF)
  • konsekwentnie obsługuje liczby zmiennoprzecinkowe (kwestie zaokrąglania i precyzji są bezproblemowe), ale UNF nie jest doskonały. Problemy obejmują:
  • jest on wrażliwy na sortowanie (identyczny zbiór danych, który jest sortowany wierszem, tworzy inny UNF; w ten sposób uprzywilejowanie kolumn/zmiennych nad wierszami/obserwacjami)
  • nie ma obsługi metadanych (np.”szerokie „i” długie ” reprezentacje tego samego zbioru danych wytwarzają różne UNF)
  • nie jest to system kontroli wersji i zasadniczo nie zapewnia wglądu w to, co się zmieniło, tylko że nastąpiła zmiana

wszystkie te narzędzia koncentrują się również na samych danych, a nie powiązanych metadanych (np. książka kodowa opisująca dane). Podczas gdy niektóre formaty danych (np. zastrzeżone formaty, takie jak Stata .dta i SPSS .sav) koduje te metadane bezpośrednio w pliku, nie jest to powszechna cecha szeroko rozdzielanych tekstowo struktur danych. Czasami książki kodowe są modyfikowane niezależnie od wartości danych i odwrotnie, ale raczej duże publiczne zbiory danych dostarczają szczegółowych informacji na temat zmian w danych lub książce kodowej, z wyjątkiem sporadycznych wydań.

kolejnym dużym wyzwaniem dla wersjonowania danych jest to, że istniejące narzędzia do kontroli wersji nie są dobrze zaprojektowane do obsługi pochodzenia. Gdy dane są generowane, przechowywane lub modyfikowane, zorientowany na oprogramowanie system kontroli wersji nie ma oczywistego mechanizmu rejestrowania, dlaczego wartości w zbiorze danych są tym, czym są lub dlaczego wprowadzane są zmiany do poszczególnych wartości. Wiadomość o zatwierdzeniu może dostarczyć tych informacji, ale gdy tylko wartość zostanie ponownie zmieniona, historia zmian danej wartości zostanie utracona w szerszej historii pliku danych jako całości.

tak więc wyraźnie nie istnieją kompletne narzędzia do wersjonowania danych.

niektóre zasady wersjonowania danych

pierwszą zasadą wersjonowania danych jest to, że zmiany danych mają źródła lub wyjaśnienia. System wersjonowania danych musi być w stanie połączyć wartości danych, strukturę i metadane (oraz zmiany tych funkcji) z wyjaśnieniami tych wartości lub zmianami wartości na poziomie wartości (a nie na poziomie zmiennych, obserwacji lub plików).

druga zasada polega na tym, że wersjonowanie danych powinno być oparte na wartościach, a nie na zmiennych lub obserwacjach. System nie może uprzywilejować obserwacji nad zmiennymi lub zmiennych nad obserwacjami; zmiana obserwacji jest koniecznie zmianą zmiennej i odwrotnie.

trzecia zasada wersjonowania danych polega na tym, że dane istnieją niezależnie od ich formatu. Jeśli zmieni się wartość danych w pliku CSV w porównaniu z drzewem JSON, są to zmiany równoważne zawartości. W związku z tym każdy system kontroli wersji powinien umożliwiać użytkownikom danych interakcję z danymi w dowolnym formacie pliku, który wybierają, bez konieczności korzystania z podstawowego formatu przechowywania danych.

czwarta zasada wersjonowania danych polega na tym, że współpraca jest niezbędna do generowania i kuratorowania danych. System wersjonowania danych musi być natywnie współpracujący i logicznie rejestrować, kto generuje i modyfikuje dane.

piąta zasada wersjonowania danych polega na tym, że zmiany w strukturze danych powinny być rejestrowane niezależnie od wartości danych. Sortowanie kolejności obserwacji, rozmieszczenie kolumn / zmiennych oraz rozmieszczenie wierszy jako przypadków w stosunku do przypadków-lat, itd. (tj., „szerokie „kontra” długie ” układy) są cechami strukturalnymi zbioru danych, a nie cechami danych per se. Są one ważne, ale proces wersjonowania danych powinien być w stanie odróżnić zmianę zawartości zbioru danych od zmiany organizacji lub struktury zbioru danych i, w tym ostatnim przypadku, prawidłowo rozpoznać identyczny zbiór danych, który jest ułożony na dwa różne sposoby.

szósta zasada wersjonowania danych jest taka, że metadane mają znaczenie, ale, podobnie jak struktura, powinny być traktowane oddzielnie od zmian w danych. Dwa identyczne zbiory danych z różnymi metadanymi powinny być rozpoznawane jako identyczne treści.

wstępne wnioski

dane powinny być przechowywane w sposób klucz-wartość, gdzie dowolny klucz przechowuje określoną wartość danych. Następnie mapowanie łączy te konkretne wartości danych zarówno z obserwacjami, jak i zmiennymi, dzięki czemu każda ocena zmian danych jest niezależna od formatu i struktury. W związku z tym zmiana wartości jest najpierw rejestrowana jako zmiana wartości, ale może być wtórnie rozpoznana jako jednoczesna zmiana zarówno obserwacji, jak i zmiennej.

każdy interfejs do takiego magazynu kluczy powinien mieć znajomą i elastyczną formę: użytkownicy powinni wchodzić w interakcje z systemem wersjonowania danych za pomocą dowolnego sposobu, w jaki obecnie używają danych (np. edytor tekstu, oprogramowanie do analizy danych, arkusz kalkulacyjny itp.). Zmiany powinny być rejestrowane w pliku głównym, który może natywnie i natychmiast importować i eksportować do dowolnego formatu pliku danych (w tym plików rozdzielanych, arkuszy kalkulacyjnych, XML, JSON itp.).

systemy wersjonowania danych muszą mieć bardziej wyrafinowany system zatwierdzania niż ten zapewniany przez obecne, zorientowane na oprogramowanie systemy kontroli wersji. W szczególności commity powinny rejestrować nie tylko zmianę wartości danych, struktury lub metadanych, ale także ustrukturyzowane informacje wyjaśniające tę zmianę, w tym przyczynę zmiany, źródła(źródła) wartości danych i autora zmiany. Zasadniczo zarówno zestawy zmian, jak i stany kompletnych danych powinny być w pełni cytowalne i zawierać metadane istotne dla cytowania.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.