Обработка крупномасштабного набора данных
От дискуссионных групп онлайн и блогов, я видел, что много вопросов об интервью связано с обработкой крупномасштабного набора данных. Я задаюсь вопросом, там систематический подход для анализа этого типа вопросов? Или в более определенном, там какая-либо структура данных или алгоритмы, которые могут использоваться для контакта с этим? Любые предложения действительно ценятся.
4 ответа
«Крупномасштабные» наборы данных, которые я видел, подразделяются на несколько категорий, каждая из которых представляет для вас разные проблемы.
- Данные, слишком большие для размещения в памяти. Вот некоторые ключевые техники:
- Кэширование данных, которые часто используются для повышения производительности.
- Работа с данными из файла по частям вместо попытки чтения всего файла в память сразу (если вы не работаете последовательно через файл, это может быть особенно сложной задачей!)
- Распределение данных по памяти нескольких машин.
- Данные, которые слишком велики, чтобы поместиться в один файл, из-за ограничений файловой системы или архитектуры оборудования. Это довольно легко решить - разделить файл - но во многих случаях возникает практический вопрос о том, что такое разумное разделение.
- Данные, которые слишком велики, чтобы поместиться на одном жестком диске. Здесь в основном методы заключаются в том, чтобы купить диски большего размера :-) или распределить данные по нескольким машинам.
- Распределение данных между несколькими машинами создает интересные проблемы, когда вам нужно провести анализ или преобразование данных. Это глубокая тема с множеством разных подходов и проблем. Фреймворки сопоставления / сокращения, такие как CouchDB и Hadoop, в последнее время стали популярными инструментами для исследований и применения в этой области.
- Данные слишком велики для единственного экземпляра базы данных. Это может быть проблема с размером диска (не хватает места) или производительностью (кеш памяти постоянно раздувается, индексы просто стали слишком большими).Поддержание надежности и производительности данных, разделенных между несколькими экземплярами БД, потенциально в нескольких центрах обработки данных, является областью постоянного интереса для крупных предприятий. Здесь возможны следующие варианты:
- Вертикальное разделение (разные таблицы для разных БД)
- Горизонтальное разделение (одна и та же таблица в разных БД, но с разными данными)
Другие проблемы, часто связанные с крупномасштабными наборами данных, но не связанные с размером как таковые , это:
- Данные, которые поступают быстро. Подумайте о системах, которые необходимо масштабировать до миллионов или даже миллиардов транзакций в минуту.
- Данные, которые постоянно меняются. Как вы поступаете с устаревшими данными или данными, которые изменяются в процессе работы над ними?
Не существует единой структуры данных или алгоритма для «обработки» больших наборов данных любого характера и для всех возможных целей - скорее, существует обширная коллекция таких архитектур, структур данных, и алгоритмы для такого множества различных типов данных и требуемой «обработки» (в однозадачных, SMP и распределенных средах - они вполне могут потребовать очень разных подходов во многих случаях).
Серебряной пули не существует. Чтобы понять, какие алгоритмы и структуры данных полезны для конкретной крупномасштабной цели, требуется больше контекстной информации. Для данных, которые слишком велики, чтобы поместиться в памяти, например, многие системы управления базами данных используют B+ Trees".
Когда люди описывают большой набор данных, они часто имеют в виду такой набор данных, который не может быть сохранен в памяти целиком. Это создает проблемы с тем, какие данные загружать и когда их загружать и выгружать.
Один из подходов заключается в использовании последовательного файла данных и обработке от начала до конца. Это эффективно, когда характер обработки является последовательным, но не очень хорошо работает, когда при обработке необходимо объединить данные из различных частей набора данных.
Другой подход - это своего рода индексированный файл, извлекающий необходимые биты данных по мере их необходимости.
Специализацией этого подхода является использование файлов с отображением памяти, когда вы позволяете менеджеру памяти обрабатывать загрузку и кэширование данных.
СУБД может значительно упростить доступ к данным, но добавляет некоторые системные накладные расходы.