Хранение

Хранение данных является краеугольным камнем жизненного цикла инженерии данных (Рисунок 6−1) и лежит в основе его основных этапов — поглощения, преобразования и предоставления. Данные сохраняются много раз по мере их прохождения через жизненный цикл. Парафразируя старую поговорку, это хранение данных на всех этапах. Будь то данные, которые понадобятся через секунды, минуты, дни, месяцы или годы, они должны сохраняться до тех пор, пока системы не будут готовы потреблять их для дальнейшей обработки и передачи. Знание сценариев использования данных и способа их получения в будущем — это первый шаг к выбору правильных решений для хранения данных в вашей архитектуре.

Мы также обсуждали хранение данных в Главе 5, но с разницей в фокусе и области контроля. Исходные системы обычно не поддерживаются и не контролируются инженерами данных. Хранение данных, которое инженеры данных обрабатывают непосредственно и на котором мы сосредоточимся в этой главе, охватывает этапы жизненного цикла инженерии данных от поглощения данных из исходных систем до предоставления данных для создания ценности с помощью аналитики, науки о данных и т. д. Многие формы хранения данных поддерживают весь жизненный цикл инженерии данных в какой-то степени.

Чтобы разобраться в хранении данных, мы начнём с изучения основных компонентов, составляющих системы хранения данных, включая жёсткие диски, твердотельные накопители и системную память (см. Рисунок 6−2). Важно понимать базовые характеристики физических технологий хранения данных, чтобы оценить компромиссы, присущие любой архитектуре хранения данных. В этом разделе также обсуждаются сериализация и сжатие, ключевые программные элементы практического хранения данных. (Мы откладываем более глубокое техническое обсуждение сериализации и сжатия до Приложения A.) Мы также обсуждаем кэширование, которое критически важно при сборке систем хранения данных.

Далее мы рассмотрим системы хранения данных. На практике мы не напрямую обращаемся к системной памяти или жёстким дискам. Эти физические компоненты хранения существуют внутри серверов и кластеров, которые могут поглощать и извлекать данные с использованием различных парадигм доступа.

Наконец, мы рассмотрим абстракции хранения данных. Системы хранения данных объединяются в облачное хранилище данных, озеро данных и т. д. При построении конвейеров данных инженеры выбирают подходящие абстракции для хранения своих данных по мере их прохождения через этапы поглощения, преобразования и предоставления.

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

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

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

Магнитные диски (magnetic disk) используют вращающиеся пластины, покрытые ферромагнитным слоем (Рисунок 6−3). Этот слой магнетизируется считывающей/записывающей головкой во время операций записи для физического кодирования двоичных данных. Считывающая/записывающая головка обнаруживает магнитное поле и выводит поток битов во время операций чтения. Магнитные дисковые накопители существуют уже много лет. Они всё ещё составляют основу систем массового хранения данных, потому что значительно дешевле SSD по стоимости на гигабайт хранимых данных.

С одной стороны, эти диски продемонстрировали экстраординарные улучшения в производительности, плотности хранения и стоимости.

С другой стороны, SSD значительно превосходят магнитные диски по различным метрикам. В настоящее время коммерческие магнитные дисковые накопители стоят примерно 3 цента за гигабайт ёмкости. (Обратите внимание, что мы будем часто использовать сокращения HDD и SSD для обозначения вращающихся магнитных дисков и твердотельных накопителей соответственно.)

IBM разработала технологию магнитных дисковых накопителей в 1950-х годах. С тех пор ёмкость магнитных дисков неуклонно росла. Первый коммерческий магнитный дисковый накопитель, IBM 350, имел ёмкость 3,75 мегабайт. На момент написания этого текста коммерчески доступны магнитные диски ёмкостью 20 ТБ. На самом деле, магнитные диски продолжают активно развиваться, с использованием методов, таких как термомагнитная запись (HAMR), черепичная магнитная запись (SMR) и дисковые корпуса, заполненные гелием, для достижения всё большей плотности хранения. Несмотря на продолжающиеся улучшения в ёмкости дисков, другие аспекты производительности HDD ограничены физическими законами.

Во-первых, скорость передачи данных диска, то есть скорость, с которой данные могут быть прочитаны и записаны, не масштабируется пропорционально ёмкости диска. Ёмкость диска масштабируется с плотностью поверхности (гигабиты, хранящиеся на квадратный дюйм), тогда как скорость передачи масштабируется с линейной плотностью (биты на дюйм). Это означает, что если ёмкость диска увеличивается в четыре раза, скорость передачи увеличивается только в два раза. В результате, текущие диски центров данных поддерживают максимальные скорости передачи данных 200−300 МБ/с. Другими словами, чтобы прочитать все содержимое 30 ТБ магнитного диска, потребуется более 20 часов, при условии скорости передачи 300 МБ/с.

Второе крупное ограничение — это время поиска. Чтобы получить доступ к данным, накопитель должен физически переместить считывающие/записывающие головки на соответствующую дорожку на диске. Третье, чтобы найти конкретный фрагмент данных на диске, контроллер диска должен ждать, пока эти данные пройдут под считывающими/записывающими головками. Это приводит к задержке вращения. Типичные коммерческие диски, вращающиеся со скоростью 7200 оборотов в минуту (RPM), время поиска и задержка вращения приводят к более чем четырём миллисекундам общей средней задержки (время доступа к выбранному фрагменту данных). Четвёртое ограничение — это операции ввода-вывода в секунду (IOPS), критичные для транзакционных баз данных. Магнитный диск имеет диапазон от 50 до 500 IOPS.

Различные уловки могут улучшить задержку и скорость передачи. Использование более высокой скорости вращения может увеличить скорость передачи и уменьшить задержку вращения. Ограничение радиуса дисковой пластины или запись данных только в узкую полосу на диске уменьшает время поиска. Однако ни одна из этих техник не делает магнитные диски хотя бы отдалённо конкурентоспособными с SSD для случайного доступа. SSD могут предоставлять данные с значительно меньшей задержкой, большим количеством IOPS и более высокими скоростями передачи, частично потому что нет физически вращающегося диска или магнитной головки, которую нужно ждать.

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

Твердотельные накопители (solid-state drive — SSD) хранят данные в виде зарядов в ячейках флеш-памяти. SSD исключают механические компоненты магнитных дисков; данные считываются чисто электронными средствами. SSD могут выполнять случайный поиск данных менее чем за 0,1 мс (100 микросекунд). Кроме того, SSD могут масштабировать как скорости передачи данных, так и IOPS, разделяя хранилище на разделы с множеством контроллеров хранения, работающих параллельно. Коммерческие SSD могут поддерживать скорости передачи данных в несколько гигабайт в секунду и десятки тысяч IOPS.

Благодаря этим исключительным характеристикам производительности, SSD революционизировали транзакционные базы данных и стали принятым стандартом для коммерческих развёртываний OLTP-систем. SSD позволяют реляционным базам данных, таким как PostgreSQL, MySQL и SQL Server, обрабатывать тысячи транзакций в секунду.

Однако SSD пока не являются стандартным вариантом для хранения данных аналитики в больших масштабах. Это снова связано с затратами. Коммерческие SSD обычно стоят 20−30 центов (USD) за гигабайт ёмкости, что почти в 10 раз дороже, чем ёмкость магнитного диска. Таким образом, хранение объектов на магнитных дисках стало ведущим вариантом для крупномасштабного хранения данных в озёрах данных и облачных хранилищах данных.

SSD всё ещё играют значительную роль в OLAP-системах. Некоторые OLAP-базы данных используют кэширование SSD для поддержки высокопроизводительных запросов к часто используемым данным. По мере того как OLAP становятся всё более популярными, мы ожидаем, что использование SSD в этих системах будет расти.

Мы часто используем термины «оперативная память» (random access memory — RAM) и «память» как синонимы. Строго говоря, магнитные диски и SSD также служат памятью, которая хранит данные для последующего случайного доступа, но RAM имеет несколько специфических характеристик:
■ Она подключена к CPU и отображается в адресном пространстве CPU. • Она хранит код, который выполняется CPU, и данные, которые этот код непосредственно обрабатывает.
■ Она является летучей, тогда как магнитные диски и SSD являются нелетучими. Хотя они могут иногда выходить из строя и повреждать или терять данные, диски обычно сохраняют данные при отключении питания. RAM теряет данные менее чем за секунду при отключении питания.
■ Она обеспечивает значительно более высокие скорости передачи данных и более быстрое время извлечения, чем SSD. Память DDR5 — последний широко используемый стандарт для RAM — обеспечивает задержку извлечения данных порядка 100 нс, что примерно в 1000 раз быстрее, чем SSD. Типичный CPU может поддерживать пропускную способность 100 ГБ/с к подключённой памяти и миллионы IOPS. (Статистика сильно варьируется в зависимости от количества каналов памяти и других деталей конфигурации.)
■ Она значительно дороже, чем SSD, примерно 10 долларов за ГБ (на момент написания).
■ Она ограничена количеством RAM, подключённой к отдельному CPU и контроллеру памяти. Это добавляет дополнительную сложность и затраты. Серверы с большим объёмом памяти обычно используют множество взаимосвязанных CPU на одной плате, каждая с блоком подключённой RAM.
■ Она всё ещё значительно медленнее, чем кэш CPU, тип памяти, расположенный непосредственно на кристалле CPU или в том же корпусе. Кэш хранит часто и недавно используемые данные для ультрабыстрого извлечения во время обработки. Дизайн CPU включает несколько уровней кэша различного размера и характеристик производительности.

Когда мы говорим о системной памяти, мы почти всегда имеем в виду динамическую RAM, высокоплотную и низкозатратную форму памяти. Динамическая RAM хранит данные в виде зарядов в конденсаторах. Эти конденсаторы текут со временем, поэтому данные должны часто обновляться (считываться и перезаписываться), чтобы предотвратить потерю данных. Аппаратный контроллер памяти обрабатывает эти технические детали; инженерам данных нужно беспокоиться только о характеристиках пропускной способности и задержки извлечения. Другие формы памяти, такие как статическая RAM, используются в специализированных приложениях, таких как кэши CPU.

Текущие CPU практически всегда используют архитектуру фон Неймана, где код и данные хранятся вместе в одном и том же адресном пространстве памяти. Однако CPU обычно также поддерживают возможность отключения выполнения кода на определённых страницах памяти для повышения безопасности. Эта функция напоминает архитектуру Гарварда, которая разделяет код и данные.

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

