Поделиться через


Сборник схем POC Synapse: хранение данных с выделенным пулом SQL в Azure Synapse Analytics

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Это важно

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

Примените параметры миграции

Если вы переносите устаревшую систему хранилища данных в Azure Synapse, ознакомьтесь с некоторыми вопросами.

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

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

Определение текущих точек боли

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

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

Затем необходимо задать критерии успешного выполнения POC.

Установка условий успешности POC

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

Помните, что POC должен быть коротким и сосредоточенным усилием, чтобы быстро доказать или проверить ограниченный набор концепций. Если у вас есть длинный список элементов, которые необходимо проверить, их можно разделить на несколько прототипов (Proof of Concept). PoCs могут иметь ворота между ними, чтобы определить, следует ли переходить к следующему POC.

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

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

Затем необходимо создать тестовый план.

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

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

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

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

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

Цель Тест Ожидаемые результаты
Нам нужно знать, что производительность запросов для наших больших сложных запросов отчетов будет соответствовать новым соглашениям об уровне обслуживания — последовательный тест сложных запросов
— проверка параллелизма сложных запросов к указанным соглашениям об уровне обслуживания
— запросы A, B и C завершены в 10, 13 и 21 секундах соответственно
— с 10 одновременными пользователями, запросы A, B и C завершены в 11, 15 и 23 секундах в среднем
Нам нужно знать производительность запросов для наших интерактивных пользователей. — проверка параллелизма выбранных запросов на ожидаемом уровне параллелизма 50 пользователей.
— выполнение предыдущего запроса с кэшированием результирующих наборов
— В 50 одновременных пользователей среднее время выполнения должно быть менее 10 секунд и без кэширования результирующих наборов
— При 50 одновременных пользователях ожидается, что среднее время выполнения составляет менее пяти секунд с кэшированием результирующих наборов
Нам нужно знать, могут ли существующие процессы ETL выполняться в рамках SLA. — выполнение одного или двух процессов 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 поддерживает различные варианты, рекомендуется использовать параметры по умолчанию. Параметры по умолчанию используют распределение с циклическим перебором и кластеризованный колонковый индекс. При необходимости эти параметры можно настроить позже, как описано далее в этой статье.

В следующем примере показан метод загрузки 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
);

Запрашивание

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

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

В 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 Минимальная длительность Максимальная длительность (S) Медианная продолжительность
100 1,000 5,000 3 10 5
50 5,000 5,000 3 6 4

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

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

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

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

Наиболее распространенными ошибками во время установки являются следующие:

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

Чтобы повысить производительность запросов, можно:

Тесты с добавленной стоимостью

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

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

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

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

Ниже приведен пример:

Тест Длительность теста DWU $/час за DWU Стоимость теста
Тест 1 10 мин. 1000 $12/hr $2
Тест 2 30 мин 500 $6/ч $3

В этом примере легко увидеть, что Тест 1 на DWU1000 является более экономичным при цене $2 за один запуск по сравнению с $3 за запуск другого теста.

Примечание.

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

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

Дальнейшие действия