Optimalizace výkonu a optimalizace dat pro R

platí pro: SQL Server 2016 (13.x) a novější verze

Tento článek popisuje optimalizace výkonu pro skripty R nebo Python, které se spouštějí v SQL Server. Tyto metody můžete použít k aktualizaci kódu R, a to jak ke zvýšení výkonu, tak k zabránění známým problémům.

Volba výpočetního kontextu

V SQL Server můžete při spuštění skriptu v R nebo Python použít buď lokální nebo SQL výpočetní kontext.

Při použití místního výpočetního kontextu se analýza provádí na vašem počítači a ne na serveru. Proto pokud získáváte data z SQL Server pro použití v kódu, musí se data načíst přes síť. Pokles výkonu při tomto síťovém přenosu závisí na velikosti přenášených dat, rychlosti sítě a dalších síťových přenosech probíhajících současně.

Při použití výpočetního kontextu SQL Server se kód spustí na serveru. Pokud získáváte data z SQL Serveru, měla by být data lokálně uložena na serveru, na kterém běží analýza, bez potřeby síťového přenosu. Pokud potřebujete importovat data z jiných zdrojů, zvažte uspořádání ETL předem.

Při práci s velkými datovými sadami byste měli vždy použít výpočetní kontext SQL.

Faktory

Jazyk R má koncept faktorů, které jsou speciální proměnnou pro kategorická data. Datoví vědci často ve vzorci používají faktorové proměnné, protože zpracování kategorických proměnných jako faktorů zajišťuje, aby data byla správně zpracována funkcemi strojového učení.

V rámci návrhu mohou být faktorové proměnné převedeny z řetězců na celá čísla a zpět pro účely ukládání nebo zpracování. Funkce R data.frame zpracovává všechny řetězce jako proměnné faktoru, pokud není argument stringsAsFactors nastavený na False. To znamená, že řetězce se automaticky převedou na celé číslo pro zpracování a pak se mapují zpět na původní řetězec.

Pokud jsou zdrojová data pro faktory uložená jako celé číslo, může dojít k omezení výkonu, protože R převede celá čísla faktoru na řetězce za běhu a pak provede vlastní interní převod typu string-to-integer.

Abyste se vyhnuli takovým převodům za běhu, zvažte uložení hodnot jako celých čísel do tabulky SQL Server a použití argumentu colInfo k určení úrovní sloupce použitého jako faktoru. Většina objektů zdroje dat v RevoScaleR převezme parametr colInfo. Tento parametr použijete k pojmenování proměnných používaných zdrojem dat, určení jejich typu a definování úrovní proměnných nebo transformací hodnot sloupců.

Například následující volání funkce jazyka R získá z tabulky celá čísla 1, 2 a 3, ale mapuje hodnoty na faktor s úrovněmi "jablko", "oranžová" a "banán".

c("fruit" = c(type = "factor", levels=as.character(c(1:3)), newLevels=c("apple", "orange", "banana")))

Pokud zdrojový sloupec obsahuje řetězce, je vždy efektivnější určit úrovně předem pomocí parametru colInfo . Například následující kód R považuje řetězce za faktory při jejich čtení.

c("fruit" = c(type = "factor", levels= c("apple", "orange", "banana")))

Pokud v generování modelu neexistuje žádný sémantický rozdíl, může druhý přístup vést k lepšímu výkonu.

Transformace dat

Datoví vědci často používají transformační funkce napsané v jazyce R jako součást analýzy. Funkce transformace se použije na každý řádek načtený z tabulky. V SQL Server se tyto transformace použijí na všechny řádky načtené v dávce, které vyžadují komunikaci mezi interpretem R a analytickým modulem. Aby bylo možné provést transformaci, data se přesunou z SQL do analytického modulu a pak do procesu interpreta R a zpět.

Z tohoto důvodu může použití transformací v rámci kódu R mít významný nepříznivý vliv na výkon algoritmu v závislosti na množství zahrnutých dat.

Před provedením analýzy je efektivnější mít všechny potřebné sloupce v tabulce nebo zobrazení a vyhnout se transformacím během výpočtu. Pokud do existujících tabulek není možné přidat další sloupce, zvažte vytvoření jiné tabulky nebo zobrazení s transformovanými sloupci a načtení dat pomocí vhodného dotazu.

Čtení řádků služby Batch

