Хранилище данных

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

Я Хамзет Шогенов, архитектор облачной платформы Mail.ru Cloud Solutions, расскажу о системах хранения данных, доступных на нашей платформе, подробно остановлюсь на их технических характеристиках и оптимальных вариантах использования.

Типы дисков, которые вы можете использовать в облаке

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

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

Особенности облачных (блочных) дисков:

1. Есть определенная гарантированная производительность в единицу времени на единицу объема хранения данных, выражаемая в операциях на диске в секунду (IOPS, пропускная способность).

2. Широкий выбор типов дисков. Возможность изменения типа диска на лету.

3. Возможность создания снапшотов и образов (шаблонов) дисков.

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

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

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

Отличия облачных (блочных) дисков от других облачных систем хранения данных:

• Масштабирование производится вручную.

• Уменьшение размера существующего диска недоступно: потребуется пересоздание.

• Доступ возможен из любой зоны доступности (AZ), но ресурс локализован в одной AZ. Размещение диска и виртуальной машины в разных ЦОДах не рекомендуется, хотя это и возможно.

• Непригодны для одновременного доступа при работе как с блочным устройством.

• Наибольшая стоимость среди всех типов облачных хранилищ, если говорить про наиболее производительные типы дисков.

На нашей платформе поддерживаются несколько типов дисков: HDD, SSD, SSD High IOPS и Low Latency NVMe. Вначале рассмотрим характеристики, которые будут общими для всех дисков, затем остановимся более подробно на каждом из них.

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

Общие характеристики для всех типов облачных дисков

1. Capacity. Рекомендуемый максимальный размер диска 2 Тб.

2. Масштабирование. Вручную через веб-консоль управления облаком или OpenStack CLI (Command Line Interface). Возможно только увеличение размера диска. Уменьшение недоступно, так как подобная процедура может негативно сказаться на работе файловой системы и целостности данных.

3. Доступность. Гарантируется SLA, общий для облака, 99,95%.

4. Бэкапы и восстановление. Для всех дисков поддерживаются снапшоты и резервные копии. Создание снапшотов доступно через консоль управления облаком и OpenStack CLI. Создание бэкапов возможно через встроенный механизм MCS либо с использованием сторонних решений наших партнеров: Acronis и VMware Backup & Replication. Встроенный механизм хорош интеграцией с облачной платформой, сохранением бэкапов в S3, что дешевле, и платой только за хранение данных. Однако в этом случае нет возможности восстановления данных в ту же виртуальную машину и восстановления отдельных файлов.

5. Границы доступности. Ресурс локализован в рамках одной зоны доступности (AZ, Availability Zone). Чтобы избежать потенциального снижения производительности работы, при создании диска, подключаемого к существующему инстансу, рекомендуется выбирать зону доступности инстанса.

6. Безопасность. Доступ к данным ограничен механизмами изоляции ресурсов (различные Namespace) проекта.

7. Механизм расчета стоимости. Цена определяется запрошенным объемом диска. При изменении размера стоимость автоматически пересчитывается.

Диски HDD

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

Характеристики, специфичные для HDD

Диски SSD

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

Характеристики, специфичные для SSD

Диски High IOPS SSD

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

Характеристики, специфичные для High IOPS SSD

Low Latency NVMe

Сверхбыстрые диски с минимальными задержками, доступные на высокочастотных конфигурациях ВМ. Самые производительные и дорогие. Этому классу хранения соответствуют физические диски NVMe. Используются там, где важно обеспечить минимальные задержки: высокопроизводительные СУБД, аналитика, кэш.

Характеристики, специфичные для Low Latency NVMe

Объектные хранилища S3 еще один тип хранения данных в облаке

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

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

S3 может выступать в качестве более надежной и дешевой альтернативы дискам HDD для большей части сценариев их использования.

В нашем облаке доступны три класса объектных хранилищ S3, которые различаются по своему назначению и стоимости:

1. S3 HotBox предназначен для хранения горячих данных с частым доступом. В первую очередь это онлайн-сервисы с повышенной нагрузкой, работа которых требует хранения и раздачи контента: потоковая раздача мультимедиа, хостинг статических сайтов, хранилища для Backend-платформ. Могут также использоваться для анализа данных в Big Data, Data Mining и так далее. В HotBox хранение дороже, а исходящий трафик дешевле, входящий трафик не тарифицируется.

2. S3 IceBox используют для хранения холодных данных с редким доступом, например несколько раз в месяц. Чаще всего это годовая и месячная отчетность, документы, бэкапы и журналы, к которым периодически нужен быстрый доступ. По сравнению с HotBox в IceBox хранение дешевле, а исходящий трафик дороже, входящий трафик также не тарифицируется.

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

Что хорошего в S3-хранилище:

• Неограниченный объем хранимых данных (петабайты).

• Подходит для неструктурированных данных за счет хранения дополнительной информации (метаданных) рядом с объектами.

• Разграничение доступа за счет ACL и префиксных ключей.

• Возможность одновременного использования большим количеством приложений.

• Стабильная скорость раздачи любых объектов независимо от числа одновременных обращений.

• Автоматическое и виртуально неограниченное масштабирование.

• Возможность настройки Webhooks для автоматической обработки при создании/удалении объектов (например, автообработка фото и видео).

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

• У S3 нет понятия зоны доступности: это глобальный сервис. Его доступность обеспечивается из пяти ЦОД MCS.

• Наименьшая стоимость среди всех типов облачных хранилищ.

Основное отличие S3-хранилища от других облачных (блочных) систем хранения блочные хранилища предназначены для использования виртуальными машинами и представляются как диски, а объектное хранилище доступно только по HTTP.

Основные особенности S3

1. Capacity. Нет ограничений на общий объем можно хранить петабайты данных. В одном хранилище может быть до 25 бакетов, размер одного бакета произвольный. Число объектов в одном бакете не ограничено свыше 1 млрд. Для конкретных объектов действуют следующие рейт-лимиты: 32 ГБ для обычного файла, 320 ТБ для multipart.

2. IOPS (количество операций в секунду). Действуют следующие рейт-лимиты: для обычных запросов 500 запросов в секунду, 10 млн запросов в день, для запросов на листинг 15 запросов в секунду, 10 млн запросов в день.

3. Throughput (пропускная способность). Поддерживается скорость передачи объектов 1 Гбит/с. Для быстрой доставки контента хранилище S3 можно интегрировать с сетью доставки контента (CDN, Content Delivery Network), имеющей более 400 точек присутствия во всем мире и емкость канала 1,5 ТБит/с.

4. Масштабирование. Размер S3 не ограничен. Масштабирование происходит вверх и вниз автоматически, без дополнительных настроек со стороны пользователя.

5. Доступность. Гарантируется SLA, общий для облака 99,95%. Надежность хранения при этом составляет 99,99999%.

6. Поведение при выходе физического оборудования из строя. Происходит без прерывания обслуживания и потери данных.

7. Бэкапы и восстановление. Обеспечивается георепликация данных. В разработке функциональность версионирования объектов с возвратом к определенному номеру версии.

8. Границы доступности. Возможен доступ из всех зон доступности региона, а также из любого места в интернете с использованием URL объектов.

9. Протоколы доступа. S3 API. Главная особенность решения от MCS полная совместимость с API S3.

10. Безопасность. Обеспечивается за счет списков управления доступом (ACL, Access Control Lists) и префиксных ключей. На уровне каждого бакета можно определять, кто может создавать, удалять и перечислять объекты в нем. При организации внешнего доступа вне облака можно использовать HTTPS.

