Временной ряд с пониженной дискретизацией: среднее значение по сравнению с наибольшим треугольником и тремя сегментами
Я программирую линейные диаграммы с использованием Flot Charts для отображения временных рядов.
Чтобы уменьшить количество отображаемых точек, я делаю понижающую дискретизацию, применяя функцию усреднения к каждой точке данных в один и тот же час.
Однако недавно я обнаружил алгоритм наибольшего треугольника-трех корзин: http://flot.base.is/
В чем разница между использованием такого алгоритма и простой функцией, такой как среднее значение (за минуту, за час, за день, ...)?
Имеет ли смысл предварительно рассчитывать таблицу sql на стороне сервера, применяя LTTB для каждого месяца данных, и позволять клиентской стороне применять другой LTTB к агрегированным данным для ускорения длительных запросов?
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 1
1: Проблема со средними значениями для моих целей состоит в том, что они сводят на нет большие различия между выборками - мои пики и спады были более важны, чем то, что происходило между ними. Смысл алгоритма 3buckets состоит в том, чтобы попытаться сохранить эти точки перегиба (пики / спады), не беспокоясь о том, чтобы показывать вам все случаи, когда данные были похожими или одинаковыми.
Итак, в моем случае, когда данные в целом были одинаковыми (или достаточно близкими - температурные данные) до образца X, в этот момент важно было показать небольшое изменение в% на графике, алгоритм бакетов был идеальным.
Кроме того, поскольку алгоритм ведер параметризован, вы можете изменить значения (сколько данных сохранить) и посмотреть, какие значения уничтожают большинство данных, визуально выглядя почти идентично, и решить, сколько данных вы можете обойтись, прежде чем ваш график тоже будет удалено много данных.
Наивным подходом было бы прореживание (удаление X из N выборок), но что произойдет, если вам небезразличны выбросы, а алгоритм уничтожит выброс? Затем вы меняете прореживание так, чтобы, если разница слишком велика, он не уничтожал этот образец. Это своего рода более сложная версия этой концепции.
2: зависит от того, как быстро вы можете все это вычислить, если данные когда-либо изменятся, а также от различных других факторов. Решать вам. С моей точки зрения, как только мои данные были в прошлом и образец был «выбран» для представления значения корзины, он не будет изменен, и я могу сохранить его и никогда больше не пересчитывать.
Поскольку ваш вопрос немного устарел, чем вы в конечном итоге стали заниматься?
Большое спасибо, четкое объяснение. Что касается второго квартала, на данный момент LTTB все еще применяется на лету к необработанным данным. Однако, если клиент запрашивает большой период (миллион точек данных), это может занять несколько секунд. Конечно, идеальным было бы, чтобы весь график отображался за несколько секунд. Я работаю в пакетном режиме, обрабатываю весь набор данных каждый день и могу быстро выполнять вычисления. Итак, в моем случае неплохо было бы предварительно вычислить LTTB для каждого таймсерии в моем наборе данных, но неясно, какой параметр выборки LTTB применять, поскольку каждый таймсерию имеет разные диапазоны. Как вы обрабатываете на своей стороне?
По возможности лучше рассчитывать заранее. В моем случае я генерировал ~ 400 КБ JSON, я смог уменьшить это до ~ 6 КБ без заметных различий в данных, и даже небольшие различия (отклонения 1-2%) проявляются нормально. На вашем месте я бы взял пример реализации и пропустил ваши данные, настраивая параметры (в основном размер корзины), пока это не станет хорошим компромиссом между размером и визуальной точностью данных ... Моим данным нужно все на основе скользящего окна 24 часа, поэтому я просто реализовал его вручную из оригинальной бумаги.
Спасибо, впечатляющие результаты. Насколько я понял, LTTB выбирает «лучшую» точку данных из каждой корзины. У меня такая же реализация (на стороне сервера), что и у «flot.base.is», поэтому я могу настроить порог (максимальное количество точек выходных данных), но я не могу напрямую настроить размер корзины. Моя проблема в том, что у меня есть таймсерии с кратной длиной периода (с января 2018 по декабрь 2018, с января 1910 по январь 2019 и т. д.), Поэтому в основном я не могу предварительно вычислить LTTB с постоянным порогом. Считаете ли вы, что для каждой таймсерии в моем наборе данных целесообразно применять LTTB с динамическим порогом в отношении длины периода?
Не уверен, и основная проблема заключается в том, что алгоритм не может сказать вам, что лучше для вашей ситуации, вам нужно запустить его, построить график, определить, удастся ли вам уйти с удалением дополнительных данных ... Критической проблемой для меня было что мы не теряем точек перегиба, и это определенно очень хорошо работает в этой ситуации. Я бы поиграл с этим.
Дипломная работа, на который ссылается ссылка на странице, подробно описывает, как работает алгоритм LTTB и отличается от простой средней функции. Страница 23 специально использует псевдокод для демонстрации алгоритма.