Введение
Недавно я помогал крупной игровой студии разработать конвейер приема данных, который ежедневно обрабатывает несколько ГБ новых данных об активности в приложении. Последние данные необходимо эффективно вводить в золотую таблицу масштаба TB с помощью Delta и Databricks Lake House. У меня был сеанс с командой игровой студии, где мы обсуждали различные варианты оптимизации, доступные для столов Delta, которые могут принести пользу более широкой аудитории.
Задача, с которой столкнулась игровая студия, включала масштабируемость, надежность и непрерывность бизнеса. Их золотой набор данных стоимостью в ТБ находится в хранилище данных, которое не оптимизировано и не предназначено для обработки большого объема пакетного трафика и выполнения upsert. Текущий конвейер был ненадежен, а в хранилище данных постоянно возникали перебои.
Отключения отрицательно сказывались на непрерывности бизнеса, задерживая принятие решений на основе данных.
Каждая новая запись содержит более 400 полей. Им необходимо обновлять эти записи в больших объемах и с высокой скоростью, с минимальными затратами и без привязки к поставщику. Версии также имеют решающее значение для их соблюдения. Им необходимо вести историю изменений за последние 60 дней. Хранение всех этих данных в хранилище данных имеет серьезные финансовые последствия. Это повлияет на использование в будущем, если у вас есть варианты использования AI и ML, которые вы хотите запустить, поскольку выход данных из хранилищ также будет дорогостоящим.
Delta и Databricks Lakehouse соответствуют всем их требованиям. В течение трех недель был создан новый конвейер, который сейчас тестируется и развертывается в рабочей среде без дополнительных администраторов или разработчиков. Всего один инженер разработал этот новый трубопровод!
Delta — это мощная технология, разработанная Databricks и предоставленная сообществу разработчиков открытого исходного кода. Тем не менее, Databricks по-прежнему является лучшим местом для создания конвейеров данных с поддержкой машинного обучения и искусственного интеллекта в масштабе. Многие внутренние оптимизации и улучшения производительности доступны только на платформе Databricks.
Варианты оптимизации
ОПТИМИЗИРОВАТЬ
Помогает быстрее читать таблицы. Сжимает небольшие файлы в файлы размером 1 ГБ или файлы, содержащие 10 М записей. Оптимизация является идемпотентной операцией. Вы можете управлять размером файла, который создает оптимизация, установив maxFileSize. Файлы, которые достигли верхнего предела размера 1 ГБ или 10 М записей, не будут участвовать ни в какой дальнейшей операции оптимизации. Если в дельта-таблицу добавляются новые данные, будут участвовать файлы, не достигшие предела в 10 М записей или 1 ГБ.
ОПТИМИЗАЦИЯ+ZЗаказать
Помогает при пропуске данных, использует разбиение по диапазонам, кривую Гильберта в предварительном просмотре, поддерживает частичное приращение. Не является идемпотентом. Помогает улучшить операции чтения и слияния таблиц. Если есть дельта-таблица и вы вызываете для нее zorder, сначала файлы будут сжаты и записаны в файлы большего размера, как это делает optimize, а затем эти файлы присоединяются к логическому объекту, называемому zcube. Максимальный размер zcube составляет 100 ГБ. Представьте, что вы оптимизируете zorder один раз в таблице, а позже новые данные добавляются в таблицу Delta, при повторном запуске оптимизации zorder сначала будет проверен размер zcube, чтобы понять, составляет ли он 100 ГБ или нет. Это проверит, составляют ли данные в текущих оптимизированных файлах 100 ГБ или нет. Если объем данных составляет менее 100 ГБ, то вновь добавленные данные и существующие данные полностью перезаписываются для обеспечения совместной локализации данных. Если zcube имеет размер 100 ГБ, создается новый zcube. Это все происходит в фоновом режиме.
Автооптимизация
Оптимизированная запись = полезно улучшить операцию записи в целом. Создает файлы размером 128 МБ вместо 1 ГБ, который делает традиционная оптимизация. Мы можем изменить размер файла. если наши операции с таблицей требуют интенсивной записи, мы можем использовать меньший размер каждого файла (не меньше 32 МБ). Если таблица предназначена для чтения, оставьте ее на уровне 128 МБ. Теперь эта операция не выполняет автоматическое zorder для новых данных. В результате запрос ключа в конце дня, который изначально является частью вашего zorder, даст другую производительность для ваших старых данных, которые были задействованы в исходном zorder, а не нет.
Auto-Compaction = происходит после завершения операции записи. Он также создает файлы размером 128 МБ. Нам не нужно запускать автоматическое сжатие, так как оно запускается автоматически в конце завершения записи/фиксации. Он проверяет, есть ли в каталоге не менее 50 файлов размером менее 128 МБ, а затем выполняет упаковку в корзину.