Почему мы упоминаем сеть и ЦПУ как базовые компоненты для хранения данных?

Всё больше систем хранения данных становятся распределёнными для повышения производительности, долговечности и доступности. Мы специально упомянули, что отдельные магнитные диски обеспечивают относительно низкую производительность передачи данных, но кластер дисков параллелизует операции чтения для значительного масштабирования производительности. Хотя стандарты хранения данных, такие как массивы независимых дисков (RAID), параллелизуют операции на одном сервере, кластеры облачного хранения объектов работают на гораздо большем масштабе, с дисками, распределёнными по сети и даже по нескольким центрам обработки данных и зонам доступности.

Зоны доступности — это стандартная конструкция облака, состоящая из вычислительных сред, с независимыми ресурсами электропитания, воды и другими ресурсами. Мультизональное хранение данных улучшает как доступность, так и долговечность данных.

ЦПУ обрабатывают детали обслуживания запросов, агрегации чтений и распределения записей. Хранение данных становится веб-приложением с API, компонентами серверных служб и балансировкой нагрузки. Производительность сетевых устройств и топология сети являются ключевыми факторами для достижения высокой производительности.

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

Сериализация — это ещё один базовый компонент хранения данных и критический элемент проектирования баз данных. Решения, связанные с сериализацией, будут влиять на то, как хорошо выполняются запросы через сеть, на нагрузку на CPU, задержку запросов и многое другое. Например, проектирование озера данных включает выбор базовой системы хранения (например, Amazon S3) и стандартов сериализации, которые балансируют между совместимостью и производительностью.

Что же такое сериализация? Данные, хранящиеся в системной памяти программным обеспечением, обычно не находятся в формате, подходящем для хранения на диске или передачи по сети. Сериализация — это процесс уплощения и упаковки данных в стандартный формат, который сможет декодировать читатель. Форматы сериализации обеспечивают стандарт обмена данными. Мы можем кодировать данные в строковом формате, таком как XML, JSON или CSV, и передавать их другому пользователю, который затем сможет декодировать их с помощью стандартной библиотеки. Алгоритм сериализации имеет логику для обработки типов, накладывает правила на структуру данных и позволяет обмен между языками программирования и CPU. Алгоритм сериализации также имеет правила для обработки исключений. Например, объекты Python могут содержать циклические ссылки; алгоритм сериализации может выдавать ошибку или ограничивать глубину вложенности при обнаружении цикла.

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

Мы предоставляем более подробный каталог распространённых техник и форматов сериализации данных в Приложении A. Мы рекомендуем инженерам данных ознакомиться с распространёнными практиками и форматами сериализации, особенно с наиболее популярными текущими форматами (например, Apache Parquet), гибридной сериализацией (например, Apache Hudi) и сериализацией в памяти (например, Apache Arrow).

Сжатие — это ещё один критический компонент инженерии хранения данных. На базовом уровне сжатие делает данные меньше, но алгоритмы сжатия взаимодействуют с другими деталями систем хранения данных сложными способами.

Высокоэффективное сжатие имеет три основных преимущества в системах хранения данных. Во-первых, данные становятся меньше и, следовательно, занимают меньше места на диске. Во-вторых, сжатие увеличивает практическую скорость сканирования на диске. При коэффициенте сжатия 10:1 мы переходим от сканирования 200 МБ/с на магнитный диск к эффективной скорости 2 ГБ/с на диск.

Третье преимущество заключается в производительности сети. При условии, что сетевое соединение между экземпляром Amazon EC2 и S3 обеспечивает пропускную способность 10 гигабит в секунду (Гбит/с), коэффициент сжатия 10:1 увеличивает эффективную пропускную способность сети до 100 Гбит/с.
Сжатие также имеет свои недостатки. Сжатие и декомпрессия данных требуют дополнительного времени и ресурсов для чтения или записи данных.

Мы уже упоминали кэширование в нашем обсуждении RAM. Основная идея кэширования заключается в хранении часто или недавно используемых данных в слое с быстрым доступом. Чем быстрее кэш, тем выше его стоимость и тем меньше доступного места для хранения. Менее часто используемые данные хранятся в более дешёвом и медленном хранилище. Кэши критически важны для предоставления, обработки и преобразования данных.

При анализе систем хранения данных полезно рассматривать каждый тип используемого хранения в контексте иерархии кэшей (Таблица 6−1). Большинство практических систем данных полагаются на множество уровней кэша, собранных из хранилищ с различными характеристиками производительности. Это начинается внутри CPU; процессоры могут использовать до четырёх уровней кэша. Мы спускаемся по иерархии к RAM и SSD. Облачное хранилище объектов является более низким уровнем, который поддерживает долговременное хранение и долговечность данных, при этом позволяя предоставлять данные и динамически перемещать их в конвейерах.

Таблица 6−1. Эвристическая иерархия кэш-памяти, отображающая типы хранения с приблизительными ценовыми и производительными характеристиками

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

Этот раздел охватывает основные системы хранения данных, с которыми вы столкнётесь как инженер данных. Системы хранения данных существуют на уровне абстракции выше базовых компонентов. Например, магнитные диски являются базовым компонентом хранения, тогда как основные облачные платформы хранения объектов и HDFS — это системы хранения, которые используют магнитные диски. Существуют ещё более высокие уровни абстракции хранения, такие как озёра данных и lakehouses (о которых мы расскажем в разделе «Абстракции хранения данных в инженерии данных»).

По мере того как схемы хранения и доступа к данным становятся всё более сложными и перестают удовлетворять потребности одного сервера, становится необходимым распределять данные на несколько серверов. Данные могут храниться на нескольких серверах, что называется распределённым хранением. Это распределённая система, цель которой — хранить данные в распределённом виде (Рисунок 6−4).

Распределённое хранение координирует деятельность нескольких серверов для хранения, извлечения и обработки данных быстрее и в большем масштабе, при этом обеспечивая избыточность на случай, если сервер станет недоступным. Распределённое хранение распространено в архитектурах, где требуется встроенная избыточность и масштабируемость для больших объёмов данных. Например, хранилище объектов, Apache Spark и облачные хранилища данных полагаются на архитектуры распределённого хранения.

Инженеры данных всегда должны быть осведомлены о парадигмах согласованности распределённых систем, которые мы рассмотрим далее.

Проблема распределённых систем заключается в том, что данные распределены по нескольким серверам. Как эта система поддерживает согласованность данных? К сожалению, распределённые системы создают дилемму для точности хранения и запросов. Требуется время для репликации изменений по узлам системы; часто существует баланс между получением актуальных данных и получением «почти» актуальных данных в распределённой базе данных. Давайте рассмотрим две распространённые парадигмы согласованности в распределённых системах: согласованность в конечном счёте и строгая согласованность.

Мы рассматривали соответствие ACID на протяжении всей книги, начиная с Главы 5. Другой акроним — BASE, что означает basically available, soft-state, eventual consistency (базовая доступность, мягкое состояние, согласованность в конечном счёте). Представьте это как противоположность ACID. BASE является основой согласованности в конечном счёте. Давайте кратко рассмотрим её компоненты:

Базовая доступность
Согласованность не гарантируется, но операции чтения и записи в базе данных выполняются на основе лучших усилий, что означает, что согласованные данные доступны большую часть времени.

Неопределённое состояние
Состояние транзакции неопределённо, и неясно, завершена ли транзакция или нет.

Согласованность в конечном счёте
В какой-то момент чтение данных вернёт согласованные значения.
Если чтение данных в системе с согласованностью в конечном счёте ненадёжно, зачем её использовать? Согласованность в конечном счёте — это распространённый компромисс в крупномасштабных распределённых системах. Если вы хотите масштабироваться горизонтально (по нескольким узлам) для обработки больших объёмов данных, то согласованность в конечном счёте часто будет той ценой, которую вы заплатите. Согласованность в конечном счёте позволяет быстро извлекать данные без проверки, что у вас есть последняя версия на всех узлах.

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

Обычно инженеры данных принимают решения о согласованности в трёх местах. Во-первых, сама технология базы данных задаёт уровень согласованности. Во-вторых, параметры конфигурации базы данных будут влиять на согласованность. В-третьих, базы данных часто поддерживают некоторую конфигурацию согласованности на уровне отдельного запроса. Например, DynamoDB поддерживает чтения с согласованностью в конечном счёте и строго согласованные чтения. Строго согласованные чтения медленнее и потребляют больше ресурсов, поэтому их лучше использовать экономно, но они доступны, когда требуется согласованность.

Вам следует понимать, как ваша база данных обрабатывает согласованность. Опять же, инженеры данных должны глубоко понимать технологии и использовать их для решения проблем соответствующим образом. Инженеру данных может потребоваться согласовать требования к согласованности с другими техническими и бизнес-заинтересованными сторонами. Обратите внимание, что это как технологическая, так и организационная проблема; убедитесь, что вы собрали требования от ваших заинтересованных сторон и выбрали технологии соответствующим образом.

Мы работаем с файлами каждый день, но понятие файла довольно тонкое. Файл — это объект данных с определёнными характеристиками чтения, записи и ссылок, используемый программным обеспечением и операционными системами. Мы определяем файл как имеющий следующие характеристики:

Конечная длина
Файл представляет собой поток байтов конечной длины.

Операции добавления
Мы можем добавлять байты к файлу до пределов системы хранения хоста.

Случайный доступ
Мы можем читать из любого места в файле или записывать обновления в любое место.

Хранение объектов ведёт себя похоже на файловое хранение, но с ключевыми различиями. Хотя мы начали обсуждение с файлового хранения, хранение объектов, возможно, гораздо важнее для типа инженерии данных, которой вы будете заниматься сегодня. Мы будем часто ссылаться на обсуждение хранения объектов на следующих страницах.

Системы файлового хранения организуют файлы в древовидную структуру каталогов. Ссылка на каталог для файла может выглядеть так:

/Users/matthewhousley/output.txt

