Графики больших объемов данных

Question

В продукте, над которым я работаю, есть итерационный цикл, который может иметь от нескольких сотен до нескольких миллионов итераций. Каждая итерация вычисляет набор статистических переменных (двойной точности), и количество переменных может быть до 1000 (обычно 15-50).

Как часть цикла, мы отображаем изменение переменных за итерации, поэтому ось X - это итерации, а ось y - переменные (закодированные цветом):

http://sawtoothsoftware.com/download/temp/walt/graph.jpg

В настоящее время данные хранятся в файле, содержащем:
4-байтовое целое, для которого переменная,
4-байтовое целое число, для которого итерация,
и 8-байтовый двойной для значения.

Общий масштаб оси y изменяется со временем, и желательно, чтобы график изменял размеры в соответствии с текущим масштабом (это можно увидеть на рисунке).

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

Я ищу идеи о том, как обработать этот объем данных более эффективно и быстро, если это возможно.

Answer 1

В терминах SQL вы должны сгруппировать и агрегировать результаты. Невозможно отобразить все 10000 точек данных на графике, не прокручивая их за пределы экрана. Одним из способов является группировка по шкале времени (секунды, минуты и т. Д.) И запрос к AVG(), MAX() или MIN(), чтобы уменьшить точки данных до меньшего масштаба.

Пример MySQL, сгруппировать по секундам:

select time_collected, AVG(value)
from Table
group by UNIX_TIMESTAMP(time_collected)

Также рассмотрите возможность объединения агрегированных значений и визуализации в свечном графике .

Answer 2

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

Например, если пользователь заботится только о тренде, вы легко можете оценить эти функции только через столько итераций (вместо каждой итерации). На графике выше вы, вероятно, могли бы получить столь же информативный график, рисуя только значение на кривой каждые 100 итераций, что уменьшило бы размер вашего набора данных (и скорость вашего алгоритма рисования) в 100 раз. Очевидно, вы можете настроить это, если вам понадобится больше деталей.

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

Если вы беспокоитесь о таких вещах, как пропущенные выбросы из-за ошибки выборки, вы можете просто вычислить набор точек выборки на основе скользящих окон вместо отдельных выборок из исходных данных. Вы можете держать около максимума, минимума, среднего значения, медианы и, возможно, вычислять полосы ошибок для данных, которые вы отображаете пользователю.

Если вам нужно быть действительно агрессивным, люди придумали множество причудливых методов для сокращения и отображения данных временных рядов. Для получения дополнительной информации вы можете проверить статью в википедии или посмотреть наборы инструментов, например R , в которых уже встроено множество этих методов.

Наконец, этот вопрос о переполнении стека также представляется актуальным.

Answer 3

Из графика видно, что вы строите 10000 итераций на нескольких сотнях пикселей, поэтому просто используйте одну из 100 информационных точек для графика и игнорируйте остальные. Это будет выглядеть одинаково для пользователей

Answer 4

Почему вы не создаете растровое изображение (или растровое изображение, подобное XPM)? Каждый столбец (или строка) соответствует итерации, а высота одинаковых цветов (ширина для строк) соответствует значению переменной. Формат XPM проще, поскольку он текстовый (один символ на пиксель) и кроссплатформенный.