Сборник схем по подтверждению концепции Synapse: хранение данных с использованием выделенного пула SQL в Azure Synapse Analytics

В этой статье описывается общая методология для подготовки и запуска эффективного проекта по подтверждению концепции (POC) Azure Synapse Analytics для выделенного пула SQL.

Примечание.

Эта статья является частью серии статей Сборник схем по подтверждению концепции в Azure Synapse. Общие сведения о серии см. в статье Сборник схем по подтверждению концепции в Azure Synapse.

Совет

Если вы не знакомы с выделенными пулами SQL, рекомендуется пройти схему обучения Работа с хранилищами данных с помощью Azure Synapse Analytics.

Подготовка к POC

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

Определение спонсоров и потенциальных блокирующих факторов

После знакомства с Azure Synapse пришло время убедиться, что подтверждение концепции имеет необходимую поддержку и не столкнется с какими-либо препятствиями. Вы должны:

• Определите ограничения или политики, существующие в организации, для перемещения данных в облако и хранения их в нем.
• Определите поддержку руководящего состава для проекта по облачному хранилищу данных.
• Убедитесь, что рабочая нагрузка подходит для Azure Synapse. Дополнительные сведения см. в статье Архитектура выделенного пула SQL в Azure Synapse Analytics.

Определение сроков

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

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

1. Загрузка данных: не более трех дней
2. Выполнение запросов: не более пяти дней
3. Дополнительные тесты: не более двух дней

Ниже приведено несколько советов.

• Реалистично оцените время, которое вам потребуется для выполнения задач по вашему плану.
• Поймите, что время завершения POC будет связано с размером набора данных, количеством объектов базы данных (таблиц, представлений и хранимых процедур), сложностью объектов базы данных и количеством интерфейсов, которые вы будете тестировать.
• Если вы считаете, что подтверждение концепции будет выполняться дольше четырех недель, рассмотрите возможность сокращения области охвата, чтобы сосредоточиться только на наиболее важных целях.
• До начала POC заручитесь поддержкой всех ведущих руководителей и спонсоров в отношении сроков.

После того как вы определили, что нет никаких непосредственных препятствий, и установили сроки, можно приступать к определению области высокоуровневой архитектуры.

Создание высокоуровневой архитектуры с заданной областью

Высокоуровневая будущая архитектура, скорее всего, содержит множество источников данных и потребителей данных, компонентов больших данных и, возможно, потребителей машинного обучения и данных ИИ. Чтобы цели POC были достижимыми (и не выходили за рамки установленных сроков), решите, какие из этих компонентов войдут в состав POC, а какие будут исключены.

Кроме того, если вы уже используете Azure, определите следующее:

• Все существующие ресурсы Azure, которые можно использовать во время POC. Например, ресурсы могут включать идентификатор Microsoft Entra или Azure ExpressRoute.
• Какие регионы Azure предпочитает ваша организация.
• Подписка, используемая для работы непроизводственного POC.
• Пропускная способность сетевого подключения к Azure.

  Важно!

  Убедитесь, что POC может использовать часть этой пропускной способности без негативного влияния на рабочие решения.

Применение вариантов переноса

Если вы переходите с устаревшей системы хранилища данных на Azure Synapse, примите во внимание ряд вопросов.

• Вы осуществляете миграцию и хотите внести как можно меньше изменений в существующие процессы извлечения, преобразования и загрузки (ETL) и потребление хранилища данных?
• Вы осуществляете миграцию, но хотите одновременно с этим провести масштабные улучшения?
• Вы создаете совершенно новую среду аналитики данных (иногда называемую создаваемым с нуля проектом)?

Далее необходимо рассмотреть проблемные моменты.

Определение текущих проблемных моментов

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

• Какие пробелы в текущей реализации вы планируете устранить с помощью Azure Synapse?
• Какие новые потребности бизнеса вы должны поддерживать?
• Какие Соглашения об уровне обслуживания (SLA) вы обязаны соблюдать?
• Что собой будут представлять рабочие нагрузки (например, ETL, пакетные запросы, аналитика, запросы отчетности или интерактивные запросы)?

Затем необходимо задать критерии успешной реализации POC.

Задание критериев успешной реализации POC

