Следует ли программистам использовать SSIS, и если да, то почему? [закрыто]

94

Как разработчик .NET, по каким причинам я должен предпочесть пакеты SSIS написанию кода? У нас есть масса пакетов в производстве, где я сейчас работаю, и это кошмар как для «написания» (возможно, рисования?), Так и для поддержки. Каждый пакет выглядит как миска с разноцветными спагетти со скриптами C # и VB.NET, смешанными в точках, где абстракции ломаются. Чтобы понять, что делает каждая «задача выполнения SQL» или «цикл по каждому элементу», мне нужно дважды щелкнуть эту проклятую вещь и просмотреть дерево буквальных значений и выражений, разбросанных по нескольким вкладкам.

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

Чарльз
источник
4
не знаю, как это происходит, но SSIS намного быстрее, чем любой ручной код, который я написал для создания хранилища данных. это инструмент, предназначенный для работы - попробуйте разбить задачи на дочерние пакеты, которые выполняются из основного пакета,
г-н Шубс
1
Ссылка на аналогичный вопрос: stackoverflow.com/q/690123/327165
Илья Бердичевский
5
Только что наткнулся на это. Я работаю над поддержкой некоторых проблемных пакетов SSIS и написал декомпилятор, чтобы извлечь из них полезную работу в программу на C #. code.google.com/p/csharp-dessist
Тед Спенс
5
По моему опыту, SSIS может быть болезненным, если у вас есть «длинные» и / или «сложные» сценарии или много сценариев. Отладка консольного приложения намного проще. В SSIS вы не можете отлаживать свой скрипт самостоятельно. Сообщения об ошибках, создаваемые сценарием, являются загадочными, и вы не можете увидеть точную строку, вызвавшую ошибку. ИМО, если потребности проекта могут быть удовлетворены с помощью стандартных компонентов SSIS, то SSIS может быть подходящим вариантом. Но для этого вам нужно знать ограничения компонентов SSIS. Например, это видео показывает, почему «задача отправки почты» практически бесполезна - youtube.com/watch?v=IlUzkMPYDSk
Steam
3
у этого вопроса 7 ответов, поэтому он не требовал дебатов, аргументов, опросов или расширенного обсуждения. Почему бы не оставить его открытым?
Майкл

Ответы:

94

Я использую SSIS каждый день для обслуживания и управления большим хранилищем данных и кубом. Я занимаюсь 100% бизнес-аналитикой и хранением данных в течение двух лет. До этого я был разработчиком .NET-приложений для 10.

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

  1. Сохраняйте простые пакеты, задачи sql и задачи потока данных.
  2. Выполняйте как можно больше работы вне SSIS, желательно в SQL.
  3. Храните свои переменные в единой глобальной области видимости
  4. Храните свой SQL в переменных или храните процедуры, а не в строке
  5. Храните значения переменных в хранилище конфигурации, предпочтительно в базе данных SQL.
Кевин Д. Уайт
источник
1
С моей проблемой SSIS я бы дал более предвзятый ответ (как если бы вы не могли понять тональность моего вопроса :)). Хороший ответ, Кевин.
Чарльз
6
Как вы работали с .NET в течение 10 лет, если он был выпущен в 2002 году?
Брэди Холт
7
[цитата] Microsoft начала разработку .NET Framework в конце 1990-х годов под названием Next Generation Windows Services (NGWS). К концу 2000 года были выпущены первые бета-версии .NET 1.0 [/ quote] Так, наверное, работал с бета-версией.
nitefrog
На этот вопрос был дан ответ в 2010 году, так что возьмите два года BI, а затем следующие 10, получите 1998 год, за два года до упомянутой вами бета-версии. В противном случае хороший ответ! :)
finoutlook
Да, глобальный масштаб имеет смысл. Если вы сделаете его локальным и хотите получить к нему доступ в другом месте, у вас есть проблема. Вы не можете просто изменить область видимости с локального на глобальный. Вместо этого вам нужно много кликов и удалений. Если у вас есть хотя бы 10-15 местных жителей, это становится болью.
Steam
52

Я несколько раз пробовал использовать SSIS, но отказался от этого. ИМО, намного проще просто делать все, что мне нужно, на C #. SSIS слишком сложен, в нем слишком много подводных камней, и это того не стоит. Гораздо лучше потратить больше времени на улучшение навыков работы с C #, чем на изучение SSIS - вы получите гораздо большую отдачу от своего обучения.

Кроме того, гораздо проще найти и поддерживать функциональность в решении VS. Модульное тестирование с VS очень просто. Все, что мне нужно сделать, это проверить исходный код в Subversion и проверить, как он загружается. Модульное тестирование пакетов SSIS, мягко говоря, очень сложно.

Кроме того, были ситуации, когда SSIS молча не заполнял некоторые столбцы в некоторых строках, просто пропускал их, не вызывая исключений. Мы потратили много времени на устранение неполадок и выяснение того, что происходит. Разработка альтернативного решения на C # заняла менее часа, а работает без проблем два года.

