Визуализация и создание отчетов для миграций Teradata

Это четвертая из семи статей, посвященных рекомендациям по миграции из Teradata в Azure Synapse Analytics. В ней приведены рекомендации по визуализации и созданию отчетов.

Доступ к Azure Synapse Analytics с помощью сторонних средств бизнес-аналитики и средств Майкрософт

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

  • Средства Microsoft BI, такие как Power BI.

  • Приложения Office, например электронные таблицы Microsoft Excel.

  • Сторонние средства бизнес-аналитики от разных поставщиков.

  • Пользовательские приложения аналитики со встроенными функциями бизнес-аналитики.

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

  • Интерактивные средства разработки для обработки и анализа данных, такие как Записные книжки Spark в Azure Synapse, Машинное обучение Azure, RStudio, Jupyter Notebook.

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

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

  • Проверка подлинности: у пользователей должна быть возможность входить в хранилище данных и базы киоска данных в Azure Synapse.

  • Все пользователи должны быть перенесены в Azure Synapse.

  • Все группы пользователей должны быть перенесены в Azure Synapse.

  • Все роли должны быть перенесены в Azure Synapse.

  • Все привилегии авторизации, отвечающие за управлением доступом, должны быть перенесены в Azure Synapse.

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

    • Привилегии объекта базы данных, назначенные ролям
    • Роли, назначенные группам пользователей
    • Пользователи, назначенные группам пользователей и (или) ролям

Эти возможности важны для доступа к данным в перенесенной системе и более подробно рассматриваются в статье Безопасность, доступ и операции для миграций Teradata.

Совет

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

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

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

  • Структура таблицы останется прежней, если напрямую ссылаться на нее в запросах.

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

  • Исторический анализ остается неизменным.

  • По возможности типы данных должны оставаться прежними.

  • Поведение запроса остается неизменным.

  • Драйверы ODBC и JDBC протестированы на предмет того, что запросы работают так же.

Совет

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

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

Совет

Представления и запросы SQL, использующие защищаемые расширения запросов SQL, скорее всего, приведут к несовместимости, которая повлияет на отчеты и панели мониторинга бизнес-аналитики.

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

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

Совет

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

У вас может возникнуть соблазн сменить средства бизнес-аналитики, например для миграции на Power BI. Вы можете захотеть внести все эти изменения непосредственно при переносе схемы, данных, процессов извлечения, преобразования и загрузки и пр. Однако, чтобы минимизировать риск, лучше сначала перейти на Azure Synapse и обеспечить работоспособность всех необходимых компонентов, прежде чем приступать к дальнейшей модернизации.

Если ваши текущие средства бизнес-аналитики работают локально, убедитесь, что они могут подключаться к Azure Synapse через брандмауэр для проведения сравнений с обеими средами. Кроме того, если поставщик существующих средств бизнес-аналитики предлагает свой продукт в Azure, вы можете попробовать его там. То же самое относится к приложениям, которые работают в локальной среде и реализуют бизнес-аналитику или вызывают ваш сервер бизнес-аналитики по запросу (например, запрашивая отчет без заголовков с данными в формате XML или JSON).

Здесь есть над чем подумать, поэтому давайте рассмотрим все это подробнее.

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

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

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

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

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

Совет

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

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

Определение высокоприоритетных отчетов для переноса в первую очередь

Ключевой вопрос при переносе существующих отчетов и панелей мониторинга в Azure Synapse — какие из них следует перенести в первую очередь. На это решение могут влиять следующие факторы:

  • Использование

  • Ценность для бизнеса

  • Простота миграции

  • Стратегия переноса данных

Эти факторы рассматриваются в следующих подразделах.

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

  • удобный перенос отчетов и панелей мониторинга;
  • перенос отчетов и панелей мониторинга с минимальными усилиями;
  • перенаправление средств бизнес-аналитики в Azure Synapse вместо прежней системы хранения данных для получения идентичных отчетов, панелей мониторинга и других визуализаций.

Перенос отчетов на основе использования

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

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

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

Перенос отчетов на основе бизнес-ценностей

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

