.Net против SSIS: для чего должен использоваться SSIS?

Question

Если у меня есть возможность использовать .Net и я могу отлично выполнять преобразования данных в .Net, когда мне понадобится SSIS? Есть ли определенная задача, для которой SSIS будет лучше? Стоят ли дополнительные преимущества прозрачности? Это то, что мне удобнее? Каковы лучшие методы для определения этого?

Answer 1

хороший вопрос.

если объем передачи данных огромный? Вы обрабатываете несколько файлов данных и нуждаетесь в транзакциях (как на уровне файловой системы, так и на уровне базы данных)? Вы имеете дело с несколькими источниками данных в разных местах (например, ftp, локальная файловая система, база данных)?

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

Другая вещь, на которую я смотрю, - стоит ли писать код .net, когда все доступно внутри ssis. (не путайте меня - я люблю кодировать) однако, все, что вы кодируете, вы должны поддерживать: -)

Answer 2

Я думаю, что ограничения по времени / бюджету проекта и использование стандартного инструмента являются одними из главных аргументов в пользу использования SSIS. Создание пакета служб SSIS в большинстве случаев намного быстрее, чем попытки написать что-то подобное в .NET.

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

ИМХО: рассмотрите возможность использования служб SSIS для проектов, которые необходимо развернуть только в одной или двух домашних средах SQL Server. В противном случае подход .NET быстро станет более привлекательным.

Answer 3

Мои аргументы в пользу того, что SSIS не используется:

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

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

• Потоки данных RESTful используют HTTP-кэширование.

• Каналы / сервисы / API-интерфейсы можно легко перенести в облако эластичного масштаба.

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

• Служба SSIS плохо работает с контролем исходного кода и совместной работой.

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

• Служба SSIS не работает легко, в отличие от службы REST.

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

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

• Инструмент неуклюжий и ненадежный.

• Вы находитесь во власти дорожной карты Microsoft для SSIS.

• Рассмотрите возможность записи в таблицы / службы, которые поддерживают анализ, отчеты и представления, как только данные поступают в приложение; см. CQRS и другие шаблоны архитектуры приложений.

• Никогда не используйте Excel в качестве данных источник ; обучать сотрудников.

• Код король.

В конечном счете, я вижу SSIS как пережиток корпоративных ИТ. Я хотел бы спросить: "Будет ли Google использовать SSIS?" Как еще можно решить проблему? Думай нестандартно.

Answer 4

Я думаю, это зависит от того, что вы делаете. SSIS очень мощный, как старый DTS. Если вы загружаете много товаров и ожидаете постоянных изменений, я бы прошел SSIS до конца. Если вы хотите загрузить только несколько элементов, и это для большого количества клиентов, я поместил бы это в код. Я предпочитаю SSIS для внутренних процессов ETL, но я использую .Net в клиентских магазинах, когда мне нужно загрузить данные из устаревшей системы в базу данных SQL. Теперь, как я уже говорил ранее, если у вас есть много преобразований и много разных хранилищ данных для загрузки, я думаю, что вы с ума сошли бы, сделав это в .Net, и я бы пошел в SSIS. Если у вас есть только несколько элементов для загрузки, и это для одного приложения и может быть установлено как часть приложения на различных клиентах, я бы пошел. Net до конца. Просто мои 2 цента.

Answer 5

У меня большой опыт работы с SSIS - от небольших проектов до крупных сложных ETL. Не вдаваясь в подробности, это мое руководство для вас:

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

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

• C # теперь имеет поток данных TPL. Простые тесты производительности ставят его перед SSIS. (например, http://mymemoryleaks.blogspot.cz/2013/10/ssis-vs-tpldataflow.html)

• Если вы хотите сделать что-то, кроме тривиального, и если вы можете использовать навыки .NET, используйте .NET вместо SSIS.

Answer 6

Немного поздно, чтобы ответить на этот вопрос, но я надеюсь, что оно того стоит,

SSIS часто неправильно понимают по сравнению с языком программирования. SSIS - это фреймворк, тогда как C # - это язык в .NET Framework. У меня большой опыт работы с большими объемами хранилищ данных и их разработки (набор MSBI), а также разработка больших веб-сайтов (ASP.NET), поэтому я не могу быть предвзятым.

SSIS, если не используется должным образом, может снизить производительность на пар. Пакеты служб SSIS имеют три вида преобразования:

1. Блокирующее преобразование - которое может передавать данные только тогда, когда указанное преобразование завершено, извлекая все строки и выполнив необходимые вычисления для него.
2. Полублокирующее преобразование - которое может передавать частичные данные
3. Non-Blocking - который обрабатывает строку, как только она готова

SSIS работает исключительно хорошо с неблокирующим преобразованием с правильной настройкой потока управления и потока данных. Я использовал его на большем (более 2 ТБ хранилище данных) и могу гарантировать, что это была самая быстрая загрузка. Вы можете проверить блог Microsoft о Мы загрузили 1 ТБ за 30 минут с SSIS, и вы тоже можете

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

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

Теперь дело в том, что является более удобным подходом для решения вашей задачи. SSIS - верный победитель, загружающий большое количество записей, загружающих данные из источника в место назначения, в то время как C # идеально подходит для написания логики. Даже если вам нравится C #, я не рекомендую вам выбирать операции ETL (Extract Transform Load) в больших системах хранилищ данных.

Answer 7

Я думаю, что главное преимущество заключается в визуальном определении всей программной конструкции. Любой взгляд на пакет служб SSIS в значительной степени самоочевиден. Тесная интеграция с SSIS с SQL позволяет вам быть частью SQL для резервного копирования и огромного плюса.

Как все объяснили, если вы делаете много манипуляций с данными, это хороший инструмент. Это бесплатно, если у вас есть SQL, который вы все готовы, и очень легко изучить с VS 2008 BIDS

Answer 8

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

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

Answer 9

В основном SSIS имеет много преимуществ, таких как разделение передачи данных из точки A в точку B на более мелкие блоки и отладка их по отдельности, возможность простого доступа к таблицам SQL Server, работа с данными XML, вызовы API с использованием сценариев c # и сохранение данных в БД Читайте данные БД и FTP на удаленном сервере и многое другое.
Помимо множества уже существующих блоков BI, вы также можете создавать свои собственные настраиваемые задачи со своими собственными параметрами и выходными данными.
Надеюсь, я смог добавить некоторые моменты к уже существующим ответам.

Answer 10

Как следует из названия, SSIS является системой интеграции. В .net может быть очень трудно обрабатывать коннекторы для разрозненных источников данных, таких как excel, teradata, oracle и т. Д., А также выполнять обязанности по изящному закрытию этих соединений, сборке мусора, обработке проблем с памятью.

Итак, SSIS является готовым продуктом, идеально подходящим для сценариев, в которых данные должны быть не только получены, скажем, из двух разных источников, но затем необходимо выполнить сериальный поиск, преобразования, слияния, деривации и вычисления перед записью. это к месту назначения (будь то сервер SQL, плоский файл или другая система БД).

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

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