что меняется, когда ваш ввод имеет размер гига / терабайт?

Question

Я только сегодня сделал свой первый шаг в реальные научные вычисления, когда мне показали набор данных, где наименьший файл - 48000 полей на 1600 строк (гаплотипы для нескольких человек, для 22-й хромосомы).И это считается крошечным.

Я пишу на Python, поэтому я провел последние несколько часов, читая о HDF5, Numpy и PyTable, но я все еще чувствую, что на самом деле не таращу, какой терабайт…Размер данных на самом деле означает для меня, как программиста.

Например, кто-то указал, что при больших наборах данных становится невозможным считывать все это в память не потому, что на машине недостаточно оперативной памяти, а потому, что в архитектуре недостаточно адресного пространства!Это поразило меня.

На какие еще предположения я опирался в классе, которые просто не работают с таким большим вкладом?Какие вещи мне нужно начать делать или думать по-другому?(Это не обязательно должно быть специфично для Python.)

Answer 1

В настоящее время я занимаюсь высокопроизводительными вычислениями в небольшом уголке нефтяной промышленности и регулярно работаю с наборами данных того порядка, который вас беспокоит. Вот некоторые моменты для рассмотрения:

1. Базы данных не имеют большой тяги в этом домене. Почти все наши данные хранятся в файлах, некоторые из них основаны на форматах магнитных лент, разработанных в 70-х годах. Я думаю, что одна из причин неиспользования баз данных является исторической; 10, даже 5 лет назад, я думаю, что Oracle и ее родственники не справились с задачей управления единичными наборами данных O (TB), не говоря уже о базе данных из 1000 таких наборов данных.

   Другой причиной является концептуальное несоответствие между правилами нормализации для эффективного анализа и проектирования баз данных и характером наборов научных данных.

   Я думаю (хотя я не уверен), что причины (ы) производительности сегодня гораздо менее убедительны. И причина несоответствия понятий, вероятно, также менее актуальна, поскольку большинство основных доступных баз данных могут справляться с наборами пространственных данных, которые, как правило, намного ближе концептуально соответствуют другим наборам научных данных. Я наблюдал все более широкое использование баз данных для хранения метаданных, с некоторой ссылкой на файл (ы), содержащий данные датчика.

   Однако я все еще смотрю, фактически смотрю на HDF5. У меня есть пара преимуществ: (а) это просто еще один формат файла, поэтому мне не нужно устанавливать СУБД и бороться с ее сложностями, и (б) с подходящим оборудованием я могу читать / записывать файл HDF5 параллельно , (Да, я знаю, что я могу читать и записывать базы данных параллельно).

2. Что подводит меня ко второму пункту: при работе с очень большими наборами данных вам действительно нужно подумать об использовании параллельных вычислений. Я работаю в основном на Фортране, одной из его сильных сторон является синтаксис массива, который очень хорошо подходит для многих научных вычислений; другая хорошая поддержка параллелизации. Я считаю, что в Python также есть всяческая поддержка распараллеливания, так что это, вероятно, неплохой выбор для вас.

   Конечно, вы можете добавить параллелизм в последовательные системы, но гораздо лучше начать разработку параллелизма. Возьмем только один пример: лучший последовательный алгоритм для задачи очень часто не лучший кандидат для распараллеливания. Возможно, вам лучше использовать другой алгоритм, который лучше масштабируется на нескольких процессорах. Который аккуратно ведет к следующему пункту.

3. Я также думаю, что вам, возможно, придется смириться с отказом от любых вложений, которые у вас есть (если они у вас есть), перед множеством умных алгоритмов и структур данных, которые хорошо работают, когда все ваши данные хранятся в памяти. Очень часто попытка адаптировать их к ситуации, когда вы не можете сразу получить данные в память, гораздо сложнее (и менее производительно), чем перебор, и рассматривает весь файл как один большой массив.

4. Производительность начинает серьезно влиять как на производительность программ, так и на производительность разработчиков. Дело не в том, что для набора данных в 1 ТБ требуется в 10 раз больше кода, чем для набора данных в 1 ГБ, поэтому вам придется работать быстрее, а в том, что некоторые идеи, которые вам нужно реализовать, будут безумно сложными и, вероятно, должны быть написаны специалистами в области то есть ученые, с которыми вы работаете. Здесь специалисты домена пишут в Matlab.

Но это продолжается слишком долго, мне лучше вернуться к работе

Answer 2

В двух словах, основные различия IMO:

1. Вы должны заранее знать, каким будет ваше вероятное узкое место (ввод / вывод или ЦП), и сосредоточиться на наилучшем алгоритме и инфраструктуре для решения этой проблемы.Ввод / вывод довольно часто является узким местом.
2. Выбор и настройка алгоритма часто доминирует над любым другим сделанным выбором.
3. Даже незначительные изменения в алгоритмах и схемах доступа могут повлиять на производительность на несколько порядков.Вы будете много микрооптимизировать.«Лучшее» решение будет зависеть от системы.
4. Поговорите со своими коллегами и другими учеными, чтобы воспользоваться их опытом использования этих наборов данных.Много хитростей не найти в учебниках.
5. Предварительные вычисления и сохранение могут быть чрезвычайно успешными.