11. Механизм расчета стоимости. Оплачивается за фактически использованные ресурсы и рассчитывается посекундно. Тарифный план зависит от типа выбранного хранилища: HotBox, IceBox или Glacier.

Файловые хранилища в облаке

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

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

Преимущества файловых хранилищ:

• Есть возможность как увеличения, так и уменьшения размера хранилища.

• Есть возможность создания снапшотов.

• Оптимальный вариант хранения для Legacy-приложений, требующих протокола SMB/NFS.

• Поддерживаются большим количеством классических систем.

Недостатки файловых хранилищ:

• Масштабирование производится вручную.

• Одновременный доступ ограничен полосой пропускания стандартного сетевого интерфейса.

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

Основные характеристики файловых хранилищ

1. Capacity. Рекомендуемый максимальный размер хранилища 2 Тб. Максимальный размер файла не больше запрошенного размера хранилища.

2. IOPS (количество операций в секунду на 2 Тб пространства). Так как файловое хранилище базируется на дисках HDD, показатель SLA будет тем же: для чтения 3002400, для записи 150800.

3. Throughput (пропускная способность на 2 Тб пространства, при размере блока 1М). Аналогично, как для HDD: для чтения 250 Мб/с, для записи 100 Мб/с.

4. Масштабирование. Проводится вручную через web-консоль управления облаком или OpenStack CLI (Command Line Interface). В отличие от облачных дисков возможно как увеличение, так и уменьшение размера файлового хранилища.

5. Доступность. Гарантируется SLA, общий для облака, 99,95%.

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

7. Бэкапы и восстановление. Возможно создание снапшотов, бэкапирование из веб-консоли недоступно. Механизмы те же, что и для облачных дисков.

8. Границы доступности. Доступ осуществим из сетей, которые имеют возможность маршрутизации IP-пакетов с сетью, где размещено файловое хранилище.

9. Протоколы доступа. Подключить файловое хранилище к инстансам проекта можно по протоколам CIFS (SMB v3) или NFS.

10. Безопасность. Доступ к файловым хранилищам осуществляется только из виртуальных машин внутри проекта (Namespace) MCS. При этом дается возможность настроить правила доступа к хранилищу в зависимости от IP клиента.

11. Механизм расчета стоимости. Цена определяется в зависимости от запрошенного при создании объема хранилища. При изменении размера в дальнейшем стоимость автоматически пересчитывается.

Как выбрать облачную систему хранения с учетом потребностей компании: основные критерии

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

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

При выборе S3 необходимо дополнительно определить частоту доступа к данным и выбрать соответствующий тип хранилища: HotBox, IceBox или Glacier.

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

В порядке возрастания производительности диски можно расположить следующим образом: HDD, SSD, SSD High IOPS, Low Latency NVMe. Если требуется обеспечить минимальную задержку, Low Latency NVMe будет лучшим выбором, так как для этого типа диска определено SLA на данный показатель 0,5 мс.

Методы доступа к данным, используемые в классических приложениях (в первую очередь протоколы доступа, так как контроль над интерфейсами напрямую заказчику недоступен). Очень часто при переносе Legacy-приложений клиентов в облако требуется обеспечить конкретные, уже используемые ими протоколы. Конечно, обновление систем возможно, но, как правило, требует дополнительных затрат. В таких случаях выбор облачного хранилища полностью зависит от требований переносимого ПО. Например, файловые хранилища чаще всего выбирают, когда необходимы протоколы SMB/NFS. И это стало в свое время основной причиной того, почему у нас появилось файловое хранилище как сервис.

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

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

Для файловых хранилищ и обычных дисков цена определяется запрошенным объемом ресурсов. При этом цена дисков возрастает по мере увеличения их производительности: HDD, SSD, SSD High IOPS, Low Latency NVMe. Рекомендуем выбирать тот тип диска, который при достаточной для вас производительности будет дешевле всего, так как в дальнейшем при необходимости его можно будет изменить на лету.

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

Упрощенная схема выбора облачного хранилища

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

Расчет необходимой производительности облачной системы хранения при переносе Legacy-приложений

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

Предлагаем руководствоваться следующим набором правил:

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

2. Настройте и запустите процесс снятия метрик на исходном сервере:

   • количество потребляемых ядер;

   • потребляемая частота CPU;

   • количество операций ввода/вывода в секунду;

   • задержки чтения/записи на дисках;

   • эффективность использования ОЗУ.

3. Подготовьте синтетические данные для нагрузочного тестирования.

4. Создайте тестовый стенд, выделив на нем минимальное достаточное количество ресурсов в соответствии с расчетами. Расчеты стоит осуществлять с учетом фактического потребления ресурсов в часы наиболее высокой нагрузки. Далее, используя показатели из SLA MCS, пересчитать на ресурсы MCS.

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

6. Если показатели успешности не достигнуты, проведите диагностику для выявления узкого места, исходя из анализа данных, собранных на шаге 5. Добавьте необходимый тип ресурса или пересмотрите архитектуру и вновь приступайте к тестированию.

7. При успешном тестировании можно производить миграцию и начинать промышленную эксплуатацию.

Как сочетать облачные системы хранения между собой

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

Например, возможна следующая комбинация блочных дисков: для ОС использовать HDD, СУБД построить с использованием SSD High IOPS, а для кэша взять Low Latency NVMe. S3 в такую схему можно подключить для размещения медиаконтента (картинок и видео) с возможностью внешнего доступа или для хранения резервных копий.

Если вы используете Kubernetes, S3 подойдет для хранения образов, а файловые хранилища в качестве персистентного хранилища для групп контейнеров. Хотя здесь также в большинстве случаев с минимальными доработками можно научить ПО в контейнерах работать с более надежным и дешевым хранилищем S3.

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

Вариант комбинации облачных дисков на примере построения инфраструктуры для интернет-магазина с применением облачных сервисов

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

Итоговое сравнение облачных систем хранения данных

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

Что еще почитать по теме:

1. Работа с объектным S3-хранилищем Mail.ru Cloud Solutions как с файловой системой.

2. Принципы организации объектных хранилищ.

3. Все обновления облачных хранилищ и другие новости наших облачных сервисов в нашем телеграм-канале.

Frozen cells by arbebuk

Я, Георгий Меликов, являюсь контрибьютором проектов OpenZFS и ZFS on Linux. Также я занимаюсь разработкой IaaS в команде облачной платформы Mail.ru Cloud Solutions. Хотя в продакшене нашего подразделения мы и не используем ZFS, но хозяева подкаста SDCast пригласили меня рассказать именно о нём. Из выпуска и родилась эта статья, а вот тут можно послушать аудиоверсию.

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

ZFS и ее отличия от других решений на примере Linux

ZFS это симбиоз файловой системы и менеджера томов, которая предоставляет инструменты для простого управления дисковым массивом.

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

В Linux как де-факто стандарт используется менеджер логических томов (Logical Volume Manager, LVM), который также предлагает некоторые абстракции над нижележащим блочным устройством можно создавать абстракции в виде Physical Volume, Logical Volume и так далее. По сути, можно делать то же самое, что с ZFS, но другими методами, добавив ещё кучу слоёв к LVM.

Плюсы ZFS в том, что он знает, что и где лежит, группирует это и дает некоторые другие фишки, в частности безопасное хранение данных эта файловая система сделана с упором на целостность. Сейчас это (на мой скромный взгляд) лучшее из опенсорсных кроссплатформенных предложений на рынке. Конечно, можно собрать хранилище и без ZFS, но это будет хуже по производительности, т. к. для достижения хотя бы отдалённого паритета по функциональности придётся использовать много слоёв (LVM, mdadm, dm-integrity, что-то для дедупликации и компрессии). К сожалению, каждый слой даёт не малое пенальти.