Когда эта ссылка на файл передаётся операционной системе, она начинает с корневого каталога /, находит Users, matthewhousley, и, наконец, output.txt. Работая слева направо, каждый каталог содержится внутри родительского каталога, пока мы, наконец, не достигнем файла output.txt. Этот пример использует семантику Unix, но семантика ссылок на файлы в Windows похожа. Файловая система хранит каждый каталог как метаданные о файлах и каталогах, которые он содержит. Эти метаданные состоят из имени каждой сущности, соответствующих деталей разрешений и указателя на саму сущность. Чтобы найти файл на диске, операционная система смотрит на метаданные на каждом уровне иерархии и следует указателю к следующей сущности подкаталога, пока, наконец, не достигнет самого файла.

Обратите внимание, что другие подобные файловым сущности данных обычно не обязательно обладают всеми этими свойствами. Например, объекты в хранилище объектов поддерживают только первую характеристику — конечную длину, но всё равно являются чрезвычайно полезными. Мы обсудим это в разделе «Хранение объектов».

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

Наиболее знакомый тип файлового хранения — это файловая система, управляемая операционной системой на локальном разделе диска SSD или магнитного диска. New Technology File System (NTFS) и ext4 — это популярные файловые системы на Windows и Linux соответственно. Операционная система обрабатывает детали хранения сущностей каталогов, файлов и метаданных. Файловые системы разработаны для записи данных таким образом, чтобы обеспечить лёгкое восстановление в случае потери питания во время записи, хотя любые незаписанные данные всё равно будут потеряны.

Локальные файловые системы обычно поддерживают полную согласованность чтения после записи; чтение сразу после записи вернёт записанные данные. Операционные системы также используют различные стратегии блокировки для управления одновременными попытками записи в файл.

Локальные дисковые файловые системы могут также поддерживать передовые функции, такие как журналирование, снимки, избыточность, расширение файловой системы на несколько дисков, полное шифрование диска и сжатие. В разделе «Блочное хранение» на странице 202 мы также обсуждаем RAID.

Системы сетевого хранилища (NAS) предоставляют файловую систему клиентам через сеть. NAS — это распространённое решение для серверов; они часто поставляются с встроенным специализированным аппаратным интерфейсом NAS. Хотя существуют штрафы за производительность при доступе к файловой системе через сеть, значительные преимущества виртуализации хранения также существуют, включая избыточность и надёжность, точное управление ресурсами, объединение хранилища на нескольких дисках для создания больших виртуальных томов и совместное использование файлов на нескольких машинах. Инженеры должны быть осведомлены о модели согласованности, предоставляемой их решением NAS, особенно когда несколько клиентов могут потенциально получить доступ к одним и тем же данным.

Популярной альтернативой NAS является сеть хранения данных (SAN), но системы SAN предоставляют доступ на уровне блоков без абстракции файловой системы. Мы рассматриваем системы SAN в разделе «Блочное хранение».

Облачные файловые сервисы предоставляют полностью управляемую файловую систему для использования с несколькими облачными виртуальными машинами и приложениями, потенциально включая клиентов вне облачной среды. Облачные файловые системы не следует путать со стандартным хранилищем, прикреплённым к виртуальным машинам, — обычно это блочное хранение с файловой системой, управляемой операционной системой виртуальной машины. Облачные файловые системы ведут себя похоже на решения NAS, но детали сетевого взаимодействия, управления кластерами дисков, сбоев и конфигурации полностью обрабатываются поставщиком облачных услуг.

Например, Amazon Elastic File System (EFS) — это чрезвычайно популярный пример облачного файлового сервиса. Хранилище предоставляется через протокол NFS 4, который также используется системами NAS. EFS обеспечивает автоматическое масштабирование и оплату по объёму хранения без необходимости заранее резервировать хранилище. Сервис также предоставляет локальную согласованность чтения после записи (при чтении с машины, выполнившей запись). Он также предлагает согласованность открытия после закрытия по всей файловой системе. Другими словами, после закрытия файла приложением, последующие читатели увидят изменения, сохранённые в закрытом файле.

Фундаментально, блочное хранилище — это тип сырого хранения, предоставляемого SSD и магнитными дисками. В облаке виртуализированное блочное хранение является стандартом для виртуальных машин (VM). Эти абстракции блочного хранения позволяют точно контролировать размер хранилища, масштабируемость и долговечность данных, превышающие возможности сырых дисков.

В нашем предыдущем обсуждении SSD и магнитных дисков мы упоминали, что с этими устройствами случайного доступа операционная система может искать, читать и записывать любые данные на диске. Блок — это наименьшая адресуемая единица данных, поддерживаемая диском. На старых дисках это часто было 512 байт полезных данных, но теперь это количество увеличилось до 4096 байт для большинства современных дисков, что делает записи менее детализированными, но значительно снижает накладные расходы на управление блоками. Блоки обычно содержат дополнительные биты для обнаружения/исправления ошибок и другие метаданные.

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

Транзакционные базы данных обычно получают доступ к дискам на уровне блоков для оптимальной организации данных. Для строко-ориентированных баз данных это изначально означало, что строки данных записывались как непрерывные потоки; ситуация усложнилась с появлением SSD и связанными с ними улучшениями времени поиска, но транзакционные базы данных всё ещё полагаются на высокую производительность случайного доступа, обеспечиваемую прямым доступом к устройству блочного хранения.
Блочное хранение также остаётся стандартным вариантом для загрузочных дисков операционных систем на облачных виртуальных машинах. Блочное устройство форматируется так же, как и на физическом диске, но хранилище обычно виртуализировано. (См. «Облачное виртуализированное блочное хранение».)

RAID означает избыточный массив независимых дисков (redundant array of independent disks,), как упоминалось ранее. RAID одновременно управляет несколькими дисками для улучшения долговечности данных, повышения производительности и объединения ёмкости нескольких дисков. Массив может отображаться операционной системе как одно блочное устройство. Существует множество схем кодирования и чётности, в зависимости от желаемого баланса между улучшенной эффективной пропускной способностью и более высокой устойчивостью к сбоям (устойчивостью к множеству сбоев дисков).

Системы сети хранения данных (storage area network — SAN) предоставляют виртуализированные блочные устройства хранения через сеть, обычно из пула хранения. Абстракция SAN позволяет точно масштабировать хранилище и улучшать производительность, доступность и долговечность. Вы можете столкнуться с системами SAN, если работаете с локальными системами хранения; вы также можете встретить облачную версию SAN, как в следующем подразделе.

Облачные решения виртуализированного блочного хранилища (cloud virtualized block storage) похожи на SAN, но освобождают инженеров от необходимости работать с кластерами SAN и деталями сети. Рассмотрим Amazon Elastic Block Store (EBS) как стандартный пример; другие публичные облака предлагают аналогичные услуги. EBS является стандартным хранилищем для виртуальных машин Amazon EC2; другие облачные провайдеры также рассматривают виртуализированное объектное хранение как ключевой компонент своих предложений по виртуальным машинам.

EBS предлагает несколько уровней обслуживания с различными характеристиками производительности. Обычно метрики производительности EBS указываются в IOPS и пропускной способности (скорости передачи). Высокопроизводительные уровни хранения EBS поддерживаются SSD-дисками, тогда как хранение на основе магнитных дисков предлагает меньшее количество IOPS, но стоит дешевле за гигабайт.

Тома EBS хранят данные отдельно от сервера хоста экземпляра, но в той же зоне, чтобы обеспечить высокую производительность и низкую задержку (Рисунок 6−5). Это позволяет томам EBS сохраняться, когда экземпляр EC2 выключается, когда сервер хоста выходит из строя или даже когда экземпляр удаляется. Хранение EBS подходит для приложений, таких как базы данных, где долговечность данных является приоритетом. Кроме того, EBS реплицирует все данные по крайней мере на два отдельных хост-машины, защищая данные в случае сбоя диска.

Виртуализация хранения EBS также поддерживает несколько передовых функций. Например, тома EBS позволяют создавать мгновенные снимки состояния на момент времени, пока диск используется. Хотя на репликацию снимка в S3 всё ещё требуется некоторое время, EBS может эффективно заморозить состояние блоков данных в момент создания снимка, позволяя клиентской машине продолжать использовать диск. Кроме того, после первого полного резервного копирования снимки являются дифференциальными; только изменённые блоки записываются в S3, чтобы минимизировать затраты на хранение и время резервного копирования.

Тома EBS также высоко масштабируемы. На момент написания этого текста некоторые классы томов EBS могут масштабироваться до 64 ТиБ, 256,000 IOPS и 4,000 МиБ/с.

Облачные провайдеры также предлагают блочные тома хранения, которые физически подключены к серверу хоста, на котором работает виртуальная машина. Эти тома хранения обычно имеют очень низкую стоимость (включены в стоимость виртуальной машины в случае с Amazon EC2 Instance Store) и обеспечивают низкую задержку и высокую производительность IOPS.

Тома Instance Store (Рисунок 6−6) ведут себя практически как диск, физически подключённый к серверу в дата-центре. Одно ключевое отличие заключается в том, что при выключении или удалении виртуальной машины содержимое локально подключённого диска теряется, независимо от того, было ли это событие вызвано намеренным действием пользователя или нет. Это гарантирует, что новая виртуальная машина не сможет читать содержимое диска, принадлежащее другому клиенту.

Локально подключённые диски не поддерживают ни одну из передовых функций виртуализации, предлагаемых виртуализированными службами хранения, такими как EBS. Локально подключённый диск не реплицируется, поэтому физический сбой диска может привести к потере или повреждению данных, даже если виртуальная машина хоста продолжает работать. Кроме того, локально подключённые тома не поддерживают снимки или другие функции резервного копирования.

Несмотря на эти ограничения, локально подключённые диски чрезвычайно полезны. В многих случаях мы используем диски в качестве локального кэша и, следовательно, не нуждаемся во всех передовых функциях виртуализации, таких как EBS. Например, предположим, что мы запускаем AWS EMR на экземплярах EC2. Мы можем выполнять временную задачу, которая потребляет данные из S3, временно хранит их в распределённой файловой системе, работающей на экземплярах, обрабатывает данные и записывает результаты обратно в S3. Файловая система EMR включает репликацию и избыточность и служит кэшем, а не постоянным хранилищем. В этом случае хранилище экземпляров EC2 является вполне подходящим решением и может повысить производительность, так как данные могут быть прочитаны и обработаны локально без передачи по сети (см. Рисунок 6−7).

