Статистическое Реферирование записей
Вот проблема реального мира, которую мы решаем. У нас есть некоторые довольно большие наборы данных, которые должны быть агрегированы и получены в итоге в режиме реального времени со многими фильтрами, и формулы относились к ним. Это хорошо работает для применения их к каждой записи в режиме реального времени, когда набор данных является меньше чем 50 000 записей, но поскольку мы приближаемся 100,000 и затем 100 +, миллион издержек выполнения математики в реальном времени против всех записей становится слишком большим. Мы провели много времени в оптимизации выполнения SQL и затем предположении, что бросающие все наборы данных в поршне и мы все еще приходим к выводу, что нам нужен к †œzoom outâ€? от данных и суммируют группы. Нам нужен способ сгруппироваться как записи вместе и затем применить математику к группе †œlike recordsâ€?. Этот сбор в группу записей позволяет нам быть действительно быстрым и делающим оперативным созданием отчетов. Наши текущие официальные наборы документов групп решения, которые являются точно тем же.
Вот запись в качестве примера
ID77968 1, 43:19.7, 43:19.7, ПРАВДА, 1, 3, 0, 4, 1, 1, 1, 1, 1, 0, 0, 0, 3, 0.1 0, 0, 3, 14, 79,
Таким образом, если у нас есть 2 из них с точно теми же данными
ID77968 1, 43:19.7, 43:19.7, ПРАВДА, 1, 3, 0, 4, 1, 1, 1, 1, 1, 0, 0, 0, 3, 0.1 0, 0, 3, 14, 79,
ID77969 1, 43:19.7, 43:19.7, ПРАВДА, 1, 3, 0, 4, 1, 1, 1, 1, 1, 0, 0, 0, 3, 0.1 0, 0, 3, 14, 79,
затем мы создаем группу. Затем мы можем применить математику и логику единственной группе и затем умножить результат на 2 для получения реального ответа. Это работает действительно хорошо на нас и может быть супер полезно в том, чтобы обходить проблемы масштаба объектов. Это сказало, что у нас теперь есть новая проблема. Некоторые наши значения имеют большие диапазоны результатов, который создает наборы данных тысяч записей только с несколькими их являющийся тем же самым. После некоторой мозговой атаки мы придумали идею применить некоторый œfuzzy†â€? логика для группировки вещей вместе, которые подобны. Проблема, которую мы имеем теперь, - то, что мы, don†™t знают лучшее статистически, звучим как способ идти о сокращении официального набора документов в группы, что aren†™t требуют то же.
Вот то, что мы должны сделать. (Простой пример, отдельный столбец)
Предположим, что у нас есть следующие числа 20 чисел
106
0
8
0
1
0
4
0
3474
0
204
0
75
0
128
0
617
0
20
0
В вышеупомянутом наборе у нас есть много 0†™s, таким образом, они легки группироваться. Но как я формируюсь, let†™s говорят еще 3 группы. Я предполагаю на внешнем, связанном, мы имеем 3474, но, учитывая взвешивание ниже того числа исходящая группа могла бы быть чем-то как 2000 и затем оценивает 3474, и 617 был бы объединен единственной группе. Наше обсуждение в команде думало об этом как о проблеме силы тяжести или более известный за ваше здоровье привлекательность. Идеально мы нашли бы уравнение или подход, который позволит нам посмотреть на весь официальный набор документов и затем сказать.. выразите это в X количестве групп. Это позволило бы нам варьироваться группировка/сбор в группу данных. Поэтому предположите, что мы используем пример 20 чисел выше и хотим выразить это в 15 группах по сравнению с 8 группами, мы смогли бы сделать это. Теперь помните, что в примере выше этого просто отдельный столбец, но я пытаюсь сгруппировать все записи как
ID77968 1, 43:19.7, 43:19.7, ПРАВДА, 1, 3, 0, 4, 1, 1, 1, 1, 1, 0, 0, 0, 3, 0.1 0, 0, 3, 14, 79,
ID77969 1, 43:19.4, 43:19.7, ПРАВДА, 1.2, 3.2, 0, 3, 2, 1, 1, 1, 1, 0, 0, 0, 3, 0.1 0, 0, 3, 14, 179,
Спасибо за справку заранее
вот обновление на основе некоторых комментариев, вопросов и ответов
Мы в настоящее время хешируем каждую запись, как она входит и затем если запись имеет тот же хеш, мы группируем ее. проблема с хешем здесь то, что если это istn точно то же затем, это привычка быть сгруппированной. Это работало на нас некоторое время becuase наши значения в каждом столбце, как относительно ограничено. Мы теперь представили некоторые значения, которые имеют намного большие диапазоны, который представил наш хеш, группирующийся неэффективный. Прежде чем мы смогли взять 100-миллиметровые записи и хешировать их к ajust по 100k группам, но теперь мы видим neew данные в наборах, которые являются просто 70k со всем 70k, являющимся уникальным. Данные Deidentified здесь: Копия rv.zip (3,58 МБ)
3 ответа
Это заняло некоторое время, но я реплицировал точно цветовую конфигурацию Visual Studio. Приятного отдыха.
.com { color: #008000; }
.str, .tag { color: #A31515; }
.kwd, .atv { color: #0000FF; }
.typ { color: #2B91AF; }
.lit, .atn { color: #FF0000; }
.pun, .pln { color: #000000; }
.dec { color: #800080; }
Комментарии зеленые, строки/теги красноватые, ключевые слова синие, типы голубые, числа красные, знаки препинания черный, объявления фиолетовый.
-121--1388710-При попытке предотвратить XSS важно продумать контекст. Пример того, как и чего следует избежать, очень отличается, если вы выводите данные внутри переменной в фрагменте javascript, а не выводите данные в HTML- тэге или атрибуте HTML.
У меня есть пример этого здесь: http://erlend.oftedal.no/blog/?blogid=91
Также проверьте OWASP XSS Prevention Cheat Sheet: http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
Итак, короткий ответ, убедитесь, что вы избегаете выходных данных, как предложено Tendayi Mawushe, но обратите особое внимание, когда вы выводите данные в HTML атрибуты или javascript.
-121--1053671-Каждая строка по существу является вектором в n-пространстве, и «подобные» строки векторы, расстояние которых ниже заданного порога. Один из способов, с которым я справился что-то подобное в прошлом, но в гораздо меньшем масштабе, было использовать рекурсивный хэш-алгоритм.
Вы начинаете с хэш-таблицы, которая представляет весь диапазон векторов. Вы добавляете векторы в таблицу по одному, и как только достигаете заданного предела L векторов на таблицу, таблица делится на P непересекающихся подмножеств, которые охватывают диапазон векторов. Новые векторы, добавленные в таблицу верхнего уровня, направляются в соответствующую подтаблицу, и алгоритм рекурсирует. В указанном диапазоне хэш-таблица перестанет разделять и группировать все дочерние векторы в один вектор.
После обработки всей базы данных конечным результатом является дерево хэштабов с областями увеличенной глубины в более плотных областях набора данных. Можно решить, какие группы необходимы, исходя из количества плотных областей, давая отклонениям свои собственные группы и помещая плотные наборы в одну группу.
Я не уверен, насколько это возможно с количеством обрабатываемых строк, но кажется, что любое решение потребует значительного количества вычислений.
Нам нужно больше знать об алгоритмах, которые вы применяете к данным, потому что можно что-то вычислить, постоянно суммируя в новых данных (это может быть просто перезапись комментария Эрика Д.)
В противном случае, подумайте о том, чтобы запустить свой алгоритм на последних n днях или месяцах записей, а затем нанести результат на график во времени.
Я согласен, что нам нужно больше информации, чтобы дать вам лучший совет.
Если вам нужен анализ в режиме реального времени большого количества входящих данных, вы можете посмотреть алгоритмы потоковой передачи в целом. Многие алгоритмы потоковых потоков на самом деле не пытаются сохранить все входящие данные, а скорее использовать каждый новый dataPoint, чтобы обновить живую модель, которую вы заботитесь о. Такие алгоритмы очень полезны в таких случаях, как анализ сетевого трафика, где тенденции высокого уровня важнее каждого отдельного пакета.
Одним из примеров будет онлайн K-означает, что на самом деле не хранит каждую новую точку данных, а затем запускает K-средства на весь набор набора данных, а скорее обновляет текущий набор средств, используя новый DataPoint, а затем отбрасывает его.
Другое, что следует учитывать, будет иметь некоторое количество сжимания потерь связанных с компрессией связанных записей, таких как векторное квантование (VQ) (есть много разных ароматов VQ, оба контролируются (LVQ), так и без необходимости). Это позволит вам заменить записи «подобные» записи с представителем записи прототипа группы.