Определите, почему вы проводите POC, и обязательно установите четкие цели. Кроме того, важно знать, какие выходные данные вы хотите получить в результате POC, и что вы планируете с ними делать.

Помните, что подтверждение концепции должно быть коротким и целенаправленным мероприятием для быстрого подтверждения или тестирования ограниченного набора концепций. Если необходимо подтвердить длинный список пунктов, их можно распределить по нескольким POC. Между POC могут существовать точки принятия решений для определения необходимости перехода к следующему POC.

Ниже приведены некоторые примеры целей POC.

• Нам нужно знать, что производительность больших сложных запросов отчетов будет соответствовать новым Соглашениям об уровне обслуживания.
• Нам необходимо знать производительность запросов для интерактивных пользователей.
• Нам нужно знать, подходят ли нам существующие процессы ETL и где необходимо внести улучшения.
• Нам нужно знать, можно ли сократить время выполнения ETL и на сколько.
• Нам нужно знать, что Synapse Analytics имеет достаточные возможности обеспечения безопасности для надлежащей защиты данных.

Затем нужно создать план тестирования.

Создание плана тестирования

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

Доработайте тесты, добавив несколько сценариев тестирования, чтобы прояснить все возникающие вопросы по структуре таблицы.

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

Большинство планов тестирования касаются производительности и ожидаемого взаимодействия с пользователем. Ниже приведен пример плана тестирования. Важно настроить план тестирования в соответствии с бизнес-требованиями. Четкое определение целей тестирования принесет свой результат позже в этом процессе.

Цель	Тест	Ожидаемые результаты
Нам нужно знать, что производительность больших сложных запросов отчетов будет соответствовать новым Соглашениям об уровне обслуживания.	— Последовательный тест сложных запросов — Тест параллелизма сложных запросов в соответствии с заявленными Соглашениями об уровне обслуживания	— Запросы A, B и C выполнены за 10 с, 13 с и 21 с, соответственно. — При наличии десяти одновременно работающих пользователей запросы A, B и C выполнены за 11 с, 15 с и 23 с, в среднем.
Нам необходимо знать производительность запросов для интерактивных пользователей.	— Тест параллелизма выбранных запросов на ожидаемом уровне параллелизма, составляющем 50 пользователей. — Выполнение предыдущего запроса с кэшированием результирующего набора	— При наличии 50 одновременно работающих пользователей среднее время выполнения должно быть менее десяти секунд без кэширования результирующих наборов. — При наличии 50 одновременно работающих пользователей среднее время выполнения должно быть менее пяти секунд с кэшированием результирующих наборов.
Нам нужно знать, могут ли существующие процессы ETL выполняться в рамках Соглашения об уровне обслуживания.	— Выполнение одного или двух процессов ETL для имитации рабочих нагрузок	— Поэтапная загрузка в основную таблицу фактов должна выполняться менее чем за 20 минут (включая помещение на промежуточное хранение и обработку и очистку данных). — Обработка измерений должна занимать менее пяти минут.
Нам нужно знать, что хранилище данных имеет достаточные возможности обеспечения безопасности для защиты данных.	— Проверка и включение сетевой безопасности (виртуальных сетей и частных конечных точек), управление доступом (безопасность на уровне строк, динамическое маскирование данных)	— Подтверждение того, что данные никогда не покидают клиент. — Обеспечение эффективной защиты содержимого клиента.

Затем необходимо определить и проверить набор данных POC.

Определение и проверка набора данных POC

Используя тесты с заданной областью, можно определить набор данных, необходимый для их выполнения в Azure Synapse. Проверьте набор данных, учитывая следующие моменты.

• Набор данных надлежащим образом представляет рабочий набор данных с точки зрения содержимого, сложности и масштаба.
• Не используйте слишком маленький набор данных (менее 1TB), так как вы можете не добиться репрезентативной производительности.
• Не используйте слишком большой набор данных, так как POC не предназначено для выполнения полной миграции данных.
• Определите шаблон распределения, вариант индексирования и секционирование для каждой таблицы. При наличии вопросов о распределении, индексировании или секционировании добавьте тесты в POC, чтобы ответить на них. Имейте в виду, что для некоторых таблиц может потребоваться протестировать несколько вариантов распределения или индексирования.
• Уточните у владельцев бизнеса, нет ли препятствий для переноса набора данных POC в облако.
• Определите проблемы безопасности или конфиденциальности.

