Таблица с OData кодом failed refresh

[Inostranka_02]

бла-бла-бла
Разберитесь сначала чем network/transport layer отличается от application layer, потом будете втирать мне как вы написали hello world на питоне.
"existing connection was forcibly closed by the remote host" - это стандартное сообщение Windows sockets. Сообщение транспортного уровня, которое говорит, что не удалось установить TCP/IP соединение.

Обычно таки что существующее соединение было разорвано - как это детали (r с другой стороны, etc)
В таких случаях вы нам не про размер говорите а про время через сколько ошибка вылазит - таймауты там всякие они круглые цифры и буквы

Да, я заметила что если в 5 мин не влез refresh то тогда это сообщение и связь разорвана
А в 5 мин ого входит при размере таблицы 42MB

[Mad Hatter]

Киса, скажите как художник художнику, вы рисовать программировать умеете?

Если да, то вы должны знать, что ошибка и сообщение об ошибке могут быть совершенно разными. К примеру не так давно пришлось дебажить питоновский код, который вытаскивал данные из облачного Splunk и в какой-то момент стал падать с совершенно невразумительным сообщением (exception). Причём у разных людей по разному. У кого-то вообще не падал, у кого-то падал, но редко, а у меня падал 50/50. На первый взгляд была проблема с авторизацией прокси, а выяснилось, что совсем совсем другая.

бла-бла-бла
Разберитесь сначала чем network/transport layer отличается от application layer, потом будете втирать мне как вы написали hello world на питоне.
"existing connection was forcibly closed by the remote host" - это стандартное сообщение Windows sockets. Сообщение транспортного уровня, которое говорит, что не удалось установить TCP/IP соединение.

Свободен

[Sergunka]

Обычно таки что существующее соединение было разорвано - как это детали (r с другой стороны, etc)
В таких случаях вы нам не про размер говорите а про время через сколько ошибка вылазит - таймауты там всякие они круглые цифры и буквы

Да, я заметила что если в 5 мин не влез refresh то тогда это сообщение и связь разорвана
А в 5 мин ого входит при размере таблицы 42MB

Что Вы называете рефрешем? К примеру если у нас на Редшифте начинает работат вакум, то вполне будет похожая ситуация. Вакум это улучшение индексов таблицы и сжатие таблицы. Возможно у вас там этот рефреш слишком часто работает то надо менять скедеул расписания запуска.

[Inostranka_02]

Да, я заметила что если в 5 мин не влез refresh то тогда это сообщение и связь разорвана
А в 5 мин ого входит при размере таблицы 42MB

Что Вы называете рефрешем? К примеру если у нас на Редшифте начинает работат вакум, то вполне будет похожая ситуация. Вакум это улучшение индексов таблицы и сжатие таблицы. Возможно у вас там этот рефреш слишком часто работает то надо менять скедеул расписания запуска.

Этот отчёт- в Power BI
Refresh я имею ввиду 2 вещи -
1 Это когда я сама нажимаю кнопку Refresh и данные обновляются - загружаются из Data Source
2 Когда публикуется отчёт на Power BI Services - чтобы было доступно другим для просмотра - там да именно schedule

Отвечая на ваш вопрос - Scheduled Refresh работает раз в день - ночью

Кстати, что заметила в посл 2 дня -
Даже этот Scheduled Refresh иногда валится
Там 3 workspaces - Development, Testing, Production
И он периодически failed - на одном из них.

Раз в день это же не часто?

Ps -
Я попробую параметры что мне посоветовали на PBI форуме

Если не улучшится ситуация, можно ещё попробовать постранично грузить данные - pagination.
Но - я не знаю этих команд - OData этот...
Работала с ним до этого 1 раз в течении 2х дней - меняла простейшие фильтры и все... Не уверена - если ошибки будут - chat gpt не всегда нормально помогает

И как уже писала - самое главное - то что советовали кто больше имел с этим дело - с загрузкой данных через эту чёртову OData прямо в Power BI - это создать Workflow и оттуда уже в PBI

Сделаю моделирование - просто статическую таблицу из .csv сначала и сделаю Scheduled Refresh отчёту. Если заработает- то я на правильном пути - API- workflow - PBI


