Musimy uwzględnić przynajmniej te aspekty, aby zapewnić kompleksową odpowiedź/porównanie (w dowolnej kolejności): Speed, Memory usage, Syntax i Features.

Moim zamiarem jest omówienie każdego z nich tak wyraźnie, jak to możliwe, z perspektywy data.table.

Uwaga: jeśli wyraźnie nie zaznaczono inaczej, odnosząc się do dplyr, mamy na myśli interfejs data.frame dplyr, którego elementy wewnętrzne są w C++ i używają Rcpp.

Składnia data.table jest spójna w swojej formie - DT[i, j, by]. Trzymanie i, j i by razem jest zgodne z projektem. Łącząc powiązane operacje, pozwala łatwo zoptymalizować operacje pod kątem szybkości i, co ważniejsze, wykorzystania pamięci, a także zapewnia pewne zaawansowane funkcje , a wszystko to przy zachowaniu spójności składni.

1. Prędkość

Do pytania dodano sporo testów porównawczych (choć głównie dotyczących operacji grupowania), które już pokazują, że data.table staje się szybsza niż dplyr wraz ze wzrostem liczby grup i/lub wierszy do grupowania, w tym testy porównawcze Matta dotyczące grupowania od 10 milionów do 2 miliardów wiersze (100 GB pamięci RAM) w 100–10 milionach grup i różne kolumny grupujące, co również porównuje pandas. Zobacz też zaktualizowane testy porównawcze, które obejmują również Spark i pydatatable.

Jeśli chodzi o benchmarki, świetnie byłoby uwzględnić również pozostałe aspekty:

• Grupowanie operacji obejmujących podzbiór wierszy – tj. operacje typu DT[x > val, sum(y), by = z].

• Porównaj inne operacje, takie jak aktualizacja i łączenie.

• Oprócz czasu wykonania porównaj także zajętość pamięci dla każdej operacji.

2. Wykorzystanie pamięci

1. #P10#

   #P11#

2. #P12#

    # sub-assign by reference, updates 'y' in-place
    DT[x >= 1L, y := NA]
   

   #P13#

    # copies the entire 'y' column
    ans <- DF %>% mutate(y = replace(y, which(x >= 1L), NA))
   

   #P14# #P15#

    foo <- function(DT) {
        DT = shallow(DT)          ## shallow copy DT
        DT[, newcol := 1L]        ## does not affect the original DT 
        DT[x > 2L, newcol := 2L]  ## no need to copy (internally), as this column exists only in shallow copied DT
        DT[x > 2L, x := 3L]       ## have to copy (like base R / dplyr does always); otherwise original DT will 
                                  ## also get modified.
    }
   

   #P16#

    bar <- function(DT) {
        DT[, newcol := 1L]        ## old behaviour, original DT gets updated by reference
        DT[x > 2L, x := 3L]       ## old behaviour, update column x in original DT.
    }
   

   #P17#

   #P18#

   #P19#

3. Agreguj podczas dołączania:

   Załóżmy, że masz dwie tabele danych w następujący sposób:

    DT1 = data.table(x=c(1,1,1,1,2,2,2,2), y=c("a", "a", "b", "b"), z=1:8, key=c("x", "y"))
    #    x y z
    # 1: 1 a 1
    # 2: 1 a 2
    # 3: 1 b 3
    # 4: 1 b 4
    # 5: 2 a 5
    # 6: 2 a 6
    # 7: 2 b 7
    # 8: 2 b 8
    DT2 = data.table(x=1:2, y=c("a", "b"), mul=4:3, key=c("x", "y"))
    #    x y mul
    # 1: 1 a   4
    # 2: 2 b   3
   

   I chciałbyś otrzymać sum(z) * mul za każdy wiersz w DT2 podczas łączenia za pomocą kolumn x,y. Możemy:

   • 1. zagreguj DT1, aby uzyskać sum(z), 2) wykonaj połączenie i 3) pomnóż (lub)

        sposób na tabelę danych

        DT1[, .(z = suma(z)), keyby = .(x,y)][DT2][, z := z*mul][]

        odpowiednik dplyr

        DF1 %›% group_by(x, y) %›% podsumowania(z = suma(z)) %›% Right_join(DF2) %›% mutate(z = z * mul)

   • 2. zrób to wszystko za jednym razem (używając funkcji by = .EACHI):

        DT1[DT2, lista(z=suma(z) * mul), by = .EACHI]

   Jaka jest zaleta?

   • Nie musimy przydzielać pamięci dla wyniku pośredniego.

   • Nie musimy dwukrotnie grupować/haszować (jeden do agregacji, drugi do łączenia).

   • A co ważniejsze, operacja, którą chcieliśmy wykonać, jest jasna, patrząc na j w (2).

   Sprawdź ten post, aby uzyskać szczegółowe wyjaśnienie by = .EACHI. Nie powstają żadne wyniki pośrednie, a łączenie i agregacja są wykonywane za jednym razem.

   Spójrz na to, to i to posty dotyczące rzeczywistych scenariuszy użycia.

   W dplyr musiałbyś dołączyć i najpierw agregować lub agregować, a następnie dołączać, przy czym żadne z nich nie jest tak wydajny pod względem pamięci (co z kolei przekłada się na szybkość).

