Ограничения пропускной способности в Azure Databricks — это не проблема продукта, а скорее следствие доступности базовых виртуальных машин Azure. При создании или масштабировании кластеров они динамически выделяют виртуальные машины из Azure. Если конкретные SKU виртуальных машин в каком-либо регионе имеются в ограниченном количестве, операции с кластерами могут застопориться. Наиболее эффективный путь решения проблемы — связаться с вашей командой по работе с клиентами Microsoft, которая может инициировать процесс учета пропускной способности Azure. Прежде чем обращаться, крайне важно подготовить конкретные сведения, такие как идентификаторы подписок, желаемые регионы, семейства и SKU виртуальных машин, количество ядер, характеристики рабочей нагрузки и сроки.Понимание пропускной способности включает три уровня: инфраструктура Azure, платформа Azure Databricks и само выполнение Spark. Первый уровень, инфраструктура Azure, регулируется доступностью SKU виртуальных машин, региональным предложением и квотами vCPU подписки. Второй уровень, платформа Azure Databricks, имеет свои собственные определенные ограничения ресурсов для заданий, задач и хранилищ. Третий уровень, выполнение Spark, включает параллелизм, нехватку памяти и потребность в вводе-выводе. Проблемы с пропускной способностью часто проявляются в виде непоследовательного поведения, такого как кластеры, застрявшие в состоянии ожидания, или сбои автомасштабирования.Для диагностики проверьте причины завершения работы кластера и журналы событий, а затем сопоставьте их с журналом действий Azure. Различайте региональные нехватки пропускной способности и ограничения квот; проблемы с квотами требуют запроса на увеличение, в то время как проблемы с пропускной способностью могут потребовать изменения SKU виртуальных машин. При столкновении с немедленными ограничениями повторите операции в часы наименьшей нагрузки или переключитесь на другой SKU или семейство виртуальных машин. Рассмотрите альтернативные семейства виртуальных машин, такие как серия F для задач, ограниченных ЦП, или серия L для рабочих нагрузок с интенсивным вводом-выводом.Внедрение регионального разнообразия путем развертывания рабочих областей в нескольких регионах Azure повышает устойчивость к ограничениям пропускной способности. Кроме того, масштабирование вычислений не всегда является решением; проблемы проектирования рабочей нагрузки, такие как перекос данных или чрезмерное перемешивание, могут имитировать проблемы с пропускной способностью. Оптимизация выполнения Spark путем перераспределения, кэширования и проектирования запросов часто бывает более эффективной. Наконец, чтобы сохранить утвержденную пропускную способность, настройте пулы экземпляров для несерверных рабочих нагрузок, чтобы вычислительные ресурсы оставались активно развернутыми.