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

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

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

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

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

Ответ 1

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

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

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

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

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

Конечно, вы можете добавить parallelism в последовательные системы, но гораздо лучше начать разработку для parallelism. Возьмем только один пример: лучший последовательный алгоритм для проблемы очень часто не лучший кандидат для параллелизации. Возможно, вам лучше использовать другой алгоритм, который лучше масштабируется на нескольких процессорах. Что ведет аккуратно к следующей точке.
Я также думаю, что вам, возможно, придется договориться с тем, чтобы передать любые вложения, которые у вас есть (если они есть), множеству умных алгоритмов и структур данных, которые хорошо работают, когда все ваши данные находятся в памяти. Очень часто пытаться приспособить их к ситуации, когда вы не можете получить данные в памяти сразу, намного сложнее (и менее результативнее), чем грубая сила, и относительно всего файла как одного большого массива.
Производительность начинает серьезно зависеть как производительность исполнения программ, так и производительность разработчика. Это не значит, что для набора данных 1 ТБ требуется в 10 раз больше кода, чем набор данных 1 ГБ, поэтому вам нужно работать быстрее, что некоторые идеи, которые вам нужно реализовать, будут безумно сложными и, вероятно, должны быть написаны специалистами домена, т.е. с учеными, с которыми вы работаете. Здесь специалисты домена пишут в Matlab.

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

Ответ 2

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

Вы должны знать заранее, узким местом будет (I/O или CPU) и сосредоточиться на лучшем алгоритме и инфраструктуре для решения этой проблемы. Ввод-вывод довольно часто является узким местом.
Выбор и тонкая настройка алгоритма часто доминируют над любым другим сделанным выбором.
Даже незначительные изменения в алгоритмах и шаблонах доступа могут порядки величины. Вы будете много оптимизировать. "Лучшим" решением будет зависит от системы.
Поговорите со своими коллегами и другими учеными, чтобы извлечь выгоду из их опыта с этими наборы данных. В учебниках много трюков невозможно найти.
Предварительные вычисления и хранение могут быть чрезвычайно успешными.

Ширина полосы пропускания и ввод-вывод

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

Кластеры

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

Алгоритмы

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

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

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

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

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

Ответ 3

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

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

Ответ 4

Основными предположениями являются объем cpu/cache/ram/storage/bandwidth, который вы можете иметь на одной машине по приемлемой цене. В stackoverflow есть много ответов, которые по-прежнему основаны на старых предположениях 32-битной машины с 4 Гб оперативной памяти и около терабайта памяти и сети 1 Гбит. С 16-Гбайт модулями памяти DDR-3 на 220 евро, 512 ГБ оперативной памяти, 48 основных машин могут быть построены по разумным ценам. Другим важным изменением является переход с жестких дисков на SSD.