4. Aktualizacja i dołączenie:

   Rozważ kod data.table pokazany poniżej:

    DT1[DT2, col := i.mul]
   

   dodaje/aktualizuje kolumnę col DT1 za pomocą mul z DT2 w tych wierszach, w których kluczowa kolumna DT2 odpowiada DT1. Nie sądzę, że istnieje dokładny odpowiednik tej operacji w dplyr, tj. bez unikania operacji *_join, która musiałaby skopiować cały DT1 tylko po to, aby dodać do niego nową kolumnę, co jest niepotrzebne.

   Sprawdź ten post, aby zapoznać się z prawdziwym scenariuszem użycia.

Podsumowując, ważne jest, aby zdać sobie sprawę, że każdy szczegół optymalizacji ma znaczenie. Jak powiedziałaby Grace Hopper: Pilnuj swoich nanosekund!

3. Składnia

Przyjrzyjmy się teraz składni. Hadley skomentował tutaj:

Tabele danych są niezwykle szybkie, ale myślę, że ich zwięzłość trudniej się ich uczy, a kod, który z nich korzysta, jest trudniejszy do odczytania po napisaniu...

Uważam tę uwagę za bezsensowną, ponieważ jest ona bardzo subiektywna. Być może możemy spróbować porównać spójność składni. Porównamy składnię data.table i dplyr obok siebie.

Będziemy pracować z fikcyjnymi danymi pokazanymi poniżej:

DT = data.table(x=1:10, y=11:20, z=rep(1:2, each=5))
DF = as.data.frame(DT)

1. Podstawowe operacje agregacji/aktualizacji.

    # case (a)
    DT[, sum(y), by = z]                       ## data.table syntax
    DF %>% group_by(z) %>% summarise(sum(y)) ## dplyr syntax
    DT[, y := cumsum(y), by = z]
    ans <- DF %>% group_by(z) %>% mutate(y = cumsum(y))
   
    # case (b)
    DT[x > 2, sum(y), by = z]
    DF %>% filter(x>2) %>% group_by(z) %>% summarise(sum(y))
    DT[x > 2, y := cumsum(y), by = z]
    ans <- DF %>% group_by(z) %>% mutate(y = replace(y, which(x > 2), cumsum(y)))
   
    # case (c)
    DT[, if(any(x > 5L)) y[1L]-y[2L] else y[2L], by = z]
    DF %>% group_by(z) %>% summarise(if (any(x > 5L)) y[1L] - y[2L] else y[2L])
    DT[, if(any(x > 5L)) y[1L] - y[2L], by = z]
    DF %>% group_by(z) %>% filter(any(x > 5L)) %>% summarise(y[1L] - y[2L])
   

   • Składnia data.table jest zwarta, a dplyr dość gadatliwy. Rzeczy są mniej więcej równoważne w przypadku (a).

   • W przypadku (b) podczas podsumowywania musieliśmy użyć filter() w dplyr. Jednak podczas aktualizacji musieliśmy przenieść logikę do środka mutate(). Jednakże w data.table wyrażamy obie operacje w oparciu o tę samą logikę - operujemy na wierszach, gdzie x > 2, ale w pierwszym przypadku otrzymujemy sum(y), natomiast w drugim przypadku aktualizujemy te wiersze o y z jego skumulowaną sumą.

     To właśnie mamy na myśli, gdy mówimy, że DT[i, j, by] forma jest spójna.

   • Podobnie w przypadku (c), gdy mamy warunek if-else, jesteśmy w stanie wyrazić logikę tak jak jest zarówno w data.table, jak i dplyr. Jeśli jednak chcielibyśmy zwrócić tylko te wiersze, w których warunek if jest spełniony, a w przeciwnym razie pominąć, nie możemy bezpośrednio użyć summarise() (AFAICT). Musimy najpierw filter() a potem podsumować, ponieważ summarise() zawsze oczekuje pojedynczej wartości.

     Chociaż zwraca ten sam wynik, użycie tutaj filter() sprawia, że ​​faktyczna operacja jest mniej oczywista.

     Równie dobrze byłoby możliwe użycie filter() również w pierwszym przypadku (nie wydaje mi się to oczywiste), ale chodzi mi o to, że nie powinniśmy tego robić.

