Постарайтесь не писать SQL-запросы в целом в SSIS
Работая над проектом Хранилища данных, парень, который дал нам учебное руководство, советовал, чтобы мы придерживались использования SQL-запросов по определению большого количества преобразований потока данных, цитируя точки как он использует большую память на поле ETL, таким образом, мы оставили бы обработку полю DB. Это действительно желательно? Где баланс между доверием инструментам GUI по выполнению набора сценариев SQL на Вашем пакете Интеграции?
И честно, я хотел бы постараться не писать SQL-запросы так, как я могу. (но это не относится к делу. Я действительно хотел бы посмотреть на это объективно.)
6 ответов
Ответ: это зависит от обстоятельств, но вы хотите выбрать один или другой для любого данной работе и по возможности избегайте их смешивания.
Как правило, лучше всего либо делать все возможное в рамках инструмента, либо делать все возможное в рамках кода хранимой процедуры. Когда у вас есть значительное количество логических разделов между уровнями, систему становится труднее отслеживать и отлаживать.
Если инструмент может выполнять преобразования без того, чтобы потоки данных становились неудобными и запутанными, вы можете использовать инструмент и попытаться иметь минимальную логику или ее отсутствие. Это означает, что на одном уровне есть бизнес-логика, и должно быть довольно очевидно, где ее найти. Однако инструменты ETL, как правило, относительно плохо справляются с очень сложными преобразованиями.Лучшее место для этого типа подхода - системы, в которых имеется большое количество источников данных, но относительно простые преобразования.
Если у вас относительно сложные преобразования, возможно, вам лучше поместить всю бизнес-логику и преобразование на уровень хранимых процедур. Код SQL лучше выполняет сложные преобразования в удобном для сопровождения способе - я довольно хорошо осведомлен, что около половины всех проектов хранилищ данных в банковском и страховом секторах используют этот тип архитектуры именно по этой причине.
В этом случае инструмент ETL может использоваться для реализации относительно простых копий данных. Исходные данные могут быть скопированы в промежуточные области по существу дословно, а затем приняты основной частью кода хранимой процедуры, выполняющей ETL. Инструмент ETL можно использовать для копирования данных, операций массовой загрузки, ведения журнала, планирования и других задач платформы.
В любом случае лучше выбрать один подход. В противном случае вы можете получить бизнес-логику, распределенную по уровням извлечения, представлениям базы данных, потокам данных и коду хранимых процедур. Логику, распределенную по нескольким уровням, проверить намного сложнее.
Когда вся логика (например) содержится в хранимых процедурах или сфокусированных заданиях преобразования ETL, вы можете изолированно тестировать данное преобразование. Ясность дизайна также помогает при обслуживании и проверке.
Я считаю, что использование кода SQl не только быстрее запускается, но и быстрее разрабатывается и намного проще в обслуживании.
Обычно, когда вы хотите обрабатывать каждый ряд по отдельности, используйте поток данных, в противном случае лучше использовать Sql-команду.
Лично я предпочитаю писать SQL там, где это возможно. Его легче оптимизировать впоследствии и (обычно) быстрее. Google даст гораздо более подробные ответы.
Еще один фактор, о котором следует подумать, - это провайдер, которого вы используете для своих соединений.
Вы должны принять решение, основываясь на своих потребностях. Мы используем postgres DB, поэтому для некоторых процессов нам приходится создавать множество таблиц staging, что ускоряет работу.
Вы также должны принять во внимание, на каком ящике он работает, если у вас есть мощный DB box и маленький ETL box, то нет смысла запускать что-либо.
Если вы выполняете всю обработку на блоке ETL, вы также будете перетаскивать много данных по сети.
Посмотрите эти ссылки, чтобы начать:
ssistalk.com/category/ssis/ssis-advanced-techniques/
msdn.microsoft.com/en-us/library/ms141031.aspx
weblogs.sqlteam.com/jamesn/Default.aspx
Я думаю, что это сложный вопрос; И еще один интересный.
ИМХО, одна из причин использовать SSIS - улучшить ремонтопригодность. Если вы упаковываете всю логику в операторы SQL (а вы точно можете!), Вы в первую очередь испортите эту причину использования SSIS. Вы больше не можете "видеть поток данных".
С другой стороны, я чувствую, что бывают случаи, когда правильно размещенный оператор SQL имеет свою ценность. Например, когда вы читаете данные из таблицы и по какой-то причине уже знаете, что вам когда-либо понадобятся только строки, удовлетворяющие условию X, я не вижу причины для чтения всей таблицы и на следующем шаге «условное разделение большей ее части».
Кстати, я не знаю, что это означает с точки зрения производительности. Достаточно ли умен SSIS, чтобы увидеть, что происходит, и изменить «чтение-целая-таблица-и-условное-разделение» на «выбрать Y из , где X» на лету (или при создании / развертывание)?
Большой вопрос в том, где провести черту. И это в определенной степени зависит от людей, работающих над вашим процессом ETL.Если все, кто когда-либо поддерживал процесс, знают SQL с самого начала, вы сможете лучше поддерживать большее количество SQL в своем ETL, чем если бы у вас есть коллеги (или клиенты, или преемники, о которых вы заботитесь), которые с трудом понимают, что происходит во всем вашем SQL. , не говоря уже об изменении / улучшении / добавлении к нему.
Итак, я думаю, что суть в том, что лучше не использовать и не делать все на SQL. Постарайтесь составить несколько простых правил, которые соответствуют вашим требованиям и с которыми может жить каждый, а затем следуйте им. Это дает вам максимальную выгоду от использования SSIS.
SQL Server делает некоторые вещи хорошо, а другие - не очень. Я использую SSIS для импорта в SQL Server или экспорта данных из него. Во время переезда я использую SSIS там, где это имеет смысл. Я могу легко выполнять работу на основе каждой строки, что не очень эффективно в SQL Server (курсоры). Говорить, что не следует использовать преобразования и потоки данных в ETL-блоке, потому что это слишком дорого для ETL-блока, все равно что сказать: "Не гоняйте на своем автомобиле слишком быстро, потому что это заставляет двигатель работать". Цель ETL и SSIS - взять часть обработки, которую SQL Sever делает не очень хорошо, и перенести ее на движок, который это делает.
Надо использовать подходящий инструмент для работы. Как правило, вы делаете большинство вещей в SSIS, при этом некоторые вещи выполняются на «чистом» SQL.
Например, в случаях, когда вы выполняете много ОБНОВЛЕНИЙ (например, различия таблиц в таблице измерений в размерной модели), вы действительно не хотите выполнять ОБНОВЛЕНИЕ для каждой строки. В этом сценарии вы выполняете обычную вставку во временную таблицу, а затем выполняете ОБНОВЛЕНИЕ в SQL, присоединяясь к соответствующим ключам.