Мы рекомендуем инженерам рассматривать локально подключённое хранилище в худших сценариях. Каковы последствия сбоя локального диска? Непреднамеренного выключения виртуальной машины или кластера? Зонального или регионального сбоя облака? Если ни один из этих сценариев не приведёт к катастрофическим последствиям при потере данных на локально подключённых томах, локальное хранилище может быть экономически эффективным и производительным вариантом. Кроме того, простые стратегии минимизации рисков (периодическое резервное копирование контрольных точек в S3) могут предотвратить потерю данных.

Объектное хранилище (object storage) содержит объекты всех форм и размеров (Рисунок 6−8). Термин «объектное хранилище» несколько сбивает с толку, потому что слово «объект» имеет несколько значений в компьютерной науке. В данном контексте мы говорим о специализированной конструкции, похожей на файл. Это может быть любой тип файла — TXT, CSV, JSON, изображения, видео или аудио.

Объектные хранилища приобрели значимость и популярность с ростом больших данных и облачных технологий. Amazon S3, Azure Blob Storage и Google Cloud Storage (GCS) являются широко используемыми объектными хранилищами. Кроме того, многие облачные хранилища данных (и растущее число баз данных) используют объектное хранилище как свой уровень хранения, а облачные озёра данных, как правило, базируются на объектных хранилищах.

Хотя многие локальные системы объектного хранения могут быть установлены на кластерах серверов, мы сосредоточимся в основном на полностью управляемых облачных объектных хранилищах. С операционной точки зрения, одной из самых привлекательных характеристик облачного объектного хранилища является простота управления и использования. Объектное хранилище, пожалуй, стало одной из первых «бессерверных» услуг; инженерам не нужно учитывать характеристики underlying серверных кластеров или дисков.

Объектное хранилище — это хранилище ключ-значение для неизменяемых объектов данных. Мы теряем большую часть гибкости записи, которую ожидаем от файлового хранилища на локальном диске, при использовании объектного хранилища. Объекты не поддерживают случайные записи или операции добавления; вместо этого они записываются один раз как поток байтов. После этой первоначальной записи объекты становятся неизменяемыми. Чтобы изменить данные в объекте или добавить данные к нему, необходимо перезаписать весь объект. Объектные хранилища обычно поддерживают случайное чтение через запросы диапазонов, но такие операции могут выполняться значительно медленнее, чем случайное чтение данных, хранящихся на SSD.

Для разработчика программного обеспечения, привыкшего использовать локальное файловое хранилище с произвольным доступом, характеристики объектов могут показаться ограничениями, но «меньше — значит больше»: объектные хранилища не нуждаются в поддержке блокировок или синхронизации изменений, что позволяет хранить данные на огромных кластерах дисков. Объектные хранилища поддерживают высокопроизводительные параллельные потоки записи и чтения на множестве дисков, и эта параллельность скрыта от инженеров, которые могут просто работать с потоком, не взаимодействуя с отдельными дисками. В облачной среде скорость записи масштабируется с увеличением количества потоков записи вплоть до квот, установленных поставщиком. Пропускная способность чтения может масштабироваться с увеличением количества параллельных запросов, количества виртуальных машин, используемых для чтения данных, и количества ядер процессора. Эти характеристики делают объектное хранилище идеальным для обслуживания высоконагруженного веб-трафика или доставки данных в высокопараллельные распределённые системы запросов.

Типичные облачные объектные хранилища сохраняют данные в нескольких зонах доступности, что значительно снижает вероятность полного отключения хранилища или потери данных невосстановимым образом. Эта долговечность и доступность встроены в стоимость; поставщики облачных хранилищ предлагают другие классы хранения по сниженным ценам в обмен на уменьшенную долговечность или доступность. Мы обсудим это в разделе «Классы и уровни хранения».

Облачное объектное хранилище является ключевым элементом в разделении вычислений и хранения, позволяя инженерам обрабатывать данные с использованием временных кластеров и масштабировать эти кластеры вверх и вниз по требованию. Это ключевой фактор, делающий большие данные доступными для небольших организаций, которые не могут позволить себе собственное оборудование для задач, которые они будут выполнять лишь изредка. Некоторые крупные технологические компании продолжат использовать постоянные кластеры Hadoop на своём оборудовании. Тем не менее, общая тенденция такова, что большинство организаций переведут обработку данных в облако, используя объектное хранилище как основной уровень хранения и обслуживания, а данные будут обрабатываться на временных кластерах.

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

С точки зрения инженерии данных, объектные хранилища обеспечивают отличную производительность для крупных пакетных операций чтения и записи. Это хорошо соответствует задачам массивных OLAP-систем. Существует мнение в среде специалистов по инженерии данных, что объектные хранилища не подходят для операций обновления, но это лишь частично верно. Объектные хранилища действительно плохо подходят для транзакционных нагрузок с множеством мелких обновлений каждую секунду; такие сценарии лучше обслуживаются транзакционными базами данных или системами блочного хранения. Однако объектные хранилища хорошо справляются с низкой частотой операций обновления, когда каждая операция затрагивает большой объём данных.

Объектные хранилища стали золотым стандартом хранения для озёр данных. В ранние дни озёр данных стандартом операционной работы был принцип «запись один раз, чтение много раз» (WORM, Write Once, Read Many), но это было связано скорее со сложностями управления версиями данных и файлов, чем с ограничениями HDFS и объектных хранилищ. С тех пор появились такие системы, как Apache Hudi и Delta Lake, которые помогают управлять этой сложностью, а также регуляции вроде GDPR и CCPA, сделавшие возможности удаления и обновления данных обязательными. Управление обновлениями в объектных хранилищах является центральной идеей концепции озера-хранилища данных (data lakehouse), которую мы представили в Главе 3.

Объектное хранилище — это идеальное хранилище для неструктурированных данных в любом формате, помимо приложений для структурированных данных. Объектное хранилище может содержать любые бинарные данные без ограничений на тип или структуру и часто играет важную роль в ML-пайплайнах для работы с сырым текстом, изображениями, видео и аудио.

Как мы уже упоминали, объектные хранилища являются хранилищами ключ-значение. Что это значит для инженеров? Крайне важно понимать, что, в отличие от файловых хранилищ, объектные хранилища не используют древовидную структуру каталогов для поиска объектов. Объектное хранилище использует логический контейнер верхнего уровня (например, bucket в S3 и GCS) и ссылается на объекты по ключу. Простой пример в S3 может выглядеть так:

В данном случае S3://oreilly-data-engineering-book/ — это имя бакета (bucket), а data-example.json — ключ, указывающий на конкретный объект. Имена бакетов в S3 должны быть уникальными во всей экосистеме AWS. Ключи уникальны в пределах одного бакета. Хотя облачные объектные хранилища могут создавать видимость поддержки семантики древовидной структуры каталогов, на самом деле никакой истинной иерархии каталогов не существует. Мы можем сохранить объект с полным путём, например:

На первый взгляд, это выглядит как подкаталоги, которые можно найти в обычной файловой системе: project-data, 11, 23 и 2021. Многие облачные интерфейсы позволяют пользователям просматривать объекты внутри «каталога», а облачные инструменты командной строки часто поддерживают Unix-подобные команды, такие как ls, для работы с «каталогами» в объектном хранилище. Однако за кулисами объектная система не проходит по древовидной структуре каталогов для доступа к объекту. Вместо этого она просто видит ключ (project-data/11/23/2021/data.txt), который случайно совпадает с семантикой каталогов. Это может показаться незначительной технической деталью, но инженерам важно понимать, что определённые операции на уровне «каталогов» могут быть дорогостоящими в объектном хранилище. Например, при выполнении команды aws ls S3://oreilly-data-engineering-book/project-data/11/ объектное хранилище должно отфильтровать ключи по префиксу project-data/11/. Если бакет содержит миллионы объектов, эта операция может занять некоторое время, даже если в «подкаталоге» находится всего несколько объектов.

Как уже упоминалось, объектные хранилища, как правило, не поддерживают обновления на месте или добавления данных. Чтобы обновить объект, мы записываем новый объект под тем же ключом. Когда специалисты по инженерии данных используют обновления в своих процессах, они должны учитывать модель согласованности (consistency model) объектного хранилища, с которым работают. Объектные хранилища могут быть либо согласованными в конечном счёте (eventually consistent), либо строго согласованными (strongly consistent). Например, до недавнего времени S3 был согласованным в конечном счёте: после записи новой версии объекта под тем же ключом хранилище могло иногда возвращать старую версию объекта. Часть «в конечном счёте» в термине «согласованность в конечном счёте» означает, что через некоторое время кластер хранения достигает состояния, при котором возвращается только последняя версия объекта. Это отличается от модели строгой согласованности, которую мы ожидаем от локальных дисков, подключённых к серверу: чтение после записи всегда возвращает самые свежие данные.

В некоторых случаях может быть желательно обеспечить строгую согласованность для объектного хранилища, и для этого используются стандартные методы. Один из подходов — добавить строго согласованную базу данных (например, PostgreSQL) в систему. Теперь запись объекта становится двухэтапным процессом:

1. Записать объект.
2. Записать возвращённые метаданные для версии объекта в строго согласованную базу данных.

Метаданные версии (например, хэш объекта или временная метка) могут однозначно идентифицировать версию объекта в сочетании с ключом объекта. Чтобы прочитать объект, читатель выполняет следующие шаги:

1. Получить последние метаданные объекта из строго согласованной базы данных.
2. Запросить метаданные объекта с использованием ключа объекта. Прочитать данные объекта, если они совпадают с метаданными, полученными из согласованной базы данных.
3. Если метаданные объекта не совпадают, повторить шаг 2, пока не будет возвращена последняя версия объекта.

Практическая реализация имеет исключения и крайние случаи, которые нужно учитывать, например, когда объект перезаписывается в процессе выполнения запроса. Эти шаги могут быть скрыты за API, чтобы читатель объекта воспринимал объектное хранилище как строго согласованное, хотя это увеличивает задержку доступа к объекту.

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

Если включено управление версиями объектов, мы добавляем дополнительные метаданные, указывающие версию объекта. Хотя ссылка по умолчанию обновляется, чтобы указывать на новый объект, мы сохраняем указатели на предыдущие версии. Мы также ведём список версий, чтобы клиенты могли получить список всех версий объекта и выбрать конкретную версию для чтения. Поскольку старые версии объекта всё ещё имеют ссылки, они не удаляются сборщиком мусора.