Основы ZFS

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

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

Copy-on-write дает следующее преимущество: старые данные не меняются, можно не вести журнал и восстановить данные, записанные ранее. Мы не боимся повреждения данных, так как их нельзя повредить, новый вариант блока запишется в новое место, не затирая старый.

Сам copy-on-write процесс не гарантирует консистентность данных, но если рассматривать ZFS, то в основе его работы лежит дерево Меркла, или Хэш-дерево. У ZFS всегда консистентное состояние за счет того, что он использует атомарные транзакции. Есть дерево блоков, для каждого из них с самого нижнего блока подсчитывается хеш-сумма и так доходит до самого верхнего блока. Хеш-сумма верхнего блока (uberblock) позволяет валидировать состояние всей файловой системы на момент транзакции.

Однако из-за того, что copy-on-write система никогда не пишет в одно и то же место появляется проблема фрагментации данных. Также надо решать вопрос чтения и его эффективности. С SSD эта проблема по большей части решается, но она ощутима при работе на жестких дисках.

ZFS, как и любой copy-on-write системе, нужно иметь на дисках запас свободного места, чтобы было куда записывать данные, которые всегда пишутся в новое место. К этому добавляется проблема порядка записи, следующие блоки одного файла будут записаны в другое место на диске, то есть в наличии непростая задача по эффективному аллоцированию данных. Однако и в классических файловых системах фрагментации можно избежать, только переалоцировав последовательно отрезок и работая только с ним. По факту мы так возвращаемся к прибиванию сущностей программы к конкретному диску, а это менее удобно (а любая ФС, как мы говорили раньше, стремится облегчить жизнь разработчику).

Преимущества ZFS

Давайте же поговорим о плюсах, зачем вообще стоит выбирать ZFS:

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

Сжатие на лету. К примеру, используя алгоритм сжатия LZ4 система без проблем выдает 800 Мбайт в секунду на одно ядро на запись и до 4.5 Гбайт в секунду на чтение. Соответственно, если мы говорим про многопоточную нагрузку, то при наличии свободного процессорного времени его можно эффективно утилизировать. В таком случае можно сэкономить не только место на диске, но и IOPS жесткого диска взамен ресурсов процессора за счет меньшего количества операций к диску. Есть интересные кейсы, к примеру использование MySQL, когда при этом под нами не очень дорогой SSD или простой HDD тогда, включив LZ4, можно хорошо выиграть по многопоточной производительности, немного увеличив latency каждого потока.

Атомарность. В ZFS все атомарно за счет того, что в основе лежит дерево Меркла. Если наша файловая система всегда атомарна, то можно отказаться от WAL-лога в приложениях, потому что целостность блоков гарантируется транзакционностью файловой системы. Тут есть нюансы: нужно уметь говорить с файловой системой на ее языке, манипулировать транзакциями. Отдельный вопрос, что эти логи некоторые базы данных используют для репликации. Но в целом можно так экономить на ресурсах.

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

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

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

Архитектура ZFS

Посмотрим, как устроена ZFS изнутри. Есть набор дисков, над ним появляется абстракция в виде виртуального устройства (device). В терминологии ZFS это Vdev, сокращение от virtual device. Есть разные реализации Vdev: Mirror (зеркало), который дублирует как есть информацию на два диска, RAID-Z, похожий по логике работы на классические RAID 5, 6 или 7. Также на подходе новый dRAID, о котором поговорим позже.

Как конкретно мы храним и резервируем данные с упором на производительность или на объём полезного пространства это ответственность Vdev. Из набора Vdevов мы составляем общий пул. Если перевернуть на классическое понимание того же mdadm, чтобы собрать RAID 10, то есть набор мирроров, нужно сделать несколько Vdev Mirror и объединить их в один пул. Каждый Vdev это, по сути, stripe, то есть отдельная виртуальная единица хранения. В рамках пула каждый уникальный блок данных будет храниться только на одном Vdev.

Логически элементы ZFS делятся на 3 подсистемы:

1. SPA (Storage Pool Allocator) отвечает непосредственно за нарезку на диски, хранение данных на диске. Этот элемент отвечает за то, куда кладется конкретный блок данных, но с абстракцией от диска. Когда мы к нему обращаемся, то видим единое пространство, вне зависимости от набора конкретных Vdevов.

2. DMU (Data Management Unit) на этом уровне ZFS представляется обычным объектным хранилищем. Есть реализации, когда ее так и используют с некоторыми модификациями. К примеру, распределённая файловая система Lustre реализует свой слой поверх DMU ZFS.

3. Следующий уровень DSL (Data and Snapshot Layer) пользуется этим объектным хранилищем. Этот компонент занимается непосредственно файловыми системами, снапшотами, то есть логикой, которая реализует POSIX-совместимую файловую систему (в него входит слой ZPL ZFS POSIX layer).

Также в ZFS есть другие подсистемы, которые нужны для эффективной совместной работы всех этих слоёв.

ARC (Adaptive Replacement Cache). Его разработали, чтобы решить проблему с чтением. ARC примечателен тем, что делает упор не только на трекинг тех объектов, что были использованы последними (LRU-cache), но и на трекинг частоиспользуемых объектов, которые он и кэширует (MFU-cache).

У классического page cache Linuxа есть проблема вымывания: если прочесть файл, размер которого превышает объем оперативной памяти, то старые данные из кэша вымоются, так как по умолчанию файл будет загружен в page cache.

ARC это умная замена page cache. Когда создавался ZFS, часто использовали жесткие диски, а у них маленькие IOPS. Чтение copy-on-write данных по умолчанию случайная операция, чтобы её ускорить, используют разные ухищрения, например, аккумулируют данные, записывают большим блоком и так далее, но эти оптимизации не всегда срабатывают. На этот случай нужно умное кеширование. Нормально, если при штатном работе 99% запросов чтения попадает в кэш, если меньше, значит, что-то не так, стоит добавить оперативной памяти.

Если ARC не всегда полностью помещается в память, есть варианты вынести кэш на более быстрый отдельный SSD это называется L2ARC (Layer 2 ARC).

ZIL (ZFS intent log). Мы пишем данные в ZFS транзакциями, это набор дорогостоящих операций: подсчет хэш-сумм, построение дерева, запись метаданных, которые пишутся для безопасности несколько раз в разные места дисков. Поэтому мы стараемся набить каждую транзакцию максимальным количеством данных. Тут (сюрприз) появляется определенного вида журнал, без которого не обойтись, если нужна быстрая синхронная запись и критична задержка. Только здесь он вынесен как сущность, что позволяет использовать разные решения для персистентного хранения кусочка синхронной записи. Этот журнал обычно очень маленький, его записью и занимается ZIL (ZFS intent log).

ARC и ZIL хотя это и необязательные с технической стороны компоненты, но они нужны для обеспечения высокой производительности хранилища, без них система будет работать медленнее. ZFS в продакшене чаще применяют для крупных инсталляций хранилища данных. Архитектура подразумевает эффективную утилизацию большого количества HDD, SSD, RAM, CPU.

Паттерны использования ZFS и типовые конфигурации

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

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

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

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

Блоки типа ARC, ZIL и так далее это не диски, которые мы можем использовать, это понятия виртуальные, они всегда есть в ZFS. У нас есть возможность вынести их на более быстрые отдельные носители.

