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

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

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

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

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

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

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

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

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

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

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

В двух словах, основные отличия ИМО:

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

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

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

Кластеры

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

Алгоритмы

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

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

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

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

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

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

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

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