Если мы ссылаемся на объект с указанием версии, проблема согласованности в некоторых системах объектного хранения исчезает: ключ и метаданные версии вместе образуют уникальную ссылку на конкретный неизменяемый объект данных. При использовании этой пары мы всегда получим один и тот же объект, при условии что он не был удалён. Проблема согласованности всё ещё существует, когда клиент запрашивает «версию по умолчанию» или «последнюю версию» объекта.

Основной издержкой, которую инженерам необходимо учитывать при использовании управления версиями объектов, является стоимость хранения. Исторические версии объектов обычно имеют те же затраты на хранение, что и текущие версии. Стоимость хранения версий объектов может быть как незначительной, так и катастрофически высокой, в зависимости от различных факторов. Размер данных и частота обновлений играют важную роль: большее количество версий объектов может привести к значительному увеличению объёма данных.

Важно помнить, что речь идёт о «грубой» реализации управления версиями объектов. Системы объектного хранения обычно хранят полные данные объекта для каждой версии, а не дифференциальные снимки.

Инженеры также могут использовать политики жизненного цикла хранения (storage lifecycle policies). Эти политики позволяют автоматически удалять старые версии объектов при выполнении определённых условий (например, когда версия объекта достигает определённого возраста или существует много более новых версий). Облачные провайдеры также предлагают различные уровни архивного хранения по значительно сниженным ценам, и процесс архивирования можно управлять с помощью политик жизненного цикла.

Поставщики облачных услуг теперь предлагают классы хранения, которые снижают стоимость хранения данных в обмен на ограниченный доступ или сниженную долговечность. Мы используем термин «ограниченный доступ» здесь, потому что многие из этих уровней хранения всё ещё делают данные высокодоступными, но с высокими затратами на извлечение в обмен на снижение затрат на хранение.

Рассмотрим несколько примеров в S3, так как Amazon является эталоном для стандартов облачных сервисов. Класс хранения S3 Standard-Infrequent Access снижает ежемесячные затраты на хранение в обмен на увеличение затрат на извлечение данных. (См. «Краткий экскурс в экономику облачных хранилищ» на странице 125 для теоретического обсуждения экономики уровней облачного хранения.) Amazon также предлагает уровень Amazon S3 One Zone-Infrequent Access, который реплицирует данные только в одну зону. Прогнозируемая доступность снижается с 99,9% до 99,5%, чтобы учесть возможность отказа зоны. Amazon всё ещё заявляет о чрезвычайно высокой долговечности данных, с оговоркой, что данные будут потеряны, если зона доступности будет уничтожена.

Ниже по уровням ограниченного доступа находятся архивные уровни в S3 Glacier. S3 Glacier обещает значительное снижение долгосрочных затрат на хранение за счёт значительно более высоких затрат на доступ. Пользователи имеют различные варианты скорости извлечения, от минут до часов, с более высокими затратами на извлечение для более быстрого доступа. Например, на момент написания, S3 Glacier Deep Archive снижает затраты на хранение ещё больше; Amazon рекламирует, что затраты на хранение начинаются с $ 1 за терабайт в месяц. Взамен восстановление данных занимает 12 часов. Кроме того, этот класс хранения предназначен для данных, которые будут храниться 7−10 лет и к которым будут обращаться только один-два раза в год.

Будьте внимательны к тому, как вы планируете использовать архивное хранение, так как легко попасть в него, но часто дорого обращаться к данным, особенно если они нужны чаще, чем ожидалось. См. Главу 4 для более подробного обсуждения экономики архивного хранения.

Решения для синхронизации хранилищ объектов стали всё более популярными. Инструменты, такие как s3fs и Amazon S3 File Gateway, позволяют пользователям монтировать бакет S3 как локальное хранилище. Пользователи этих инструментов должны быть осведомлены о характеристиках записи в файловую систему и о том, как они будут взаимодействовать с характеристиками и ценообразованием хранилища объектов. Например, File Gateway довольно эффективно обрабатывает изменения в файлах, объединяя части объектов в новый объект с использованием передовых возможностей S3. Однако высокоскоростная транзакционная запись перегрузит возможности обновления хранилища объектов. Монтирование хранилища объектов как локальной файловой системы хорошо работает для файлов, которые обновляются редко.

Как обсуждалось в разделе «Основные компоненты хранения данных», оперативная память (RAM) обеспечивает отличную задержку и скорость передачи данных. Однако традиционная RAM чрезвычайно уязвима к потере данных, так как даже секундное отключение питания может стереть данные. Системы хранения на основе RAM обычно ориентированы на кэширующие приложения, предоставляя данные для быстрого доступа и высокой пропускной способности. Для целей сохранения данных их следует записывать на более долговечный носитель.

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

Memcached — это хранилище ключ-значение, предназначенное для кэширования результатов запросов к базе данных, ответов на вызовы API и других данных. Memcached использует простые структуры данных, поддерживая либо строковые, либо целочисленные типы данных. Memcached может обеспечивать результаты с очень низкой задержкой, одновременно снижая нагрузку на бэкенд-системы.

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

В недавнем прошлом «Hadoop» был практически синонимом «больших данных». Hadoop Distributed File System (HDFS) основан на Google File System (GFS) и изначально был разработан для обработки данных с использованием модели программирования MapReduce. Hadoop похож на хранилище объектов, но с ключевым отличием: Hadoop объединяет вычисления и хранение на одних и тех же узлах, тогда как хранилища объектов обычно имеют ограниченную поддержку внутренней обработки.

Hadoop разбивает большие файлы на блоки — фрагменты данных размером менее нескольких сотен мегабайт. Файловая система управляется NameNode, который поддерживает каталоги, метаданные файлов и детализированный каталог, описывающий расположение блоков файлов в кластере. В типичной конфигурации каждый блок данных реплицируется на три узла. Это увеличивает как долговечность, так и доступность данных. Если диск или узел выходит из строя, коэффициент репликации для некоторых блоков файлов упадёт ниже 3. NameNode поручит другим узлам реплицировать эти блоки файлов, чтобы они снова достигли правильного коэффициента репликации. Таким образом, вероятность потери данных очень низкая, за исключением коррелированного сбоя (например, падения астероида на дата-центр).

Hadoop — это не просто система хранения. Hadoop объединяет вычислительные ресурсы с узлами хранения, чтобы позволить обработку данных на месте. Это изначально было достигнуто с использованием модели программирования MapReduce, которую мы обсуждаем в главе 8.

Часто можно услышать утверждения, что Hadoop мёртв. Это верно лишь отчасти. Hadoop больше не является горячей, передовой технологией. Многие инструменты экосистемы Hadoop, такие как Apache Pig, теперь находятся на поддержке жизни и в основном используются для выполнения устаревших задач. Чистая модель программирования MapReduce ушла в сторону. HDFS, однако, остаётся широко используемой в различных приложениях и организациях.

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

Кроме того, HDFS является ключевым компонентом многих современных движков больших данных, таких как Amazon EMR. На самом деле, Apache Spark часто запускается на кластерах HDFS. Мы обсудим это более подробно в разделе «Разделение вычислений и хранения».

Потоковая передача данных имеет другие требования к хранению, чем непотоковые данные. В случае очередей сообщений хранимые данные являются временными и ожидается, что они исчезнут через определённое время. Однако распределённые масштабируемые фреймворки для потоковой передачи данных, такие как Apache Kafka, теперь позволяют хранить потоковые данные в течение очень долгого времени. Kafka поддерживает неограниченное хранение данных, перемещая старые, редко используемые сообщения в хранилище объектов. Конкуренты Kafka (включая Amazon Kinesis, Apache Pulsar и Google Cloud Pub/Sub) также поддерживают длительное хранение данных.

Тесно связано с хранением данных в этих системах понятие повторного воспроизведения. Повторное воспроизведение позволяет потоковой системе возвращать диапазон исторических хранимых данных. Повторное воспроизведение является стандартным механизмом извлечения данных для систем хранения потоковых данных. Повторное воспроизведение может использоваться для выполнения пакетных запросов за определённый период времени или для повторной обработки данных в потоковом конвейере. Глава 7 более подробно рассматривает повторное воспроизведение.

Другие движки хранения также появились для приложений реального времени. В каком-то смысле транзакционные базы данных возникли как первые движки запросов в реальном времени; данные становятся видимыми для запросов сразу после записи. Однако эти базы данных имеют известные ограничения масштабируемости и блокировок, особенно для аналитических запросов, выполняемых на больших объёмах данных. Хотя масштабируемые версии строково-ориентированных транзакционных баз данных преодолели некоторые из этих ограничений, они всё ещё не полностью оптимизированы для аналитики в масштабе.

Индексы предоставляют карту таблицы для определённых полей и позволяют очень быстро находить отдельные записи. Без индексов база данных должна была бы сканировать всю таблицу, чтобы найти записи, удовлетворяющие условию WHERE.

В большинстве реляционных систем управления базами данных (РСУБД) индексы используются для первичных ключей таблиц (позволяя уникально идентифицировать строки) и внешних ключей (позволяя выполнять соединения с другими таблицами). Индексы также могут применяться к другим столбцам для удовлетворения потребностей конкретных приложений. С использованием индексов РСУБД может выполнять поиск и обновление тысяч строк в секунду.

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

Ранние хранилища данных обычно строились на основе тех же типов реляционных систем управления базами данных (РСУБД), которые использовались для транзакционных приложений. Рост популярности систем с массово-параллельной обработкой (MPP) означал переход к параллельной обработке для значительного улучшения производительности сканирования больших объёмов данных для аналитических целей. Однако эти строково-ориентированные MPP всё ещё использовали индексы для поддержки соединений и проверки условий.

В разделе «Основные компоненты хранения данных» мы обсуждаем колончатую сериализацию. Колончатая сериализация позволяет базе данных сканировать только те столбцы, которые необходимы для конкретного запроса, иногда значительно сокращая объём данных, считываемых с диска. Кроме того, организация данных по столбцам упаковывает похожие значения рядом друг с другом, обеспечивая высокие коэффициенты сжатия с минимальными накладными расходами на сжатие. Это позволяет данным быстрее сканироваться с диска и передаваться по сети.

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

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