ZIL можно вынести на так называемый Slog, которому не нужно быть большим, так как синхронная запись обычно идет мелким блоком и быстро сбрасывается на основное хранилище. То есть важно как можно быстрее записать конкретный блок данных и отрапортовать клиенту об успешной записи, а не записать как можно больше данных (привет, СУБД!). Slog нужен на чтение только при сбое питания.

ARC можно дополнить одним или более SSD и выгружать на него определенный вид данных, например, кэшировать только метаданные или данные, которые последовательно или случайно прочитались с основного хранилища.

Есть много вариаций настройки ZFS. Можно оптимизировать любой профиль нагрузки, начиная от размера блока, которым мы оперируем. Например, когда мы хотим оптимизировать copy-on-write, то можем писать большим блоком, чем в классических файловых системах, для ZFS по умолчанию принят объем в 128 КБайт на блок.

Плюсы и минусы ZFS по сравнению с аппаратными решениями

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

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

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

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

Датасет отдельная файловая система в терминологии ZFS со своими настройками. К примеру, для СУБД можно создать отдельное пространство под основные данные с размером блока 8 Кбайт и отдельный датасет, оптимизированный под WAL-лог с размером блока 16 Кбайт. При этом все будет эффективно работать. Хочется сжимать одни данные отлично, zfs set compression=on. Другие данные читаются очень редко и могут без надобности вымывать ARC без проблем, zfs set primarycache=metadata.

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

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

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

Особенности работы ZFS

Фрагментация данных

В copy-on-write системе постоянно появляются новые блоки, а старые не всегда пригодны к удалению. Часто возникают ситуации, когда старый блок не полностью записан, какие-то блоки не нужны, появились дырки (пустые пространства небольшого размера) и так далее.

В ZFS пространство разрезано на так называемые metaslabs, которые ведут трекинг того, какие сектора свободны, а какие заняты. Это происходит на уровне SPA слоя, который работает с дисками.

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

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

По умолчанию на каждый Vdev создается ~200 meta-slabs. Если что-то изменилось, то надо метаданные по этим 200 meta-slabs записывать каждый раз для каждого Vdev. Сейчас это пишется постоянно на каждый Vdev, но уже перед релизом патч, который записывает информацию об изменениях в meta-slabs в виде лога на один из Vdev, а потом регулярно применяет этот лог. Это чем-то похоже на WAL-лог базы данных. Соответственно, уменьшается нагрузка на запись на диск информации о metaslabs.

Конечно, при заполнении всего места возникает проблема, но на эту ситуацию любая copy-on-write файловая система (да и традиционная тоже) закладывает какой-то процент зарезервированного места для работы, без этого с динамической аллокацией никак.

Запись данных

По умолчанию чтение данных в ZFS практически всегда является случайным, но так как мы пишем каждый раз в новое место, то можем превращать случайную запись в практически последовательную. Если нужна система хранения под запись и редкое чтение, то любая copy-on-write система, в том числе ZFS, будет отличным решением. Данные пишутся группами транзакций (txg, сокращённое от transaction groups), можно агрегировать информацию в рамках этой группы.

Тут есть особенность: существует Write Throttling мы можем использовать неограниченное количество оперативной памяти для подготовки txg-группы и за счет этого переживать резкие скачки записи, буферизируя все в оперативную память. Естественно, речь про асинхронную запись, когда мы можем себе это позволить. Потом можно последовательно и очень эффективно сложить данные на диск.

Если синхронная запись и ее целостность не важна, например, у вас не большая и дорогостоящая PostgreSQL, а сервер на одного пользователя, то синхронную запись можно отключить одной настройкой, она станет равняться асинхронной (zfs set sync=disabled).

Таким образом, собрав пул из HDD, можно ими пользоваться как дешёвыми SSD с точки зрения IOPS. Сколько IOPS даст оперативная память, столько и будет. При этом целостность ZFS обеспечивает в любом случае при потере питания произойдет откат на последнюю целую транзакцию и все будет хорошо. В худшем случае мы теряем последние несколько секунд записи, сколько у нас настроено в параметре txg_timeout, по умолчанию это до 5 секунд, (до т.к. ещё есть задаваемый лимит на размер буфера, при превышении данные запишутся раньше).

Зависимость скорости работы ZFS от количества дисков

Один блок данных всегда приходит на один Vdev. Если мы делим файл на небольшие блоки по 128 KB каждый, то такой блок будет на одном Vdev. Далее мы резервируем данные с помощью Mirror или как-то еще. Набив пул сотней Vdev, мы в один поток будем писать только на один из них.

Если дать многопоточную нагрузку, например в 1 000 клиентов, то они могут использовать сразу много Vdev параллельно, нагрузка распределится. При добавлении дисков мы, конечно, не получим полностью линейного роста, но параллельная нагрузка эффективно размажется по Vdevам.

Обработка запросов на запись

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

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

Как появились OpenZFS и ZFS on Linux и проблемы с версионированием

ZFS изначально создана в Sun Microsystems для проприетарной операционной системы Solaris. Она появилась в качестве замены UFS, которая должна была покрыть любые надобности от файловой системы на долгое время (характерно само название ZFS Zettabyte File System, намёк на недостижимые объёмы). После продукт стал распространяться с открытым кодом под лицензией CDDL и названием OpenSolaris. Затем Oracle купили Sun Microsystems, и проект перевели обратно в разряд проприетарных. До этого FreeBSD успел притянуть к себе код, были наработки у Apple, они даже встроили реализацию в штатную поставку, но отказались от нее, в конечном итоге внедрив свой аналог AFS. Тогда же появился форк, который превратился в OpenZFS. Сначала желающие работали на OpenSolaris, а потом создали OpenZFS, под которым собрали все усилия в рамках Illumos (форк OpenSolaris).

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

У ZFS on Linux другая история. В Ливерморской национальной лаборатории США в качестве распределённой файловой системы для суперкомпьютеров использовали Lustre FS. Ее особенность в том, что на каждой ноде под ней используется еще одна локальная файловая система Ldiskfs это патченный Ext3, наработки которой послужили основой для Ext4. У Ldiskfs был ряд недостатков, и ZFS должен был заменить эту файловую систему, так и появился проект ZFS on Linux.

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

На тот момент в проекте OpenZFS уже было много реализаций: FreeBSD, Linux, Solaris, Macos, нужно было связать все наработки. Для этого придумали feature flags, т. н. функциональные флаги. Например, взводишь флажок, что пул поддерживает LZ4 сжатие и в дальнейшем смотришь на него из кода поддерживается/не поддерживается фича (т. е. можно ли импортировать пул).

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

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

В Linux для этого есть два механизма:

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

2. KMOD модуль ядра приезжает из репозитория в бинарном виде, конкретная сборка совместима с определённой версией ABI ядра. Отсутствует риск проблем при сборке модуля, характерные для DKMS, но сопровождающие пакета с модулем должны оперативно предоставлять новые версии при появлении свежих ядер.

Разница в том, что приедет из пакета: исходный код как в DKMS или сразу бинарный файл как в KMOD.

Что нового в последних релизах

В версии 0.8 появилось нативное шифрование. Есть американская компания Datto, которая занимается бэкапами данных и базируется на ZFS. Они предложили реализацию нативного шифрования.

Ее плюс в том, что шифруются только данные и то, что связано с ними, а информация о датасетах и большая часть метаданных не шифруются. То есть информация на уровне DSL, о директориях и так далее, шифруется, а то, что ниже DMU и SPA, нет. Что это дает? Можно зашифровать данные на стороне клиента и, не отдавая ключ, отправить их сначала полностью, потом регулярно обновлять инкрементально, принять на стороне сервера также инкрементально без расшифровки и проверить целостность.

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

