Методология успеха реализации Synapse: оценка проекта для бессерверного пула SQL

Примечание.

Эта статья входит в серию статей, посвященных успешному внедрению Azure Synapse, предпосылки к которому закладываются изначально. Общие сведения о серии см. в статье "Внедрение Azure Synapse — успешно по умолчанию".

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

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

Анализ несоответствий

При планировании реализации бессерверных пулов SQL в Azure Synapse сначала необходимо убедиться в том, что бессерверные пулы подходят для ваших рабочих нагрузок. Необходимо учитывать эффективность операционных процессов, уровень производительности, надежность и безопасность.

Эффективность работы

Для обеспечения эффективности операционных процессов оцените следующие моменты.

• Среда разработки решений. В рамках этой методологии используется оценка среды разработки решений. Определите, как среды (среда разработки, среда тестирования и рабочая среда) поддерживают разработку решения. Как правило, вы найдете рабочие и нерабочие среды (для разработки и тестирования). Рабочие области Synapse должны находиться во всех средах. В большинстве случаев вы обязаны разделить пользователей и рабочие нагрузки в рабочей среде и среде разработки/тестирования.
• Проектирование рабочей области Synapse. В рамках этой методологии вы оцениваете архитектуру рабочей области Synapse. Определите архитектуру рабочих областей, которые были созданы для вашего решения. Познакомьтесь с проектом и узнайте, будут ли в решении использоваться одна или несколько рабочих областей. Узнайте, почему выбрана одна или несколько рабочих областей. Архитектура с несколькими рабочими областями часто выбирается для реализации строгих границ безопасности.
• Развертывание. Бессерверный SQL доступен по запросу с каждой рабочей областью Synapse, поэтому для его развертывания не требуется никаких дополнительных действий. Проверьте региональную близость службы и учетной записи Azure Data Lake Storage 2-го поколения, к которой она подключена.
• Мониторинг. Проверьте, достаточно ли встроенного мониторинга и необходимо ли разворачивать внешние службы для хранения исторических данных журнала. Данные журнала позволяют анализировать изменения в производительности и определять оповещения или запускаемые действия для конкретных обстоятельств.

Оптимизация производительности

В отличие от традиционных ядер СУБД, бессерверный SQL не использует собственный оптимизированный уровень хранения. По этой причине его производительность сильно зависит от того, как организованы данные в ADLS 2-го поколения. Для обеспечения оптимизации производительности оцените следующие моменты.

• Прием данных. Проверьте, как данные хранятся в озере данных. На производительность влияют размеры файлов, количество файлов и структура папок. Имейте в виду, что хотя некоторые размеры файлов могут быть оптимальными для бессерверного SQL, эти размеры могут вызвать проблемы с эффективной обработкой и использованием данных в других подсистемах и приложениях. Вам потребуется оценить структуру хранилища данных и проверить его для всех потребителей данных, включая бессерверный SQL и любые другие средства обработки данных, которые входят в состав решения.
• Размещение данных. Оцените, унифицирован ли ваш проект и определены ли общие шаблоны для размещения данных. Убедитесь, что ветвление каталогов поддерживает ваши требования к безопасности. Существует несколько распространенных шаблонов, которые помогут упорядочить данные временных рядов. Независимо от выбранного шаблона убедитесь в том, что этот шаблон поддерживается другими подсистемами и рабочими нагрузками. Кроме того, проверьте, может ли этот шаблон помочь в автоматическом обнаружении секций для приложений Spark и внешних таблиц.
• Форматы данных. В большинстве случаев бессерверный SQL обеспечивает наилучшую производительность и совместимость на уровне функций за счет использования формата Parquet. Проверьте требования к производительности и совместимости. Хотя Parquet повышает производительность благодаря лучшему сжатию и уменьшению числа операций ввода-вывода (так как считываются только столбцы, необходимые для анализа), он требует большего объема вычислительных ресурсов. Кроме того, поскольку некоторые исходные системы изначально не поддерживают Parquet в качестве формата экспорта, это может привести к дополнительным этапам преобразования в конвейерах и (или) зависимостям в общей архитектуре.
• Исследование. Каждая отрасль имеет свои особенности. Однако во многих случаях существуют общие шаблоны доступа к данным, используемые в наиболее часто выполняемых запросах. Шаблоны обычно включают фильтрацию и агрегирование по датам, категориям или географическим регионам. Определите наиболее распространенные критерии фильтрации и соотносите их с объемом данных, которые считываются и удаляются наиболее часто выполняемыми запросами. Проверьте, соответствует ли информация об озере данных требованиям к исследованию и ожиданиям. Для запросов, определенных в проекте и оценке, проверьте, можно ли устранить ненужные участки в параметре пути OPENROWSET, а также стоит ли создать дополнительные индексы (при наличии внешних таблиц).