2. Agregacja/aktualizacja w wielu kolumnach

    # case (a)
    DT[, lapply(.SD, sum), by = z]                     ## data.table syntax
    DF %>% group_by(z) %>% summarise_each(funs(sum)) ## dplyr syntax
    DT[, (cols) := lapply(.SD, sum), by = z]
    ans <- DF %>% group_by(z) %>% mutate_each(funs(sum))
   
    # case (b)
    DT[, c(lapply(.SD, sum), lapply(.SD, mean)), by = z]
    DF %>% group_by(z) %>% summarise_each(funs(sum, mean))
   
    # case (c)
    DT[, c(.N, lapply(.SD, sum)), by = z]     
    DF %>% group_by(z) %>% summarise_each(funs(n(), mean))
   

   • W przypadku (a) kody są mniej więcej równoważne. data.table wykorzystuje znaną funkcję bazową lapply(), podczas gdy dplyr wprowadza *_each() wraz z wieloma funkcjami do funs().

   • data.table := wymaga podania nazw kolumn, podczas gdy dplyr generuje je automatycznie.

   • W przypadku (b) składnia dplyr jest stosunkowo prosta. Ulepszanie agregacji/aktualizacji wielu funkcji znajduje się na liście data.table.

   • Jednak w przypadku (c) dplyr zwróci n() tyle samo kolumn, a nie tylko raz. W data.table wystarczy zwrócić listę w j. Każdy element listy stanie się w wyniku kolumną. Możemy więc ponownie użyć znanej funkcji bazowej c(), aby połączyć .N z list, która zwraca list.

   Uwaga: ponownie w data.table wystarczy zwrócić listę w j. Każdy element listy stanie się w rezultacie kolumną. Aby to osiągnąć, możesz użyć funkcji podstawowych c(), as.list(), lapply(), list() itd., bez konieczności uczenia się nowych funkcji.

   Będziesz musiał nauczyć się tylko zmiennych specjalnych - przynajmniej .N i .SD. Odpowiednikami w dplyr są n() i .

3. Dołącza

   dplyr udostępnia osobne funkcje dla każdego typu łączenia, gdzie data.table umożliwia łączenie przy użyciu tej samej składni DT[i, j, by] (i nie bez powodu). Alternatywnie udostępnia także równoważną funkcję merge.data.table().

    setkey(DT1, x, y)
   
    # 1. normal join
    DT1[DT2]            ## data.table syntax
    left_join(DT2, DT1) ## dplyr syntax
   
    # 2. select columns while join    
    DT1[DT2, .(z, i.mul)]
    left_join(select(DT2, x, y, mul), select(DT1, x, y, z))
   
    # 3. aggregate while join
    DT1[DT2, .(sum(z) * i.mul), by = .EACHI]
    DF1 %>% group_by(x, y) %>% summarise(z = sum(z)) %>% 
        inner_join(DF2) %>% mutate(z = z*mul) %>% select(-mul)
   
    # 4. update while join
    DT1[DT2, z := cumsum(z) * i.mul, by = .EACHI]
    ??
   
    # 5. rolling join
    DT1[DT2, roll = -Inf]
    ??
   
    # 6. other arguments to control output
    DT1[DT2, mult = "first"]
    ??
   

• Niektórzy mogą uznać, że osobna funkcja dla każdego łączenia jest o wiele ładniejsza (lewe, prawe, wewnętrzne, anty, pół itp.), podczas gdy innym może się spodobać DT[i, j, by] lub merge() w data.table, które są podobne do podstawowego R.

