Cześć, Habr!
Jesienią ubiegłego roku na Kaggle odbył się konkurs na klasyfikację narysowanych ręcznie obrazków Quick Draw Doodle Recognition, w którym wzięła udział m.in. drużyna R-owców w składzie , i . Nie będziemy szczegółowo opisywać zawodów, to zostało już zrobione w .
Z medalami w tym razem się nie udało, ale zdobyto wiele cennego doświadczenia, dlatego chcielibyśmy opowiedzieć społeczności o kilku najciekawszych i użytecznych rzeczach na Kaggle oraz w codziennej pracy. Wśród omawianych tematów: trudne życie bez OpenCV, parsowanie JSON-ów (w tych przykładach omawiane są integracje kodu C++ w skrypty lub pakiety R przy użyciu Rcpp), parametryzacja skryptów i konteneryzacja końcowego rozwiązania. Cały kod z wiadomości w gotowej do uruchomienia formie dostępny jest w .
Zawartość:
1. Efektywne ładowanie danych z CSV do bazy MonetDB
Dane w tym konkursie dostarczane są nie w formie gotowych obrazków, a w postaci 340 plików CSV (po jednym pliku na każdą klasę), zawierających JSON-y z współrzędnymi punktów. Łącząc te punkty liniami, otrzymujemy końcowy obrazek o rozmiarze 256x256 pikseli. Dla każdej pozycji podawana jest etykieta, czy obrazek został poprawnie rozpoznany przez klasyfikator używany w momencie zbierania zestawu danych, dwu-literowy kod kraju zamieszkania autora rysunku, unikalny identyfikator, znacznik czasu oraz nazwa klasy, odpowiadająca nazwie pliku. Uproszczona wersja danych zajmuje 7,4 GB w archiwum i około 20 GB po rozpakowaniu, pełne dane po rozpakowaniu zajmują 240 GB. Organizatorzy zapewnili, że obie wersje reprodukują te same rysunki, więc pełna wersja jest zbędna. W każdym razie, przechowywanie 50 milionów obrazków w plikach graficznych lub w postaci tablic zostało uznane za nieopłacalne, dlatego postanowiliśmy zintegrować wszystkie pliki CSV z archiwum train_simplified.zip w bazie danych z późniejszą generacją obrazków odpowiedniego rozmiaru „w locie” dla każdej partii.
Jako system baz danych wybrano dobrze się sprawdzającą MonetDB, a mianowicie realizacja dla R w postaci pakietu . Pakiet zawiera embedded-wersję serwera bazy danych i pozwala na uruchomienie serwera bezpośrednio z sesji R i pracę z nim. Tworzenie bazy danych i połączenie odbywa się za pomocą jednej komendy:
con <- DBI::dbConnect(drv = MonetDBLite::MonetDBLite(), Sys.getenv("DBDIR"))Będziemy potrzebować stworzyć dwie tabele: jedną dla wszystkich danych, a drugą dla informacji pomocniczych o załadowanych plikach (przyda się, jeśli coś pójdzie nie tak i proces będzie trzeba wznowić po załadowaniu kilku plików):
Tworzenie tabel
if (!DBI::dbExistsTable(con, "doodles")) {
DBI::dbCreateTable(
con = con,
name = "doodles",
fields = c(
"countrycode" = "char(2)",
"drawing" = "text",
"key_id" = "bigint",
"recognized" = "bool",
"timestamp" = "timestamp",
"word" = "text"
)
)
}
if (!DBI::dbExistsTable(con, "upload_log")) {
DBI::dbCreateTable(
con = con,
name = "upload_log",
fields = c(
"id" = "serial",
"file_name" = "text UNIQUE",
"uploaded" = "bool DEFAULT false"
)
)
}Najlepszym sposobem na załadowanie danych do bazy okazało się bezpośrednie kopiowanie plików CSV za pomocą SQL — komenda COPY OFFSET 2 INTO tablename FROM path USING DELIMITERS ',', 'n', '"' NULL AS '' BEST EFFORT, gdzie tablename — nazwa tabeli i path — ścieżka do pliku. Podczas pracy z archiwum stwierdzono, że wbudowana realizacja unzip w R nie działa poprawnie z niektórymi plikami z archiwum, dlatego użyliśmy systemowego unzip (za pomocą parametru getOption("unzip")).
Funkcja do zapisu do bazy
#' @title Извлечение и загрузка файлов
#'
#' @description
#' Извлечение CSV-файлов из ZIP-архива и загрузка их в базу данных
#'
#' @param con Объект подключения к базе данных (класс `MonetDBEmbeddedConnection`).
#' @param tablename Название таблицы в базе данных.
#' @oaram zipfile Путь к ZIP-архиву.
#' @oaram filename Имя файла внури ZIP-архива.
#' @param preprocess Функция предобработки, которая будет применена извлечённому файлу.
#' Должна принимать один аргумент `data` (объект `data.table`).
#'
#' @return `TRUE`.
#'
upload_file <- function(con, tablename, zipfile, filename, preprocess = NULL) {
# Проверка аргументов
checkmate::assert_class(con, "MonetDBEmbeddedConnection")
checkmate::assert_string(tablename)
checkmate::assert_string(filename)
checkmate::assert_true(DBI::dbExistsTable(con, tablename))
checkmate::assert_file_exists(zipfile, access = "r", extension = "zip")
checkmate::assert_function(preprocess, args = c("data"), null.ok = TRUE)
# Извлечение файла
path <- file.path(tempdir(), filename)
unzip(zipfile, files = filename, exdir = tempdir(),
junkpaths = TRUE, unzip = getOption("unzip"))
on.exit(unlink(file.path(path)))
# Применяем функция предобработки
if (!is.null(preprocess)) {
.data <- data.table::fread(file = path)
.data <- preprocess(data = .data)
data.table::fwrite(x = .data, file = path, append = FALSE)
rm(.data)
}
# Запрос к БД на импорт CSV
sql <- sprintf(
"COPY OFFSET 2 INTO %s FROM '%s' USING DELIMITERS ',','n','"' NULL AS '' BEST EFFORT",
tablename, path
)
# Выполнение запроса к БД
DBI::dbExecute(con, sql)
# Добавление записи об успешной загрузке в служебную таблицу
DBI::dbExecute(con, sprintf("INSERT INTO upload_log(file_name, uploaded) VALUES('%s', true)",
filename))
return(invisible(TRUE))
}W przypadku, gdy wymagane jest przekształcenie tabeli przed zapisaniem do bazy, wystarczy przekazać w argumencie preprocess funkcję, która przekształci dane.
Kod do sekwencyjnego załadowania danych do bazy:
Zapis danych do bazy
# Список файлов для записи
files <- unzip(zipfile, list = TRUE)$Name
# Список исключений, если часть файлов уже была загружена
to_skip <- DBI::dbGetQuery(con, "SELECT file_name FROM upload_log")[[1L]]
files <- setdiff(files, to_skip)
if (length(files) > 0L) {
# Запускаем таймер
tictoc::tic()
# Прогресс бар
pb <- txtProgressBar(min = 0L, max = length(files), style = 3)
for (i in seq_along(files)) {
upload_file(con = con, tablename = "doodles",
zipfile = zipfile, filename = files[i])
setTxtProgressBar(pb, i)
}
close(pb)
# Останавливаем таймер
tictoc::toc()
}
# 526.141 sec elapsed - копирование SSD->SSD
# 558.879 sec elapsed - копирование USB->SSDCzas ładowania danych może się różnić w zależności od charakterystyki prędkości używanego nośnika. W naszym przypadku odczyt i zapis w obrębie jednego SSD lub z pendrive'a (plik źródłowy) na SSD (baza) zajmuje mniej niż 10 minut.
Kilka dodatkowych sekund jest wymaganych do stworzenia kolumny z całkowitą etykietą klasy oraz kolumny indeksu (ORDERED INDEX) z numerami wierszy, według których będą wybierane obserwacje przy tworzeniu partii:
Tworzenie dodatkowych kolumn i indeksu
message("Generate lables")
invisible(DBI::dbExecute(con, "ALTER TABLE doodles ADD label_int int"))
invisible(DBI::dbExecute(con, "UPDATE doodles SET label_int = dense_rank() OVER (ORDER BY word) - 1"))
message("Generate row numbers")
invisible(DBI::dbExecute(con, "ALTER TABLE doodles ADD id serial"))
invisible(DBI::dbExecute(con, "CREATE ORDERED INDEX doodles_id_ord_idx ON doodles(id)"))Aby rozwiązać problem generowania batcha "w locie", musieliśmy osiągnąć maksymalną prędkość wydobywania losowych wierszy z tabeli. doodles. W tym celu zastosowaliśmy 3 sztuczki. Pierwsza polegała na zredukowaniu wymiarowości typu, w którym przechowywane jest ID obserwacji. W początkowym zbiorze danych do przechowywania ID wymagany jest typ bigint, ale liczba obserwacji pozwala na zmieszczenie ich identyfikatorów, równych numerowi porządkowemu, w typie int. Dzięki temu wyszukiwanie przebiega znacznie szybciej. Drugą sztuczką było zastosowanie ORDERED INDEX — do tego rozwiązania doszliśmy empirycznie, testując wszystkie dostępne . Trzecia polegała na użyciu zapytań parametryzowanych. Istota metody polega na jednokrotnym wykonaniu polecenia PREPARE z późniejszym wykorzystaniem przygotowanego wyrażenia przy tworzeniu stosu jednorodnych zapytań, ale realne korzyści w porównaniu do prostego SELECT okazały się w granicach statystycznego błędu.
Proces ładowania danych zużywa nie więcej niż 450 MB RAM. Oznacza to, że opisane podejście pozwala na przetwarzanie zestawów danych o wadze dziesiątek gigabajtów praktycznie na każdym budżetowym sprzęcie, w tym na niektórych jednopłytowych komputerach, co jest dość fajne.
Pozostaje wykonać pomiary prędkości wydobywania (losowych) danych oraz ocenić skalowanie przy wybieraniu batchy o różnych rozmiarach:
Benchmark bazy danych
library(ggplot2)
set.seed(0)
# Połączenie z bazą danych
con <- DBI::dbConnect(MonetDBLite::MonetDBLite(), Sys.getenv("DBDIR"))
# Funkcja do przygotowania zapytania po stronie serwera
prep_sql <- function(batch_size) {
sql <- sprintf("PREPARE SELECT id FROM doodles WHERE id IN (%s)",
paste(rep("?", batch_size), collapse = ","))
res <- DBI::dbSendQuery(con, sql)
return(res)
}
# Funkcja do pobierania danych
fetch_data <- function(rs, batch_size) {
ids <- sample(seq_len(n), batch_size)
res <- DBI::dbFetch(DBI::dbBind(rs, as.list(ids)))
return(res)
}
# Przeprowadzenie pomiaru
res_bench <- bench::press(
batch_size = 2^(4:10),
{
rs <- prep_sql(batch_size)
bench::mark(
fetch_data(rs, batch_size),
min_iterations = 50L
)
}
)
# Parametry benchmarku
cols <- c("batch_size", "min", "median", "max", "itr/sec", "total_time", "n_itr")
res_bench[, cols]
# batch_size min median max `itr/sec` total_time n_itr
#
# 1 16 23.6ms 54.02ms 93.43ms 18.8 2.6s 49
# 2 32 38ms 84.83ms 151.55ms 11.4 4.29s 49
# 3 64 63.3ms 175.54ms 248.94ms 5.85 8.54s 50
# 4 128 83.2ms 341.52ms 496.24ms 3.00 16.69s 50
# 5 256 232.8ms 653.21ms 847.44ms 1.58 31.66s 50
# 6 512 784.6ms 1.41s 1.98s 0.740 1.1m 49
# 7 1024 681.7ms 2.72s 4.06s 0.377 2.16m 49
ggplot(res_bench, aes(x = factor(batch_size), y = median, group = 1)) +
geom_point() +
geom_line() +
ylab("czas mediany, s") +
theme_minimal()
DBI::dbDisconnect(con, shutdown = TRUE) 
2. Przygotowanie partii
Cały proces przygotowania partii składa się z następujących etapów:
- Parsowanie kilku JSON-ów, zawierających wektory ciągów z współrzędnymi punktów.
- Rysowanie kolorowych linii według współrzędnych punktów na obrazie o wymaganym rozmiarze (np. 256×256 lub 128×128).
- Przekształcanie uzyskanych obrazów w tensor.
W ramach rywalizacji między kernelami w Pythonie zadanie to rozwiązano głównie przy użyciu OpenCV. Jednym z najprostszych i najbardziej oczywistych odpowiedników w R będzie wyglądać następująco:
Implementacja przekształcenia JSON w tensor w R
r_process_json_str <- function(json, line.width = 3,
color = TRUE, scale = 1) {
# Parsowanie JSON
coords <- jsonlite::fromJSON(json, simplifyMatrix = FALSE)
tmp <- tempfile()
# Usuwanie pliku tymczasowego po zakończeniu funkcji
on.exit(unlink(tmp))
png(filename = tmp, width = 256 * scale, height = 256 * scale, pointsize = 1)
# Pusty wykres
plot.new()
# Rozmiar okna wykresu
plot.window(xlim = c(256 * scale, 0), ylim = c(256 * scale, 0))
# Kolory linii
cols <- if (color) rainbow(length(coords)) else "#000000"
for (i in seq_along(coords)) {
lines(x = coords[[i]][[1]] * scale, y = coords[[i]][[2]] * scale,
col = cols[i], lwd = line.width)
}
dev.off()
# Przekształcenie obrazu w trójwymiarową tablicę
res <- png::readPNG(tmp)
return(res)
}
r_process_json_vector <- function(x, ...) {
res <- lapply(x, r_process_json_str, ...)
# Łączenie trójwymiarowych tablic obrazów w czterowymiarowy tensor
res <- do.call(abind::abind, c(res, along = 0))
return(res)
}Rysowanie wykonywane jest standardowymi narzędziami R z zapisywaniem do tymczasowego pliku PNG, przechowywanego w pamięci RAM (w systemie Linux tymczasowe katalogi R znajdują się w folderze /tmp, zamontowanym w pamięci RAM). Następnie ten plik jest odczytywany jako trójwymiarowa tablica z liczbami w przedziale od 0 do 1. To jest ważne, ponieważ bardziej powszechny BMP zostałby odczytany jako surowa tablica z kodami hex kolorów.
Przetestujmy wynik:
zip_file <- file.path("data", "train_simplified.zip")
csv_file <- "cat.csv"
unzip(zip_file, files = csv_file, exdir = tempdir(),
junkpaths = TRUE, unzip = getOption("unzip"))
tmp_data <- data.table::fread(file.path(tempdir(), csv_file), sep = ",",
select = "drawing", nrows = 10000)
arr <- r_process_json_str(tmp_data[4, drawing])
dim(arr)
# [1] 256 256 3
plot(magick::image_read(arr)) 
Sam proces formowania zbioru będzie przebiegał w następujący sposób:
res <- r_process_json_vector(tmp_data[1:4, drawing], scale = 0.5)
str(res)
# num [1:4, 1:128, 1:128, 1:3] 1 1 1 1 1 1 1 1 1 1 ...
# - attr(*, "dimnames")=List of 4
# ..$ : NULL
# ..$ : NULL
# ..$ : NULL
# ..$ : NULLTo wdrożenie wydawało nam się nieoptymalne, ponieważ formowanie dużych zbiorów zajmuje nieprzyzwoicie dużo czasu, więc postanowiliśmy skorzystać z doświadczeń kolegów, wykorzystując potężną bibliotekę OpenCV. W tamtym czasie gotowego pakietu dla R nie było (nie ma go do teraz), dlatego napisana została minimalna implementacja wymaganego funkcjonalności w C++ z integracją w kod R przy użyciu Rcpp.
Do rozwiązania zadania wykorzystano następujące pakiety i biblioteki:
OpenCV do pracy z obrazami i rysowania linii. Użyto wcześniej zainstalowanych bibliotek systemowych i plików nagłówkowych, a także dynamicznego linkowania.
xtensor do pracy z wielowymiarowymi tablicami i tensorami. Użyto plików nagłówkowych dołączonych do pakietu R o tej samej nazwie. Biblioteka umożliwia pracę z wielowymiarowymi tablicami, zarówno w porządku major row, jak i column major.
ndjson do parsowania JSON. Ta biblioteka jest używana w xtensor automatycznie, gdy jest obecna w projekcie.
RcppThread do organizacji wielowątkowej obróbki wektora z JSON-ów. Użyto plików nagłówkowych dostarczonych przez ten pakiet. W porównaniu z bardziej popularnym RcppParallel pakiet ten wyróżnia się między innymi wbudowanym mechanizmem przerywania cyklu (interrupt).
Warto zauważyć, że xtensor okazał się prawdziwym odkryciem: poza tym, że dysponuje rozbudowaną funkcjonalnością i wysoką wydajnością, jego twórcy byli bardzo pomocni i szybko oraz szczegółowo odpowiadają na pojawiające się pytania. Dzięki nim udało się zrealizować konwersje macierzy OpenCV na tensory xtensor, a także sposób łączenia trójwymiarowych tensorów obrazów w czterowymiarowy tensor o odpowiednich wymiarach (właściwie batch).
Materiały do nauki Rcpp, xtensor i RcppThread
Do kompilacji plików wykorzystujących pliki systemowe i dynamiczne linkowanie z zainstalowanymi w systemie bibliotekami, skorzystaliśmy z mechanizmu wtyczek zrealizowanego w pakiecie Rcpp. Do automatycznego znajdowania ścieżek i flagów użyto popularnego narzędzia linuxowego pkg-config.
Implementacja wtyczki Rcpp do wykorzystania biblioteki OpenCV
Rcpp::registerPlugin("opencv", function() {
# Możliwe nazwy pakietu
pkg_config_name <- c("opencv", "opencv4")
# Plik binarny narzędzia pkg-config
pkg_config_bin <- Sys.which("pkg-config")
# Sprawdzenie obecności narzędzia w systemie
checkmate::assert_file_exists(pkg_config_bin, access = "x")
# Sprawdzenie obecności pliku konfiguracyjnego OpenCV dla pkg-config
check <- sapply(pkg_config_name,
function(pkg) system(paste(pkg_config_bin, pkg)))
if (all(check != 0)) {
stop("Konfiguracja OpenCV dla pkg-config nie została znaleziona", call. = FALSE)
}
pkg_config_name <- pkg_config_name[check == 0]
list(env = list(
PKG_CXXFLAGS = system(paste(pkg_config_bin, "--cflags", pkg_config_name),
intern = TRUE),
PKG_LIBS = system(paste(pkg_config_bin, "--libs", pkg_config_name),
intern = TRUE)
))
})W wyniku działania wtyczki w trakcie kompilacji zostaną podstawione następujące wartości:
Rcpp:::.plugins$opencv()$env
# $PKG_CXXFLAGS
# [1] "-I/usr/include/opencv"
#
# $PKG_LIBS
# [1] "-lopencv_shape -lopencv_stitching -lopencv_superres -lopencv_videostab -lopencv_aruco -lopencv_bgsegm -lopencv_bioinspired -lopencv_ccalib -lopencv_datasets -lopencv_dpm -lopencv_face -lopencv_freetype -lopencv_fuzzy -lopencv_hdf -lopencv_line_descriptor -lopencv_optflow -lopencv_video -lopencv_plot -lopencv_reg -lopencv_saliency -lopencv_stereo -lopencv_structured_light -lopencv_phase_unwrapping -lopencv_rgbd -lopencv_viz -lopencv_surface_matching -lopencv_text -lopencv_ximgproc -lopencv_calib3d -lopencv_features2d -lopencv_flann -lopencv_xobjdetect -lopencv_objdetect -lopencv_ml -lopencv_xphoto -lopencv_highgui -lopencv_videoio -lopencv_imgcodecs -lopencv_photo -lopencv_imgproc -lopencv_core"Kod implementacji parsowania JSON i tworzenia partii do przesłania do modelu jest podany w spolarze. Najpierw dodajemy lokalny katalog projektu do poszukiwania plików nagłówkowych (jest to potrzebne do ndjson):
Sys.setenv("PKG_CXXFLAGS" = paste0("-I", normalizePath(file.path("src"))))Implementacja konwersji JSON do tensora w C++
// [[Rcpp::plugins(cpp14)]]
// [[Rcpp::plugins(opencv)]]
// [[Rcpp::depends(xtensor)]]
// [[Rcpp::depends(RcppThread)]]
#include <xtensor/xjson.hpp>
#include <xtensor/xadapt.hpp>
#include <xtensor/xview.hpp>
#include <xtensor-r/rtensor.hpp>
#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
#include <opencv2/imgproc/imgproc.hpp>
#include <Rcpp.h>
#include <RcppThread.h>
// Синонимы для типов
using RcppThread::parallelFor;
using json = nlohmann::json;
using points = xt::xtensor<double,2>; // Извлечённые из JSON координаты точек
using strokes = std::vector<points>; // Извлечённые из JSON координаты точек
using xtensor3d = xt::xtensor<double, 3>; // Тензор для хранения матрицы изоображения
using xtensor4d = xt::xtensor<double, 4>; // Тензор для хранения множества изображений
using rtensor3d = xt::rtensor<double, 3>; // Обёртка для экспорта в R
using rtensor4d = xt::rtensor<double, 4>; // Обёртка для экспорта в R
// Статические константы
// Размер изображения в пикселях
const static int SIZE = 256;
// Тип линии
// См. https://en.wikipedia.org/wiki/Pixel_connectivity#2-dimensional
const static int LINE_TYPE = cv::LINE_4;
// Толщина линии в пикселях
const static int LINE_WIDTH = 3;
// Алгоритм ресайза
// https://docs.opencv.org/3.1.0/da/d54/group__imgproc__transform.html#ga5bb5a1fea74ea38e1a5445ca803ff121
const static int RESIZE_TYPE = cv::INTER_LINEAR;
// Шаблон для конвертирования OpenCV-матрицы в тензор
template <typename T, int NCH, typename XT=xt::xtensor<T,3,xt::layout_type::column_major>>
XT to_xt(const cv::Mat_<cv::Vec<T, NCH>>& src) {
// Размерность целевого тензора
std::vector<int> shape = {src.rows, src.cols, NCH};
// Общее количество элементов в массиве
size_t size = src.total() * NCH;
// Преобразование cv::Mat в xt::xtensor
XT res = xt::adapt((T*) src.data, size, xt::no_ownership(), shape);
return res;
}
// Преобразование JSON в список координат точек
strokes parse_json(const std::string& x) {
auto j = json::parse(x);
// Результат парсинга должен быть массивом
if (!j.is_array()) {
throw std::runtime_error("'x' must be JSON array.");
}
strokes res;
res.reserve(j.size());
for (const auto& a: j) {
// Каждый элемент массива должен быть 2-мерным массивом
if (!a.is_array() || a.size() != 2) {
throw std::runtime_error("'x' must include only 2d arrays.");
}
// Извлечение вектора точек
auto p = a.get<points>();
res.push_back(p);
}
return res;
}
// Отрисовка линий
// Цвета HSV
cv::Mat ocv_draw_lines(const strokes& x, bool color = true) {
// Исходный тип матрицы
auto stype = color ? CV_8UC3 : CV_8UC1;
// Итоговый тип матрицы
auto dtype = color ? CV_32FC3 : CV_32FC1;
auto bg = color ? cv::Scalar(0, 0, 255) : cv::Scalar(255);
auto col = color ? cv::Scalar(0, 255, 220) : cv::Scalar(0);
cv::Mat img = cv::Mat(SIZE, SIZE, stype, bg);
// Количество линий
size_t n = x.size();
for (const auto& s: x) {
// Количество точек в линии
size_t n_points = s.shape()[1];
for (size_t i = 0; i < n_points - 1; ++i) {
// Точка начала штриха
cv::Point from(s(0, i), s(1, i));
// Точка окончания штриха
cv::Point to(s(0, i + 1), s(1, i + 1));
// Отрисовка линии
cv::line(img, from, to, col, LINE_WIDTH, LINE_TYPE);
}
if (color) {
// Меняем цвет линии
col[0] += 180 / n;
}
}
if (color) {
// Меняем цветовое представление на RGB
cv::cvtColor(img, img, cv::COLOR_HSV2RGB);
}
// Меняем формат представления на float32 с диапазоном [0, 1]
img.convertTo(img, dtype, 1 / 255.0);
return img;
}
// Обработка JSON и получение тензора с данными изображения
xtensor3d process(const std::string& x, double scale = 1.0, bool color = true) {
auto p = parse_json(x);
auto img = ocv_draw_lines(p, color);
if (scale != 1) {
cv::Mat out;
cv::resize(img, out, cv::Size(), scale, scale, RESIZE_TYPE);
cv::swap(img, out);
out.release();
}
xtensor3d arr = color ? to_xt<double,3>(img) : to_xt<double,1>(img);
return arr;
}
// [[Rcpp::export]]
rtensor3d cpp_process_json_str(const std::string& x,
double scale = 1.0,
bool color = true) {
xtensor3d res = process(x, scale, color);
return res;
}
// [[Rcpp::export]]
rtensor4d cpp_process_json_vector(const std::vector<std::string>& x,
double scale = 1.0,
bool color = false) {
size_t n = x.size();
size_t dim = floor(SIZE * scale);
size_t channels = color ? 3 : 1;
xtensor4d res({n, dim, dim, channels});
parallelFor(0, n, [&x, &res, scale, color](int i) {
xtensor3d tmp = process(x[i], scale, color);
auto view = xt::view(res, i, xt::all(), xt::all(), xt::all());
view = tmp;
});
return res;
}Ten kod należy umieścić w pliku src/cv_xt.cpp i skompilować poleceniem Rcpp::sourceCpp(file = "src/cv_xt.cpp", env = .GlobalEnv); do działania potrzebne będzie również nlohmann/json.hpp z . Kod jest podzielony na kilka funkcji:
to_xt— funkcja szablonowa do konwersji macierzy obrazu (cv::Mat) do tensoraxt::xtensor;parse_json— funkcja, która parsuje ciąg JSON, wyodrębnia współrzędne punktów, pakując je w wektor;ocv_draw_lines— z uzyskanego wektora punktów rysuje kolorowe linie;process— łączy opisane wyżej funkcje, a także dodaje możliwość skalowania uzyskanego obrazu;cpp_process_json_str— opakowanie funkcjiprocess, która eksportuje wynik do obiektu R (wielowymiarowa tablica);cpp_process_json_vector— opakowanie funkcjicpp_process_json_str, która pozwala przetwarzać wektor ciągów w trybie wielowątkowym.
Do rysowania kolorowych linii zastosowano model kolorów HSV z późniejszą konwersją do RGB. Przetestujmy wynik:
arr <- cpp_process_json_str(tmp_data[4, drawing])
dim(arr)
# [1] 256 256 3
plot(magick::image_read(arr)) 
Porównanie szybkości działania implementacji w R i C++
res_bench <- bench::mark(
r_process_json_str(tmp_data[4, drawing], scale = 0.5),
cpp_process_json_str(tmp_data[4, drawing], scale = 0.5),
check = FALSE,
min_iterations = 100
)
# Parametry benchmarku
cols <- c("expression", "min", "median", "max", "itr/sec", "total_time", "n_itr")
res_bench[, cols]
# expression min median max `itr/sec` total_time n_itr
#
# 1 r_process_json_str 3.49ms 3.55ms 4.47ms 273. 490ms 134
# 2 cpp_process_json_str 1.94ms 2.02ms 5.32ms 489. 497ms 243
library(ggplot2)
# Przeprowadzenie pomiaru
res_bench <- bench::press(
batch_size = 2^(4:10),
{
.data <- tmp_data[sample(seq_len(.N), batch_size), drawing]
bench::mark(
r_process_json_vector(.data, scale = 0.5),
cpp_process_json_vector(.data, scale = 0.5),
min_iterations = 50,
check = FALSE
)
}
)
res_bench[, cols]
# expression batch_size min median max `itr/sec` total_time n_itr
# <bch:tm> <bch:tm> <bch:tm> <dbl> <bch:tm> <int>
# 1 r 16 50.61ms 53.34ms 54.82ms 19.1 471.13ms 9
# 2 cpp 16 4.46ms 5.39ms 7.78ms 192. 474.09ms 91
# 3 r 32 105.7ms 109.74ms 212.26ms 7.69 6.5s 50
# 4 cpp 32 7.76ms 10.97ms 15.23ms 95.6 522.78ms 50
# 5 r 64 211.41ms 226.18ms 332.65ms 3.85 12.99s 50
# 6 cpp 64 25.09ms 27.34ms 32.04ms 36.0 1.39s 50
# 7 r 128 534.5ms 627.92ms 659.08ms 1.61 31.03s 50
# 8 cpp 128 56.37ms 58.46ms 66.03ms 16.9 2.95s 50
# 9 r 256 1.15s 1.18s 1.29s 0.851 58.78s 50
# 10 cpp 256 114.97ms 117.39ms 130.09ms 8.45 5.92s 50
# 11 r 512 2.09s 2.15s 2.32s 0.463 1.8m 50
# 12 cpp 512 230.81ms 235.6ms 261.99ms 4.18 11.97s 50
# 13 r 1024 4s 4.22s 4.4s 0.238 3.5m 50
# 14 cpp 1024 410.48ms 431.43ms 462.44ms 2.33 21.45s 50
ggplot(res_bench, aes(x = factor(batch_size), y = median,
group = expression, color = expression)) +
geom_point() +
geom_line() +
ylab("mediana czasu, s") +
theme_minimal() +
scale_color_discrete(name = "", labels = c("cpp", "r")) +
theme(legend.position = "bottom") 
Jak widać, przyrost prędkości okazał się bardzo znaczący i nie jest możliwe osiągnięcie kodu w C++ za pomocą równolegle zrealizowanego kodu w R.
3. Iteratory do pobierania partii z bazy danych
R ma zasłużoną reputację języka do przetwarzania danych, które mieszczą się w RAM, podczas gdy Python bardziej charakteryzuje się iteracyjnym przetwarzaniem danych, umożliwiającym łatwe i naturalne implementowanie obliczeń out-of-core (obliczeń z wykorzystaniem pamięci zewnętrznej). Klasycznym i aktualnym w kontekście omawianego zadania przykładem takich obliczeń są głębokie sieci neuronowe, uczone metodą spadku gradientu z przybliżeniem gradientu na każdym kroku za pomocą małej porcji obserwacji, czyli mini-batch.
Frameworki do głębokiego uczenia, napisane w Pythonie, mają specjalne klasy implementujące iteratory danych: tabele, obrazy w folderach, formaty binarne itd. Można korzystać z gotowych rozwiązań lub pisać własne do specyficznych zadań. W R możemy skorzystać ze wszystkich możliwości biblioteki Pythona keras z różnymi backendami za pomocą pakietu o tej samej nazwie, który z kolei działa na pakiecie reticulate. Ostatni zasługuje na osobny, obszerny artykuł; pozwala on nie tylko na uruchamianie kodu w Pythonie z poziomu R, ale także zapewnia transfer obiektów między sesjami R i Python, automatycznie wykonując wszystkie niezbędne konwersje typów.
Odwolaliśmy się z konieczności przechowywania wszystkich danych w RAM dzięki użyciu MonetDBLite, całą "sieciową" pracę wykona oryginalny kod w Pythonie, pozostaje nam jedynie napisać iterator danych, ponieważ gotowego dla takiej sytuacji nie ma ani w R, ani w Pythonie. W zasadzie są dwa wymagania: musi on zwracać batche w nieskończonej pętli i zachować swoje stany między iteracjami (ostatnie w R realizowane jest w najprostszy sposób za pomocą funkcji zamykających). Wcześniej wymagało to wewnątrz iteratora jawnej konwersji tablic R na tablice numpy, ale aktualna wersja pakietu keras robi to sama.
Iterator dla danych treningowych i walidacyjnych wygląda następująco:
Iterator dla danych treningowych i walidacyjnych
train_generator <- function(db_connection = con,
samples_index,
num_classes = 340,
batch_size = 32,
scale = 1,
color = FALSE,
imagenet_preproc = FALSE) {
# Проверка аргументов
checkmate::assert_class(con, "DBIConnection")
checkmate::assert_integerish(samples_index)
checkmate::assert_count(num_classes)
checkmate::assert_count(batch_size)
checkmate::assert_number(scale, lower = 0.001, upper = 5)
checkmate::assert_flag(color)
checkmate::assert_flag(imagenet_preproc)
# Перемешиваем, чтобы брать и удалять использованные индексы батчей по порядку
dt <- data.table::data.table(id = sample(samples_index))
# Проставляем номера батчей
dt[, batch := (.I - 1L) %/% batch_size + 1L]
# Оставляем только полные батчи и индексируем
dt <- dt[, if (.N == batch_size) .SD, keyby = batch]
# Устанавливаем счётчик
i <- 1
# Количество батчей
max_i <- dt[, max(batch)]
# Подготовка выражения для выгрузки
sql <- sprintf(
"PREPARE SELECT drawing, label_int FROM doodles WHERE id IN (%s)",
paste(rep("?", batch_size), collapse = ",")
)
res <- DBI::dbSendQuery(con, sql)
# Аналог keras::to_categorical
to_categorical <- function(x, num) {
n <- length(x)
m <- numeric(n * num)
m[x * n + seq_len(n)] <- 1
dim(m) <- c(n, num)
return(m)
}
# Замыкание
function() {
# Начинаем новую эпоху
if (i > max_i) {
dt[, id := sample(id)]
data.table::setkey(dt, batch)
# Сбрасываем счётчик
i <<- 1
max_i <<- dt[, max(batch)]
}
# ID для выгрузки данных
batch_ind <- dt[batch == i, id]
# Выгрузка данных
batch <- DBI::dbFetch(DBI::dbBind(res, as.list(batch_ind)), n = -1)
# Увеличиваем счётчик
i <<- i + 1
# Парсинг JSON и подготовка массива
batch_x <- cpp_process_json_vector(batch$drawing, scale = scale, color = color)
if (imagenet_preproc) {
# Шкалирование c интервала [0, 1] на интервал [-1, 1]
batch_x <- (batch_x - 0.5) * 2
}
batch_y <- to_categorical(batch$label_int, num_classes)
result <- list(batch_x, batch_y)
return(result)
}
}Funkcja przyjmuje jako argument zmienną z połączeniem z bazą danych, numery używanych wierszy, liczbę klas, rozmiar batcha, skalę (scale = 1 odpowiadająca rysowaniu obrazów 256x256 pikseli, scale = 0.5 - 128x128 pikseli), wskaźnik kolorów (color = FALSE ustawia rysowanie w odcieniach szarości, podczas użycia color = TRUE każdy rysunek jest rysowany nowym kolorem) i wskaźnik wstępnej obróbki dla sieci, które zostały wstępnie wytrenowane na datasetach imagenet. Ostatni jest potrzebny do przeskalowania wartości pikseli z zakresu [0, 1] do przedziału [-1, 1], który był używany podczas treningu dostarczonych modeli. keras modeli.
Zewnętrzna funkcja zawiera sprawdzanie typów argumentów, tabelę data.table ze losowo pomieszanymi numerami wierszy z samples_index i numerami partii, licznik i maksymalna liczba partii, a także wyrażenie SQL do eksportu danych z bazy danych. Dodatkowo zdefiniowaliśmy wewnątrz szybką analogię funkcji keras::to_categorical(). Użyliśmy do treningu prawie wszystkich danych, zostawiając pół procenta do walidacji, dlatego rozmiar epoki był ograniczony parametrem steps_per_epoch przy wywołaniu keras::fit_generator(), a warunek if (i > max_i) był spełniany tylko dla walidującego iteratora.
W wewnętrznej funkcji następuje wybór indeksów wierszy dla kolejnej partii, eksportowanie rekordów z bazy danych przy zwiększaniu licznika partii, parsowanie JSON-ów (funkcja cpp_process_json_vector(), napisana w C++) i tworzenie tablic odpowiadających obrazom. Następnie tworzone są wektory one-hot z etykietami klas, tablice z wartościami pikseli i z etykietami są łączone w listę, która jest zwracanym wynikiem. W celu przyspieszenia działania wykorzystywano tworzenie indeksów w tabelach data.table i modyfikację przez odwołanie — bez tych „sztuczek” pakietu data.table dość trudno wyobrazić sobie efektywną pracę z większymi zbiorami danych w R.
Wyniki pomiarów prędkości działania na laptopowym Core i5 wyglądają następująco:
Benchmark iteratora
library(Rcpp)
library(keras)
library(ggplot2)
source("utils/rcpp.R")
source("utils/keras_iterator.R")
con <- DBI::dbConnect(drv = MonetDBLite::MonetDBLite(), Sys.getenv("DBDIR"))
ind <- seq_len(DBI::dbGetQuery(con, "SELECT count(*) FROM doodles")[[1L]])
num_classes <- DBI::dbGetQuery(con, "SELECT max(label_int) + 1 FROM doodles")[[1L]]
# Indeksy dla próbki treningowej
train_ind <- sample(ind, floor(length(ind) * 0.995))
# Indeksy dla próbki walidacyjnej
val_ind <- ind[-train_ind]
rm(ind)
# Współczynnik skalowania
scale <- 0.5
# Przeprowadzenie pomiaru
res_bench <- bench::press(
batch_size = 2^(4:10),
{
it1 <- train_generator(
db_connection = con,
samples_index = train_ind,
num_classes = num_classes,
batch_size = batch_size,
scale = scale
)
bench::mark(
it1(),
min_iterations = 50L
)
}
)
# Parametry benchmarku
cols <- c("batch_size", "min", "median", "max", "itr/sec", "total_time", "n_itr")
res_bench[, cols]
# batch_size min median max `itr/sec` total_time n_itr
#
# 1 16 25ms 64.36ms 92.2ms 15.9 3.09s 49
# 2 32 48.4ms 118.13ms 197.24ms 8.17 5.88s 48
# 3 64 69.3ms 117.93ms 181.14ms 8.57 5.83s 50
# 4 128 157.2ms 240.74ms 503.87ms 3.85 12.71s 49
# 5 256 359.3ms 613.52ms 988.73ms 1.54 30.5s 47
# 6 512 884.7ms 1.53s 2.07s 0.674 1.11m 45
# 7 1024 2.7s 3.83s 5.47s 0.261 2.81m 44
ggplot(res_bench, aes(x = factor(batch_size), y = median, group = 1)) +
geom_point() +
geom_line() +
ylab("czas mediany, s") +
theme_minimal()
DBI::dbDisconnect(con, shutdown = TRUE) 
Jeśli jest wystarczająca ilość pamięci RAM, można znacznie przyspieszyć działanie bazy danych przenosząc ją do tej pamięci (dla naszego zadania wystarcza 32 GB). W systemie Linux domyślnie montowany jest obszar /dev/shm, zajmujący do połowy objętości pamięci RAM. Można przydzielić więcej, edytując /etc/fstab, aby uzyskać zapis w postaci tmpfs /dev/shm tmpfs defaults,size=25g 0 0. Konieczne jest ponowne uruchomienie i sprawdzenie wyniku, wykonując polecenie df -h.
Iterator dla danych testowych wygląda znacznie prościej, ponieważ cały zestaw danych testowych mieści się w pamięci RAM:
Iterator dla danych testowych
test_generator <- function(dt,
batch_size = 32,
scale = 1,
color = FALSE,
imagenet_preproc = FALSE) {
# Проверка аргументов
checkmate::assert_data_table(dt)
checkmate::assert_count(batch_size)
checkmate::assert_number(scale, lower = 0.001, upper = 5)
checkmate::assert_flag(color)
checkmate::assert_flag(imagenet_preproc)
# Проставляем номера батчей
dt[, batch := (.I - 1L) %/% batch_size + 1L]
data.table::setkey(dt, batch)
i <- 1
max_i <- dt[, max(batch)]
# Замыкание
function() {
batch_x <- cpp_process_json_vector(dt[batch == i, drawing],
scale = scale, color = color)
if (imagenet_preproc) {
# Шкалирование c интервала [0, 1] на интервал [-1, 1]
batch_x <- (batch_x - 0.5) * 2
}
result <- list(batch_x)
i <<- i + 1
return(result)
}
}4. Wybór architektury modelu
Pierwszą z wykorzystanych architektur była , której cechy zostały omówione w opracowaniu. Jest ona dostępna w standardowej dostawie keras i, odpowiednio, dostępna w tym samym pakiecie dla R. Jednakże podczas próby użycia jej z jedno kanałowymi obrazami okazało się, że tensor wejściowy zawsze musi mieć wymiar (batch, height, width, 3), co oznacza, że liczby kanałów nie można zmienić. W Pythonie nie ma tego ograniczenia, dlatego pospieszyliśmy i napisaliśmy naszą własną implementację tej architektury, według oryginalnego artykułu (bez dropout, który występuje w wersji keras):
Architektura mobilenet v1
library(keras)
top_3_categorical_accuracy <- custom_metric(
name = "top_3_categorical_accuracy",
metric_fn = function(y_true, y_pred) {
metric_top_k_categorical_accuracy(y_true, y_pred, k = 3)
}
)
layer_sep_conv_bn %
layer_batch_normalization() %>%
layer_activation_relu() %>%
layer_conv_2d(
filters = filters * alpha,
kernel_size = c(1, 1),
strides = c(1, 1)
) %>%
layer_batch_normalization() %>%
layer_activation_relu()
}
get_mobilenet_v1 <- function(input_shape = c(224, 224, 1),
num_classes = 340,
alpha = 1,
depth_multiplier = 1,
optimizer = optimizer_adam(lr = 0.002),
loss = "categorical_crossentropy",
metrics = c("categorical_crossentropy",
top_3_categorical_accuracy)) {
inputs <- layer_input(shape = input_shape)
outputs %
layer_conv_2d(filters = 32, kernel_size = c(3, 3), strides = c(2, 2), padding = "same") %>%
layer_batch_normalization() %>%
layer_activation_relu() %>%
layer_sep_conv_bn(filters = 64, strides = c(1, 1)) %>%
layer_sep_conv_bn(filters = 128, strides = c(2, 2)) %>%
layer_sep_conv_bn(filters = 128, strides = c(1, 1)) %>%
layer_sep_conv_bn(filters = 256, strides = c(2, 2)) %>%
layer_sep_conv_bn(filters = 256, strides = c(1, 1)) %>%
layer_sep_conv_bn(filters = 512, strides = c(2, 2)) %>%
layer_sep_conv_bn(filters = 512, strides = c(1, 1)) %>%
layer_sep_conv_bn(filters = 512, strides = c(1, 1)) %>%
layer_sep_conv_bn(filters = 512, strides = c(1, 1)) %>%
layer_sep_conv_bn(filters = 512, strides = c(1, 1)) %>%
layer_sep_conv_bn(filters = 512, strides = c(1, 1)) %>%
layer_sep_conv_bn(filters = 1024, strides = c(2, 2)) %>%
layer_sep_conv_bn(filters = 1024, strides = c(1, 1)) %>%
layer_global_average_pooling_2d() %>%
layer_dense(units = num_classes) %>%
layer_activation_softmax()
model % compile(
optimizer = optimizer,
loss = loss,
metrics = metrics
)
return(model)
}Wady tego podejścia są oczywiste. Chcemy przetestować wiele modeli, a nie chcemy ręcznie przepisywać każdej architektury. Ponadto nie mogliśmy skorzystać z wag modeli wstępnie wytrenowanych na imagenet. Jak zwykle, pomocne okazało się studiowanie dokumentacji. Funkcja get_config() pozwala uzyskać opis modelu w formie nadającej się do edycji (base_model_conf$layers — normal lista R-owska), a funkcja from_config() przeprowadza odwrotne przekształcenie w obiekt modelu:
base_model_conf <- get_config(base_model)
base_model_conf$layers[[1]]$config$batch_input_shape[[4]] <- 1L
base_model <- from_config(base_model_conf)Teraz łatwo napisać uniwersalną funkcję do uzyskiwania dowolnej z modeli dostarczonych w pakiecie keras z wagami wytrenowanymi na imagenet lub bez nich:
Funkcja do ładowania gotowych architektur
get_model <- function(name = "mobilenet_v2",
input_shape = NULL,
weights = "imagenet",
pooling = "avg",
num_classes = NULL,
optimizer = keras::optimizer_adam(lr = 0.002),
loss = "categorical_crossentropy",
metrics = NULL,
color = TRUE,
compile = FALSE) {
# Weryfikacja argumentów
checkmate::assert_string(name)
checkmate::assert_integerish(input_shape, lower = 1, upper = 256, len = 3)
checkmate::assert_count(num_classes)
checkmate::assert_flag(color)
checkmate::assert_flag(compile)
# Uzyskujemy obiekt z pakietu keras
model_fun <- get0(paste0("application_", name), envir = asNamespace("keras"))
# Weryfikacja istnienia obiektu w pakiecie
if (is.null(model_fun)) {
stop("Model ", shQuote(name), " not found.", call. = FALSE)
}
base_model <- model_fun(
input_shape = input_shape,
include_top = FALSE,
weights = weights,
pooling = pooling
)
# Jeśli obraz nie jest kolorowy, zmieniamy wymiary wejścia
if (!color) {
base_model_conf <- keras::get_config(base_model)
base_model_conf$layers[[1]]$config$batch_input_shape[[4]] <- 1L
base_model <- keras::from_config(base_model_conf)
}
predictions <- keras::get_layer(base_model, "global_average_pooling2d_1")$output
predictions <- keras::layer_dense(predictions, units = num_classes, activation = "softmax")
model <- keras::keras_model(
inputs = base_model$input,
outputs = predictions
)
if (compile) {
keras::compile(
object = model,
optimizer = optimizer,
loss = loss,
metrics = metrics
)
}
return(model)
}Podczas korzystania z obrazów jednokanałowych wstępnie wytrenowane wagi nie są używane. Można to by naprawić: za pomocą funkcji get_weights() uzyskać wagi modelu w postaci listy z tablic R, zmienić wymiar pierwszego elementu tej listy (biorąc jeden kanał kolorowy lub uśredniając wszystkie trzy), a potem załadować wagi z powrotem do modelu funkcją set_weights(). Nie dodaliśmy tej funkcjonalności, ponieważ na tym etapie było już jasne, że lepiej pracować z kolorowymi obrazkami.
Większość eksperymentów przeprowadziliśmy z użyciem wersji 1 i 2 modelu mobilenet oraz resnet34. W tym konkursie dobrze wypadły nowocześniejsze architektury, takie jak SE-ResNeXt. Niestety, nie mieliśmy gotowych realizacji, a własnych jeszcze nie napisaliśmy (ale na pewno napiszemy).
5. Parametryzacja skryptów
Dla wygody cały kod do uruchamiania treningu został przygotowany jako jeden skrypt, który został parametryzowany przy pomocy w następujący sposób:
doc <- '
Usage:
train_nn.R --help
train_nn.R --list-models
train_nn.R [options]
Options:
-h --help Pokaż tę wiadomość.
-l --list-models Wyświetl dostępne modele.
-m --model= Nazwa modelu sieci neuronowej [domyślnie: mobilenet_v2].
-b --batch-size= Rozmiar partii [domyślnie: 32].
-s --scale-factor= Współczynnik skali [domyślnie: 0.5].
-c --color Użyj kolorowych linii [domyślnie: FALSE].
-d --db-dir= Ścieżka do katalogu bazy danych [domyślnie: Sys.getenv("db_dir")].
-r --validate-ratio= Współczynnik próby walidacji [domyślnie: 0.995].
-n --n-gpu= Liczba GPU [domyślnie: 1].
'
args <- docopt::docopt(doc)Pakiet docopt stanowi implementację dla R. Dzięki niemu skrypty uruchamiane są za pomocą prostych poleceń w rodzaju Rscript bin/train_nn.R -m resnet50 -c -d /home/andrey/doodle_db lub ./bin/train_nn.R -m resnet50 -c -d /home/andrey/doodle_db, jeśli plik train_nn.R jest wykonywalny (to polecenie uruchomi trening modelu resnet50 na trójwymiarowych obrazach o rozmiarach 128x128 pikseli, baza danych powinna znajdować się w folderze /home/andrey/doodle_db). Na listę można dodać szybkość uczenia, typ optymalizatora i inne opcjonalne parametry. W trakcie przygotowywania publikacji odkryto, że architekturę mobilenet_v2 z aktualnej wersji keras w R używać z powodu nieuwzględnionych w pakiecie R zmian — czekamy na poprawki.
Podejście to pozwoliło na znaczne przyspieszenie eksperymentów z różnymi modelami w porównaniu z bardziej tradycyjnym uruchamianiem skryptów w RStudio (jako możliwą alternatywę zauważamy pakiet ). Ale główną zaletą jest łatwość zarządzania uruchamianiem skryptów w dockerze lub po prostu na serwerze, bez konieczności instalowania RStudio.
6. Dokeryzacja skryptów
Użyliśmy dockera w celu zapewnienia przenośności środowiska do treningu modeli między członkami zespołu i do szybkiego wdrażania w chmurze. Aby zacząć zapoznawać się z tym relatywnie nieznanym dla programisty R narzędziem, można zacząć od serii publikacji lub z .
Docker pozwala zarówno na tworzenie własnych obrazów „od podstaw”, jak i na wykorzystanie innych obrazów jako bazy do stworzenia własnych. Po analizie dostępnych opcji doszliśmy do wniosku, że instalacja sterowników NVIDIA, CUDA+cuDNN i bibliotek Pythona to dość obszerna część obrazu, dlatego zdecydowaliśmy się na użycie oficjalnego obrazu tensorflow/tensorflow:1.12.0-gpu, dodając do niego niezbędne pakiety R.
Ostateczny plik Dockerfile wyglądał tak:
Dockerfile
FROM tensorflow/tensorflow:1.12.0-gpu
MAINTAINER Artem Klevtsov
SHELL ["/bin/bash", "-c"]
ARG LOCALE="en_US.UTF-8"
ARG APT_PKG="libopencv-dev r-base r-base-dev littler"
ARG R_BIN_PKG="futile.logger checkmate data.table rcpp rapidjsonr dbi keras jsonlite curl digest remotes"
ARG R_SRC_PKG="xtensor RcppThread docopt MonetDBLite"
ARG PY_PIP_PKG="keras"
ARG DIRS="/db /app /app/data /app/models /app/logs"
RUN source /etc/os-release &&
echo "deb https://cloud.r-project.org/bin/linux/ubuntu ${UBUNTU_CODENAME}-cran35/" > /etc/apt/sources.list.d/cran35.list &&
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys E084DAB9 &&
add-apt-repository -y ppa:marutter/c2d4u3.5 &&
add-apt-repository -y ppa:timsc/opencv-3.4 &&
apt-get update &&
apt-get install -y locales &&
locale-gen ${LOCALE} &&
apt-get install -y --no-install-recommends ${APT_PKG} &&
ln -s /usr/lib/R/site-library/littler/examples/install.r /usr/local/bin/install.r &&
ln -s /usr/lib/R/site-library/littler/examples/install2.r /usr/local/bin/install2.r &&
ln -s /usr/lib/R/site-library/littler/examples/installGithub.r /usr/local/bin/installGithub.r &&
echo 'options(Ncpus = parallel::detectCores())' >> /etc/R/Rprofile.site &&
echo 'options(repos = c(CRAN = "https://cloud.r-project.org"))' >> /etc/R/Rprofile.site &&
apt-get install -y $(printf "r-cran-%s " ${R_BIN_PKG}) &&
install.r ${R_SRC_PKG} &&
pip install ${PY_PIP_PKG} &&
mkdir -p ${DIRS} &&
chmod 777 ${DIRS} &&
rm -rf /tmp/downloaded_packages/ /tmp/*.rds &&
rm -rf /var/lib/apt/lists/*
COPY utils /app/utils
COPY src /app/src
COPY tests /app/tests
COPY bin/*.R /app/
ENV DBDIR="/db"
ENV CUDA_HOME="/usr/local/cuda"
ENV PATH="/app:${PATH}"
WORKDIR /app
VOLUME /db
VOLUME /app
CMD bash
Dla wygody używane pakiety zostały przeniesione do zmiennych; główna część napisanych skryptów jest kopiowana do kontenerów podczas budowy. Zmieniliśmy również powłokę na /bin/bash w celu ułatwienia korzystania z zawartości /etc/os-release. To pozwoliło uniknąć konieczności podawania wersji systemu operacyjnego w kodzie.
Dodatkowo napisano mały skrypt bash, który umożliwia uruchamianie kontenera z różnymi poleceniami. Na przykład mogą to być skrypty do nauki sieci neuronowych, wcześniej umieszczone w kontenerze, lub powłoka do debugowania i monitorowania działania kontenera:
Skrypt do uruchamiania kontenera
#!/bin/sh
DBDIR=${PWD}/db
LOGSDIR=${PWD}/logs
MODELDIR=${PWD}/models
DATADIR=${PWD}/data
ARGS="--runtime=nvidia --rm -v ${DBDIR}:/db -v ${LOGSDIR}:/app/logs -v ${MODELDIR}:/app/models -v ${DATADIR}:/app/data"
if [ -z "$1" ]; then
CMD="Rscript /app/train_nn.R"
elif [ "$1" = "bash" ]; then
ARGS="${ARGS} -ti"
else
CMD="Rscript /app/train_nn.R $@"
fi
docker run ${ARGS} doodles-tf ${CMD}Jeśli ten skrypt bash zostanie uruchomiony bez parametrów, wewnątrz kontenera zostanie wywołany skrypt train_nn.R z wartościami domyślnymi; jeśli pierwszy argument pozycyjny to 'bash', kontener uruchomi się w trybie interaktywnym z powłoką. W pozostałych przypadkach nastąpi podstawienie wartości argumentów pozycyjnych: CMD="Rscript /app/train_nn.R $@".
Warto zwrócić uwagę, że katalogi z danymi źródłowymi i bazą danych oraz katalog do zapisania wyuczonych modeli są montowane do kontenera z systemu hosta, co pozwala na dostęp do wyników działania skryptów bez zbędnych manipulacji.
7. Użycie kilku GPU w chmurze Google Cloud
Jedną z cech rywalizacji były dość hałaśliwe dane (zob. zdjęcie tytułowe, zapożyczone od @Leigh.plt z ODS Slack). Walkę z tym wspierają duże partie, więc po eksperymentach na PC z 1 GPU postanowiliśmy opanować szkolenie modeli na kilku GPU w chmurze. Użyliśmy Google Cloud () z powodu szerokiego wyboru dostępnych konfiguracji, rozsądnych cen i bonusowych 300 dolarów. Z chciwości zamówiono instancję z 4xV100 z SSD i ogromną ilością RAM, co okazało się dużym błędem. Taki sprzęt szybko zjada pieniądze, w eksperymentach bez wypracowanego pipeline'u można zbankrutować. Na cele edukacyjne lepiej wziąć K80. Ale duża ilość RAM była przydatna — cloud SSD nie zachwycił wydajnością, więc bazę danych przy każdym uruchomieniu instancji przenosiliśmy na dev/shm.
Największe zainteresowanie budzi fragment kodu odpowiedzialny za użycie kilku GPU. Na początku model tworzy się na CPU za pomocą menedżera kontekstu, tak jak w Pythonie:
with(tensorflow::tf$device("/cpu:0"), {
model_cpu <- get_model(
name = model_name,
input_shape = input_shape,
weights = weights,
metrics =(top_3_categorical_accuracy,
compile = FALSE
)
})Następnie niekompilowany (co jest ważne) model jest kopiowany na określoną liczbę dostępnych GPU, a dopiero potem jest kompilowany:
model <- keras::multi_gpu_model(model_cpu, gpus = n_gpu)
keras::compile(
object = model,
optimizer = keras::optimizer_adam(lr = 0.0004),
loss = "categorical_crossentropy",
metrics = c(top_3_categorical_accuracy)
)Klasycznej metody zamrażania wszystkich warstw poza ostatnią, uczenia ostatniej warstwy, rozmrażania i doszkalania całego modelu w przypadku kilku GPU nie udało się zrealizować.
Nadzorowaliśmy naukę bez użycia tensorboard, ograniczając się do rejestrowania logów i zapisywania modeli z informacyjnymi nazwami po każdej epoce:
Callbacki
# Шаблон имени файла лога
log_file_tmpl <- file.path("logs", sprintf(
"%s_%d_%dch_%s.csv",
model_name,
dim_size,
channels,
format(Sys.time(), "%Y%m%d%H%M%OS")
))
# Шаблон имени файла модели
model_file_tmpl <- file.path("models", sprintf(
"%s_%d_%dch_{epoch:02d}_{val_loss:.2f}.h5",
model_name,
dim_size,
channels
))
callbacks_list <- list(
keras::callback_csv_logger(
filename = log_file_tmpl
),
keras::callback_early_stopping(
monitor = "val_loss",
min_delta = 1e-4,
patience = 8,
verbose = 1,
mode = "min"
),
keras::callback_reduce_lr_on_plateau(
monitor = "val_loss",
factor = 0.5, # уменьшаем lr в 2 раза
patience = 4,
verbose = 1,
min_delta = 1e-4,
mode = "min"
),
keras::callback_model_checkpoint(
filepath = model_file_tmpl,
monitor = "val_loss",
save_best_only = FALSE,
save_weights_only = FALSE,
mode = "min"
)
)8. Zamiast zakończenia
Lista problemów, które napotkaliśmy, nie została jeszcze pokonana:
- do keras brak gotowej funkcji do automatycznego wyszukiwania optymalnej prędkości uczenia się (odpowiednik
lr_finderw bibliotece fast.ai); przyłożono pewne wysiłki, aby przenieść zewnętrzne realizacje na R, na przykład, ; - w wyniku poprzedniego punktu, nie udało się dobrać odpowiedniej prędkości uczenia się przy użyciu kilku GPU;
- brakuje nowoczesnych architektur sieci neuronowych, szczególnie tych wcześniej wytrenowanych na imagenet;
- brak one cycle policy i rozróżniających szybkości uczenia (cosine annealing na naszą prośbę został , dziękuję ).
Co przydatnego udało się wydobyć z tego konkursu:
- Na stosunkowo mało wydajnym sprzęcie można bez trudności pracować z przyzwoitymi (znacznie przekraczającymi rozmiar RAM) objętościami danych. Pakiet data.table oszczędza pamięć dzięki in-place modyfikacji tabel, co pozwala uniknąć ich kopiowania, a przy odpowiednim wykorzystaniu jego możliwości niemal zawsze demonstruje największą szybkość spośród wszystkich znanych nam narzędzi dla języków skryptowych. Zapis danych w bazie danych pozwala w wielu przypadkach w ogóle nie myśleć o konieczności wciskania całego zbioru danych do RAM.
- Wolne funkcje w R można zastąpić szybkimi w C++ za pomocą pakietu Rcpp. Jeśli dodatkowo użyjemy RcppThread lub RcppParallel, otrzymujemy wieloplatformowe wielowątkowe realizacje, więc kod na poziomie R nie wymaga równoleglenia.
- Pakietem Rcpp można się posługiwać bez poważnej znajomości C++, niezbędne minimum jest opisane . Pliki nagłówkowe dla wielu znanych bibliotek w C, takich jak xtensor są dostępne na CRAN, co oznacza, że powstaje infrastruktura do realizacji projektów integrujących w R gotowy, wysokowydajny kod w C++. Dodatkowym udogodnieniem jest podświetlenie składni i statyczny analizator kodu w C++ w RStudio.
- docopt pozwala na uruchamianie samodzielnych skryptów z parametrami. To wygodne rozwiązanie do użycia na zdalnym serwerze, w tym pod Dockerem. W RStudio przeprowadzanie wielogodzinnych eksperymentów ze szkoleniem sieci neuronowych jest niewygodne, a sama instalacja IDE na serwerze nie zawsze jest uzasadniona.
- Docker zapewnia przenośność kodu i powtarzalność wyników między deweloperami używającymi różnych wersji systemów operacyjnych i bibliotek, a także ułatwia uruchamianie na serwerach. Cały proces uczenia można uruchomić za pomocą jednego polecenia.
- Google Cloud to przystępny sposób na eksperymentowanie z drogi sprzętem, ale należy starannie dobierać konfiguracje.
- Mierzenie wydajności poszczególnych fragmentów kodu jest bardzo przydatne, zwłaszcza w połączeniu R i C++, a z pakietem bench — jest to także bardzo łatwe.
Ogólnie rzecz biorąc, to doświadczenie było bardzo pomocne i nadal pracujemy nad rozwiązaniem niektórych z poruszonych problemów.
Źródło: habr.com