Хотя колончатые базы данных обеспечивают высокую скорость сканирования, всё ещё полезно минимизировать объём сканируемых данных. Помимо сканирования только данных в столбцах, relevant to a query, мы можем разбить таблицу на несколько подтаблиц, разделив её по полю. В аналитических и научных о данных случаях использования очень распространено сканирование по временному диапазону, поэтому разбиение по дате и времени является чрезвычайно распространённым. Колончатые базы данных обычно поддерживают различные другие схемы разбиения.

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

Мы упоминаем микроразбиение (micro-partitioning) Snowflake, потому что это хороший пример недавних разработок и эволюции подходов к колоночному хранению данных. Микроразбиения — это наборы строк размером от 50 до 500 мегабайт в несжатом виде. Snowflake использует алгоритмический подход, который пытается группировать схожие строки вместе. Это отличается от традиционного подхода, где разбиение выполняется по одному заданному полю, например, дате. Snowflake специально ищет значения, которые повторяются в поле во многих строках. Это позволяет агрессивно сокращать объём данных, обрабатываемых запросами, на основе предикатов. Например, условие WHERE может выглядеть так:

В таком запросе Snowflake исключает любые микроразбиения, которые не содержат указанную дату, эффективно отсекая эти данные. Snowflake также позволяет создавать перекрывающиеся микроразбиения, потенциально разбивая данные по нескольким полям, которые содержат значительные повторы значений.

Эффективное отсечение данных обеспечивается за счёт метабазы данных Snowflake, которая хранит описание каждого микроразбиения, включая количество строк и диапазоны значений для полей. На каждом этапе запроса Snowflake анализирует микроразбиения, чтобы определить, какие из них нужно сканировать. Snowflake использует термин гибридное колоночное хранение, частично указывая на то, что таблицы разбиваются на небольшие группы строк, хотя хранение данных в основе своей остаётся колоночным. Метабаза данных выполняет роль, аналогичную индексу в традиционной реляционной базе данных.

Абстракции хранения данных в инженерии данных представляют собой организацию данных и шаблоны запросов, которые лежат в основе жизненного цикла инженерии данных и строятся поверх систем хранения данных, обсуждавшихся ранее (см. Рисунок 6−3). Мы ввели многие из этих абстракций в главе 3 и вернёмся к ним здесь.

Основные типы абстракций, которые нас интересуют, поддерживают случаи использования в области науки о данных, аналитики и отчётности. К ним относятся хранилища данных, озёра данных, озёрные дома данных, платформы данных и каталоги данных. Мы не будем рассматривать исходные системы, так как они обсуждаются в главе 5.

Абстракция хранения, которая вам необходима как инженеру данных, сводится к нескольким ключевым соображениям:

Цель и сценарий использования
Сначала нужно определить цель хранения данных. Для чего они используются?

Шаблоны обновления
Оптимизирована ли абстракция для массовых обновлений, потоковых вставок или операций upsert (обновление или вставка)?

Затраты
Каковы прямые и косвенные финансовые затраты? Время до получения ценности? Альтернативные издержки?

Разделение хранения и вычислений
Тенденция идёт к разделению хранения и вычислений, но большинство систем гибридизируют разделение и совместное размещение. Мы рассматриваем это в разделе «Разделение вычислений и хранения», так как это влияет на цель, скорость и затраты.

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

Хранилища данных являются стандартной архитектурой OLAP. Как обсуждалось в главе 3, термин «хранилище данных» относится к технологическим платформам (например, Google BigQuery и Teradata), архитектуре централизации данных и организационной модели внутри компании. В плане тенденций хранения данных мы эволюционировали от построения хранилищ данных на основе традиционных транзакционных баз данных, строково-ориентированных MPP-систем (например, Teradata и IBM Netezza) и колончатых MPP-систем (например, Vertica и Teradata Columnar) к облачным хранилищам данных и платформам данных. (См. наше обсуждение хранилищ данных в главе 3 для более подробной информации о MPP-системах.)

На практике облачные хранилища данных часто используются для организации данных в озеро данных — область хранения для огромных объёмов необработанных сырых данных, как это было изначально задумано Джеймсом Диксоном. Облачные хранилища данных могут обрабатывать огромные объёмы текста и сложных JSON-документов. Ограничение заключается в том, что облачные хранилища данных не могут обрабатывать действительно неструктурированные данные, такие как изображения, видео или аудио, в отличие от настоящего озера данных. Облачные хранилища данных могут быть интегрированы с хранилищем объектов для предоставления полного решения для озера данных.

Озеро данных изначально задумывалось как массивное хранилище, где данные сохранялись в сыром, необработанном виде. Первоначально озёра данных строились в основном на системах Hadoop, где дешёвое хранение позволяло сохранять огромные объёмы данных без затрат на использование проприетарных MPP-систем.

За последние пять лет произошли два крупных изменения в эволюции хранения данных в озёрах. Во-первых, произошла значительная миграция к разделению вычислений и хранения. На практике это означало переход от Hadoop к облачному хранилищу объектов для долговременного хранения данных. Во-вторых, инженеры данных обнаружили, что многие функции, предлагаемые MPP-системами (управление схемами; возможности обновления, слияния и удаления), которые первоначально были отвергнуты в стремлении к озёрам данных, на самом деле очень полезны. Это привело к появлению концепции озеро-хранилище данных (data lakehouse).

Озеро-хранилище данных (data lakehouse) — это архитектура, которая объединяет аспекты хранилища данных и озера данных. Как правило, озеро-хранилище данных хранит данные в объектном хранилище, как и озеро данных. Однако озеро-хранилище данных добавляет к этой схеме функции, предназначенные для упрощения управления данными и создания инженерного опыта, подобного хранилищу данных. Это означает поддержку надёжных таблиц и схем, а также функции для управления инкрементальными обновлениями и удалениями. Озеро-хранилища данных обычно также поддерживают историю таблиц и откат; это достигается за счёт сохранения старых версий файлов и метаданных.

Система озера-хранилища данных представляет собой слой управления метаданными и файлами, развёрнутый с инструментами управления данными и трансформации. Databricks активно продвигает концепцию озеро-хранилища данных с Delta Lake, системой управления хранением с открытым исходным кодом.

Мы не можем не отметить, что архитектура озеро-хранилища данных похожа на архитектуру, используемую различными коммерческими платформами данных, включая BigQuery и Snowflake. Эти системы хранят данные в объектном хранилище и предоставляют автоматическое управление метаданными, историю таблиц и возможности обновления/удаления. Сложности управления базовыми файлами и хранением полностью скрыты от пользователя.

Ключевое преимущество озеро-хранилища данных перед проприетарными инструментами — это интероперабельность. Гораздо легче обмениваться данными между инструментами, когда они хранятся в открытом формате файлов. Ресериализация данных из проприетарного формата базы данных влечёт за собой накладные расходы на обработку, время и затраты. В архитектуре озеро-хранилища данных различные инструменты могут подключаться к слою метаданных и читать данные непосредственно из объектного хранилища.

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

Технология озера-хранилища данных быстро развивается. Появилось множество новых конкурентов Delta Lake, включая Apache Hudi и Apache Iceberg.

Всё чаще поставщики позиционируют свои продукты как платформы данных. Эти поставщики создали экосистемы взаимодействующих инструментов с тесной интеграцией в основной слой хранения данных. При оценке платформ инженеры должны убедиться, что предлагаемые инструменты соответствуют их потребностям. Инструменты, не предоставляемые непосредственно на платформе, всё равно могут взаимодействовать, но с дополнительными накладными расходами на обмен данными. Платформы также подчёркивают тесную интеграцию с объектным хранилищем для неструктурированных случаев использования, как упоминалось в нашем обсуждении облачных хранилищ данных.

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

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

Некоторые из этих потребителей могут быть системами обработки в реальном времени, которые генерируют статистику по потоку. Кроме того, потребитель пакетного хранения записывает данные для долговременного хранения и пакетных запросов. Потребителем пакетного хранения может быть AWS Kinesis Firehose, который может генерировать объекты S3 на основе настраиваемых триггеров (например, времени и размера пакета). Системы, такие как BigQuery, загружают потоковые данные в буфер потоковой передачи. Этот буфер потоковой передачи автоматически ресериализуется в колончатое объектное хранилище. Движок запросов поддерживает бесшовное запрашивание как буфера потоковой передачи, так и объектных данных, чтобы предоставить пользователям актуальное, почти реальное представление таблицы.

В этом разделе мы обсудим несколько ключевых идей в области хранения данных — основные аспекты, которые следует учитывать при разработке вашей архитектуры хранения. Многие из этих аспектов являются частью более крупных тенденций. Например, каталоги данных вписываются в тенденцию к «корпоративной» инженерии данных и управлению данными. Разделение вычислений и хранения данных в настоящее время в значительной степени реализовано в облачных системах данных. И обмен данными становится всё более важным аспектом, поскольку бизнес внедряет технологии данных.

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

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

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

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

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

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

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

Обмен данными позволяет организациям и отдельным лицам делиться определёнными данными и тщательно определёнными разрешениями с конкретными субъектами. Обмен данными позволяет специалистам по данным делиться данными из песочницы с их коллегами внутри организации. Между организациями обмен данными облегчает сотрудничество между партнёрскими компаниями. Например, компания, занимающаяся рекламными технологиями, может делиться рекламными данными со своими клиентами.

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

Обмен данными является ключевой функцией многих облачных платформ данных. См. главу 5 для более подробного обсуждения обмена данными.

Какой ожидается формат данных? Какой формат файла? Данные структурированные, полуструктурированные или неструктурированные? Какие типы данных ожидаются? Как данные вписываются в более крупную иерархию? Связаны ли они с другими данными через общие ключи или другие отношения?

Обратите внимание, что схема не обязательно должна быть реляционной. Данные становятся более полезными, когда у нас есть как можно больше информации о их структуре и организации. Для изображений, хранящихся в озере данных, эта информация о схеме может объяснять формат изображения, разрешение и то, как изображения вписываются в более крупную иерархию.
Схема может функционировать как своего рода Розеттский камень, инструкции, которые говорят нам, как читать данные. Существуют два основных шаблона схемы: схема при записи и схема при чтении. Схема при записи — это, по сути, традиционный шаблон хранилища данных: у таблицы есть интегрированная схема; любые записи в таблицу должны соответствовать ей. Для поддержки схемы при записи озеро данных должно интегрировать метахранилище схемы.