• Jednak połączenia dplyr właśnie to robią. Nic więcej. Nic mniej.

• data.tables mogą wybierać kolumny podczas łączenia (2), a w dplyr będziesz musiał najpierw select() na obu data.frames przed dołączeniem, jak pokazano powyżej. W przeciwnym razie zmaterializowałbyś połączenie z niepotrzebnymi kolumnami tylko po to, aby je później usunąć, a to jest nieefektywne.

• data.tables może agregować podczas dołączania przy użyciu by = .EACHI funkcji (3), a także aktualizować podczas dołączania (4). Po co materializować cały wynik łączenia, aby dodać/zaktualizować tylko kilka kolumn?

• data.table umożliwia złączenia kroczące (5) - przewijanie do przodu, LOCF, przewiń do tyłu, NOCB, najbliższy.

• data.table ma również argument mult =, który wybiera pierwsze, ostatnie lub wszystkie dopasowania (6).

• data.table zawiera argument allow.cartesian = TRUE chroniący przed przypadkowymi nieprawidłowymi połączeniami.

Po raz kolejny składnia jest zgodna z DT[i, j, by] z dodatkowymi argumentami pozwalającymi na dalszą kontrolę wyjścia.

4. do()...

   Podsumowanie dplyr zostało specjalnie zaprojektowane dla funkcji zwracających pojedynczą wartość. Jeśli Twoja funkcja zwróci wiele/nierównych wartości, będziesz musiał skorzystać z do(). Musisz wcześniej wiedzieć o wszystkich wartościach zwracanych przez funkcje.

    DT[, list(x[1], y[1]), by = z]                 ## data.table syntax
    DF %>% group_by(z) %>% summarise(x[1], y[1]) ## dplyr syntax
    DT[, list(x[1:2], y[1]), by = z]
    DF %>% group_by(z) %>% do(data.frame(.$x[1:2], .$y[1]))
   
    DT[, quantile(x, 0.25), by = z]
    DF %>% group_by(z) %>% summarise(quantile(x, 0.25))
    DT[, quantile(x, c(0.25, 0.75)), by = z]
    DF %>% group_by(z) %>% do(data.frame(quantile(.$x, c(0.25, 0.75))))
   
    DT[, as.list(summary(x)), by = z]
    DF %>% group_by(z) %>% do(data.frame(as.list(summary(.$x))))
   

• Odpowiednik .SD to .

• W data.table możesz wrzucić praktycznie wszystko do j - jedyną rzeczą, o której należy pamiętać, jest zwrócenie listy, dzięki czemu każdy element listy zostanie przekonwertowany na kolumnę.

• W dplyr nie można tego zrobić. Musisz skorzystać z do() w zależności od tego, jak pewny jesteś, czy Twoja funkcja zawsze zwróci pojedynczą wartość. I to jest dość powolne.

Po raz kolejny składnia data.table jest zgodna z DT[i, j, by]. Możemy po prostu wrzucać wyrażenia w j, nie martwiąc się o te rzeczy.

Spójrz na to pytanie SO i ten. Zastanawiam się, czy możliwe byłoby wyrażenie odpowiedzi tak prosto, używając składni dplyr ...

Podsumowując, szczególnie podkreśliłem kilka przypadków, w których składnia dplyr jest albo nieefektywna, ograniczona, albo nie ułatwia wykonywania operacji. Dzieje się tak szczególnie dlatego, że data.table spotyka się z dużą krytyką trudniejszej do odczytania/nauki składni (jak ta wklejona/linkowana powyżej). Większość postów dotyczących dplyr mówi o najprostszych operacjach. I to jest świetne. Ale ważne jest, aby zdać sobie sprawę z jego ograniczeń składniowych i funkcjonalnych, a nie widziałem jeszcze postu na ten temat.

data.table ma również swoje dziwactwa (niektóre z nich, jak wskazałem, staramy się naprawić). Próbujemy także ulepszyć łączenia data.table, jak podkreśliłem tutaj.

Ale należy również wziąć pod uwagę liczbę funkcji, których brakuje dplyr w porównaniu z data.table.

4. Funkcje

Większość funkcji wskazałem tutaj, a także w tym poście. Ponadto:

• fread - szybki czytnik plików jest dostępny już od dłuższego czasu.

