SSIS выгрузка из Clickhouse данных типа string. Висит на стороне

SSIS. Вижу с помощью Wireshark, что Clickhouse отдает все правильно. SSIS висит на обработке столбца типа DT_Text. Никто не сталкивался? Понимаю, что это проблема клиента MS... Причем preview из SSIS дизайнера полученные данные парсит и отображает без проблем

https://github.com/ClickHouse/clickhouse-odbc/issues?q=is%3Aissue+ssis

Спасибо, попробую!

Просмотрел. В основном, уже читал ранее... Переспрошу так, кто-нибудь смог успешно выгрузить поле типа string из Clickhouse в MS SQL с помощью SSIS?

весьма редко используемая тут связка давайте по другому переспрошу драйвер ODBC последний? по issue прошли там есть какие то советы

Насколько помню есть dt_ntext, верно ? Как varchar-nvarchar Может его попробовать

Да, последний. И я уверен, что проблема не на стороне CH, а на стороне SSIS

Пробовал. Как только SSIS встречает столбец типа string, описывает его на своей стороне как DT_Text. А разобрать ответ от ODBC-драйвера CH - не может. Достаточно убрать string- столбец из Select-запроса и все читается. Но у меня куча столбцов типa string...

Забавно, что Preview из SSIS прекрасно читает данные...

а в чём проблема ?

Как только SSIS встречает столбец типа string, описывает его на своей стороне как DT_Text. А разобрать ответ от ODBC-драйвера CH - не может. Достаточно убрать string- столбец из Select-запроса и все читается. Но у меня куча столбцов типa string...

Это ответ от CH ODBC-драйвера.

Petr Ivanov
в Advanced поменяйте ручками тип поля на DT_WSTR с...

Пробовал. Эта фича недоступна. Как не меняй тип DT_TEXT в Advanced Editor - эти изменения не сохраняются и применить их не получается. Всегда изменения откатываются к DT_Text😕

А это тестовый запрос: SELECT TOP(1) event_datetime ,version ,san FROM <имя_таблицы> WHERE event_datetime >= '2023-06-01' AND event_datetime <= '2023-06-02'

ээээ шта ?

Не сохраняет Advanced Editor изменение типа DT_Text на тип DT_WSTR

должен сохранять. попробуй драйвер от mysql, ch на 9000 порту его иммитирует

какая версия ch ?

[SSIS.Pipeline] Error: SSIS Error Code DTS_E_PRIMEOUTPUTFAILED. The PrimeOutput method on ODBC Source returned error code 0x80004005. The component returned a failure code when the pipeline engine called PrimeOutput(). The meaning of the failure code is defined by the component, but the error is fatal and the pipeline stopped executing. There may be error messages posted before this with more information about the failure.

version 22.10.2.11 (official build) - отвечает на ?query=hello

https://stackoverflow.com/questions/37841797/ssis-advanced-editor-for-odbc-source-input-and-output-properties-does-not-sa "You cannot alter the data type via that dialogue box as the column meta data is set/refreshed by the source object."

И с MySql ODBC driver как-то не заладилось

Вдогонку... Даже если оставить в SQL-запросе единственное поле типа string SSIS - вешается при попытке принять данные от ODBC Source: SELECT TOP(1) san —string на стороне CH, DT_Text на стороне SSIS FROM <имя таблицы> WHERE event_datetime >= '2023-06-01' AND event_datetime <= '2023-06-02' Результат (hanging) одинаков как для ANSI Clickhouse ODBC, так и для Unicode Clickhouse ODBC

вот всё работает

Принципиальное отличие - Я использовал ODBC Source, в Вашем примере - ADO Net Source. Попробую воспроизвести.

Для .NET 6 существует версия Clickhouse ADO NET driver? Пока вижу только для .NET 5... https://github.com/killwort/ClickHouse-Net https://www.opensourceagenda.com/projects/clickhouseclient https://github.com/qoollo/Qoollo.ClickHouse.Net

Вообще говоря .NET библиотеки обратно совместимы. Но если хочется явно указанной совместимости, Clickhouse.Client компилится для net6 https://www.nuget.org/packages/ClickHouse.Client/6.7.0#supportedframeworks-body-tab

Спасибо!

там внутри ODBC DSN

Спасибо, Пётр! Воспроизвел, задышало.

Из минусов – катастрофически упала производительность. ODBC driver (без string столбца) скачивал 450 млн. строк за 30 минут. Через ADO Net запрос с добавлением string-поля показал такую производительность: 120 млн. записей за 12 часов. Деградация на 2 порядка (в 100 раз). Пребываю в недоумении по следующим пунктам: 1. Так как ADO Net драйвер - это всего лишь обертка поверх ODBC-драйвера, то почему ODBC-драйвер не может разобрать ответ, содержащий string-поле, получаемый от КХ, а будучи обернутым в ADO Net драйвер - может; 2. Почему такая деградация при использовании ADO Net драйвера?

там можно с размером кеша и батча поиграться. ещё в настройках драйвера есть про сжатие

ОК, попробую.

но вообще может стоит всё в csv выгрузить заархивировать переместить и потом через bulk load качнуть

Рассматривал, как вариант. Глядя на впечатляющее быстродействие КХ мне кажется уместнее вести обработку на стороне КХ, а уже результаты тащить на сторону MS для визуализации.

450 млн для визуализации ? что-то не то с проектом

Конечно не 450 млн сырых данных, а результат их обработки - агрегирования и т.д. действующая система принимала логи, парсила, грузила в MS SQL БД и далее выполнялась обработка упомянутых сотен миллионов событий в сутки. Теперь данные из логов попадают в КХ.

Транзакционная БД для визуализации, а OLAP для обработки.. это что-то. Из жизни. Если во время инсерта в КХ происходит сбой - часть ошметков остаётся уже вставленными в таблицы и их надо чистить. При отсутствии нормального UPDATE. Это прям забавно

а зачем тащить в МС для визуализации, когда КХ для этого лучше подходит?

Может если сотни запросов ? В секунду

от визуализации? :))) Это проект для ЦУПа? :)))

А если больше реплик сделать если такие проблемы с количеством запросов. Теоретически запрос кидается на ту реплику, на которой меньше нагрузка

Теоретически там round-robin

Черт! А я-то где-то это не то видел, не то читал. Обидно.