Обзор
Стремясь предоставить масштабируемую и унифицированную платформу для ETL, хранения данных и анализа данных в моей компании, мы выбрали технологии Databricks + Apache Spark в Azure. Azure и Databricks оказались полезными для ускорения инноваций, предоставив сообществу специалистов по обработке и анализу данных высокопроизводительную платформу данных и аналитики.
Внедрение блоков данных Azure ускорилось, каждому пользователю и команде была предоставлена свобода создавать и изменять требования к вычислительным ресурсам. Беспрецедентный интерес к лазурным блокам данных среди специалистов по проектированию и аналитике данных, а также ограниченное время для доработки некоторых функций управления привели к неконтролируемому скачку стоимости использования блоков данных. В этой статье я хочу поделиться некоторыми своими знаниями и мерами, применяемыми для оптимизации среды блоков данных с точки зрения затрат.
концепции Azure Databricks
Те, у кого есть базовые знания о блоках данных и концепциях, могут перейти к разделу обучения. В противном случае вот краткий обзор концепций блоков данных Azure.
Блоки данных Azure предлагаются как платформа как услуга.
Рабочее пространство Databricks — это среда для доступа ко всем вашим ресурсам Databricks. Рабочая область организует объекты (блокноты, библиотеки, информационные панели и эксперименты) в папки и обеспечивает доступ к объектам данных и вычислительным ресурсам (кластеры блоков данных). Ценовая категория Workspace может быть стандартной или премиальной. Для платформ корпоративного класса рекомендуется ценовая категория «Премиум».
Кластеры Databricks бывают двух типов — интерактивные кластеры и кластеры заданий. Каждый тип кластера может иметь два режима — стандартный и высокий параллелизм.
В кластерах интерактивных блоков данных размещаются рабочие нагрузки по анализу данных. Интерактивные кластеры с высокой степенью параллелизма поддерживают несколько пользователей с высокой степенью изоляции ресурсов, безопасностью на уровне таблиц базы данных, вытеснением запросов и функциями сквозного доступа AAD.
В кластерах заданий размещаются инженеры данных и легкие рабочие нагрузки.
В то время как рабочие нагрузки Data Engineering упрощают инженерам данных создание и выполнение заданий, рабочая нагрузка Data Analytics позволяет исследователям данных исследовать, визуализировать, манипулировать и обмениваться данными и идеями в интерактивном режиме.
Ниже упомянуты некоторые из основных компонентов платформы блоков данных, которые влияют на стоимость платформы.
Аспекты инфраструктуры, такие как рабочая область, виртуальные машины, хранилище, сетевые и общедоступные IP-адреса и т. д.
Аспекты программного обеспечения, такие как искровые рабочие нагрузки и связанные блоки данных (DBU)*, которые может потреблять конкретная рабочая нагрузка. DBU — это единица вычислительной мощности, оплачиваемая за посекундное использование. Потребление DBU зависит от размера и типа экземпляра, на котором запущены Azure Databricks. Каждый из них влияет на общую стоимость блоков данных.
Обучение
Ниже приведены некоторые рекомендации, которые помогут вам контролировать стоимость блоков данных Azure и оптимизировать их использование.
Выберите правильную ценовую категорию для рабочей области Data Bricks.
Когда это возможно, предлагайте стандартные цены по сравнению с премиальными уровнями ценообразования рабочей области блоков данных для непроизводственных сред. Стоимость DBU почти в два раза превышает стандартную ценовую категорию «Премиум», которая включает управление доступом на основе ролей и конечные точки аутентификации jdbc/odbc.
Всегда подготавливайте кластеры блоков данных программно.
Используйте API вакансий. Стандартная подготовка на основе пользовательского интерфейса предполагает, что вы создаете кластеры аналитики данных и взимаете с вас плату за DBU аналитики данных, что почти вдвое превышает стоимость DBU инженерии данных.
Всегда применяйте пользовательские теги для рабочих нагрузок в целях возврата средств.
Не полагайтесь на теги по умолчанию, которые блоки данных применяют при подготовке кластера. Применяйте пользовательские теги, которые помогут упростить процесс возврата средств.
Отслеживайте и оптимизируйте использование вычислительных ресурсов.
Общие кластеры в режиме высокого параллелизма с функциями автоматического масштабирования и автоматического завершения помогают лучше использовать ресурсы и контролировать затраты.
Используйте мониторинг Ganglia в блоках данных. Повторяйте и оптимизируйте рабочие нагрузки.
Выберите оптимальные вычислительные ресурсы для рабочей нагрузки. Общая рекомендация заключается в использовании вычислений общего назначения для рабочих нагрузок ETL, памяти, оптимизированной для машинного обучения, и вычислений, оптимизированных для потоковых рабочих нагрузок.
Оцените требования к вычислительным ресурсам и DBU для конкретной рабочей нагрузки с помощью сред тестирования производительности и мониторинга Ganglia. Повторите и уточните выбор вычислительных ресурсов для определенного типа рабочей нагрузки.
В большинстве случаев вычислительные ресурсы общего назначения могут помочь с меньшими затратами. Всегда начинайте с небольших вычислений общего назначения для заданий по сравнению со специализированными вычислениями или вычислениями в памяти, где это применимо.
Время запуска кластеров обычно составляет около 5–10 минут. Для любого задания, которое требуется для выполнения в течение 5–10 минут, нет смысла создавать автоматизированный кластер заданий. Используйте общий кластер, предпочтительно интерактивный, чтобы сократить время выполнения и затраты.
Рекомендуется, чтобы каждое задание программно создавало свой собственный отдельный кластер для выполнения. По возможности используйте кластеры заданий для рабочих нагрузок Data Engineering, чтобы снизить стоимость DBU.
Архитектура и проектирование конвейера данных имеют решающее значение. Я объясню это на примере использования.
Наши конвейеры ETL обычно состоят из оркестратора, технологий организации очередей, обработки и хранения. В нашем случае мы использовали кластеры Azure Data Factory, EventHub и Azure Databricks соответственно. Потоковые задания были настроены на использование вычислений 24x7, что требовало больших затрат. Конвейер отслеживания измененных данных был настроен для каждой таблицы в источнике, сопоставленной с одной очередью концентратора событий. Для обработки сообщений из этой очереди был настроен выделенный кластер потоковой передачи. Дизайн, который работал в пользу, поскольку скорость поступления длинных данных была выше, чем скорость обработки данных. Мы использовали этот шаблонный метод почти для всех потоковых конвейеров, чтобы уменьшить сложность devops. Но вскоре мы поняли, что это нерентабельно. Были задания, которые имеют более низкую скорость поступления данных и не требуют немедленной обработки. Мы предприняли указанные ниже меры, чтобы контролировать расходы.
Преобразование потоковых заданий в пакетные/мини-пакетные задания. В зависимости от объемов данных и частоты поступления любых рабочих нагрузок сбора измененных данных рекомендуется оценить вариант преобразования потоковых заданий в пакетные задания и запускать их через равные промежутки времени. Это устранит необходимость запуска вычислений в режиме 24x7 и значительно сократит все затраты на вычисления и DBU.
Консолидация конвейеров потоковой передачи/CDC. В дополнение к преобразованию потокового задания в пакетное задание, где это применимо, рекомендуется консолидировать несколько конвейеров сбора измененных данных в единую очередь обмена сообщениями и сопоставить их с одним кластером блоков данных. Это оптимизирует использование вычислительных ресурсов в кластере и снижает использование и стоимость DBU. Архитектура очереди сообщений должна включать несколько разделов для обработки нагрузки чтения.
В будущее
Автоматизация, размещение рабочей нагрузки, правильное определение размеров и оптимизация архитектуры помогли прилично оптимизировать затраты. Зарезервированные вычислительные ресурсы могут еще больше сократить расходы. Я планирую поделиться дополнительными сведениями по мере того, как мы продвигаемся вперед по внедрению Azure DataBacks.
Это мой личный блог. Я работаю со многими талантливыми людьми изо дня в день, которые определенно внесли свой вклад в эти склонности прямо или косвенно. Хочу выразить искреннюю благодарность James, Subhransu, Sreekanth, Ugandhar, Tony, Srinivas и многим другим.
Справочник
https://azure.microsoft.com/en-us/services/databricks/
https://databricks.com/product/unified-data-analytics-platform
https://databricks.com/blog/2017/05/22/running-streaming-jobs-day-10x-cost-savings.html
