Автоматическое прогнозирование временных рядов с данными из SQL Server - PullRequest
0 голосов
/ 07 октября 2019

Я работаю над проектом, который включает создание живой онлайн-панели мониторинга (с использованием начальной загрузки, Visual Studio, C # и т. Д.) С возможностью прогнозирования временных рядов.

Источник данных взят из SQL Server. Каков наилучший общий подход для достижения этой цели:

  • Нужно ли делать точное прогнозирование в базе данных, а затем просто извлекать результаты и показывать их на панели инструментов ИЛИ.
  • Нужно ли мне извлекать необходимые данные, а затем делать прогноз в визуальной студии и на C #.
  • Или я что-то упустил?.

1 Ответ

0 голосов
/ 07 октября 2019

Обычно вы берете локальные копии своих данных из источника и загружаете их в BI-движок / базу данных - скажем так:

Sales|Month
$100:Jan
$200:Feb
$300:Mar

В этот момент вы выполняете прогнозирование / разметку/ черная магия - запись данных обратно в базу данных BI - на этот раз разметка «реальных» и «оцененных» записей и выполнение любого необходимого агрегирования.

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

Sales|Month|Source
$100:Jan|SalesSystem
$200:Feb|SalesSystem
$300:Mar|SalesSystem
$400:Apr|ForecastingAlgorithm1234
$500:May|ForecastingAlgorithm1234

Этот объединенный источник реальности / проекции является ближайшим источником для любых визуализаций или дальнейшего анализа, которые вам необходимо выполнить или представить.

В этом примере «алгоритм прогнозирования» не зависит от системы - онможет выполняться в Visual Studio (.net и т. д.) или в SQL Server в зависимости от технологии, которая вам нужна.

Ключевым моментом здесь является принятие нескольких простых принципов: - Поддерживать происхождение данных - Не писать или «работать» в своих исходных системах (используйте отдельный экземпляр BI SQL - или хотя бы БД) -Сохраняйте ясность в отношении канонических и построенных данных - не выполняйте «работу» в памяти - материализуйте все это в таблицы / БД для последующего анализа и отладки - поверьте мне - это будет неправильно в первые несколько итераций, и намного проще будет распаковывать материализованные данныечем временно!

...