Pokud ve svém kódu používáte zdroj dat SQL Server (RxSqlServerData), doporučujeme použít parametr rowsPerRead k určení velikosti dávky. Tento parametr definuje počet řádků, které jsou dotazovány, a pak se odešle do externího skriptu pro zpracování. V době běhu algoritmus zobrazí pouze zadaný počet řádků v každé dávce.

Schopnost řídit množství zpracovávaných dat vám může pomoct vyřešit nebo se vyhnout problémům. Pokud je například vstupní datová sada velmi široká (má mnoho sloupců) nebo pokud datová sada obsahuje několik velkých sloupců (například volný text), můžete zmenšit velikost dávky, aby se zabránilo stránkování dat z paměti.

Ve výchozím nastavení je hodnota tohoto parametru nastavena na 50000, aby se zajistil slušný výkon i na počítačích s nedostatkem paměti. Pokud má server dostatek dostupné paměti, zvýšení této hodnoty na 500 000 nebo i milion může přinést lepší výkon, zejména pro velké tabulky.

Výhody zvětšení dávkové velikosti se projeví u velké datové sady a v úloze, která může běžet na více procesech. Zvýšení této hodnoty ale vždy nevytváří nejlepší výsledky. K určení optimální hodnoty doporučujeme experimentovat s daty a algoritmy.

Paralelní zpracování

Pro zlepšení výkonu rx analytických funkcí můžete využít schopnost SQL Server provádět úlohy paralelně s dostupnými jádry na serverovém počítači.

Paralelizace s jazykem R se dá dosáhnout dvěma způsoby v SQL Server:

  • Použijte @parallel. Při použití sp_execute_external_script uložené procedury ke spuštění skriptu jazyka R nastavte @parallel parametr na 1. Toto je nejlepší metoda, pokud váš skript R nepoužívá funkce RevoScaleR, které mají další mechanismy pro zpracování. Pokud váš skript používá funkce RevoScaleR (obecně s předponou "rx"), paralelní zpracování se provádí automaticky a není nutné explicitně nastavit @parallel .1

    Pokud lze paralelizovat skript jazyka R a pokud je možné paralelizovat dotaz SQL, databázový stroj vytvoří více paralelních procesů. Maximální počet procesů, které lze vytvořit, se rovná maximálnímu stupni paralelismu (MAXDOP) pro instanci. Všechny procesy pak spustí stejný skript, ale obdrží jenom část dat.

    Proto tato metoda není užitečná se skripty, které musí vidět všechna data, například při trénování modelu. Je ale užitečné při paralelním provádění úkolů, jako je dávkové předpovědi. Další informace o použití paralelismu s sp_execute_external_script najdete v části Pokročilé rady: Paralelní zpracování v "Using R Code in Transact-SQL".

  • Použijte numTasks =1. Při použití funkcí rx ve výpočetním kontextu SQL Server nastavte hodnotu parametru numTasks na počet procesů, které chcete vytvořit. Počet vytvořených procesů nesmí být nikdy větší než MAXDOP; Skutečný počet vytvořených procesů je však určen databázovým strojem a může být menší, než jste požadovali.

    Pokud je možné paralelizovat skript jazyka R a pokud je možné paralelizovat dotaz SQL, SQL Server při spouštění funkcí rx vytvoří více paralelních procesů. Skutečný počet vytvořených procesů závisí na různých faktorech. Patří sem zásady správného řízení prostředků, aktuální využití prostředků, další relace a plán provádění dotazů pro dotaz použitý se skriptem R.

Paralelizace dotazů

V Microsoft R můžete pracovat s SQL Server zdroji dat definováním dat jako objektu zdroje dat RxSqlServerData.

Vytvoří zdroj dat založený na celé tabulce nebo zobrazení:

RxSqlServerData(table= "airline", connectionString = sqlConnString)

Vytvoří zdroj dat založený na dotazu SQL:

RxSqlServerData(sqlQuery= "SELECT [ArrDelay],[CRSDepTime],[DayOfWeek] FROM  airlineWithIndex WHERE rowNum <= 100000", connectionString = sqlConnString)

Note

Pokud je tabulka zadaná ve zdroji dat místo dotazu, služba R Services používá interní heuristiku k určení potřebných sloupců pro načtení z tabulky; Tento přístup však pravděpodobně nebude mít za následek paralelní provádění.