Со схемой при чтении схема создаётся динамически при записи данных, и читатель должен определить схему при чтении данных. Идеально, схема при чтении реализуется с использованием форматов файлов, которые включают встроенную информацию о схеме, таких как Parquet или JSON. Файлы CSV известны своей непоследовательностью схемы и не рекомендуются в этом контексте.

Основное преимущество схемы при записи заключается в том, что она обеспечивает соблюдение стандартов данных, делая данные более легкими для использования и потребления в будущем. Схема при чтении подчеркивает гибкость, позволяя записывать практически любые данные. Однако это влечёт за собой большую сложность потребления данных в будущем.

Ключевая идея, к которой мы возвращаемся на протяжении всей книги, — это разделение вычислений и хранения. Это стало стандартным шаблоном доступа к данным и запросов в современную облачную эру. Озёра данных, как мы обсуждали, хранят данные в объектных хранилищах и запускают временные вычислительные мощности для их чтения и обработки. Большинство полностью управляемых OLAP-продуктов теперь полагаются на объектное хранилище в фоновом режиме. Чтобы понять мотивы для разделения вычислений и хранения, сначала рассмотрим совмещение вычислений и хранения.

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

Та же основная идея применяется к аналитическим системам запросов, работающим на кластере машин. Например, с HDFS и MapReduce стандартный подход заключается в размещении блоков данных, которые нужно сканировать в кластере, а затем отправке отдельных задач map к этим блокам. Сканирование и обработка данных для этапа map строго локальны. Этап reduce включает перемешивание данных по кластеру, но сохранение локальности этапов map эффективно сохраняет больше пропускной способности для перемешивания, обеспечивая лучшую общую производительность; этапы map, которые сильно фильтруют, также значительно уменьшают объём данных для перемешивания.

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

Временность и масштабируемость. В облаке мы наблюдаем значительный сдвиг к временности. В общем, дешевле купить и разместить сервер, чем арендовать его у облачного провайдера, при условии, что вы используете его 24 часа в сутки непрерывно в течение многих лет. На практике нагрузка сильно варьируется, и значительные эффективности достигаются с моделью «плати по мере использования», если серверы могут масштабироваться вверх и вниз. Это верно для веб-серверов в онлайн-ритейле, и это также верно для больших пакетных задач, которые могут выполняться только периодически.
Временные вычислительные ресурсы позволяют инженерам запускать массивные кластеры для выполнения задач в срок, а затем удалять кластеры после завершения этих задач. Преимущества производительности от временной работы на ультравысоком уровне могут перевесить ограничения пропускной способности объектного хранилища.

Долговечность и доступность данных. Облачные объектные хранилища значительно снижают риск потери данных и обычно обеспечивают чрезвычайно высокую доступность. Например, S3 хранит данные в нескольких зонах; если стихийное бедствие уничтожит одну зону, данные всё равно будут доступны из оставшихся зон. Наличие нескольких зон также снижает вероятность отказа данных. Если ресурсы в одной зоне выходят из строя, инженеры могут запустить те же ресурсы в другой зоне.

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

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

С многоуровневым кэшированием мы используем объектное хранилище для долговременного хранения и доступа к данным, но запускаем локальное хранилище для использования во время запросов и на различных этапах конвейеров данных. И Google, и Amazon предлагают версии гибридного объектного хранилища (объектное хранилище, тесно интегрированное с вычислениями).

Рассмотрим примеры того, как некоторые популярные движки обработки гибридизируют разделение и совмещение хранения и вычислений.
Пример: AWS EMR с S3 и HDFS. Сервисы больших данных, такие как Amazon EMR, запускают временные кластеры HDFS для обработки данных. Инженеры могут ссылаться как на S3, так и на HDFS в качестве файловой системы. Обычный шаблон — это запуск HDFS на SSD-дисках, извлечение данных из S3 и сохранение данных от промежуточных этапов обработки на локальном HDFS. Это может привести к значительным улучшениям производительности по сравнению с обработкой непосредственно из S3. Полные результаты записываются обратно в S3 после завершения этапов кластера, а затем кластер и HDFS удаляются. Другие потребители читают выходные данные непосредственно из S3.

Пример: Apache Spark. На практике Spark обычно выполняет задачи на HDFS или другом временном распределённом файловом хранилище для поддержки производительного хранения данных между этапами обработки. Кроме того, Spark сильно полагается на хранение данных в памяти для улучшения обработки. Проблема с владением инфраструктурой для запуска Spark заключается в том, что динамическая оперативная память (DRAM) очень дорогая; разделяя вычисления и хранение в облаке, мы можем арендовать большие объёмы памяти и освобождать её после завершения задачи.

Пример: Apache Druid. Apache Druid сильно полагается на SSD для достижения высокой производительности. Поскольку SSD значительно дороже, чем магнитные диски, Druid хранит только одну копию данных в своём кластере, снижая «живые» затраты на хранение в три раза. Конечно, поддержание долговечности данных всё ещё критично, поэтому Druid использует объектное хранилище в качестве своего уровня долговечности. Когда данные загружаются, они обрабатываются, сериализуются в сжатые колонки и записываются в SSD кластера и объектное хранилище. В случае сбоя узла или повреждения данных кластера данные могут быть автоматически восстановлены на новых узлах. Кроме того, кластер может быть выключен и затем полностью восстановлен из SSD-хранилища.

Пример: Гибридное объектное хранилище. Система файлового хранения Colossus от Google поддерживает детализированный контроль расположения блоков данных, хотя эта функциональность не доступна публично. BigQuery использует эту функцию для совмещения таблиц клиентов в одном месте, обеспечивая ультравысокую пропускную способность для запросов в этом месте. Мы называем это гибридным объектным хранилищем, потому что оно сочетает чистые абстракции объектного хранилища с некоторыми преимуществами совмещения вычислений и хранения. Amazon также предлагает некоторую концепцию гибридного объектного хранилища через S3 Select, функцию, которая позволяет пользователям фильтровать данные S3 непосредственно в кластерах S3 перед возвратом данных через сеть.

Мы предполагаем, что публичные облака будут более широко использовать гибридное объектное хранилище для улучшения производительности своих предложений и более эффективного использования доступных сетевых ресурсов. Некоторые, возможно, уже делают это, не раскрывая это публично. Концепция гибридного объектного хранилища подчёркивает, что всё ещё могут быть преимущества от наличия низкоуровневого доступа к оборудованию, а не полагаться на чужое публичное облако. Публичные облачные сервисы не раскрывают низкоуровневые детали оборудования и систем (например, расположение блоков данных для Colossus), но эти детали могут быть чрезвычайно полезны для оптимизации и улучшения производительности. См. наше обсуждение облачной экономики в главе 4.

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

Облачные системы, основанные на объектном хранилище, поддерживают клонирование без копирования. Это обычно означает, что создаётся новая виртуальная копия объекта (например, новая таблица) без необходимости физического копирования базовых данных. Обычно создаются новые указатели на исходные файлы данных, и будущие изменения в этих таблицах не будут записаны в старую таблицу. Для тех, кто знаком с внутренней работой объектно-ориентированных языков, таких как Python, этот тип «поверхностного» копирования знаком из других контекстов.

Клонирование без копирования (zero-copy cloning) — это привлекательная функция, но инженеры должны понимать её сильные и слабые стороны. Например, клонирование объекта в среде озера данных и последующее удаление файлов в исходном объекте может также уничтожить новый объект.

Для полностью управляемых систем на основе объектного хранилища (например, Snowflake и BigQuery) инженеры должны быть чрезвычайно знакомы с точными ограничениями поверхностного копирования. Инженеры имеют больше доступа к базовому объектному хранилищу в системах озёр данных, таких как Databricks, — это и благословение, и проклятие. Инженеры данных должны проявлять большую осторожность перед удалением любых исходных файлов в базовом объектном хранилище. Databricks и другие технологии управления озёрами данных иногда также поддерживают концепцию глубокого копирования, при котором копируются все базовые объекты данных. Это более дорогостоящий процесс, но также более надёжный в случае, если файлы случайно потеряны или удалены.

Хранение данных — это не просто сохранение их в объектное хранилище или на диск и забывание о них. Вам нужно думать о жизненном цикле хранения данных и их сохранении. Когда вы думаете о частоте доступа и сценариях использования, спросите себя: «Насколько важны эти данные для конечных пользователей и как часто им нужно к ним обращаться?» Это и есть жизненный цикл хранения данных. Ещё один вопрос, который вы должны задать себе: «Как долго мне нужно хранить эти данные?» Нужно ли сохранять данные бесконечно, или можно удалить их после определённого времени? Это и есть сохранение данных. Давайте рассмотрим каждый из этих аспектов подробнее.

Знали ли вы, что у данных есть температура? В зависимости от частоты доступа к данным, мы можем условно разделить способ их хранения на три категории постоянства: горячие, тёплые и холодные. Шаблоны доступа к запросам различаются для каждого набора данных (см. рисунок 6−9). Обычно новые данные запрашиваются чаще, чем старые. Давайте рассмотрим горячие, холодные и тёплые данные в этом порядке.

Горячие данные (Hot Data). Горячие данные требуют мгновенного или частого доступа. Хранилище для горячих данных подходит для быстрого доступа и чтения, такого как SSD или память. Из-за типа оборудования, используемого для горячих данных, их хранение часто является самой дорогой формой хранения. Примеры использования горячих данных включают получение рекомендаций по продуктам и результатов страниц продуктов. Стоимость хранения горячих данных самая высокая среди этих трёх уровней хранения, но извлечение данных часто недорогое.

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

Тёплые данные (Warm Data). Тёплые данные доступны полурегулярно, например, один раз в месяц. Нет жёстких правил, указывающих, как часто доступны тёплые данные, но это меньше, чем горячие данные, и больше, чем холодные данные. Основные облачные провайдеры предлагают уровни объектного хранилища, которые подходят для тёплых данных. Например, S3 предлагает уровень «Инфреквентно доступные данные» (Infrequently Accessed Tier), а Google Cloud имеет аналогичный уровень хранения под названием Nearline. Поставщики дают свои рекомендации по частоте доступа, и инженеры также могут проводить моделирование затрат и мониторинг. Хранение тёплых данных дешевле, чем горячих данных, с немного более высокими затратами на извлечение.