Пропускная способность и ввод / вывод

Первоначально пропускная способность и ввод / вывод частоявляется узким местом.Чтобы дать вам представление: при теоретическом пределе для SATA 3 , чтение 1 ТБ занимает около 30 минут.Если вам нужен произвольный доступ, чтение несколько раз или запись, вы хотите делать это в памяти большую часть времени или вам нужно что-то существенно более быстрое (например, iSCSI с InfiniBand ).В идеале ваша система должна иметь возможность параллельного ввода-вывода , чтобы максимально приблизиться к теоретическому пределу того интерфейса, который вы используете.Например, простой параллельный доступ к разным файлам в разных процессах или HDF5 поверх MPI-2 I / O довольно распространен.В идеале вы также должны выполнять вычисления и ввод / вывод параллельно, чтобы один из двух был «бесплатным».

Clusters

В зависимости от вашего случая, либо я/ O или процессор может быть узким местом.Независимо от того, какой из них, с помощью кластеров, можно добиться значительного увеличения производительности, если вы сможете эффективно распределять свои задачи (пример MapReduce ).Это может потребовать совершенно других алгоритмов, чем типичные примеры из учебников.Тратить время на разработку здесь часто - лучшее время.

Алгоритмы

При выборе между алгоритмами большое значение O алгоритма очень важно, но алгоритмы с аналогичным большим значением Oможет существенно отличаться по производительности в зависимости от местности.Чем менее локальным является алгоритм (т. Е. Чем больше кеша и основной памяти), тем хуже будет производительность - доступ к хранилищу обычно на порядок медленнее, чем к основной памяти.Классическими примерами улучшений могут быть мозаика для умножения матриц или обмен циклами .

Компьютер, язык, специализированные инструменты

Если узким местом является ввод / вывод, это означает, что алгоритмы для больших наборов данных могут извлечь выгоду из большего объема основной памяти (например, 64-разрядной) или языков программирования / структур данных с меньшим потреблением памяти (например, в Python __slots__ может быть полезным), потому что больше памяти может означать меньшее количество операций ввода-вывода на процессорное время.Кстати, системы с ТБ основной памяти не являются неслыханными (например, HP Superdomes ).

Аналогичным образом, если узким местом является ЦП, более быстрые машины, языки и компиляторы, которые позволяют использовать специальные функции архитектуры (например, SIMD , например, SSE ), могутповысить производительность на порядок.

Способ, которым вы находите данные и получаете к ним доступ, а также сохраняете метаинформацию, может быть очень важен для производительности.Вы будете часто использовать плоские файлы или специфичные для домена нестандартные пакеты для хранения данных (например, не реляционные базы данных напрямую), которые позволят вам получить более эффективный доступ к данным.Например, kdb + - это специализированная база данных для больших временных рядов, а ROOT использует объект TTree для эффективного доступа к данным.Упомянутые вами pyTables будут еще одним примером.

Answer 3

Хотя некоторые языки имеют естественно меньшую нагрузку на память в своих типах, чем другие, это действительно не имеет значения для данных такого размера - вы не храните весь свой набор данных в памяти независимо от используемого вами языка, поэтому «Расход» Python здесь не имеет значения. Как вы указали, адресного пространства просто не хватает даже для ссылки на все эти данные, не говоря уже о том, чтобы их хранить.

Обычно это означает либо а) хранение ваших данных в базе данных, либо б) добавление ресурсов в виде дополнительных компьютеров, тем самым добавляя к вашему доступному адресному пространству и памяти. Реально вы собираетесь в конечном итоге сделать обе эти вещи. При использовании базы данных следует помнить о том, что база данных - это не просто место для размещения ваших данных, когда вы ее не используете - вы можете выполнять РАБОТУ в базе данных, и вам следует попытаться это сделать. Технология баз данных, которую вы используете, оказывает большое влияние на то, какую работу вы можете выполнять, но, например, база данных SQL хорошо подходит для выполнения сложных математических заданий и выполнения этого эффективно (конечно, это означает, что разработка схемы становится очень важная часть вашей общей архитектуры). Не просто высасывайте данные и манипулируйте ими только в памяти - постарайтесь использовать возможности вычислительных запросов вашей базы данных, чтобы выполнить как можно больше работы, прежде чем вы когда-либо поместите данные в память в своем процессе.

Answer 4

Основные предположения касаются количества процессора / кэша / оперативной памяти / хранилища / пропускной способности, которое вы можете иметь на одной машине по приемлемой цене. Здесь, в stackoverflow, есть много ответов, основанных на старых предположениях о 32-битной машине с 4G RAM и о терабайтах хранилища и сети 1Gb. С 16 ГБ оперативной памяти DDR-3 по 220 евро и 512 ГБ оперативной памяти можно собрать 48 ядерных машин по разумным ценам. Переход с жестких дисков на SSD - еще одно важное изменение.