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

[vmoskalenko]

Цитата:

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

А в чем преимущество Data Lake? Я тут был просто на презентации, технически мне показалось что это просто выглядит как выгрузка данных в CSV файлы в папке. Т.е. на первый взгляд это как-бы большой шаг назад по сравнению с хранением данных в БД(к примеру нет типизации, индексов, неудобный доступ и прочее). По поводу стоимости - если так уж стоит вопрос стоимости, может стоит рассмотреть бесплатные БД типа PosgreSQL. Но почему-то все так ждут этого?

Бесплатные БД надо хостить еще где-то. Ну и Майкрософт же....

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

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

С другой стороны, я согласен что CSV файлики это шаг назад по сравнению с SQL. С другой стороны, для выгрузки данных - держать целый 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 сред, можно даже попытаться по имени БД угадать клиента )

[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/