АК
источник
Спасибо за очки, Алекс. Вот пример того, что, как мне кажется, может быть ошибкой - stackoverflow.com/questions/21616435/… .
Steam
2
Есть ли список всех тем C # / программирования, которые должен знать разработчик ETL? Например. LINQ, SqlDataReader, DataTable и т. Д. Я тоже считаю, что SSIS не подходит для сложных задач. Если у вас есть простой проект / задача «копировать-вставить», тогда SSIS может быть лучшим инструментом.
Steam
@blasto, вы пробовали Rhino ETL: ayende.com/blog/3102/rhino-etl-2-0
AK
Алекс, ответ Джерома также предложил Rhino ETL. Мне это кажется непонятным. Поэтому я бы не решился использовать его из-за отсутствия документации, поддержки и руководств. Кроме того, похоже, что над этим работает только один разработчик. Это снижает мою уверенность в инструменте. Я бы попробовал это для развлечения или из любопытства, но я не могу использовать это для реального проекта. Спасибо.
Steam
Если кому-то нужен учебник по Rhino ETL (с чистым C #), вот один - codeproject.com/Articles/34556/Write-ETL-jobs-in-pure-C
Steam
14

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

Кристоф
источник
8
ETL = Извлечь нагрузку преобразования
Кристоф
3
Я почти так чувствую. В нашем случае мы используем SSIS для таких вещей, как электронная почта (или SFTP) CSV, содержащая информацию о ценах. Ветвление, встроенные скрипты и т. Д. Довольно ужасны. Если бы просто переместили некоторые данные с помощью SSIS, это, вероятно, было бы не так уж плохо.
Чарльз
1
Думаю, ваш ответ мог бы быть более глубоким.
Steam
3
Может ли T в ETL не включать какую-то логику? Просто мысль ...
cs0815
Если это связано только с формированием / маршрутизацией данных, конечно. Но я бы избегал любой бизнес-логики.
Кристоф
11

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

возможно, мы просто использовали его неправильно, но у нас было много трудностей, если мы когда-либо изменили нашу схему, и в конечном итоге мы просто повторно использовали наши определения ORM из внешнего интерфейса, чтобы написать собственный инструмент на C # для этого. Поскольку у нас уже была модель данных, это оказалось на удивление легко. очевидно, что YMMV и я ни в коем случае не эксперт по SSIS, но в этом одном случае SSIS вызвал много дублирования работы и головных болей, когда просто закатав рукава и «ручное кодирование» оказалось проще, чем ожидалось.

Поэтому при рассмотрении SSIS я бы много подумал о гибкости.

Люк
источник
7
Я разделяю одни и те же чувства. Реорганизовать код легко ... не так много с визуальным DSL.
Чарльз
Люк, не могли бы вы дать нам краткое описание требований к вашему проекту? Спасибо.
Steam
@blasto мы пытались объединить данные из нескольких баз данных и использовать некоторые из встроенных утилит вероятностного сопоставления строк для объединения данных из разных систем (по сути, баз данных CRM). Это было 5+ лет назад, поэтому я не помню всех подробностей.
Люк
Если вы являетесь магазином .net и участвуете в перемещении данных для целей хранения данных, SSIS поможет вам только в том случае, если вы достаточно хорошо это знаете. Я видел много людей, которые являются гуру .net, но не полностью понимают SSIS (и я их не виню). SSIS наверняка требует человека, который знает это достаточно хорошо, иначе вы в конечном итоге напишете пакеты, которые неэффективны и не могут делать правильные вещи.
rvphx
6

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

Старое имя (DTS, Data Transformation Services) и новое имя (SSIS, Sql Server Integration Services) ясно дают понять, что это служба (или набор служб), предназначенная для манипулирования данными для интеграции базы данных SQL Server в более крупные процессы.

Дэйв
источник
Я не понимаю, как этот ответ должен получить столько голосов. Здесь не упоминается, почему SSIS не может дать вам мощь языка программирования. Это не имеет никакого смысла для меня. Одним из примеров того, что SSIS не соответствует языку программирования, является отладка. Очевидно, SSIS 2012 меняет это. Так что, может быть, просто может быть, инструмент становится более удобным для программистов.
Steam
>> Один пример, когда SSIS не соответствует языку программирования ... Я согласен - это не язык программирования. Это достойный инструмент ETL.
DaveE
4

Если вы хотите переместить данные программно, вам стоит взглянуть на Rhino ETL.

Я также работаю над своей собственной структурой Fluent ETL , поскольку считаю, что SSIS слишком задействован для простых задач с данными, связанных с разработкой, таких как загрузка данных модульного теста из файла CSV.

Джером
источник
Rhino ETL малоизвестен и на данный момент имеет только 24 вопроса по SO - stackoverflow.com/questions/tagged/rhino-etl . Я думаю, что C # подойдет для ETL, если у вас есть знания и опыт.
Steam
1
Есть ли популярные альтернативы Rhino ETL?
Steam
3

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

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

TomTom
источник
2
Вы можете привести нам пример того, как SSIS может ускорить разработку в одном сценарии и замедлить в других?
Steam