Важно!

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

Далее необходимо собрать команду экспертов.

Формирование команды

Определите участников команды и их приверженность поддержке POC. В число участников команды должны входить следующие лица:

• Руководитель проекта для выполнения проекта POC.
• Представитель компании для надзора за соблюдением требований и достижением результатов.
• Эксперт по данным приложения для получения данных для набора данных POC.
• Специалист по Azure Synapse.
• Советник для оптимизации тестов POC.
• Любой человек, который будет необходим для выполнения определенных задач по проекту POC, но участие которого не требуется на весь срок реализации проекта. Эти вспомогательные ресурсы могут включать администраторов сети, администраторов Azure или администраторов Microsoft Entra.

Совет

Рекомендуется пригласить эксперта, который поможет вам реализовать проект POC. В сообщество партнеров Майкрософт входят эксперты-консультанты, которые могут помочь вам оценить или внедрить Azure Synapse.

Теперь, когда вы полностью готовы, пришло время применить POC на практике.

Применение POC на практике

Важно учитывать следующие моменты:

• Реализуйте проект POC с присущей любому производственному проекту дисциплиной и строгостью.
• Проводите POC в соответствии с планом.
• Внедрите процесс запроса изменений, чтобы предотвратить расширение или изменение объема POC.

Перед запуском тестов необходимо настроить тестовую среду. Процесс состоит из четырех этапов:

1. Настройка
2. Загрузка данных
3. Выполнение запроса
4. Дополнительные тесты

Настройка

Чтобы настроить POC в Azure Synapse, выполните следующие действия.

1. Используйте это краткое руководство для подготовки рабочей области Synapse и настройки хранилища и разрешений в соответствии с планом тестирования POC.
2. Используйте это краткое руководство для добавления выделенного пула SQL в рабочую область Synapse.
3. Настройте сеть и систему безопасности в соответствии со своими требованиями.
4. Предоставьте участникам команды POC соответствующие права доступа. Сведения о проверке подлинности и авторизации для доступа к выделенным пулам SQL см. в этой статье.

Совет

Для разработки тестов кода и модульного тестирования рекомендуется использовать уровень обслуживания DW500c (или ниже). Выполнять нагрузочные тесты и тесты производительности рекомендуется с использованием уровня обслуживания DW1000c (или выше). Вы в любое время можете приостановить вычисление выделенного пула SQL, чтобы не получать счета за вычислительные ресурсы и сэкономить средства.

Загрузка данных

После настройки выделенного пула SQL выполните приведенные ниже действия по загрузке данных.

1. Загрузите данные в Хранилище BLOB-объектов Azure. Для POC рекомендуется использовать учетную запись хранения общего назначения версии 2 с локально избыточным хранилищем (LRS). Хотя существует несколько средств для переноса данных в Хранилище BLOB-объектов Azure, проще всего использовать Обозреватель службы хранилища Azure, который может копировать файлы в контейнер хранилища.
2. Загрузите данные в выделенный пул SQL. Azure Synapse поддерживает два метода загрузки T-SQL: PolyBase и инструкцию COPY. Чтобы использовать любой из методов, подключитесь к выделенному пулу SQL с помощью SSMS.

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

В следующем примере показан метод загрузки COPY:

--Note when specifying the column list, input field numbers start from 1
COPY INTO
    test_1 (Col_1 default 'myStringDefault' 1, Col_2 default 1 3)
FROM
    'https://myaccount.blob.core.windows.net/myblobcontainer/folder1/'
WITH (
    FILE_TYPE = 'CSV',
    CREDENTIAL = (IDENTITY = 'Storage Account Key' SECRET = '<Your_Account_Key>'),
    FIELDQUOTE = '"',
    FIELDTERMINATOR = ',',
    ROWTERMINATOR = '0x0A',
    ENCODING = 'UTF8',
    FIRSTROW = 2
);

Выполнение запроса

Основной целью хранилища данных является проведение аналитики. Для этого требуется выполнять запросы к хранилищу данных. Большинство POC начинается с выполнения небольшого количества репрезентативных запросов к хранилищу данных — сначала последовательно, а затем параллельно. В плане тестирования следует определить оба подхода.