Aby bylo možné data analyzovat paralelně, měl by být dotaz použitý k načtení dat zarámován tak, aby databázový stroj mohl vytvořit plán paralelního dotazu. Pokud kód nebo algoritmus používá velké objemy dat, ujistěte se, že je dotaz zadaný RxSqlServerData pro paralelní provádění optimalizovaný. Dotaz, který nemá za následek paralelní plán provádění, může vést k jednomu procesu výpočtu.

Pokud potřebujete pracovat s velkými datovými sadami, použijte nástroj Management Studio nebo jiný analyzátor dotazů SQL před spuštěním vašeho R kódu, abyste analyzovali plán provádění. Pak proveďte všechny doporučené kroky ke zlepšení výkonu dotazu. Například chybějící index v tabulce může ovlivnit čas potřebný ke spuštění dotazu. Další informace naleznete v tématu Monitorování a ladění výkonu.

Další běžnou chybou, která může ovlivnit výkon, je, že dotaz načte více sloupců, než je potřeba. Pokud je například vzorec založený jenom na třech sloupcích, ale zdrojová tabulka má 30 sloupců, zbytečně přesouváte data.

  • Vyhněte se používání SELECT *!
  • Zkontrolujte sloupce v datové sadě a identifikujte jenom ty, které jsou potřeba k analýze.
  • Odeberte z dotazů všechny sloupce obsahující datové typy, které nejsou kompatibilní s kódem R, jako jsou GUIDS a rowguids.
  • Kontrola nepodporovaných formátů data a času
  • Místo načtení tabulky vytvořte zobrazení, které vybere určité hodnoty nebo přetypuje sloupce, aby nedocházelo k chybám převodu.

Optimalizace algoritmu strojového učení

Tato část obsahuje různé tipy a zdroje, které jsou specifické pro RevoScaleR a další možnosti v Microsoft R.

Tip

Obecná diskuze o optimalizaci jazyka R je mimo rozsah tohoto článku. Pokud ale potřebujete kód zrychlit, doporučujeme oblíbený článek R Inferno. Zahrnuje programovací konstrukce v jazyce R a běžné nástrahy v živém jazyce a podrobnostech a poskytuje mnoho konkrétních příkladů programovacích technik jazyka R.

Optimalizace pro RevoScaleR

Mnoho algoritmů RevoScaleR podporuje parametry pro řízení způsobu generování natrénovaného modelu. I když je přesnost a správnost modelu důležitá, výkon algoritmu může být stejně důležitý. Abyste získali správnou rovnováhu mezi přesností a časem trénování, můžete upravit parametry tak, aby se zvýšila rychlost výpočtů a v mnoha případech se zlepšil výkon bez snížení přesnosti nebo správnosti.

  • rxDTree

    rxDTree maxDepth podporuje parametr, který řídí hloubku rozhodovacího stromu. Jakmile se maxDepth zvyšuje, výkon se může zhoršovat, proto je důležité posoudit výhody zvýšení hloubky vzhledem ke zhoršení výkonu.

    Můžete také řídit rovnováhu mezi časovou složitostí a přesností předpovědi úpravou parametrů, jako jsou maxNumBins, maxDepth, maxComplete a maxSurrogate. Zvýšením hloubky nad 10 nebo 15 může být výpočet velmi nákladný.

  • rxLinMod

    Zkuste použít cube argument, pokud první závislá proměnná ve vzorci je faktorová proměnná.

    Pokud cube je nastavená hodnota TRUE, regrese se provádí pomocí dělené inverzní funkce, což může být rychlejší a používat méně paměti než standardní regresní výpočty. Pokud má vzorec velký počet proměnných, může být zvýšení výkonu významné.

  • rxLogit

    cube Argument použijte, pokud první závislá proměnná je faktorová proměnná.

    Pokud je cube nastaven na TRUE, algoritmus používá dělený inverzní, což může být rychlejší a používat méně paměti. Pokud má vzorec velký počet proměnných, může být zvýšení výkonu významné.

Další informace o optimalizaci RevoScaleR najdete v těchto článcích:

Použití MicrosoftML

Doporučujeme také podívat se na nový balíček MicrosoftML , který poskytuje škálovatelné algoritmy strojového učení, které můžou používat výpočetní kontexty a transformace poskytované RevoScaleR.

Související obsah

  • Poslední aktualizace v