PPS -
Проблема имхо в том что этот OData не может грузить в Power Bi - или скорее так - Power BI не предназначен для динамической загрузки данных. Он это может, но если 1,2 фида.
Не 30.

Я проверила другие отчёты- нигде у нас нет столько OData feeds - везде 1.
И даже если 1, если таблицы больше 100к записей и этот OData feed - manual Refresh ОЧЕНЬ медленно.

Power BI в него надо грузить данные из SQL например, чтобы статическая модель
(Хотя там 10+ источников, откуда грузить можно)

Если данные динамические - нужно промежуточную загрузку, чтобы в Pbi они уже были статические. Тогда да можно и миллион записей и тд...

Подобные проблемы описывали другие ребята у нас в команде кто работал с OData - PBI
Один в один.

Имхо

[self]

бла-бла-бла
Разберитесь сначала чем network/transport layer отличается от application layer, потом будете втирать мне как вы написали hello world на питоне.
"existing connection was forcibly closed by the remote host" - это стандартное сообщение Windows sockets. Сообщение транспортного уровня, которое говорит, что не удалось установить TCP/IP соединение.

Обычно таки что существующее соединение было разорвано - как это детали (r с другой стороны, etc)

Технически вы правы. В данном случае в сокет пришел пакет RST - разорвать соединение. Но это детали.
А суть же в том, что прикладные сервисы в наше время практически никогда не управляют сокетами напрямую. За них это делают фреймворки. В рассматриваемом случае, готов поспорить, что это .NET

И тогда существует два разумных сценария -
а) ODATA endpoint хостится под IIS. В этом варианте при возникновении необработанных ошибок в сервисе (таймауты и прочие неприятности) IIS будет их перехватывать, и транслировать в HTTP коды 40X-50X. Соединения он не обрывает.
b) ODATA endpoint - standalone app, который самохоститься под kestrel. Kestrel не такой устойчивый как IIS, но в принципе ведет себя так же за исключением полного краша сервисаппа. Но мне трудно представить, чтобы ендпойнт писали люди не знающие про try-catch.

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

[voyager3]

Но мне трудно представить, чтобы ендпойнт писали люди не знающие про try-catch.

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

Как раз больше верится в endpoint, который валится на больших запросах с какой-нибудь out of memory.

[self]

Но мне трудно представить, чтобы ендпойнт писали люди не знающие про try-catch.

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

Как раз больше верится в endpoint, который валится на больших запросах с какой-нибудь out of memory.

Видали и не такое. IIS возвращает 500.
Поскольку топикстартер не смог установить, какой именно ендпойнт отваливается, похоже, что проблема плавающая и возникает только когда клиент обращается одновременно к множеству ендпойнтов. Name resolver разбрасывает нагрузку по разным IP, и случайно попадает на blacklisted/not whitelisted.

В пользу этой гипотезы указывает и факт, что явление не наблюдается, когда вызовы идут из ажуровского воркфлоу

[Inostranka_02]

Update -
Я пока так и не знаю точную причину time out (когда Refresh валится с сообщением в самой большой таблице "Canceled by host"), но, вот что помогло:

Вместо загрузки одновременно всех OData feeds в таблицу, как было раньше:

Table.Combine (
OData = "https://....Project1"
OData = "https://....Project2"
OData = "https://....Project3"
............
OData = "https://....Project30")



можно загружать вот так
Source = OData = "https://....Project1"

#"Add all projects1" =
(source,

Table.Combine(
OData = "https://....Project2"
OData = "https://....Project3"))

#"Add projects2" =
#"Add all projects1",

Table.Combine(
OData = "https://....Project4"
OData = "https://....Project5"))


#"Add projects3" =
#"Add all projects2",

Table.Combine(
OData = "https://....Project6"
OData = "https://....Project7"))

......

#"Add projects15" =
#"Add all projects14",

Table.Combine(
OData = "https://....Project29"
OData = "https://....Project30"))

То есть добавлять по несколько Projects в таблицу, насколько я поняла.

После такого изменения в самои большои таблице - больше нет time out, canceled by host
Теперь поставила на Scheduled Refresh в PBI services - все тоже прошло без проблем.
Буду еше смотреть. Есть minor questions у меня насчет данных - in a process of clarification пока.