Еще одно обновление это Special Allocation Class. Предположим, что есть большое количество медленных жестких дисков плюс используется реализация Vdev RAIDZ, особенность которого в том, что он не заточен на большие IOPS. Так обеспечивается целостность, он всегда атомарен (не страшна проблема потери массива при т. н. raid write hole), но у этого есть минусы в части производительности. Читать метаданные и мелкие блоки с RAIDZ дорого.

Special Allocation Class это специальный Vdev, куда пишутся метаданные или блоки данных меньше 4 килобайт (запись данных конфигурируется). Получается, что под большие блоки данных можно использовать медленное, но дешевое HDD-хранилище, а рядом поставить SSD-диски, хранящие его по блоки метаданных и блоки небольших размеров.

Планы по развитию ZFS

ZFS файловая система, которая может работать с большинством операционных систем. Скоро появится полнофункциональная версия даже под MS Windows.

В настоящий момент в планах на развитие идет упор на производительность, к примеру на оптимизацию для NVMe. Они дорогие, хочется выжать из них максимум. ARC в данном случае не даёт сильного выигрыша, так как это дополнительные операции по копированию данных в ОЗУ. Сейчас, если поставить 5 10 NVMe, мы быстро упремся в производительность ОЗУ и ЦПУ. Специально для этого случая ведутся работы по поддержке direct io с целью исключения лишних операций в ARC.

Другие направления больше удобства для конечных пользователей-частных лиц. При использовании ZFS дома есть проблема в том, что объем наращивается либо установкой нового Vdev, либо заменой всех дисков в Vdev на большие (ZFS видит, что диски увеличились и может использовать дополнительное пространство). То есть собрав один RAIDZ, мы не можем добавить к нему на ходу еще один диск. Уже в альфе патч, который позволяет это делать.

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

Проблема в том, что жесткие диски, наращивая объем в 20 ТБ и более, не сильно наращивают производительность с точки зрения пропускной способности. У любого диска есть количество ошибок на каждый терабайт чтения, официально заявленное производителем (URE unrecoverable read error rate). И любой RAID 5 и более с дисками больше 3 ТБ практически гарантированно развалится при пересборке, когда один диск вылетел и мы читаем с оставшихся. Риск ошибки чтения хотя бы одного не того байта с этих 3 ТБ каждого диска просто огромен (для потребительских HDD стандартом является одна ошибка чтения на каждые 10¹⁴ бит, т.е. на каждые ~11 ТиБ). Когда мы пересобираем RAIDZ, а это тот же RAID 5, 6 и так далее, есть та же проблема.

Конечно, можно увеличить количество дисков, которое мы можем потерять: поставить RAIDZ 2, RAIDZ 3 сколько копий будет хранится, но мы не решаем вопрос производительности восстановления. Новый диск, который мы меняем, по-прежнему является узким горлышком. Эти 15 20 ТБ будут восстанавливаться в лучшем случае со скоростью 200 МБ/сек (а в реалистичном около 100 МБ/сек, а то и меньше). Несколько суток на восстановление одного диска это очень долго.

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

По сути, это RAID 5 или RAIDZ, повернутый на 90 градусов. Мы в рамках физических дисков имеем виртуальные сущности. Если вылетает один диск, то на других зарезервировано свободное место, можно восстановить вылетевший диск со скоростью, которая зависит от количества элементов в массиве. То есть когда у нас десять блоков данных, можно восстанавливаться сразу на десять дисков. Такой подход увеличивает скорость восстановления.

Например, мы собрали dRAID, аналогичный RAIDZ2 с одним spare диском, который позволяет вылететь двум дискам, один вылетел, осталось девять. Пока мы не вставили новый диск, размазываем данные на пустое зарезервированное пространство других дисков в группе. И так восстанавливаем ситуацию: дисков по-прежнему девять, но вылететь может уже два, а не один, ведь блоки с вылетевшего диска уже разъехались по уцелевшим оставшимся. Таким образом снимается проблема узкого горлышка в виде производительности spare диска, технически он теперь размазан на другие диски массива.

По этой же причине теперь можно задействовать spare диск, в RAIDZ он бы стоят без дела, а в dRAID он является активным участником, т.к. размазан по всем дискам.

Послесловие

В связи с тем, что ZFS пережил существование в разных компаниях и ОС, идёт активная централизация кода и документаций в проекте OpenZFS. Приглашаю желающих к созданию единой документации по проекту, буду рад вашим PR!

Полезные ссылки:

• Проект openzfs на github.

• Общая документация.

• Newcomer Resources.

• Developer resources.

• Неофициальный telegram-чат сообщества OpenZFS на русском.

Также, как я уже говорил, в основном блочном и объектном хранилище Mail.ru Cloud Solutions, которое разрабатывают коллеги в моей команде, хранение устроено по-другому, об объектном хранилище недавно подробно рассказал наш архитектор Монс Андерсон: Архитектура S3. 3 года эволюции Mail.ru Cloud Storage.

Коллеги пишут про хранение данных:

1. Пример event-driven приложения на основе вебхуков в объектном S3-хранилище Mail.ru Cloud Solutions.

2. Больше чем Ceph: блочное хранилище облака MCS.

3. Наш Телеграм-канал с новостями об обновлениях S3-хранилища и других продуктов.

P.S. Наш проект ищет разработчиков на Go в команду Identity Access Management. Из интересного разработка на open source, highload, Kubernetes, распределенные системы. А полный список наших вакансий здесь.

Поверь своим глазам и тому что видишь на Дашборде

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

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

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

Уверенность в актуальности витрин данных

Прежде всего мы хотим убедиться в том, что пользовательские витрины содержат актуальные на момент времени данные:

• К 10 утра каждого дня у нас рассчитаны витрины за полные прошлые сутки

• Чтение из источников идет в ногу со временем и отставание не превышает 8 часов

• Все источники продолжают слать лог изменений в DWH

Выходит, задача QA формулируется следующим образом:

• Покажи мне все витрины данных, в которых время актуальности отстает от ожидаемого

Реализация для Хранилища:

• В конфигурационном файле .yml добавим параметр freshness:

freshness:   warn_after: {count: 4, period: hour}   error_after: {count: 8, period: hour} loaded_at_field: "__etl_loaded_at"

• Для каждого теста будет выполнен простой шаблонизированный SQL-запрос:

select max({{ loaded_at_field }}) as max_loaded_at, {{ current_timestamp() }} as snapshotted_atfrom {{ source }}where {{ filter }}

• Собранные метрики можно визуализировать в сводный отчет:

Мониторинг метрик расчета Витрин Данных

Неминуемо при проектировании сложных витрин, кубов, будут возникать проблемные места:

• Баги и просчеты в формулах расчета метрик

• Неожиданные данные (edge cases), которые могут нарушать заложенную логику

• Бутылочное горлышко (bottleneck) в операциях расчетов

Они могут привести к серьезным последствиям:

• Ошибки: Таймаут, Out of Memory, Disk Full

• Замедление всего пайплайна загрузок и расчетов и нарушение SLA

Для контроля можно собирать следующие метрики:

• Время, затраченное на формирование витрины + его динамика (скачки времени расчета)

• Потребление ресурсов CPU

• Потребление ресурсов диска и сети - IO, network

Лидеры этого рейтинга становятся первыми кандидатами на оптимизацию и рефакторинг.

Задача формулируется следующим образом:

• Покажи мне те витрины, формирование которых требует излишне много ресурсов

Реализация для Хранилища:

