Облачные хранилища объектов, такие как Amazon S3 и Azure Blob Storage, стали одними из крупнейших и наиболее широко используемых систем хранения на планете, хранящих эксабайты данных для миллионов клиентов. Помимо традиционных преимуществ облачных сервисов, таких как выставление счетов по мере использования, экономия за счет масштаба и экспертное управление, облачные хранилища объектов особенно привлекательны, поскольку позволяют пользователям раздельно масштабировать вычислительные ресурсы и ресурсы хранения: например, пользователь может хранить петабайт данных, но запускать кластер только для выполнения запроса на несколько часов. В результате многие организации теперь используют облачные хранилища объектов для управления большими структурированными наборами данных в хранилищах данных и озерах данных.
Некоторые проблемы Delta Lake:
- Озера данных печально известны тем, что туда сбрасывается все. Иногда у нас может не быть смысла или причины для сброса данных туда; мы можем подумать, что он понадобится нам позже.
- Большая часть этого беспорядка связана с тем, что в вашем озере данных будет много маленьких файлов и разных типов данных. Поскольку существует множество небольших файлов, которые не сжаты, пытаться прочитать их в любой форме сложно, если не невозможно.
Ключевые особенности Delta Lake:
- Транзакции ACID (атомарность, согласованность, изоляция, долговечность) — с Delta вам не нужно писать код — транзакции записываются в журнал автоматически. Этот журнал транзакций является ключом и представляет собой единственный источник достоверной информации.
- Масштабируемая обработка метаданных — с легкостью обрабатывает терабайты и даже петабайты данных. Метаданные хранятся так же, как и данные, и вы можете отобразить их, используя функцию синтаксиса под названием Describe Detail, которая подробно описывает все метаданные, связанные с таблицей. Применяет всю мощь Spark к вашим метаданным.
- Принудительное применение схемы — это то, что делает Delta сильным в этой области, поскольку она обеспечивает соблюдение ваших схем. Если вы поместите схему в дельта-таблицу и попытаетесь записать в эту таблицу данные, которые не соответствуют схеме, это выдаст вам ошибку и не позволит вам записать это, предотвращая плохую запись. Методология принудительного исполнения считывает схему как часть метаданных; он просматривает каждый столбец, тип данных и т. д. и гарантирует, что то, что вы записываете в дельта-таблицу, совпадает с тем, что схема представляет из вашей дельта-таблицы — не нужно беспокоиться о записи неверных данных в вашу таблицу.
- Upserts и Deletes — эти операции обычно трудно выполнить без чего-то вроде Delta. Delta позволяет вам очень легко выполнять upserts или слияния. Слияния подобны слияниям SQL в вашей дельта-таблице, и вы можете объединять данные из другого фрейма данных в свою таблицу и выполнять обновления, вставки и удаления. Вы также можете выполнять регулярное обновление или удаление данных с помощью предиката для таблицы — то, что было почти неслыханно до Delta.
Создание озер данных:
Озеро данных — это центральное расположение, в котором хранится большой объем данных в исходном необработанном формате, а также способ организации больших объемов самых разнообразных данных. По сравнению с иерархическим хранилищем данных, в котором данные хранятся в файлах или папках, в озере данных для хранения данных используется плоская архитектура.
Озеро данных содержит большие данные из многих источников в необработанном формате. Он может хранить структурированные, полуструктурированные или неструктурированные данные, которые можно хранить в более гибком формате, чтобы мы могли преобразовывать их при использовании для аналитики, науки о данных и машинного обучения.
Проблема с озерами данных:
При работе с данными инженеры по данным, инженеры по машинному обучению и специалисты по данным сталкиваются с двумя проблемами: надежность и производительность.
Почему у этих проектов проблемы с надежностью и производительностью?
Ненадежные, низкокачественные данные приводят к снижению производительности. Данные в большинстве случаев не готовы для обработки данных и машинного обучения, поэтому группы обработки данных заняты созданием сложных конвейеров для обработки полученных данных путем разделения, очистки и обработки, чтобы сделать их полезными для обучения моделей и бизнес-аналитики.
Проблемы с надежностью:
- Неудачные задания оставляют данные в поврежденном состоянии. Это требует утомительной очистки данных после неудачных заданий. К сожалению, доступные решения для облачного хранения не обеспечивают встроенной поддержки атомарных транзакций, что приводит к неполным и поврежденным файлам в облаке, что может нарушить выполнение запросов и заданий на чтение.
- Отсутствие согласованности при смешивании операций добавления и чтения или при пакетной обработке и потоковой передаче данных в одно и то же место. Это связано с тем, что облачное хранилище, в отличие от RDMS, не совместимо с ACID.
Проблемы с производительностью:
- Несоответствие размера файла со слишком маленькими или слишком большими файлами. Наличие слишком большого количества файлов приводит к тому, что работники тратят больше времени на доступ, открытие и закрытие файлов при чтении, что влияет на производительность.
- Хотя секционирование полезно, оно может стать узким местом в производительности, если запрос выбирает слишком много полей.
Что такое Дельта-Лейк?
Delta Lake — это уровень хранения данных с открытым исходным кодом, который обеспечивает надежность озер данных. Он обеспечивает транзакции ACID, масштабируемую обработку метаданных и унифицирует потоковую и пакетную обработку данных. Delta Lake полностью совместим с API-интерфейсами Apache Spark. Вы можете легко использовать его поверх своего озера данных с минимальными изменениями, и да, это открытый исходный код! (Построен на стандартном паркете).
Delta Lake обеспечивает надежность и производительность озер данных.
Ключевые характеристики производительности:
- Сжатие. Delta Lake может повысить скорость запросов на чтение из таблицы за счет объединения небольших файлов в более крупные.
- Пропуск данных. Когда вы записываете данные в дельта-таблицу, информация собирается автоматически. Delta Lake на Databricks использует эту информацию (минимальные и максимальные значения) для ускорения запросов. Вам не нужно настраивать пропуск данных, чтобы эта функция была активирована (если применимо).
Основные характеристики надежности:
- ACID-транзакции: Наконец-то! Сериализуемые уровни изоляции гарантируют, что читатели никогда не увидят противоречивых данных, как в RDMS.
- Принудительное применение схемы.Delta Lake автоматически проверяет записываемую схему фрейма данных на совместимость со схемой таблицы. Перед записью из фрейма данных в таблицу Delta Lake проверяет, существуют ли столбцы в таблице во фрейме данных, совпадают ли типы данных столбцов и не могут ли имена столбцов отличаться (даже по регистру).
Мы собираемся использовать учебник по записной книжке, предоставленный Databricks, чтобы узнать, как мы можем использовать Delta Lake. Мы создадим стандартную таблицу с использованием формата Parquet и запустим быстрый запрос, чтобы наблюдать за ее производительностью. Затем мы создаем дельта-таблицу, оптимизируем ее и запускаем второй запрос, используя дельта-версию той же таблицы Databricks, чтобы увидеть разницу в производительности. Мы также посмотрим на историю стола.
Используемый набор данных относится к полетам авиакомпаний в 2008 году. Он содержит более 7 миллионов записей. Я буду использовать Python для этого урока, но вы можете согласиться, поскольку API-интерфейсы примерно одинаковы для любого языка.
Мы прочитаем набор данных, который изначально имеет формат CSV:
flights = spark.read.format("csv")
.option("заголовок", "true")
.option("inferSchema", "true")
.load("/databricks-datasets/asa/airlines/2008.csv")
Затем мы создадим таблицу из демонстрационных данных с помощью Parquet:
flights.write.format("паркет")
.mode(“перезаписать”)
.partitionBy("Происхождение")
.save(“/tmp/flights_parquet”)
Чтобы проверить производительность таблицы на основе паркета, мы запросим 20 крупнейших авиакомпаний с наибольшим количеством рейсов в 2008 г. по понедельникам по месяцам:
счетчик импорта из pyspark.sql.functions
flights_parquet = spark.read.format("паркет")
.load(“/tmp/flights_parquet”)
display(flights_parquet.filter("DayOfWeek = 1")
.groupBy("Месяц", "Происхождение")
.agg(count("*").alias("TotalFlights"))
.orderBy("Всего рейсов", по возрастанию=False)
.limit(20)
)
Этот запрос занял у меня около 38,94 секунды с кластером, использующим тип машины Standard_DS3_v2; Память 14 ГБ с 4 ядрами, использующая 4–8 узлов.
Теперь попробуем Дельту. Мы создадим таблицу на основе Delta, используя тот же набор данных:
рейсы.write.format («дельта»)
.режим («добавить»)
.partitionBy("Происхождение")
.save («/tmp/flights_delta»)
# Создаем дельта-таблицу
display(spark.sql("УДАЛИТЬ ТАБЛИЦУ, ЕСЛИ СУЩЕСТВУЮТ рейсы"))
display(spark.sql("СОЗДАТЬ ТАБЛИЦУ рейсов, ИСПОЛЬЗУЯ РАСПОЛОЖЕНИЕ DELTA ‘/tmp/flights_delta’»))
Прежде чем протестировать таблицу Delta, мы можем оптимизировать ее с помощью ZORDER по столбцу DayofWeek . Этот столбец используется для фильтрации данных при запросе (получение всех рейсов по понедельникам):
display(spark.sql("ОПТИМИЗАЦИЯ рейсов В ЗАКАЗЕ (День недели)"))
Хорошо, теперь мы можем проверить производительность запроса при использовании Databricks Delta:
рейсы_дельта = искра.чтение
.формат("дельта")
.load("/tmp/flights_delta")
отображать(
рейсы_дельта
.фильтр("ДеньНедели = 1")
.groupBy("Месяц","Происхождение")
.agg(количество("*")
.alias("Всего рейсов"))
.orderBy («Всего рейсов», по возрастанию = Ложь)
.лимит(20)
)
Выполнение запроса на Databricks Delta заняло всего 6,52 секунды.
ЗАКЛЮЧЕНИЕ
Delta Lake необходимо правильно поддерживать с помощью VACUME, следовать методам оптимизации и обработке метаданных, иначе это повлияет на общую производительность выполнения. Хотя Delta Lake имеет открытый исходный код, оно работает только с Databricks.