Тесты последовательных запросов

Выполнять тесты последовательных запросов в SSMS очень просто. Важно делать это с привлечением пользователя с достаточно большим классом ресурсов. Класс ресурсов представляет собой предопределенное ограничение ресурсов в выделенном пуле SQL, который управляет вычислительными ресурсами и параллелизмом для выполнения запроса. Для простых запросов рекомендуется использовать предварительно определенный класс ресурсов staticrc20. Для более сложных запросов рекомендуется использовать предварительно определенный класс ресурсов staticrc40.

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

/* Use the OPTION(LABEL = '') Syntax to add a query label to track the query in DMVs */
SELECT TOP (1000)
    *
FROM
    [dbo].[Date]
OPTION (LABEL = 'Test1');

/* Use sys.dm_pdw_exec_requests to determine query execution duration (ms) */
SELECT
    Total_elapsed_time AS [Elapsed_Time_ms],
    [label]
FROM
    sys.dm_pdw_exec_requests
WHERE
    [label] = 'Test1';

Тесты параллельных запросов

После записи производительности последовательных запросов можно выполнить несколько запросов одновременно. Таким образом, можно имитировать рабочую нагрузку бизнес-аналитики, выполняемую в выделенном пуле SQL. Проще всего выполнить этот тест, скачав средство нагрузочного тестирования. Наиболее популярным средством является Apache JMeter, который является сторонним инструментом с открытым кодом.

Средство сообщает о минимальной, максимальной и медианной длительности запросов для заданного уровня параллелизма. Например, предположим, что вы хотите имитировать рабочую нагрузку бизнес-аналитики, которая создает 100 параллельных запросов. Можно настроить JMeter для выполнения этих 100 параллельных запросов в цикле, а затем проверить выполнение устойчивого состояния. Это можно сделать при включенном или выключенном кэшировании результирующего набора, чтобы оценить пригодность этой функции.

Обязательно задокументируйте результаты. Ниже приведен пример некоторых результатов.

Параллелизм	Кол-во выполнений запросов	DWU	Минимальная длительность (с)	Максимальная длительность (с)	Медианная длительность (с)
100	1000	5 000	3	10	5
50	5,000	5,000	3	6	4

Тесты смешанных рабочих нагрузок

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

Оптимизация данных

В зависимости от рабочей нагрузки запроса, выполняемой в Azure Synapse, может потребоваться оптимизировать распределения и индексы хранилища данных и повторно запустить тесты. Дополнительные сведения см. в статье Рекомендации по использованию выделенных пулов SQL в Azure Synapse Analytics.

Ниже приведены наиболее распространенные ошибки при установке.

• Большие запросы выполняются с использованием слишком низкого класса ресурсов.
• Слишком низкие DWU уровня обслуживания выделенного пула SQL для рабочей нагрузки.
• Для больших таблиц требуется хэш-распределение.

Для повышения производительности запросов можно сделать следующее.

• Создать материализованные представления, которые могут ускорить выполнение запросов с общими агрегатами.
• Реплицировать таблицы, особенно небольшие таблицы измерений.
• Распределить хэш больших таблиц фактов, объединенных или агрегированных.

Дополнительные тесты

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

• Безопасность на уровне строк
• Безопасность на уровне столбцов
• Динамическое маскирование данных
• Масштабирование внутри кластера с помощью изоляции рабочей нагрузки

Наконец, необходимо интерпретировать результаты POC.

Интерпретация результатов POC

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

Приведем пример:

Тест	Длительность теста	DWU	Долл. США/час для DWU	Стоимость теста
Test 1	10 мин.	1000	12 долл. США/час	$ 2
Тест 2	30 мин	500	6 долл. США/час	$3

На этом примере легко увидеть, что Тест 1 с DWU1000 является более экономически эффективным при стоимости 2 долл. США за тестовый запуск по сравнению с 3 долл. США за тестовый запуск.

Примечание.

Эту методологию можно также использовать для сравнения результатов разных поставщиков в рамках POC.

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

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

Исследование озера данных с помощью бессерверного пула SQL в Azure Synapse Analytics

Аналитика больших данных с использованием пула Apache Spark в Azure Synapse Analytics

Часто задаваемые вопросы о Azure Synapse Analytics