[voyager3]

Смищно, если в первом случае оно всё в одну транзакцию пихает и давиццо.

[Mad Hatter]

А мне тут "фаевол" говорили

[self]

Update -
Я пока так и не знаю точную причину time out (когда Refresh валится с сообщением в самой большой таблице "Canceled by host"), но, вот что помогло:

Вместо загрузки одновременно всех OData feeds в таблицу, как было раньше:

Table.Combine (
OData = "https://....Project1"
OData = "https://....Project2"
OData = "https://....Project3"
............
OData = "https://....Project30")



можно загружать вот так
Source = OData = "https://....Project1"

#"Add all projects1" =
(source,

Table.Combine(
OData = "https://....Project2"
OData = "https://....Project3"))

#"Add projects2" =
#"Add all projects1",

Table.Combine(
OData = "https://....Project4"
OData = "https://....Project5"))


#"Add projects3" =
#"Add all projects2",

Table.Combine(
OData = "https://....Project6"
OData = "https://....Project7"))

......

#"Add projects15" =
#"Add all projects14",

Table.Combine(
OData = "https://....Project29"
OData = "https://....Project30"))

То есть добавлять по несколько Projects в таблицу, насколько я поняла.

После такого изменения в самои большои таблице - больше нет time out, canceled by host
Теперь поставила на Scheduled Refresh в PBI services - все тоже прошло без проблем.
Буду еше смотреть. Есть minor questions у меня насчет данных - in a process of clarification пока.

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

[self]

А мне тут "фаевол" говорили

Нет ничего смешнее сисадмина, возомнившего себя программистом

[Mad Hatter]

А мне тут "фаевол" говорили

Нет ничего смешнее сисадмина, возомнившего себя программистом

А кто тут сисадмин?

[Inostranka_02]

Update -
Я пока так и не знаю точную причину time out (когда Refresh валится с сообщением в самой большой таблице "Canceled by host"), но, вот что помогло:

Вместо загрузки одновременно всех OData feeds в таблицу, как было раньше:

Table.Combine (
OData = "https://....Project1"
OData = "https://....Project2"
OData = "https://....Project3"
............
OData = "https://....Project30")



можно загружать вот так
Source = OData = "https://....Project1"

#"Add all projects1" =
(source,

Table.Combine(
OData = "https://....Project2"
OData = "https://....Project3"))

#"Add projects2" =
#"Add all projects1",

Table.Combine(
OData = "https://....Project4"
OData = "https://....Project5"))


#"Add projects3" =
#"Add all projects2",

Table.Combine(
OData = "https://....Project6"
OData = "https://....Project7"))

......

#"Add projects15" =
#"Add all projects14",

Table.Combine(
OData = "https://....Project29"
OData = "https://....Project30"))

То есть добавлять по несколько Projects в таблицу, насколько я поняла.

После такого изменения в самои большои таблице - больше нет time out, canceled by host
Теперь поставила на Scheduled Refresh в PBI services - все тоже прошло без проблем.
Буду еше смотреть. Есть minor questions у меня насчет данных - in a process of clarification пока.

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

Да, но к сожалению, вижу проблему опять -

Тот код, каким-то образом не добавляет все фиды в одну таблицу, а убирает или фильтрует их
(Там только этот код и все)

Почему-то теперь в таблице вместо 30 Projects, только основные 4

То есть пришла к самому началу проблемы-
Не понятно КАК (не делая значительных изменений в дизайне) - ускорить процесс refresh ?

[Inostranka_02]

Отвечая на свой вопрос, как я уже писала много раз выше -
Главная проблема в том что Power BI не может напрямую загружать много feeds, + возможно размер таблицы получившеися.
Не может это и Ms Fabric Dataflow (размер 200К для него большой)- проверили!


Ps-
В итоге - решили ужать кол-во записей в 3 раза, поставив фильтр - "Дата >= 01/01/2024" or date is not null
Будем переделывать всю модель, с помощью PySpark in Notebook(s) + pipelines
Грамотный парень, с таким работающий, показал что может Пайтон сделать