Практические пределы кадра данных R

Question

Я читал о том, что read.table неэффективен для больших файлов данных. Кроме того, как R не подходит для больших наборов данных. Поэтому мне было интересно, где я могу найти практические ограничения и любые диаграммы производительности для (1) чтения данных разных размеров (2) работы с данными разных размеров.

По сути, я хочу знать, когда производительность ухудшается и когда я сталкиваюсь с дорожным блоком. Также было бы полезно любое сравнение с C ++ / MATLAB или другими языками. наконец, если бы было какое-то специальное сравнение производительности для Rcpp и RInside, это было бы здорово!

Answer 1

R подходит для больших наборов данных, но вам, возможно, придется немного изменить свой метод работы по сравнению с тем, чему вас учат вводные учебники.Я сделал пост на Большие данные для R , который хрустит 30-Гбайтным набором данных и может оказаться полезным для вдохновения.

Обычные источники информации для начала работы: Высокий-Процесс производительности вычислений и список рассылки R-SIG HPC на R-SIG HPC .

Основное ограничение, которое вам нужно обойти, это историческое ограничение на длинувектор к 2 ^ 31-1 элементам, что было бы не так плохо, если бы R не сохранял матрицы в качестве векторов.(Ограничение на совместимость с некоторыми библиотеками BLAS.)

Мы регулярно анализируем записи телефонных звонков и маркетинговые базы данных телекоммуникационных компаний с помощью миллионов пользователей, использующих R, поэтому будем рады поговорить подробнее, если вам интересно.

Answer 2

Физические ограничения возникают из-за использования 32-битных индексов для векторов. В результате допустимы векторы до 2 ^ 31 - 1. Матрицы - это векторы с измерениями, поэтому произведение nrow(mat) и ncol(mat) должно быть в пределах 2 ^ 31 - 1. Фреймы данных и списки являются общими векторами, поэтому каждый компонент может принимать 2 ^ 31 - 1 записей, что для фреймов данных означает, что у вас может быть столько строк и столбцов. Для списков вы можете иметь 2 ^ 31 - 1 компонента, каждый из 2 ^ 31 - 1 элементов. Это взято из недавнего сообщения Дункана Мердока в ответ на вопрос о R-Help

Теперь, когда все должно уместиться в ОЗУ со стандартным R, что может быть более жестким пределом, но Высокопроизводительное вычисление Представление задач, которое упоминали другие, содержит подробности о пакетах, которые могут обойти проблемы с памятью.

Answer 3

1) Руководство по импорту / экспорту R должно быть первым портом вызова для вопросов об импорте данных - есть много вариантов, и то, что будет работать для вас, может быть очень конкретным.

http://cran.r -project.org / doc / manual / R-data.html

read.table, в частности, значительно улучшил производительность при использовании предоставленных ему опций, в частности colClasses, comment.char,и nrows - это потому, что эта информация должна быть выведена из самих данных, что может быть дорогостоящим.

2) Существует определенный предел длины (общего количества элементов) для любого вектора, матрицы, массива, столбца в data.frame или списке.Это связано с 32-битным индексом, используемым под капотом, и верно для 32-битных и 64-битных R. Число 2 ^ 31 - 1. Это максимальное количество строк для data.frame, ноон настолько велик, что у вас гораздо больше шансов исчерпать память даже для отдельных векторов, прежде чем вы начнете собирать несколько из них.

Подробнее см. help(Memory-limits) и help(Memory).

Один вектор такой длины займет много гигабайт памяти (зависит от типа и режима хранения каждого вектора - 17,1 для числового), поэтому вряд ли это будет правильным пределом, если вы действительно не продвигаете вещи.Если вам действительно нужно вытолкнуть вещи за пределы доступной системной памяти (здесь 64-битная версия обязательна), тогда стоит использовать стандартные методы работы с базами данных, описанные в руководстве по импорту / экспорту, или параметры файла с отображенной памятью (например, пакет ff).принимая во внимание.CRAN Task View High Performance Computing является хорошим ресурсом для этой цели.

Наконец, если у вас есть стеки ОЗУ (16 ГБ или более) и вам нужна 64-разрядная индексация, это может появиться в следующей версии R. http://www.mail -archive.com / r-help @r-project.org/msg92035.html

Кроме того, Росс Ихака обсуждает некоторые исторические решения и будущие направления для языка, подобного R, в статьях и беседах здесь: http://www.stat.auckland.ac.nz/~ihaka/?Papers_and_Talks

Answer 4

Я могу ответить только на вопрос о read.table, поскольку у меня нет опыта работы с большими наборами данных.read.table работает плохо, если вы не предоставите colClasses аргументы.Без этого read.table по умолчанию принимает значение NA и пытается угадать класс каждого столбца, что может быть медленным, особенно если у вас много столбцов.

Answer 5

При чтении больших CSV-файлов x GB <=> y.1e6 rows Я думаю data.table::fread (начиная с версии 1.8.7) - самая быстрая альтернатива, которую вы можете получить, делая install.packages("data.table", repos="http://R-Forge.R-project.org")

Обычно вы получаете коэффициент от 5 до 10(и все sep, row.names и т. д. обрабатываются самой функцией).Если у вас много файлов и достаточно приличный компьютер (несколько ядер), я рекомендую использовать пакет parallel (как часть R.2.14) для загрузки одного файла на ядро.

В последний раз, когда я делал это междуоднопоточная загрузка с read.csv и многопоточность на 4-х ядерном использовании fread я пошел от 5 минут до 20 секунд