rang14,

просто интересно, если не секрет :) Вы в Екб занимаетесь DWH, есть интересные проекты, норм зарплаты?


На мой взгляд SSIS - зло. У него есть как бы "плюсы":
- наглядность (на диаграммах лучше видно, что откуда и куда передается)
- простота (должно быть просто для аналитика)
- интеграция с MS SQL (настройка периодического запуска задач по передаче данных)

Но по факту если хоть чуть-чуть сложная логика обмена данными, то плюсы оказываются минусами:
- диаграммы перестают быть наглядными
- рисовать их становится очень сложно (даже тупо накликакть мапинг полей из одной таблицы в другую - очень муторно, а если ещё писать какой-то код, то вообще жесть)
- не всегда есть права доступа для настройки таких задач

Я обычно фигачу мапинги из одной схемы данных в другую на C# (.NET Core) и запускаю под IIS:
- логика может быть сколь угодно сложная
- очень много повторно используемого кода (типа найти в справочнике запись по названию и если её нет, то создать новую - благодаря EntityFramework и generic'ам пишется один раз под любой справочник)
- очень легко всё это сопровождать (100-300 строк кода, не считая повторно используемого)
- легко реализовывать разные схемы кеширования данных для повышения производительности (например, при первом обращении к справочнику полностью его загружаем и дальше работаем только с кешем, или, например, выгружаем одним запросом из основной таблицы идентификаторы добавляемых/изменяемых/удаляемых записей, сохраняем их в HashSet и по нему проверяем есть уже такая запись или нет и т.п.), разные схемы инкрементальной загрузки данных
- легко деплоить (просто копируем по FTP на сервер заказчика)

Вообще не вижу сценариев, когда стоило бы использовать SSIS. Я сам им пользовался и тогда он казался мне норм. Но сейчас по доброй воле точно не буду. Например, вот:
- логика по импорту гос. реестра лекарственных средств
- по импорту предельных цен
- импорт/экспорт из базы товарных накладных
- тут всякая повторно используемая логика типа "T FindOrCreate<T>(string name)" и т.п.

На много проще в коде написать, что такое-то поле равно такому-то, чем накликивать это мышкой в SSIS.

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

Некуда излить свою боль, изолью сюда :) Там по ссылке демка проекта, которую делал для одного заказчика. Недели 2 на неё потратил, был готов на них бесплатно работать ещё месяц, чтобы доделать полностью один из модулей их системы и убедить их, что за полгода можно поднять на качественно новый уровень всю ту жесть, которую они написали за последние 20 лет. Но не срослось.

alexdr,

"умение готовить SSIS" - эта какая-то абстракция. Я привел совершенно конкретные доводы, почему его не удобно использовать.

Я пару лет накликивал на нём мышкой разные диаграммы - сколько ещё нужно времени, чтобы постичь вселенскую гениальность SSIS? Вроде не тупой, честно, за это же время Isabelle HOL научился готовить , который немного сложнее, чем SSIS :)

КритикЛучше стандартные накликанные пакеты, чем какая-то (возможно гениальная) фигня, которую никто не знаетЭти ручные ETL написаны на C#. Само приложение тоже написано на нём. Разработчик C# там будет 100% и разобраться в 100-300 строках кода на один пакет он сможет, особенно если этот код практически полностью состоит из присваиваний. А, вот, шансов, что на таком проекте будет человек с опытом SSIS очень мало. Даже если будет, то в мешанине из SSIS и C# разбираться сложнее, чем просто в C#. К тому же SSIS привязан к MS SQL, а код на C# никак не привязан к одному вендору СУБД.

alexdrПроцентов на 90% (если не больше) задачи вполне решаются этим инструментом при затрате вполне вменяемых ресурсовНу, вот, конкретный пример - реестр предельных цен на лекарства . Его нужно разложить в нормализованную схему данных (вот, как это реализовано у меня).

Например, тут в одной строке "раствор для внутрикожного введения 0.1 мл/доза, 30 доз, 3 мл - флаконы (5) - упаковки ячейковые контурные - пачки картонные" указано следующее:
1) лекарственная форма: раствор для внутрикожного введения
2) дозировка: 0.1
3) ед. изм. дозировки: мл/доза
4) альтернативная мера лек. формы: 30
5) альтернативная ед. изм. лек формы: доз
6) мера лек. формы: 3
7) ед. изм. лек формы: мл
8) упаковки:
9.1а) номер: 1
9.1б) вид: флаконы (с признаком первичная)
9.1в) кол-во: 5
9.2а) номер: 2
9.2б) вид: упаковки ячейковые контурные (с признаком промежуточная)
9.3а) номер: 3
9.3б) вид: пачки картонные (с признаком вторичная)

Естественно, что парсинг таких строк в любом случае будет писаться на C#, в том числе при использовании SSIS. Тут сложность в том, что одна строка раскладывается в несколько таблиц:
1) лекарственные средства
2) упаковки лекарственных средств
3) виды упаковок
4) единицы измерения

со следующей логикой: если такой ед. измерения (или вида упаковок) ещё нет, то добавляем её, а если есть, то ссылаемся на существующую. И так для всех справочников.

Мы реализовали эту процедуру парсинга на C#, встроили в SSIS пакет. Процедура должна возвращать объект с несколькими полями, в том числе со вложенным списком упаковок? И потом этот объект будет раскладываться по таблицам? Такое вообще возможно в SSIS? Я честно такое никогда не делал на SSIS, по-моему это жесть. Я могу ошибаться, но такая строка выглядит гораздо понятней и сопровождать её проще:


Это можно было бы нарисовать в виде диаграммы, но она действительно была бы проще для понимания и сопровождения? Уверен, что нет.


Но это только начало. Если мы для каждой ед. измерения (вида упаковок и т.п.) отдельным SELECT-запросом будем проверять есть уже такая запись в справочнике или её нужно добавить, то это будет работать очень медленно. В коде я легко реализую кеширование справочников при первом обращении к ним, причём, это повторно используемый код, который пишется один раз.

Сложнее история с основной таблицей с лекарственными средствами. В исходном реестре нет первичного ключа, нет даты добавления/изменения записи, там просто помойка с полностью дублирующимися записями. Причём нельзя при каждом импорте полностью очищать таблицу и загружать в неё с нуля реестр. Загрузка должна быть инкрементальной. Для этого для каждой строки реестра вычисляет хеш по основным полям (суррогатный первичный ключ). При импорте данных мы проверяем есть ли уже в базе запись с таким хешем. Причём, делать это нужно одним запросом для всех импортируемых записей, чтобы работало быстро.

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

vikkivа внутри писать нормальные скрипты на C# и т.д.SSIS для этого не удобен. Проще сразу писать нормальное приложение, а не делать мешанину из диаграмм и кода. Проще сразу в коде написать, что это поле равно этому полю (одна строка кода), чем накликивать этот мапинг на диаграмме.

alexdrесть инструмент, в данном случае "промышленный" (в отличие от самописного) ETL инструментЭто не корректное сравнение. SSIS - это универсальный инструмент для описания ETL процедур. А у меня самописный не инструмент, а конкретные процедуры.

Корректнее сравнивать:
1) что удобней использовать для описания ETL процедур: SSIS или язык программирования общего назначения типа C#?
2) что проще сопровождать: SSIS-диаграммы вперемешку с C# или просто C# код?

SSIS не даёт каких-то существенных преимуществ. Вещи типа "возьми данные отсюда", "присвой значение этого поля этому полю", "сохрани данные сюда" занимают одну строку кода. Более сложные вещи типа "посмотри есть ли уже такая запись в справочнике, если есть, то используй её, иначе создай новую" - это всё ещё одна строка кода, а на SSIS-диаграмме - это уже целая история. Хотя, можно писать кастомные процедуры для SSIS, но это сложнее, чем просто написать метод в коде.

Если бы можно было обходиться только диаграммами, наверное SSIS был бы удобнее. И то, не факт, нужно открывать много окон, куда-то кликать. Ещё всё это плохо работает с системами управления версиями. Привязано к одному вендору. Но когда нужно всё это ещё интегрировать с кусками на C#, то зачем вообще этот SSIS? Только лишние усложнения.

T87,

причем тут вообще ASP.NET? На нем в этом проекте только пользовательский интерфейс, который с ETL никак не связан. Более того, интерфейс (и WinForms, и ASP.NET) там генерятся автоматически, поэтому на ASP.NET там не написано ни одной строки. ETL - это маленький кусочек этого приложения.

Сами процедуры можно запускать как угодно, они написаны просто на C# без использования вообще каких-либо фреймвоков. Даже к EntityFramework не привязаны. Потому что UI там сделан на DevExpress XAF, который не поддерживает .NET Core и соответственно для работы с базой используется EF. А API сделано под .NET Core и соответственно используется EF Core.

Поэтому схема данных и мапинги абстрагированы и от EF, и от EF Core, и тем более от XPO (который обычно используется с DevExpress XAF). Это просто "плоские" классы.

Конкретно в этой демке ETL процедуры запускаются тремя способами:
1) из пользовательского интерфейса (импорт/экспорт товарных накладных в XML формате)
2) из консольного приложения (импорт реестров лекарств)
3) через API (импорт/экспорт тех же товарных накладных и т.п.)

Этот проект я делал в качестве демки для одной фирмы, поэтому в ней нет ещё одного варианта запуска ETL (который есть в других проектах):
4) запуск на сервере по расписанию через службы реализующие IHostedService (работать эти службы могут в разных контейнерах - IIS или в качестве обычной Windows-службы. У одного из клиентов удобнее всего было использовать IIS, потому что для этого не нужны права администратора на сервере, достаточно скопировать службу по FTP)

Ни один из этих вариантов вообще никакого отношения к ASP.NET Core не имеет. Поэтому в чём претензия я не понимаю. Тем более, что 100% пунктов против SSIS, которые я привел раньше даже не упоминают ASP.NET Core и вообще про другое.

Я правда чувствую, что мне сейчас напишут, что варианты 1-3 не имеют отношения к ETL :) Потому что тру ETL пишутся только с использованием ETL инструментов (типа SSIS) и запускаются только по расписанию на сервере. На мой взгляд разницы вообще никакой: откуда приходят данные, куда уходят и как всё это запускается. Код там везде один и тот же.

Это ещё один довод в пользу того, что ETL проще сразу делать на C#.

Справедливости ради, если в компании есть отдел или человек, который занимается исключительно базами данных и ETL и не имеет никакого отношения к разработке, то возможно есть смысл использовать SSIS. Наверное проще обучить аналитиков SSIS, чем нанимать C# разработчиков. Лично я так делать не стал бы. Задачи этого отдела возможно немного упрощаются, но в целом всё усложняется: процедуры мапинга данных будут размазаны по разным подсистемам, будут дублироваться. Например, те же товарные накладные могут попадать в систему откуда угодно (через UI, через API, загружаться пакетно по расписанию) и выгружаться могут куда и как угодно. В этом случае у нас и в приложении будет мапинг накладных из XML в нашу схему, и в SSIS будет дублироваться тот же самый мапинг.