Еще один способ оценить ценность для бизнеса — проанализировать соответствие отчета бизнес-стратегии. Бизнес-стратегия, реализуемая руководителем, обычно определяет стратегические бизнес-цели, ключевые показатели эффективности (КПЭ) и целевые КПЭ, которых необходимо достичь, а также тех, кто несет ответственность за их достижение. Отчеты можно классифицировать по стратегическим бизнес-целям, реализации которых они способствуют (таким как уменьшение случаев мошенничества, повышение вовлеченности клиентов или оптимизация бизнес-операций). Затем можно выбрать для миграции в первую очередь отчеты и панели мониторинга, связанные с высокоприоритетными целями. Таким образом, первоначальная миграция может обеспечить ценность для бизнеса в стратегических аспектах.

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

Level Имя отчета или панели мониторинга Бизнес-цель Связанный отдел Частота использования Бизнес-приоритет
Стратегический
Тактическая
Операционный

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

Перенос отчетов на основе стратегии переноса данных

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

Совет

Стратегия переноса данных также определяет, какие отчеты и визуализации переносятся в первую очередь.

Проблемы с несовместимостью миграции, которые могут повлиять на отчеты и визуализации

Средства бизнес-аналитики формируют отчеты и панели мониторинга, а также другие визуализации, выполняя SQL-запросы, которые обращаются к физическим таблицам и (или) представлениям в вашем хранилище данных или киоске данных. При переносе устаревшего хранилища данных в Azure Synapse повлиять на простоту переноса отчетов, панелей мониторинга и других визуализаций могут несколько факторов. К ним относятся:

  • Несовместимость схемы между средами.

  • Несовместимость SQL между средами.

Несовместимости схемы

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

  • Нестандартные типы таблиц в СУБД старого хранилища данных, у которых нет эквивалента в Azure Synapse.

  • Типы данных в СУБД старого хранилища данных, у которых нет эквивалента в Azure Synapse.

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

Совет

Несовместимость схем предполагает устаревшие типы таблиц СУБД хранилища и типы данных, которые не поддерживаются в Azure Synapse.

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

Совет

Чтобы определить несовместимость схемы с Azure Synapse, запросите системный каталог СУБД старого хранилища.

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

Несовместимости SQL

Во время миграции несовместимость SQL может повлиять на любой отчет, панель мониторинга или другую визуализацию в приложении или средстве, которое:

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

  • Выдает SQL-запросы, которые содержат защищаемые функции SQL, характерные для диалекта SQL вашей старой среды и не имеющие аналогов в Azure Synapse.

Оценка влияния несовместимостей SQL на ваш портфель отчетов

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

Использование инструкций EXPLAIN для поиска несовместимостей SQL

Вы можете найти несовместимость SQL, просмотрев журналы недавних действий SQL в устаревшем хранилище данных Teradata. Используйте скрипт для извлечения репрезентативного набора инструкций SQL в файл. Затем добавьте инструкцию EXPLAIN в начало каждой инструкции SQL и выполните все инструкции EXPLAIN в Azure Synapse. Все неподдерживаемые операторы SQL, содержащие неподдерживаемые защищаемые расширения SQL, будут отклонены Azure Synapse при выполнении инструкций EXPLAIN. Этот подход позволяет оценить степень несовместимости SQL.

Метаданные из устаревшей СУБД хранилища данных также помогают находить несовместимые представления. Как и в предыдущем случае, сформируйте репрезентативный набор инструкций SQL из соответствующих журналов, добавьте в начало каждой из них инструкцию EXPLAIN и выполните эти инструкции EXPLAIN в Azure Synapse, чтобы найти представления с несовместимым SQL-кодом.

Совет

Оцените влияние несовместимостей SQL, собрав файлы журналов СУБД и выполняющиеся инструкции EXPLAIN.

