что изменяется, когда Ваш вход является измеренным giga/terabyte?
Я просто взял свой первый маленький шаг сегодня в реальные научные вычисления сегодня, когда мне показали набор данных, где самый маленький файл является 48 000 полей 1 600 строками (гаплотипы для нескольких человек для хромосомы 22). И это считают крошечным.
Я пишу Python, таким образом, я провел последние несколько часов, читая о HDF5, и Numpy и PyTable, но я все еще чувствую, что я не действительно понимание, что набор данных размера терабайта на самом деле означает для меня как программист.
Например, кто-то указал, что с большими наборами данных, становится невозможно считать все это в память, не потому что машина имеет недостаточную RAM, но потому что архитектура имеет недостаточное адресное пространство! Унесло мой ум.
Что другие предположения я полагался в классе, которые просто не работают с входом это большое? Какие виды вещей я должен начать делать или думать о по-другому? (Это не должно быть конкретным Python.)
3 ответа
В настоящее время я занимаюсь высокопроизводительными вычислениями в небольшом уголке нефтяной промышленности и регулярно работаю с наборами данных таких порядков величины, о которых вы беспокоитесь. Вот некоторые моменты, которые следует рассмотреть:
Базы данных не имеют большой популярности в этой области. Почти все наши данные хранятся в файлах, некоторые из которых основаны на форматах ленточных файлов, разработанных в 70-х годах. Я думаю, что частично причина неиспользования баз данных историческая; 10, даже 5 лет назад, я думаю, Oracle и ему подобные просто не справлялись с задачей управления единичными наборами данных размером O(TB), не говоря уже о базе данных из 1000 таких наборов данных.
Другая причина - концептуальное несоответствие между правилами нормализации для эффективного анализа и проектирования баз данных и природой научных наборов данных.
Я думаю (хотя и не уверен), что причина (причины) производительности сегодня гораздо менее убедительна. И причина несоответствия концепции, вероятно, также менее актуальна сейчас, когда большинство основных доступных баз данных могут работать с наборами пространственных данных, которые, как правило, гораздо ближе по концепции к другим научным наборам данных. Я наблюдаю все более широкое использование баз данных для хранения мета-данных, с некоторой ссылкой на файл(ы), содержащий(ие) сенсорные данные.
Тем не менее, я бы все еще рассматривал, и фактически рассматриваю, HDF5. У него есть пара привлекательных для меня моментов (а) это просто другой формат файлов, поэтому мне не нужно устанавливать СУБД и разбираться с ее сложностями, и (б) при наличии подходящего оборудования я могу читать/писать файлы HDF5 параллельно. (Да, я знаю, что я также могу читать и писать базы данных параллельно).
Это подводит меня ко второму моменту: при работе с очень большими наборами данных вам действительно нужно думать об использовании параллельных вычислений. Я работаю в основном на Fortran, одной из его сильных сторон является синтаксис массивов, который очень хорошо подходит для многих научных вычислений; другой - хорошая поддержка параллелизации. Я полагаю, что Python тоже имеет всевозможную поддержку параллелизации, так что, вероятно, это неплохой выбор для вас.
Конечно, вы можете добавить параллелизм к последовательным системам, но гораздо лучше начинать проектирование с параллелизма. Приведем лишь один пример: лучший последовательный алгоритм для решения задачи очень часто не является лучшим кандидатом на распараллеливание. Возможно, лучше использовать другой алгоритм, который лучше масштабируется на нескольких процессорах. Это приводит к следующему пункту.
Я также думаю, что вам, возможно, придется смириться с тем, что вам придется отказаться от любых привязанностей (если они у вас есть) к множеству умных алгоритмов и структур данных, которые хорошо работают, когда все ваши данные находятся в памяти. Очень часто попытка адаптировать их к ситуации, когда вы не можете получить данные в память все сразу, оказывается гораздо сложнее (и менее производительной), чем перебор и рассмотрение всего файла как одного большого массива.
Производительность начинает иметь серьезное значение, как производительность выполнения программ, так и производительность разработчика. Дело не в том, что набор данных объемом 1 ТБ требует в 10 раз больше кода, чем набор данных объемом 1 ГБ, поэтому вы должны работать быстрее, а в том, что некоторые идеи, которые вам нужно будет реализовать, будут безумно сложными и, вероятно, должны быть написаны специалистами в данной области, то есть учеными, с которыми вы работаете. Здесь специалисты пишут на Matlab.
Но это продолжается слишком долго, я лучше вернусь к работе
.В то время как некоторые языки естественно имеют меньшие накладные расходы на память в своих типах, чем другие, это действительно не имеет значения для данных такого размера - вы не храните весь свой набор данных в памяти, независимо от языка, который вы используете, поэтому «расход» Python здесь не имеет значения. Как вы отметили, просто не хватает адресного пространства, чтобы даже ссылаться на все эти данные, не говоря уже о том, чтобы удерживать их.
Обычно это означает либо а) хранение ваших данных в базе данных, или б) добавление ресурсов в виде дополнительных компьютеров, таким образом увеличивая доступное адресное пространство и память. На самом деле вы в конечном итоге сделаете и то, и другое. При использовании базы данных следует иметь в виду одну ключевую вещь: база данных - это не просто место для хранения данных, когда вы ее не используете - вы можете выполнять РАБОТУ в базе данных, и вы должны попытаться это сделать. Технология баз данных, которую вы используете, оказывает большое влияние на тип работы, которую вы можете выполнять, но база данных SQL, например, хорошо подходит для выполнения большого количества математических операций с наборами и делает это эффективно (конечно, это означает, что проектирование схемы становится очень важная часть вашей общей архитектуры). Не просто извлекайте данные и манипулируйте ими только в памяти - попробуйте использовать возможности вычислительных запросов вашей базы данных, чтобы выполнить как можно больше работы, прежде чем вы когда-либо помещаете данные в память в своем процессе.
В двух словах, основные различия IMO:
- Вы должны знать заранее, что будет вашим вероятным узкое место (ввод/вывод или процессор) и сосредоточиться на лучшем алгоритме и инфраструктуре. для решения этой проблемы. I/O довольно часто является узким местом.
- Выбор и тонкая настройка алгоритма часто доминируют над любым другим выбором.
- Даже незначительные изменения в алгоритмах и шаблонах доступа могут повлиять на производительность на порядок величины. Вы будете много заниматься микрооптимизацией. "Лучшее" решение будет зависит от системы.
- Поговорите со своими коллегами и другими учеными, чтобы извлечь пользу из их опыта работы с этими наборами данных. Многие приемы невозможно найти в учебниках.
- Предварительные вычисления и хранение данных могут быть чрезвычайно успешными.
Пропускная способность и ввод/вывод
На начальном этапе пропускная способность и ввод/вывод часто являются узким местом. Для примера: при теоретическом пределе для SATA 3 чтение 1 ТБ занимает около 30 минут. Если вам нужен произвольный доступ, чтение несколько раз или запись, вы хотите делать это в памяти большую часть времени или вам нужно что-то значительно более быстрое (например, iSCSI с InfiniBand). В идеале ваша система должна уметь выполнять параллельный ввод-вывод, чтобы максимально приблизиться к теоретическому пределу того интерфейса, который вы используете. Например, простой параллельный доступ к разным файлам в разных процессах или HDF5 поверх MPI-2 I/O - довольно распространенное явление. В идеале вы также выполняете вычисления и ввод/вывод параллельно, чтобы одно из двух выполнялось "бесплатно".
Кластеры
В зависимости от вашего случая, узким местом может быть либо ввод-вывод, либо центральный процессор. Независимо от того, что именно является узким местом, при использовании кластеров можно добиться огромного прироста производительности, если эффективно распределить задачи (пример MapReduce). Это может потребовать совершенно иных алгоритмов, чем типичные примеры из учебников. Затраты времени на разработку здесь часто оказываются наилучшим времяпрепровождением.
Алгоритмы
При выборе между алгоритмами большое O алгоритма очень важно, но алгоритмы с одинаковым большим O могут резко отличаться по производительности в зависимости от локальности. Чем менее локален алгоритм (т.е. чем больше промахов кэша и основной памяти), тем хуже будет производительность - доступ к хранилищу обычно на порядок медленнее, чем к основной памяти. Классическими примерами улучшения являются тайлинг для матричных умножений или чередование циклов.
Компьютер, язык, специализированные инструменты
Если узким местом является ввод-вывод, это означает, что алгоритмы для больших наборов данных могут выиграть от большего объема основной памяти (например, 64-битной) или языков программирования / структур данных с меньшим потреблением памяти (например, в Python __slots__ могут быть полезны), потому что больше памяти может означать меньше ввода-вывода за процессорное время. BTW, системы с ТБ основной памяти - не редкость (например, HP Superdomes).
Аналогично, если ваше узкое место - процессор, более быстрые машины, языки и компиляторы, позволяющие использовать специальные возможности архитектуры (например, SIMD, как SSE), могут увеличить производительность на порядок.
Способ поиска и доступа к данным, а также хранения метаинформации может быть очень важен для производительности. Часто для хранения данных используются плоские файлы или нестандартные пакеты, специфичные для конкретной области (например, не реляционная база данных напрямую), которые позволяют получить доступ к данным более эффективно. Например, kdb+ - это специализированная база данных для больших временных рядов, а ROOT использует объект TTree для эффективного доступа к данным. pyTables, о котором вы упомянули, был бы еще одним примером.