Есть простое решение для выгрузки из dynamics 365 for operations в SQL?

[Vadik]

Цитата:

Сообщение от vmoskalenko

Я так думаю что под капотом это выглядит как D365FO SQL -> BCP -> CSV -> ADLS
Причем к первым трём пунктам у тебя нет доступа. И это получается быстро

А существуют какие-то основания считать что BYOD сейчас (из D365FO SQL в Azure SQL) - это "медленно" именно из-за Azure SQL а не скажем из-за вытягивания изменений из data entity на 10-15 таблиц через change tracking ? И что все магическим образом станет "быстро" если писать не в другую БД, а в файловую систему ?
По поводу "дешевле" вопросов нет

[trud]

Цитата:

Сообщение от vmoskalenko

Далее Майкрософт готовит все остальные свои сервисы чтобы они работали с этим форматом из коробки. Power BI, Azure Synapse (DW), Azure Analytics (SSAS). Azure Data Fabric (SSIS)

Это кстати тоже непонятно. т.е. все эти сервисы уже нормально нативно работают с SQL, и пока не очень работают с файлами под названием "Data Lake"

Цитата:

Сообщение от vmoskalenko

С другой стороны, для выгрузки данных - держать целый SQL тоже как-то странно.

Хотя в такой поставке вопроса - да, т.е. эти сервисы как я понимаю имеют внутренний формат, т.е. получается исходный BYOD SQL Server служит только для перекачки.

Цитата:

Сообщение от Vadik

И что все магическим образом станет "быстро" если писать не в другую БД, а в файловую систему ?

Если не ошибаюсь, Брент Озар вроде бы тестировал SQL Azure, и там совсем слабая скорость чтения(порядки 50МБ-С) при малых DTU(но это как бы логично, ибо предполагается что данные будут в памяти)
В нашем же случае мы закачиваем данные в SQL для единственной цели - их потом прочитать из Power BI, Azure Synapse (DW).... И такие ограничения(на скорость линейного чтения) как раз критичны ибо эти системы будут читать все целиком.
Получается они придумали закачивать в файлы(где наверное лимитов на скорость чтения нет) и читать оттуда
Т.е. вся эта суета из-за обхода искуственных ограничений, которые они сами и создали

[Vadik]

Вчера ночером (© Маззи) поэкспериментировал с BYOD в Azure SQL

Вводная:

• "своя" таблица (размер записи 1KB)
• 1M записей (2.8 GB allocated)
• "своя" "плоская" data entity без добавленных datasources и виртуальных полей
• экспорт из D365FO в DM (Full push only)

Таблица ниже - сводная:

• primary_max_log_rate и primary_group_max_io - лимиты на log writes (bytes/seс) и IOPS из sys.dm_user_db_resource_governance
• время полного экспорта 1М записей (2.8GB), как его рапортует data management
• рассчитанная пропускная способность (MB/sec, делим 2.8GB на время экспорта)

Выводы:

• Basic tiers, естественно, в контексте BYOD существуют просто для галочки (чтоб было). Результаты даже сохранять не стал, так как несерьезно
• Standard tier (тестировал S2) - нельзя сказать что не работает, но страсть какой медленный (2MB/s на запись, почему - см. таблицу). Ну а что мы хотели за эти деньги, с другой стороны
• Premium tier (тестировал P1, P6 и P15) работает без нареканий (P6 быстрее чем S2 где-то раз в 20), но ограничения есть и не все проблемы можно решить тупо перейдя на более высокий (дорогой) уровень. Так, P6 и P15 (P15 дороже навскидку раза в 4) при записи в один поток упираются в один и тот же потолок по Log IO (т.е. быстрее уже не будет даже в теории), а P6 уже со всеми накладными расходами (D365, data management, трафик и пр.) выдал около 90% (40.1 МБ/c) от теоретических максимальных 44 МБ/c. "Пацан сказал - пацан сделал" (с)

Как по мне, так даже начальные premium tier позволяют не напрягаясь выгрузить инкрементом все данные которые типичный D365FO клиент генерит за день за вполне приемлемые время и деньги. Data lakes могу рассматривать как альтернативный вариант (дешевле/моднее), но "быстрее" - зачем? Чтобы выгружать весь GeneralJournalAccountEntry каждые 15 минут? Ну, можно конечно

По поводу того, тянуть сырые данные из BYOD куда-то дальше, или крутить отчеты прямо из него - вариантов масса, primary_group_max_io на средних и старших premium tier много чего позволяет. Лично мне репортить прямо из BYOD не очень нравится

P.S. Из забавного - покопавшись в sys.dm_user_db_resource_governance на sandboх-е (T2 и выше), можно узнать разное про лимиты на своем инстансе, а также узнать кто еще сидит на нашем spartan-е (на моем тестовом инстансе было еще порядка 50 других D365FO сред, можно даже попытаться по имени БД угадать клиента )

[raz]

Разница в цене и скорости впечатляет.

[vmoskalenko]

Цитата:

Сообщение от Vadik

Вчера ночером (© Маззи) поэкспериментировал с BYOD в Azure SQL

А можешь заодно еще протестить модель цены vCore? vCore, Serverless
По идеи, это решение будет намного дешевле.
А если еще и автопаузу включить - то вообще красота

https://docs.microsoft.com/en-us/azu...-tier-overview

Хотя... всё-равно для многих решений это будет или не быстро или дорого

[Vadik]

Serverless было бы интересно попробовать. Постараюсь потестировать на следующей неделе

[Vadik]

А вот что получилось с serverless. До 8 ядер масштабировалось строго линейно, дальше уперлись в лимит на Log IO

[Vadik]

https://msdyn365fo.wordpress.com/202...or-msdyn365fo/

[Vadik]

Цитата:

Сообщение от trud

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

кстати KWS добавили обработку троттлинга для FinOps

Цитата:

Enhancement: F&O service calls now gracefully handle 429 error returned by the service by following the instruction given in the service response

https://www.kingswaysoft.com/product...ange-log#v21.1

В общем, одни роботы троттлят, другие ретраят, жизнь кипит

[vmoskalenko]

Цитата:

Сообщение от Vadik

кстати KWS ...

Если пользуешься этой тулзой - поделись впечатлениями.

[Vadik]

Цитата:

Сообщение от vmoskalenko

Если пользуешься этой тулзой - поделись впечатлениями.

Впечатления смешанные. И штука вроде рабочая, у нас ее использовали (разработчики) для разового экспорта-импорта в FO и CE, и сделано вроде качественно и от души. Непонятно кому ее продавать. Мелким и средним облачным клиентам - дорого (лицензия на сам продукт + SQL Server) и экспертиза по SSIS и желание его внедрять встречаются нечасто. Крупным облачным OData - вроде как неправильно с точки зрения масштабируемости плюс непонятности с тем как троттлинг заработает. У меня KWS только на одном LBD проекте был, да и там его клиенту до меня "продали"

[Vadik]

Export to Azure Data Lake Overview