Надежность

Для обеспечения надежности оцените следующие моменты.

• Доступность. Проверьте все требования к доступности, выявленные на этапе оценки. Хотя для бессерверного SQL отсутствуют конкретные соглашения об уровне обслуживания, для выполнения каждого запроса устанавливается время ожидания в 30 минут. Определите самые длительные запросы из вашей оценки и проверьте их на соответствие проекту бессерверного SQL. 30-минутное время ожидания может не соответствовать ожиданиям рабочей нагрузки и может быть расценено как проблема со службой.
• Согласованность. Бессерверный SQL предназначен в основном для рабочих нагрузок чтения. Поэтому проверьте, были ли выполнены все проверки согласованности во время подготовки и формирования данных в озере данных. Следите за новыми возможностями, такими как уровень хранения с открытым исходным кодом Delta Lake, который обеспечивает поддержку атомарность, согласованность, изоляцию и устойчивость транзакций (ACID). Эта возможность позволяет реализовать эффективные лямбда-архитектуры или каппа-архитектуры для поддержки вариантов использования с потоковыми и пакетными данными. Не забудьте проверить проект на возможность применения новых функций, но не за счет сроков реализации или затрат проекта.
• Резервное копирование. Просмотрите все требования к аварийному восстановлению, выявленные во время оценки. Проверьте их на соответствие проекту бессерверного SQL для восстановления. Бессерверный SQL не имеет собственного уровня хранения и требует обработки моментальных снимков и резервного копирования данных. Бессерверный SQL обращается к внешнему хранилищу данных (ADLS 2-го поколения). Проверьте архитектуру восстановления в вашем проекте для этих наборов данных.

Безопасность

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

Для обеспечения безопасности оцените следующие моменты.

• Хранилище данных. Используя сведения, собранные на этапе оценки, определите, нужно ли размещать типовые области озера данных (Необработанные данные, Промежуточные данные и Курируемые данные) в одной учетной записи хранения или в независимых учетных записях хранения. Последний вариант может обеспечить большую гибкость с точки зрения ролей и разрешений. Он также может увеличить число операций ввода-вывода в секунду (IOPS), которые могут потребоваться, если архитектура должна поддерживать масштабные и выполняемые одновременно рабочие нагрузки чтения и записи (например, сценарии в режиме реального времени или сценарии Интернета вещей). Проверьте необходимость дальнейшего разделения, при котором изолированные и главные области данных находятся в отдельных учетных записях хранения. Большинству пользователей не нужно обновлять или удалять данные, поэтому им не нужны разрешения на запись в озеро данных, за исключением изолированных и частных областей.
• На основе сведений об оценке определите, зависят ли какие-либо требования от функций обеспечения безопасности, таких как Always Encrypted, динамическое маскирование данных или безопасность на уровне строк. Проверьте доступность этих функций в определенных сценариях, например, при использовании с функцией OPENROWSET. Продумайте возможные обходные пути, которые могут потребоваться.
• На основе сведений об оценке определите, какие методы проверки подлинности являются оптимальными для вашей конфигурации. Рассмотрим субъекты-службы Microsoft Entra, подписанный URL-адрес (SAS) и когда и как можно использовать сквозную проверку подлинности и интегрировать их в средство исследования, выбранное клиентом. Оцените проект и убедитесь, что выбран наилучший метод проверки подлинности.

Дополнительные рекомендации

Просмотрите свой проект и проверьте, были ли реализованы рекомендации. Обратите особое внимание на оптимизацию фильтров и параметры сортировки, чтобы обеспечить правильное включение предикатов.

Следующие шаги

В следующей статье серии об успешном внедрении Azure Synapse, предпосылки к которому закладываются изначально, вы узнаете, как оценить проект пула Spark, чтобы определить проблемы и проверить соответствие проекта рекомендациям и требованиям.