Тестирование миграции отчетов и панелей мониторинга в Azure Synapse Analytics

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

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

  • Убедиться, что все пользователи перенесены.

  • Убедиться, что все роли перенесены и назначены пользователям.

  • Убедиться, что все права доступа к данным перенесены, чтобы обеспечить миграцию списков управления доступом (ACL).

  • Обеспечить согласованность результатов всех известных запросов, отчетов и панелей мониторинга.

  • Убедиться, что перенос данных и процессов извлечения, преобразования и загрузки (ETL) завершен и не содержит ошибок.

  • Убедиться, что соблюдается конфиденциальность данных.

  • Протестировать производительность и масштабируемость.

  • Протестировать аналитические функции.

Совет

Тестируйте и настраивайте производительность, чтобы минимизировать затраты на вычисления.

Сведения о переносе пользователей, групп пользователей, ролей и привилегий см. в разделе Безопасность, доступ и операции для миграций Netezza.

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

Совет

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

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

Совет

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

Анализ происхождения для определения зависимостей между отчетами, панелями мониторинга и данными

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

Совет

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

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

Совет

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

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

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

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

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

  • Какие данные необходимо перенести, чтобы обеспечить успешное выполнение отчетов и панелей мониторинга в Azure Synapse.

  • Какие преобразования были выполнены и должны быть выполнены для обеспечения успешного выполнения в Azure Synapse.

  • Как предотвратить дублирование отчетов.

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

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

Перенос семантических слоев средства бизнес-аналитики в Azure Synapse Analytics

Некоторые средства бизнес-аналитики имеют так называемый слой семантических метаданных. Этот уровень метаданных упрощает доступ бизнес-пользователей к физическим структурам данных в базовом хранилище или базе киоска данных. Уровень семантических метаданных упрощает доступ, предоставляя высокоуровневые объекты, такие как измерения, меры, иерархии, вычисляемые метрики и объединения. Эти высокоуровневые объекты используют бизнес-термины, знакомые бизнес-аналитикам, и сопоставляются с физическими структурами данных в хранилище или киоске данных.

Совет

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

Во время миграции хранилища данных изменения имен столбцов или таблиц могут быть принудительными. Например, в Teradata имена таблиц могут включать символ "#". В Azure Synapse символ # допускается только в качестве префикса имени таблицы для указания временной таблицы. В Teradata ВРЕМЕННЫЕ ТАБЛИЦЫ необязательно имеют символ "#" в имени, но в Synapse они должны его иметь. В таких случаях вам может потребоваться доработка для изменения сопоставлений таблиц.

Чтобы обеспечить согласованность в нескольких инструментах бизнес-аналитики, создайте универсальный семантический уровень с помощью сервера виртуализации данных, расположенного между средствах и приложениями бизнес-аналитики и средой Azure Synapse. На сервере виртуализации используйте общие имена данных для высокоуровневых объектов, таких как измерения, меры, иерархии и соединения. В результате настраивать все, включая вычисляемые поля, соединения и сопоставления, потребуется только один раз (а не для каждого средства). Затем перенаправьте все средства бизнес-аналитики на сервер виртуализации данных.

Совет

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

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

Схема с общими именами данных и определениями, которые связаны с сервером виртуализации данных.

Выводы

При переносе хранилища данных методом lift-and-shift большинство отчетов, панелей мониторинга и других визуализаций должны быть перенесены достаточно легко.

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

Для выявления этих проблем не полагайтесь на пользовательскую документацию. Вместо этого используйте инструкции EXPLAIN — быстрый и практичный способ обнаружения несовместимостей SQL. Внесите изменения в несовместимые инструкции SQL таким образом, чтобы обеспечить эквивалентную функциональность в Azure Synapse. Кроме того, используйте автоматизированные средства обнаружения метаданных и происхождения данных для анализа зависимостей, поиска повторяющихся и выявления недопустимых отчетов, которые используют устаревшие, сомнительные или несуществующие источники. Используйте средства определения происхождения данных, которые помогают сравнить происхождение, чтобы убедиться, что отчеты, работающие в устаревшей среде хранилища, создаются в Azure Synapse идентичным образом.

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

Совет

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

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

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

Чтобы узнать больше о минимизации проблем с SQL, см. следующую статью из этой серии: Минимизация проблем с SQL для миграции Teradata.