• Снять метрики расчетов витрин

• Отрисовать дашборд

• Настроить алерты

+pre-hook: "{{ logging.log_model_start_event() }}"+post-hook: "{{ logging.log_model_end_event() }}"

Валидация схемы данных в основе тестирования

Современные Хранилища предполагают структуру, строгую типизацию, поколоночное хранение и компрессию данных. Структура данных суть схема - набор атрибутов, их типов, ограничений, например, PRIMARY KEY, FOREIGN KEY, NOT NULL, UNIQUE.

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

Какие базовые ожидания можем иметь относительно данных:

• Есть ли в данных пропуски (NULL) там, где их быть не должно?

• Какова атомарность моих данных (UNIQUE ID строки)?

• Как таблицы соотносятся между собой (PRIMARY - FOREIGN KEYS)?

• Есть ли записи, выходящие из списка допустимых значений(ACCEPTED VALUES)?

Задача QA формулируется следующим образом:

• Покажи мне те витрины и источники, данные в которых нарушают наши ожидания

Реализация для Хранилища:

• В конфигурационном файле .yml добавим параметр tests:

- name: dim_cars     description: Wheely partners cars.     columns:         - name: car_id           tests:               - not_null               - unique         - name: status           tests:               - not_null               - accepted_values:                   values: ['deleted', 'unknown', 'active', 'end_of_life', 'pending', 'rejected'                           , 'blocked', 'expired_docs', 'partner_blocked', 'new_partner']   

• Для каждого теста будет выполнен простой шаблонизированный SQL-запрос

-- NOT NULL testselect count(*) as validation_errorsfrom "wheely"."dbt_test"."dim_cars"where car_id is null -- UNIQUE testselect count(*) as validation_errorsfrom (   select       car_id   from "wheely"."dbt_test"."dim_cars"   where car_id is not null   group by car_id   having count(*) > 1) validation_errors -- ACCEPTED VALUES testwith all_values as (   select distinct       status as value_field   from "wheely"."dbt_test"."dim_cars"),validation_errors as (   select       value_field   from all_values   where value_field not in (       'deleted','unknown','active','end_of_life','pending','rejected','blocked','expired_docs','partner_blocked','new_partner'   ))select count(*) as validation_errorsfrom validation_errors

Бизнес-логика тоже подлежит проверке

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

Несколько простых примеров:

• Сумма заказа не может быть отрицательной

• Время подачи машины по заказу строго больше времени бронирования

• Пользовательская сессия заканчивается только одним заказом, либо прерывается

• Комиссия не превышает заданного %

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

Задача QA формулируется следующим образом:

• Покажи мне те витрины данных, в которых нарушены бизнес-правила.

Реализация для Хранилища:

• В терминах SQL выразить ту ситуацию, которая описывает нарушение правил

• Сформировать тест на базе SQL-запроса

• Тест считается пройденным (PASSED) если запрос возвращает 0 записей, и проваленным (FAILED) если записей >= 1

Continuous Integration на страже мастер-ветки DWH

Хорошо, идём дальше. Над DWH мы работаем совместно всей командой. Это подразумевает скоординированность и согласованность действий. Однако нередки случаи ошибок, просчеты, невнимательности на этапе разработки, которые приводят к ошибкам в PROD-окружении после PR Merge:

• Доработка в одной части может послужить причиной ошибки в другой части

• DEV-окружение инженера может отличаться от PROD-окружения

• Запуск неоптимального кода на всех данных может привести к ошибке (например, Out of Memory)

Решение давно придумано - это использование практик тестирования в рамках Continuous Integration (CI). И его можно и нужно применять к данным!

Задача формулируется следующим образом:

• Минимизировать вероятность появления ошибок в master-ветке и PROD-окружении DWH после релизов.

Реализация для Хранилища:

• Подготовить окружение для CI (например, актуальная копия PROD-окружения, содержащая только 7 последних дней)

• Выполнить полный пересчет всех витрин и метрик без ошибок прежде чем дать возможность влить feature-ветку в master

Кросс-сверка состояния DWH и Источников

От Хранилища Данных мы ожидаем отображение актуального состояния (а также всей истории) источников данных:

• Наличие в DWH всех записей, которые присутствуют в источнике

• Точное соответствие значений атрибутов (статус, временные метки, метрики) один-к-одному

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

Задача формулируется следующим образом:

• Убедиться в том, что Хранилище находится в консистентном (согласованном) с источниками состоянии.

Эта задача имеет одну из самых сложных реализаций и может стать темой отдельной статьи, судите сами:

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

• Выгрузить все строки из источника, актуальные на текущий момент

• Загрузить строки в DWH и подготовить логику сверок

• Настроить визуализацию и уведомления

Визуальное представление с возможностью drill-down до уровня атомарных записей:

Собирая всё в единый пазл

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

• Регулярный мониторинг, сбор и анализ метрик

• Continuous Integration and Testing

• Настройка уведомлений и алертов для команды

• Проактивная работа над устранением инцидентов и причин ошибок

• Управление ожиданиями пользователей в случае возникновения проблем (У нас всё под контролем)

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

Обширный набор тем, связанных с обработкой, хранением, тестированием данных изучается в рамках курса Data Engineer в OTUS, запуск которого состоится уже совсем скоро.

Как преподаватель курса я приглашаю вас 4 ноября в 20:00 на День Открытых Дверей курса Data Engineer. Приходите на вебинары в OTUS знакомиться со мной и другими экспертами, будем ждать.

Что почитать еще

Напоследок я оставлю вам несколько ссылок на смежную тематику для дальнейшего изучения:

1. Data Build Tool или что общего между Хранилищем Данных и Смузи - обзор DBT на русском языке

2. The farm-to-table testing framework - комплексный подход к тестированию качества данных

3. Tests - Related reference docs - раздел документации DBT, посвященный тестированию

4. How to get started with data testing - тред на dbt discourse с обсуждением по теме

5. Data testing: why you need it - взгляд на преимущества тестирования данных

6. Manual Work is a Bug - несколько слов о принципах автоматизации и DRY

Уже более двух лет data build tool активно используется в компании Wheely для управления Хранилищем Данных. За это время накоплен немалый опыт, мы на тернистом пути проб и ошибок к совершенству в Analytics Engineering.

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

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

Структура превыше всего

Измерять сложность Хранилища Данных в количестве гигабайт сегодня - дурной тон

Налить кучу тяжело интерпретируемых данных без метаинформации (читай мусора) не составит большого труда. Гораздо сложнее из этих данных получить что-то осмысленное. То, на что с уверенностью могут опираться business stakeholders, принимая решения. То, что регулярно измеряется на предмет качества и актуальности. Наконец, то, что соответствует принципам Keep it simple (KISS) и Dont repeat yourself (DRY).

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

Зеленым цветом слой источников данных sources. Это реплики структур и таблиц из исходных систем, которые поддерживаются ELT-сервисом. Данные синхронизируются 1:1 с источником, без каких-либо преобразований. Опциональный слой flatten позволяет вложенные иерархические структуры (JSON) превратить в плоские таблицы.

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

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

Кульминацией являются data marts или Витрины Данных, которые используются Data Scientists / Business Users / BI tools. Слой, в свою очередь, делится на:

• dimensions: пользователи, компании, машины, водители, календарь

• facts: поездки, транзакции, сеансы, продвижения, коммуникации

• looker: материализованные представления и витрины, оптимизированные под чтение из BI-системы

Число 120 из заголовка публикации относится только к витринам данных:

Running with dbt=0.19.0Found 273 models, 493 tests, 6 snapshots, 4 analyses, 532 macros, 7 operations, 8 seed files, 81 sources, 0 exposures

На текущий момент в проекте:

• 273 модели во всех перечисленных слоях

• 493 теста на эти модели, включая not null, unique, foreign key, accepted values

• 6 снапшотов для ведения истории SCD (slowly changing dimensions)

• 532 макроса (большая часть из которых импортирована из сторонних модулей)

• 7 operations включая vacuum + analyze

• 81 источник данных

Помимо разбиения на логические слои, Хранилище можно нарезать по бизнес-областям. В случае необходимости есть возможность пересчитать или протестировать витрины, относящиеся к вертикалям Marketing / Supply / Growth / B2B. Например, в случае late arriving data или ручных корректировках маппингов/справочников.

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

dbt run -m +tag:marketing

Этот же принцип лежит в основе организации кодой базы. Все скрипты объединены в директории с общей логикой и понятными наименованиями. Сложно потеряться даже при огромном количестве моделей и витрин:

.|____staging| |____webhook| |____receipt_prod| |____core| |____wheely_prod| |____flights_prod| |____online_hours_prod| |____external| |____financial_service|____marts| |____looker| |____dim| |____snapshots| |____facts|____flatten| |____webhook| |____receipt_prod| |____wheely_prod| |____communication_prod|____audit|____sources|____aux| |____dq| | |____marts| | |____external|____intermediate

Оптимизация физической модели

Логическое разделение на слои и области - это замечательно. Но не менее важно и то, как эта логика ложится на конкретную СУБД. В случае Wheely это Amazon Redshift.

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

На этапе обогащения данных важна скорость склейки таблиц (join performance), поэтому данные сегментированы и отсортированы в одинаковом ключе, начиная с sources. Это позволит использовать самый быстрый вид соединения - sort merge join:

{{config(materialized='table',unique_key='request_id',dist="request_id",sort="request_id")}}

Витрина же хранится отсортированной по самым популярным колонкам доступа: city, country, completed timestamp, service group. В случае правильного подбора колонок Interleaved key позволяет значительно оптимизировать I/O и ускорить отрисовку графиков в BI-системах.

{{config(materialized='table',unique_key='request_id',dist="request_id",sort_type='interleaved',sort=["completed_ts_loc", "city", "country", "service_group", "is_airport", "is_wheely_journey"])}}

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

staging:+materialized: view+schema: staging+tags: ["staging"]

Другой интересный пример результаты проверки качества данных. Выбранный тип материализации ephemeral, т.е. на уровне СУБД не будет создано ни таблицы, ни представления. При каждом обращении к такой модели будет выполнен лишь запрос. Результат такого запроса является слагаемым в суммарной таблице, содержащей метрики всех проверяемых объектов.

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

{{config(materialized='incremental',sort='metadata_timestamp',dist='fine_id',unique_key='id')}}with fines as (selectfine_id, city_id, amount, details, metadata_timestamp, created_ts_utc, updated_ts_utc, created_dt_utcfrom {{ ref('stg_fines') }}where true-- filter fines arrived since last processed time{% if is_incremental() -%}and metadata_timestamp > (select max(metadata_timestamp) from {{ this }}){%- endif %}),...

Кстати, о принципах MPP и о том, как выжать максимум из аналитических СУБД я рассказываю на курсах Data Engineer и Data Warehouse Analyst (скоро первый запуск!).

SQL + Jinja = Flexibility

Высокоуровневый декларативный язык SQL прекрасен сам по себе, но вкупе с движком шаблонизации Jinja он способен творить чудеса.

Любой код, который вы используете с dbt проходит этапы compile & run. На этапе компиляции интерпретируются все шаблонизированные выражения и переменные. На этапе запуска код оборачивается в конструкцию CREATE в зависимости от выбранного типа материализации и фишек используемой СУБД: clustered by / distributed by / sorted by. Рассмотрим пример:

{{config(materialized='table',dist="fine_id",sort="created_ts_utc")}}with details as (  select{{dbt_utils.star(from=ref('fine_details_flatten'),except=["fine_amount", "metadata_timestamp", "generated_number"])}}from {{ ref('fine_details_flatten') }}where fine_amount > 0)select * from details

with details as (select  "id","fine_id","city_id","amount","description","created_ts_utc","updated_ts_utc","created_dt_utc"from "wheely"."dbt_test_akozyr"."fine_details_flatten"where fine_amount > 0)select * from details

create table"wheely"."dbt_test_akozyr"."f_chauffeurs_fines"diststyle key distkey (fine_id)compound sortkey(created_ts_utc)as (with details as (select"id","fine_id","city_id","amount","description","created_ts_utc","updated_ts_utc","created_dt_utc"from "wheely"."dbt_test_akozyr"."fine_details_flatten"where fine_amount > 0)select * from details);

Ключевым моментом является тот факт, что пишете вы только лаконичный шаблонизированный код, а остальным занимается движок dbt. Написание boilerplate code сведено к минимуму. Фокус инженера или аналитика остается преимущественно на реализуемой логике.

Во-вторых, как происходит выстраивание цепочки связей и очередности создания витрин, продемонстрированные на картинках выше? Внимательный читатель уже заметил, что в рамках написания кода при ссылках на другие модели нет хардкода, но есть конструкция {{ ref('fine_details_flatten') }} ссылка на наименование другой модели. Она и позволяет распарсить весь проект и построить граф связей и зависимостей. Так что это тоже делается абсолютно прозрачным и органичным способом.

С помощью шаблонизации Jinja в проекте Wheely мы гибко управляем схемами данных и разделением сред dev / test / prod. В зависимости от метаданных подключения к СУБД будет выбрана схема и период исторических данных. Продакшн модели создаются в целевых схемах под технической учетной записью. Аналитики же ведут разработку каждый в своей личной песочнице, ограниченной объемом данных в 3-е последних суток. Это реализуется с помощью макроса:

{% macro generate_schema_name_for_env(custom_schema_name, node) -%}{%- set default_schema = target.schema -%}{%- if target.name == 'prod' and custom_schema_name is not none -%}{{ custom_schema_name | trim }}{%- else -%}{{ default_schema }}{%- endif -%}{%- endmacro %}

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

Не повторяйся лучше подготовь макрос

Однотипный код, повторяющиеся обращения и действия, зачастую реализуемые по принципу copy-paste нередко являются причиной ошибок и багов. В Wheely мы придерживаемся принципа Do not repeat yourself и любой сколько-нибудь похожий код шаблонизируем в макрос с параметрами. Писать и поддерживать такой код становится сплошным удовольствием.

-- currency conversion macro{% macro convert_currency(convert_column, currency_code_column) -%}( {{ convert_column }} * aed )::decimal(18,4) as {{ convert_column }}_aed, ( {{ convert_column }} * eur )::decimal(18,4) as {{ convert_column }}_eur, ( {{ convert_column }} * gbp )::decimal(18,4) as {{ convert_column }}_gbp, ( {{ convert_column }} * rub )::decimal(18,4) as {{ convert_column }}_rub, ( {{ convert_column }} * usd )::decimal(18,4) as {{ convert_column }}_usd{%- endmacro %}

select...-- price_details, r.currency, {{ convert_currency('price', 'currency') }}, {{ convert_currency('transfer_min_price', 'currency') }}, {{ convert_currency('discount', 'currency') }}, {{ convert_currency('insurance', 'currency') }}, {{ convert_currency('tips', 'currency') }}, {{ convert_currency('parking', 'currency') }}, {{ convert_currency('toll_road', 'currency') }}, {{ convert_currency('pickup_charge', 'currency') }}, {{ convert_currency('cancel_fee', 'currency') }}, {{ convert_currency('net_bookings', 'currency') }}, {{ convert_currency('gross_revenue', 'currency') }}, {{ convert_currency('service_charge', 'currency') }}...from {{ ref('requests_joined') }} r