• fwrite — dostępny jest teraz równoległy szybki zapis plików. Zobacz ten post, aby uzyskać szczegółowe wyjaśnienie dotyczące implementacji oraz #1664 do śledzenia dalszego rozwoju sytuacji.

• Automatyczne indeksowanie — kolejna przydatna funkcja służąca do wewnętrznej optymalizacji podstawowej składni języka R.

• Grupowanie ad hoc: dplyr automatycznie sortuje wyniki, grupując zmienne podczas summarise(), co nie zawsze jest pożądane.

• Liczne zalety złączeń data.table (pod względem szybkości, wydajności pamięci i składni), o których mowa powyżej.

• Złączenia nierówne: umożliwia złączenia przy użyciu innych operatorów <=, <, >, >= wraz ze wszystkimi innymi zaletami złączy data.table.

• Nakładające się łączenia zakresów zostały niedawno zaimplementowane w data.table. Sprawdź ten post, aby zapoznać się z omówieniem testów porównawczych.

• setorder() funkcja w data.table, która pozwala na naprawdę szybką zmianę kolejności data.tables przez odwołanie.

• dplyr zapewnia interfejs z bazami danych przy użyciu tej samej składni, która data.table obecnie tego nie robi.

• data.table zapewnia szybsze odpowiedniki operacji na setach (napisane przez Jana Góreckiego) - fsetdiff, fintersect, funion i fsetequal z dodatkowym argumentem all (jak w SQL).

