В / О: Работа с хранилищем данных большого объема в Centerprise

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

В: Может ли профилирование данных работать отдельно?

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

В: Можем ли мы сгруппировать набор правил качества данных и использовать их в нескольких потоках?

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

В: Объясните, как Persistent Lookup Cache улучшает производительность

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

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

A: причина номер один проблем с производительностью Centerprise, как и любой Интеграция данных Программа — это объем данных — слишком много запросов, особенно слишком много запросов в столбце. В приведенном ниже примере вы можете видеть, что в таблице фактов все ключи нуждаются в каком-то поиске, и если у вас есть, например, 10 поисков непосредственно перед таблицей измерений, каждый из этих поисков должен быть завершен, прежде чем запись может быть вставлена. в таблицу фактов. Таким образом, наличие большого количества неэффективных поисков значительно замедлит поток данных.

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

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

Затем в последующие моменты времени поток данных будет запускаться, он будет обращаться к этому файлу и в основном делать то же самое, что вы определили в своем предложении «где», но автоматически сделает это в этом «где» файле. Таким образом, недостатком является то, что вам не нужно отслеживать переменные, недостатком является то, что теперь у вас есть инкрементный файл для каждого объекта, из которого вы загружаете. Это поднимает вопрос о том, что вы можете даже хотеть, чтобы источники были общими действиями, таким образом вам не нужно постоянно определять их и их поля аудита.

Q: Использует ли запись на основе ограничений автоматически выяснить последовательность записи

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

Q: Как Diff Processor сравнивается с производительностью upsert?

A: Diff Processor намного быстрее, чем upsert. Upsert собирается запустить другой запрос, чтобы проверить, существует ли информация или нет, в то время как Diff Processor работает, отправляя все записи в группы в целевую систему. Затем они записываются во временную таблицу и объединяются. Это сравнение происходит на стороне базы данных, а не на Centerprise сторона, поэтому большие фрагменты подготавливаются на стороне базы данных, а не с помощью отдельного запроса, чтобы узнать, нужно ли выполнить вставку или обновление. По сути, upsert выполняет одну запись за раз, а Diff Processor сравнивает партиями. Мы обнаружили, что это происходит на несколько порядков быстрее.

В: Поддерживаете ли вы быструю загрузку для Teradata?

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