Холодные данные (Cold Data). На другом конце спектра находятся холодные данные, которые доступны редко. Оборудование, используемое для архивирования холодных данных, обычно дешёвое и долговечное, такое как HDD, ленточное хранилище и облачные архивные системы. Холодные данные предназначены в основном для долговременного архивирования, когда нет намерения часто обращаться к данным. Хотя хранение холодных данных дешёвое, извлечение холодных данных часто дорогое.
Рассмотрение уровней хранения. При выборе уровня хранения для ваших данных учитывайте затраты на каждый уровень. Если вы храните все данные в горячем хранилище, все данные могут быть быстро доступны. Но это обходится в огромную цену! С другой стороны, если вы храните все данные в холодном хранилище, чтобы сэкономить на затратах, вы, конечно, снизите затраты на хранение, но за счёт увеличенного времени извлечения и высоких затрат на извлечение, если вам нужно получить доступ к данным. Стоимость хранения снижается от более быстрого/высокопроизводительного хранилища к более медленному.

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

Инженерам данных нужно учитывать переполнение данных из горячего хранилища в тёплое/холодное. Память дорогая и ограниченная. Например, если горячие данные хранятся в памяти, они могут быть перемещены на диск, когда появляется слишком много новых данных для хранения и недостаточно памяти. Некоторые базы данных могут перемещать редко используемые данные в тёплые или холодные уровни, перенося данные на HDD или объектное хранилище. Последнее становится всё более распространённым из-за экономической эффективности объектного хранилища. Если вы используете облачные услуги, переполнение данных на диск произойдёт автоматически.
Если вы используете облачное объектное хранилище, создайте автоматические политики жизненного цикла для ваших данных. Это значительно снизит ваши затраты на хранение. Например, если ваши данные нужно обращаться только один раз в месяц, переместите данные в уровень хранения с инфреквентным доступом. Если ваши данные старше 180 дней и не используются для текущих запросов, переместите их в архивный уровень хранения. В обоих случаях вы можете автоматизировать миграцию данных из обычного объектного хранилища, и вы сэкономите деньги. Однако учитывайте затраты на извлечение — как по времени, так и по деньгам — при использовании уровней хранения с инфреквентным или архивным доступом.

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

В ранние дни «больших данных» существовала тенденция накапливать все возможные данные, независимо от их полезности, с ожиданием, что «эти данные могут понадобиться в будущем». Это накопление данных неизбежно становилось громоздким и «грязным», что привело к появлению «болот данных» и ужесточению регулирования хранения данных, среди прочих последствий и проблем. В наши дни инженерам данных необходимо учитывать хранение данных: какие данные нужно сохранять и как долго их нужно хранить? Вот несколько аспектов, которые следует учитывать при сохранении данных (data retention).

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

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

Соответствие требованиям. Некоторые нормативные акты (например, HIPAA и Payment Card Industry, или PCI) могут требовать хранения данных в течение определённого времени. В таких ситуациях данные должны быть доступны по запросу, даже если вероятность такого запроса низка. Другие нормативные акты могут требовать хранения данных только в течение ограниченного времени, и вам нужно будет иметь возможность удалять определённую информацию вовремя и в соответствии с установленными правилами. Вам потребуется процесс хранения и архивирования данных, а также возможность поиска данных, соответствующая требованиям хранения конкретного нормативного акта, с которым вы должны соответствовать. Конечно, вам нужно будет балансировать соответствие требованиям и затраты.

Затраты. Данные — это актив, который (надеюсь) имеет окупаемость инвестиций (ROI). С точки зрения затрат на ROI, очевидные расходы на хранение связаны с данными. Учитывайте временные рамки, в которых вам нужно хранить данные. Учитывая наше обсуждение горячих, тёплых и холодных данных, внедрите автоматические практики управления жизненным циклом данных и перемещайте данные в холодное хранилище, если они не нужны после истечения срока хранения. Или удаляйте данные, если они действительно не нужны.

В главе 3 мы рассмотрели компромиссы между одноарендной и мультиарендной архитектурой. Для повторения: в одноарендной архитектуре каждая группа арендаторов (например, отдельные пользователи, группы пользователей, аккаунты или клиенты) получает свой собственный набор ресурсов, таких как сеть, вычислительные мощности и хранилище. Мультиарендная архитектура, наоборот, делит эти ресурсы между группами пользователей. Обе архитектуры широко используются. В этом разделе мы рассмотрим последствия одноарендного и мультиарендного хранения данных.

Принятие одноарендного хранения данных означает, что каждый арендатор получает своё собственное хранилище. В примере на рисунке 6−10 каждый арендатор получает свою собственную базу данных. Никакие данные не делятся между этими базами данных, и хранилище полностью изолировано. Примером использования одноарендного хранения данных является ситуация, когда данные каждого клиента должны храниться в изоляции и не могут быть смешаны с данными других клиентов. В этом случае каждый клиент получает свою собственную базу данных.

Раздельное хранение данных подразумевает отдельные и независимые схемы, структуры бакетов и всё, что связано с хранением. Это означает, что у вас есть свобода проектировать хранилище каждого арендатора одинаково или позволить им развиваться по-своему. Вариации схем между клиентами могут быть как преимуществом, так и усложнением; как всегда, учитывайте компромиссы. Если схема каждого арендатора не унифицирована для всех арендаторов, это имеет серьёзные последствия, если вам нужно запрашивать таблицы нескольких арендаторов для создания единого представления всех данных арендаторов.

Мультиарендное хранение позволяет хранить данные нескольких арендаторов в одной базе данных. Например, вместо одноарендного сценария, где клиенты получают свою собственную базу данных, несколько клиентов могут находиться в одних и тех же схемах или таблицах базы данных в мультиарендной базе данных. Хранение мультиарендных данных означает, что данные каждого арендатора хранятся в одном месте (рисунок 6−11).

Вам нужно учитывать запросы как к одноарендному, так и к мультиарендному хранилищу, что мы рассмотрим более подробно в главе 8.

Хранение данных — это центральная часть инфраструктуры инженерии данных. Вам придётся взаимодействовать с людьми, ответственными за вашу ИТ-инфраструктуру, — обычно это DevOps, специалисты по безопасности и облачные архитекторы. Определение областей ответственности между инженерами данных и другими командами является критически важным. Имеют ли инженеры данных полномочия развёртывать свою инфраструктуру в аккаунте AWS, или эти изменения должна обрабатывать другая команда? Работайте с другими командами, чтобы определить оптимизированные процессы, чтобы команды могли эффективно и быстро работать вместе.

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

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

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

Хотя инженеры часто считают безопасность препятствием для их работы, они должны принять идею, что безопасность является ключевым фактором успеха. Надёжная безопасность данных в состоянии покоя и в движении с детализированным контролем доступа к данным позволяет данным шире распространяться и использоваться внутри компании. Ценность данных значительно возрастает, когда это возможно.

Как всегда, придерживайтесь принципа минимальных привилегий. Не предоставляйте полный доступ к базе данных никому, если это не требуется. Это означает, что большинству инженеров данных в реальной практике не нужен полный доступ к базе данных. Также обратите внимание на контроль доступа на уровне столбцов, строк и ячеек в вашей базе данных. Предоставляйте пользователям только ту информацию, которая им действительно необходима, и ничего лишнего.

Управление данными критически важно при чтении и записи данных с использованием систем хранения.

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

При разработке ваших систем хранения инвестируйте в метаданные. Интеграция словаря данных с этими инструментами позволяет пользователям делиться и записывать корпоративные знания надёжно.

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

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

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

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

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

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

Глава 3 охватывает основы архитектуры данных, так как хранение является критически важной основой жизненного цикла инженерии данных.
Рассмотрите следующие советы по архитектуре данных. Проектируйте с учётом необходимой надёжности и долговечности. Понимайте вверхстоящие источники данных и как эти данные, после загрузки, будут храниться и доступны. Понимайте типы моделей данных и запросов, которые будут происходить ниже по цепочке.

Если данные ожидается увеличиваться, можете ли вы договориться о хранении с вашим облачным провайдером? Принимайте активный подход к FinOps и рассматривайте его как центральную часть архитектурных обсуждений. Не оптимизируйте преждевременно, но готовьтесь к масштабированию, если существуют бизнес-возможности, связанные с работой с большими объёмами данных.

Склоняйтесь к использованию полностью управляемых систем и понимайте соглашения об уровне обслуживания (SLA) провайдера. Полностью управляемые системы, как правило, гораздо более надёжны и масштабируемы, чем системы, за которыми нужно постоянно следить.

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

Мы можем рассматривать инженерию программного обеспечения в контексте хранения данных с двух точек зрения. Во-первых, код, который вы пишете, должен хорошо работать с вашей системой хранения. Убедитесь, что код, который вы пишете, правильно хранит данные и не вызывает утечек данных, памяти или проблем с производительностью. Во-вторых, определите вашу инфраструктуру хранения как код и используйте временные вычислительные ресурсы, когда приходит время обрабатывать ваши данные. Поскольку хранение всё больше отделяется от вычислений, вы можете автоматически запускать и останавливать ресурсы, сохраняя данные в объектном хранилище. Это поддерживает чистоту вашей инфраструктуры и избегает связывания уровней хранения и запросов.

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

■ «Column-Oriented DBMS», Wikipedia
■ «The Design and Implementation of Modern Column-Oriented Database Sys‐
tems», Daniel Abadi et al.
■ «Designing Data-Intensive Applications», Martin Kleppmann (O’Reilly)
■ «Diving Into Delta Lake: Schema Enforcement and Evolution», Burak Yavuz
et al.
■ «Hot Data vs. Cold Data: Why It Matters», Afzaal Ahmad Zeeshan
■ IDC’s «Data Creation and Replication Will Grow at a Faster Rate than Installed
Storage Capacity, пресс-релиз IDC Global DataSphere and StorageSphere
Forecasts»
■ «Rowise vs. Columnar Database? Theory and in Practice», Mangat Rai Modi
■ «Snowflake Solution Anti-Patterns: The Probable Data Scientist», John Aven
■ «What Is a Vector Database?», Bryan Turriff
■ «What Is Object Storage? A Definition and Overview», Alex Chan
■ «The What, When, Why, and How of Incremental Loads», Tim Mitchell