Заменить SSIS на PowerShell? - PullRequest
       2

Заменить SSIS на PowerShell?

2 голосов
/ 19 февраля 2012

Некоторые люди не любят SSIS по следующим причинам,

  1. Нужно найти и щелкнуть экспресс-замену, разбросанную в другом месте, когда конструируешь немного более сложную упаковку.
  2. Эти компоненты слияния, поиска не работают хорошо. Я слышал, что многие консультанты просто рекомендуют загружать данные в таблицы SQL Server и использовать transact-sql.

Я использовал powershell в небольшом проекте, который экспортирует данные и создает CSV-файлы. Я использовал PowerShell и мне это нравится. Есть ли тенденция заменить некоторые задачи, традиционно использующие SSIS, на Powershell? Особенно на экспорт только случаи?

Ответы [ 2 ]

6 голосов
/ 20 февраля 2012

Для очень маленьких проектов / задач Power Shell - хороший инструмент.

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

SSIS - это не просто графический интерфейс для автоматического запуска SP и TSQL.Если вы действительно хотите узнать больше по этому вопросу, я советую взять несколько книг - внимательно выслушать узкопрофильных экспертов;их наборы навыков могут легко исчезнуть из актуальности и удержать других позади себя.

Тенденция PowerShell от SSIS?Не близко к тому, что имеет значение.

0 голосов
/ 16 мая 2019

Это старая тема, но я считаю, что ее стоит обсудить.Поэтому я хотел бы привести несколько идей, почему я считаю, что SSIS является плохим выбором в 99% случаев в качестве инструмента ETL.

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

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

В моей среде prod есть много пакетов SSIS, развернутых и запланированных с заданиями агента sql, поэтому в случае сбоя задания у меня нет возможности выяснить проблему, пока я не перешел в TFS, чтобы найтипроект SSIS и откройте его в Visual Studio, чтобы выяснить логику.Это кошмар.

С PowerShell код, который вы видите, - это исполняемый код, и вы всегда можете получить логику из кода PS и по пути устранить неполадки.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...