• data.table ładuje się czysto, bez ostrzeżeń maskujących i ma mechanizm opisany tutaj dla [.data.frame zgodności po przekazaniu do dowolnego pakietu R. dplyr zmienia podstawowe funkcje filter, lag i [, co może powodować problemy; np. tutaj i tutaj.

Wreszcie:

• W przypadku baz danych - nie ma powodu, dla którego data.table nie mogłaby zapewnić podobnego interfejsu, ale nie jest to teraz priorytetem. Może się to pogorszyć, jeśli użytkownikom bardzo spodoba się ta funkcja… nie jestem pewien.

• O równoległości - Wszystko jest trudne, dopóki ktoś nie pójdzie dalej i tego nie zrobi. Oczywiście będzie to wymagało wysiłku (bezpieczeństwo wątków).

  • Progress is being made currently (in v1.9.7 devel) towards parallelising known time consuming parts for incremental performance gains using OpenMP.

Oto moja próba kompleksowej odpowiedzi z perspektywy dplyr, zgodnie z ogólnym zarysem odpowiedzi Aruna (ale nieco zmieniona w oparciu o różne priorytety).

Składnia

Składnia jest pewna subiektywna, ale podtrzymuję swoje stwierdzenie, że zwięzłość pliku data.table utrudnia naukę i czytanie. Dzieje się tak częściowo dlatego, że dplyr rozwiązuje znacznie łatwiejszy problem!

Jedną z naprawdę ważnych rzeczy, które robi dla Ciebie dplyr, jest to, że ogranicza Twoje opcje. Twierdzę, że większość problemów z pojedynczą tabelą można rozwiązać za pomocą zaledwie pięciu kluczowych czasowników: filtruj, wybieraj, mutuj, porządkuj i podsumowuj, wraz z przysłówkiem „według grupy”. To ograniczenie jest bardzo pomocne podczas nauki manipulacji danymi, ponieważ pomaga uporządkować myślenie o problemie. W dplyr każdy z tych czasowników jest mapowany na pojedynczą funkcję. Każda funkcja ma jedno zadanie i jest łatwa do zrozumienia oddzielnie.

Tworzysz złożoność, łącząc te proste operacje razem z %>%. Oto przykład z jednego z postów, do których Arun linkuje:

diamonds %>%
  filter(cut != "Fair") %>%
  group_by(cut) %>%
  summarize(
    AvgPrice = mean(price),
    MedianPrice = as.numeric(median(price)),
    Count = n()
  ) %>%
  arrange(desc(Count))

Nawet jeśli nigdy wcześniej nie widziałeś dplyr (ani nawet R!), nadal możesz zrozumieć, co się dzieje, ponieważ wszystkie funkcje są czasownikami angielskimi. Wadą czasowników angielskich jest to, że wymagają one więcej wpisania niż [, ale myślę, że można to w dużym stopniu złagodzić dzięki lepszemu autouzupełnianiu.

Oto równoważny kod data.table:

diamondsDT <- data.table(diamonds)
diamondsDT[
  cut != "Fair", 
  .(AvgPrice = mean(price),
    MedianPrice = as.numeric(median(price)),
    Count = .N
  ), 
  by = cut
][ 
  order(-Count) 
]

Trudniej jest zastosować się do tego kodu, jeśli nie znasz już data.table. (Nie mogłem też wymyślić, jak wciąć powtórzone [ w sposób, który będzie dobrze wyglądał na moje oko). Osobiście, kiedy patrzę na kod, który napisałem 6 miesięcy temu, mam wrażenie, że patrzę na kod napisany przez nieznajomego, więc wolę prosty, choć szczegółowy kod.

Dwa inne drobne czynniki, które moim zdaniem nieznacznie zmniejszają czytelność:

• Ponieważ prawie każda operacja na tabeli danych wykorzystuje [, potrzebny jest dodatkowy kontekst, aby dowiedzieć się, co się dzieje. Na przykład, czy x[y] łączy dwie tabele danych, czy wyodrębnia kolumny z ramki danych? Jest to tylko mały problem, ponieważ w dobrze napisanym kodzie nazwy zmiennych powinny sugerować, co się dzieje.

• Podoba mi się, że group_by() to osobna operacja w dplyr. Zasadniczo zmienia to obliczenia, więc myślę, że powinno być oczywiste podczas przeglądania kodu i łatwiej jest wykryć group_by() niż argument by do [.data.table.

Podoba mi się też to, że potok nie ogranicza się tylko do jednego pakietu. Możesz zacząć od uporządkowania danych za pomocą tidyr, a zakończyć za pomocą fabuła w ggvis. I nie jesteś ograniczony do pakietów, które piszę — każdy może napisać funkcję, która stanowi płynną część potoku manipulacji danymi. Właściwie wolę poprzedni kod data.table przepisany za pomocą %>%:

diamonds %>% 
  data.table() %>% 
  .[cut != "Fair", 
    .(AvgPrice = mean(price),
      MedianPrice = as.numeric(median(price)),
      Count = .N
    ), 
    by = cut
  ] %>% 
  .[order(-Count)]

Pomysł potokowania za pomocą %>% nie ogranicza się tylko do ramek danych i można go łatwo uogólnić na inne konteksty: interaktywna grafika internetowa, przeszukiwanie sieci, podstawy, kontrakty wykonawcze, ...)

Pamięć i wydajność

Zebrałem je w jedno, ponieważ dla mnie nie są one aż tak ważne. Większość użytkowników R pracuje z mniej niż 1 milionem wierszy danych, a dplyr jest wystarczająco szybki dla takiego rozmiaru danych, że nie jesteś świadomy czasu przetwarzania. Optymalizujemy dplyr pod kątem wyrazistości na średnich danych; możesz użyć data.table, aby uzyskać surową prędkość w przypadku większych danych.

Elastyczność dplyr oznacza również, że możesz łatwo dostosować charakterystykę wydajności, używając tej samej składni. Jeśli wydajność dplyr z backendem ramki danych nie jest dla Ciebie wystarczająco dobra, możesz użyć backendu data.table (aczkolwiek z nieco ograniczonym zestawem funkcjonalności). Jeśli dane, z którymi pracujesz, nie mieszczą się w pamięci, możesz użyć zaplecza bazy danych.

Wszystko to powiedziawszy, wydajność dplyr poprawi się w dłuższej perspektywie. Z pewnością wdrożymy kilka świetnych pomysłów z data.table, takich jak porządkowanie radix i używanie tego samego indeksu dla złączeń i filtrów. Pracujemy również nad równoległością, abyśmy mogli wykorzystać wiele rdzeni.

Cechy

Kilka rzeczy, nad którymi planujemy pracować w 2015 roku:

• pakiet readr, aby ułatwić pobieranie plików z dysku do pamięci, analogicznie do fread().

• Bardziej elastyczne łączenia, w tym obsługa połączeń innych niż równorzędne.

• Bardziej elastyczne grupowanie, takie jak próbki bootstrap, zestawienia i inne

Inwestuję także czas w ulepszanie złączy baz danych R, czyli możliwości komunikowania się z apis sieciowy i ułatwienie zeskrob strony HTML.