По большому счету, макрос это просто вызов функции с передачей аргументов, на уже знакомом вам диалекте Jinja. Результатом работы макроса является готовый к исполнению SQL-скрипт. Макрос для кросс-сверки значений в колонках:

-- compare two columns{% macro dq_compare_columns(src_column, trg_column, is_numeric=false) -%}{%- if is_numeric == true -%}{%- set src_column = 'round(' + src_column + ', 2)' -%}{%- set trg_column = 'round(' + trg_column + ', 2)' -%}{%- endif -%}CASEWHEN {{ src_column }} = {{ trg_column }} THEN 'match'WHEN {{ src_column }} IS NULL AND {{ trg_column }} IS NULL THEN 'both null'WHEN {{ src_column }} IS NULL THEN 'missing in source'WHEN {{ trg_column }} IS NULL THEN 'missing in target'WHEN {{ src_column }} <> {{ trg_column }} THEN 'mismatch'ELSE 'unknown'END{%- endmacro %}

В макрос можно запросто записать даже создание UDF-функций:

-- cast epoch as human-readable timestamp{% macro create_udf() -%}{% set sql %}CREATE OR REPLACE FUNCTION {{ target.schema }}.f_bitwise_to_delimited(bitwise_column BIGINT, bits_in_column INT)RETURNS VARCHAR(512)STABLEAS $$# Convert column to binary, strip "0b" prefix, pad out with zeroesif bitwise_column is not None:b = bin(bitwise_column)[2:].zfill(bits_in_column)[:bits_in_column+1]return belse:None$$ LANGUAGE plpythonu;CREATE OR REPLACE FUNCTION {{ target.schema }}.f_decode_access_flags(access_flags INT, deleted_at TIMESTAMP)RETURNS VARCHAR(128)STABLEAS $$SELECT nvl(DECODE($2, null, null, 'deleted'), DECODE(LEN(analytics.f_bitwise_to_delimited($1, 7))::INT, 7, null, 'unknown'), DECODE(analytics.f_bitwise_to_delimited($1, 7)::INT, 0, 'active', null), DECODE(SUBSTRING(analytics.f_bitwise_to_delimited($1, 7), 1, 1), 1, 'end_of_life', null), DECODE(SUBSTRING(analytics.f_bitwise_to_delimited($1, 7), 7, 1), 1, 'pending', null), DECODE(SUBSTRING(analytics.f_bitwise_to_delimited($1, 7), 6, 1), 1, 'rejected', null), DECODE(SUBSTRING(analytics.f_bitwise_to_delimited($1, 7), 5, 1), 1, 'blocked', null), DECODE(SUBSTRING(analytics.f_bitwise_to_delimited($1, 7), 4, 1), 1, 'expired_docs', null), DECODE(SUBSTRING(analytics.f_bitwise_to_delimited($1, 7), 3, 1), 1, 'partner_blocked', null), DECODE(SUBSTRING(analytics.f_bitwise_to_delimited($1, 7), 2, 1), 1, 'new_partner', null))$$ LANGUAGE SQL;{% endset %}{% set table = run_query(sql) %}{%- endmacro %}

Параметризовать можно и довольно сложные вещи, такие как работа с nested structures (иерархическими структурами) и выгрузка во внешние таблицы (external tables) в S3 в формате parquet. Эти примеры вполне достойны отдельных публикаций.

Не изобретай велосипед импортируй модули

Модуль или package - это набор макросов, моделей, тестов, который можно импортировать в свой проект в виде готовой к использованию библиотеки. На портале dbt hub есть неплохая подборка модулей на любой вкус, и, что самое главное, их список постоянно пополняется.

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

models:+pre-hook: "{{ logging.log_model_start_event() }}"+post-hook: "{{ logging.log_model_end_event() }}"

Измерение календаря собирается в одну строку, при этом набор колонок поражает:

{{ dbt_date.get_date_dimension('2012-01-01', '2025-12-31') }}

С помощью модуля dbt_external_tables я уже выстраиваю полноценный Lakehouse, обращаясь из Хранилища к данным, расположенным в файловом хранилище S3. К примеру, самые свежие курсы валют, получаемые через API Open Exchange Rates в формате JSON:

- name: externalschema: spectrumtags: ["spectrum"]description: "External data stored in S3 accessed vith Redshift Spectrum"tables:- name: currencies_oxrdescription: "Currency Exchange Rates fetched from OXR API https://openexchangerates.org"freshness:error_after: {count: 15, period: hour}loaded_at_field: timestamp 'epoch' + "timestamp" * interval '1 second'external:location: "s3://data-analytics.wheely.com/dwh/currencies/"row_format: "serde 'org.openx.data.jsonserde.JsonSerDe'"columns:- name: timestampdata_type: bigint- name: basedata_type: varchar(3)- name: ratesdata_type: struct<aed:float8, eur:float8, gbp:float8, rub:float8, usd:float8>

Ну и, конечно, ночью по расписанию работает VACUUM + ANALYZE, ведь Redshift это форк PostgreSQL. Дефрагментация, сортировка данных в таблицах, сбор статистик. Иначе говоря поддержание кластера в тонусе, пока dba спит.

dbt run-operation redshift_maintenance --args '{include_schemas: ["staging", "flatten", "intermediate", "analytics", "meta", "snapshots", "ad_hoc"]}'

Running in production: используем dbt Cloud в Wheely

dbt Cloud это платный сервис для управления проектами, основанными на движке dbt. За небольшие деньги команда получает возможность создавать окружения, конфигурировать джобы и таски, устанавливать расписание запусков, и даже полноценную IDE (среду разработки!) в браузере.

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

Во-вторых, это гибкие настройки условий запуска джобов. Начиная от простых условий с выбором дня недели и времени, продолжая кастомными cron-выражениями, и заканчивая триггером запуска через webhook. Например, именно через вебхук мы связываем в цепочку завершение выгрузок для кросс-сверки и начало расчета соответствующих витрин в Хранилище (kicked off from Airflow):

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

Сам dbt является проектом с открытым исходным кодом, и использование продукта dbt Cloud представляется очень удобным, но не обязательным. В качестве альтернативных способов можно выбрать любой другой оркестратор: Airflow, Prefect, Dagster, и даже просто cron. В своем проекте Сквозная Аналитика я организую оркестрацию при помощи Github Actions. Выходит очень занятно.

Вместо заключения

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

Сегодня бизнес и команда активно растут. Доступен ряд интересных позиций:

• Head of Data Insights - https://wheely.com/ru/careers/4425384003

• Product Analyst, Backoffice - https://wheely.com/ru/careers/4308521003

• Product Analyst, Business - https://wheely.com/ru/careers/4425290003

• Product Analyst, Chauffeur growth - https://wheely.com/ru/careers/4185132003

• Product Analyst, Marketplace - https://wheely.com/ru/careers/4425328003

• Product Analyst, Passenger growth - https://wheely.com/ru/careers/4194291003

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

Также время от времени я провожу вебинары и выступления, на которых подробнее рассказываю о своей работе и проектах. Следить за моими публикациями можно в телеграм-канале Technology Enthusiast https://t.me/enthusiastech

Пишите, задавайте вопросы и, конечно, пробуйте dbt в своих проектах!