Агрегирование данных
«. Агрегирование данных (data aggregation): процесс сбора, обработки и представления информации в окончательном виде. Агрегирование данных в основном выполняется для формирования отчетов, выработки политики, управления здравоохранением, научных исследований, статистического анализа и изучения здоровья населения. «
Источник:
«ИНФОРМАТИЗАЦИЯ ЗДОРОВЬЯ. ТРЕБОВАНИЯ К АРХИТЕКТУРЕ ЭЛЕКТРОННОГО УЧЕТА ЗДОРОВЬЯ. ГОСТ Р ИСО/ТС 18308-2008»
(утв. Приказом Ростехрегулирования от 11.03.2008 N 44-ст)
Смотреть что такое «Агрегирование данных» в других словарях:
агрегирование данных — Процесс сбора, обработки и представления информации в окончательном виде. Агрегирование данных в основном выполняется для формирования отчетов, выработки политики, управления здравоохранением, научных исследований, статистического анализа и… … Справочник технического переводчика
агрегирование данных — (data aggregation): Процесс сбора, обработки и представления информации в окончательном виде. Агрегирование данных в основном выполняется для формирования отчетов, выработки политики, управления здравоохранением, научных исследований,… … Словарь-справочник терминов нормативно-технической документации
агрегирование — 3.2 агрегирование (aggregation): Процесс или результат объединения конструкций языка моделирования и других компонентов модели в единое целое. Примечание Конструкции языка моделирования и другие компоненты модели могут быть агрегированы в более… … Словарь-справочник терминов нормативно-технической документации
агрегирование — Объединение, суммирование экономических показателей по какому либо признаку для получения обобщенных совокупных показателей. При агрегировании необходим учет структуры объединяемых элементов, в ряде случаев требуется анализ возможности и… … Справочник технического переводчика
Агрегирование — [aggregation, aggregation problem] объединение, укрупнение показателей по какому либо признаку для получения обобщенных, совокупных показателей — агрегатов. С математической точки зрения А. рассматривается как преобразование модели в модель … Экономико-математический словарь
агрегирование информации — Преобразование детализированной информации в пакеты (агрегаты) данных, что позволяет анализировать экономику в терминах небольшого числа соответствующих агрегированных переменных, которые включают капитал, труд, товары (промежуточные и конечные) … Справочник технического переводчика
агрегирование каналов — Метод повышения пропускной способности за счет объединения нескольких параллельных каналов в один высокоскоростной поток данных. [Л.М. Невдяев. Телекоммуникационные технологии. Англо русский толковый словарь справочник. Под редакцией Ю.М.… … Справочник технического переводчика
АГРЕГИРОВАНИЕ — соединение отдельных единиц или данных в единый показатель. Например, все цены индивидуальных товаров и услуг образуют один общий уровень цен или все единицы продукции агрегируются в реальный чистый национальный продукт … Большой бухгалтерский словарь
АГРЕГИРОВАНИЕ ИНФОРМАЦИИ — преобразование детализированной информации в пакеты (агрегаты) данных, что позволяет анализировать экономику в терминах небольшого числа соответствующих агрегированных переменных, которые включают капитал, труд, товары (промежуточные и конечные) … Большой бухгалтерский словарь
АГРЕГИРОВАНИЕ — соединение отдельных единиц или данных в единый показатель. Например, все цены индивидуальных товаров и услуг образуют один общий уровень цен или все единицы продукции агрегируются в реальный чистый национальный продукт … Большой экономический словарь
Большой курс по MongoDB
Агрегация
Jan 11, 2018 · 4 min read
Агрегация — это группировка значений многих документов. Операции агрегирования позволяют манипулировать такими сгруппированными данными например проводить подсчет по полям. В MySQL аналогом агрегации является команда group by. MongoDB предоставляет три способа выполнения агрегации: pipeline, Map-Reduce и одноцелевые методы агрегирования.
Pipeline
Фреймворк для агрегации в MongoDB моделирует концепцию обработку данных с помощью pipeline. Документы вводят многоэтапный конвейер, который преобразует документы в агрегированный результат.
Самые основные pipeline представляют фи л ьтры, которые работают как запросы и преобразования документов. Другие pipeline это функции для группировки и сортировки документов по конкретному полю или нескольким полям, а также инструменты для агрегирования массивов. Также эти инструменты может обеспечивать выполнение таких задач как вычисление среднего числа или конкатенация строк.
Pipeline обеспечивает эффективную агрегацию данных с использование собственных операторов в MongoDB и является предпочтительным методом работы с агрегацией в MongoDB.
Pipeline агрегация можно работать и с sharded коллекциями. Что это мы узнаем позже.
Pipeline агрегация может использовать индексы для увеличения производительности на некоторых этапах. Кроме того pipeline агрегация имеет внутреннюю оптимизацию. Чтобы использовать агрегацию MongoDB предоставляет метод:
Некоторые этапы pipeline принимают выражение конвейера в качестве операнда. Выражения конвейера указывают преобразование, применяемое к входным документам. Выражения имеют структуру документа и могут содержать другое выражение.
Выражения pipeline могут работать только с текущим документом в pipeline и не могут ссылаться на данные из других документов: операции выражения обеспечивают преобразование документов в оперативной памяти. Как правило, выражения не имеют состояния и оцениваются только при рассмотрении процесса агрегации с одним исключением: выражения аккумулятора.
Представим, что у нас есть простая коллекция.
Напишем простой агрегатор:
Таким образом на выход мы получим документ:
Map-Reduce
map-reduce — это алгоритм предложенный гугл для обработки больших данных. Тут все довольно просто есть две функции одна map, которая удаляет поля в документах по определенным признакам и группирует их и функция reduce, которая может свернуть значение сгруппированных документов.
Представим, что у нас есть вот такая коллекция:
И задача, подсчитать среднюю зарплату по профессии независимо от его специальности, напишем следующий mapReduce:
А теперь детально разберемся, что тут происходит!
Если не понимаете, что происходит прочитайте еще раз.
А затем этот массив поместиться в коллекцию, которую мы указали в out и мы можем позже проанализировать результат. Мощность данного алгоритма заключается в том, что в теории мы можем его распараллелить, что позволяет обрабатывать огромные массивы данных на множестве ядер/процессоров/машин.
Одноцелевая агрегация
Это агрегация одной коллекции по определенному ключу. Например:
Позволяет нам узнать, количество элементов в коллекции, это агрегация, по определенному признаку, которая встроена в MongoDB, но мы ее можем создать сами с помощью алгоритмов изложенных выше. Чтобы сделать агрегацию по определенному полю:
Таким образом мы получим список уникальных тегов в коллекции. Также мы можем передать вторым аргументом селектор, который преобразует подмножество коллекции products.
Наследование, композиция, агрегация
Нередко случается, что решив разобраться с какой-то новой темой, понятием, инструментом программирования, я читаю одну за другой статьи на различных сайтах в интернете. И, если тема сложная, то эти статьи могут не на шаг не приблизить меня к понимаю. И вдруг встречается статья, которая моментально дает озарение и все паззлы складываются воедино. Трудно определить, что отличает такую статью от других. Правильно подобранные слова, оптимальная логика изложения или же просто более релевантный пример. Я не претендую на то, что моя статься окажется новым словом в C# или же лучшей обучающей статьей. Но, возможно для кого-то она станет именно той, которая позволит разобраться, запомнить и начать правильно применять те понятия, о которых пойдет речь.
В объектно-ориентированных языках программирования существует три способа организации взаимодействия между классами. Наследование — это когда класс-наследник имеет все поля и методы родительского класса, и, как правило, добавляет какой-то новый функционал или/и поля. Наследование описывается словом «является». Легковой автомобиль является автомобилем. Вполне естественно, если он будет его наследником.
Ассоциация – это когда один класс включает в себя другой класс в качестве одного из полей. Ассоциация описывается словом «имеет». Автомобиль имеет двигатель. Вполне естественно, что он не будет являться наследником двигателя (хотя такая архитектура тоже возможна в некоторых ситуациях).
Выделяют два частных случая ассоциации: композицию и агрегацию.
Композиция – это когда двигатель не существует отдельно от автомобиля. Он создается при создании автомобиля и полностью управляется автомобилем. В типичном примере, экземпляр двигателя будет создаваться в конструкторе автомобиля.
Агрегация – это когда экземпляр двигателя создается где-то в другом месте кода, и передается в конструктор автомобиля в качестве параметра.
Хотя ведутся дискуссии о преимуществах того или иного способа организации взаимодействия между классами, какого-либо абстрактного правила не существует. Разработчик выбирает тот или иной путь основываясь на элементарной логике (“является” или “имеет”), но также принимает во внимание возможности и ограничения, которые дают и накладывают эти способы. Для того, чтобы увидеть эти возможности и ограничения, я попытался написать пример. Достаточно простой, чтобы код оставался компактным, но и достаточно развитый, чтобы в рамках одной программы можно было применить все три способа. И, главное, я попытался сделать этот пример как можно менее абстрактным – все объекты и экземпляры понятны и осязаемы.
Напишем простенькую игру – танковый бой. Играют два танка. Они поочередно стреляют и проигрывает тот, здоровье которого упало до нуля. В игре будут различные типы снарядов и брони. Для того, чтобы нанести урон необходимо во-первых, попасть по танку противника, во-вторых, пробить его броню. Если броня не пробита, урон не наносится. Логика игры построена на принципе «камень-ножницы-бумага»: то есть броня одного типа хорошо противостоит снарядам определенного типа, но плохо держит другие снаряды. Кроме того, снаряды, которые хорошо пробивают броню, наносят малый «заброневой» урон, и, напротив, наиболее «летальные» снаряды имеют меньше шансов пробить броню.
Создадим простенький класс для пушки. Он будет иметь два приватных поля: калибр и длину ствола. От калибра зависит урон, и, частично, способность к пробитию брони. От длины ствола – точность стрельбы.
Сделаем также конструктор для пушки:
Сделаем метод для получения калибра из других классов:
Помните, что для поражения цели должно произойти две вещи: попадание в цель и пробитие брони? Так вот, пушка будет отвечать за первую из них: попадание. Поэтому делаем булевый метод IsOnTarget, который принимает случайную величину (dice) и возвращает результат: попали или нет:
Целиком класс пушки выглядит следующим образом:
Здесь мы применили агрегацию. Где-то будет создана пушка. Потом к этой пушке будут создаваться снаряды, которые имеют указатель на пушку.
Теперь сделаем разные типы снарядов, которые будут наследовать абстрактный снаряд: фугасный, кумулятивный, подкалиберный. Фугасный наносит самый большой урон, кумулятивный – меньше, подкалиберный – еще меньше. Дочерние классы не имеют полей и вызывают конструктор базового снаряда, передавая ему пушку, и строковый тип. В дочернем классе переопределяется метод GetDamage() – вносятся коэффициенты, которые увеличат или уменьшат урон по сравнению с дефолтным.
Фугасный (дефолтный урон):
Кумулятивный (дефолтный урон х 0.6):
Подкалиберный (дефолтный урон х 0.3):
Обратите внимание, что в переопределенном методе GetDamage вызывается и метод базового класса. То есть, переопределив метод, мы также сохраняем возможность обратиться к дефолтному методу, использовав ключевое слово base).
Итак, для снарядов мы применили и агрегацию (пушка в базовом классе), и наследование.
Создадим теперь броню для танка. Здесь применим только наследование. Любая броня имеет толщину. Поэтому абстрактный класс брони будет иметь поле thickness, и строковое поле type, которое будет определятся при создании дочерних классов.
Броня будет в нашей игре определять пробита они или нет. Поэтому, у нее будет лишь один метод, который будет переопределяться в дочерних, в зависимости от типа брони.
Для того, чтобы конструктор танка остался более-менее компактным, сделаем два вспомогательных приватных метода, которые добавляют три типа брони соответствующей толщины, и наполняют боеукладку 10 снарядами каждого из трех типов:
Теперь конструктор танка выглядит вот таким образом:
Пользовательский интерфейс танка состоит из трех методов: выбрать броню, зарядить пушку, выстрелить.
Как я упомянул в начале, в этом примере я старался максимально уйти от абстрактных понятий, которые нужно все время держать в голове. Поэтому каждый экземпляр снаряда у нас равен физическому снаряду, который положили в боеукладку перед боем. Следовательно, снаряды могут закончится в самый неподходящий момент!
Этот интерфейс требует реализации метода Clone(). Вот она:
Теперь все супер реалистично: при выстреле генерируется dice, пушка рассчитывает попадание своим методом IsOnTarget, и, если попадание есть, то метод Shoot вернет экземпляр снаряда, а если промах – то вернет null.
Последний метод танка – его поведение при попадании вражеского снаряда:
Все готово. Остается только написать консольный (или неконсольный) вывод, в котором будет обеспечен пользовательский интерфейс и в цикле реализованы поочередные ходы игроков.
Подведем итоги. Мы написали программу, в которой использовали наследование, композицию и агрегацию, надеюсь, поняли и запомнили различия. Активно задействовали возможности полиморфизма, во-первых, когда любые экземпляры дочерних классов можно сложить в список, имеющий тип данных родительского, а во-вторых, создавая методы, которые принимают в качестве параметра родительский экземпляр, но внутри которых вызываются методы дочернего. По ходу текста я упоминал возможные альтернативные реализации – замену наследования на агрегацию, и, универсального рецепта тут нет. В нашей реализации наследование дало нам легкость добавления новых деталей в игру. Например, чтобы добавить новый тип снаряда нам нужно лишь:
Ниже – приведена диаграмма наших классов.
В финальном коде игры все «магические числа», которые использовались в тексте, вынесены в отдельный статический класс Config. К публичным полям статического класса мы можем обратиться из любого фрагмента нашего кода и его экземпляр не нужно (и невозможно) создавать. Вот так он выглядит:
ElasticSearch — агрегация данных
В статье мы рассмотрим, как правильно реализовывать агрегацию данных, зачем это может понадобиться, и сдобрим это кучей рабочих примеров.
Для всех, кому интересно как сделать свои запросы в ES интереснее и посмотреть на обычной поиск с другой стороны, прошу под кат.
В предыдущей статье пользователи разделились поровну между статьёй по более простой теме и по более сложной, поэтому я выбрал не очень сложную тему, но довольно свежую, которая добавилась в ES относительно недавно(v1.0) и несёт довольно интересный функционал.
Aggregation module
Этот модуль пришел в ES на смену Facets, причем в настойчивой форме, Facets теперь считаются устаревшими и будут удалены в ближайшие релизы. Хотя агрегаты и были добавлены в v1.0.0RC1, а сейчас уже >1.2, я все же не рекомендую использовать Facets.
Зачем же понадобилось изменять рабочий инструмент?
Наверное, главной фишкой агрегатов является их вложенность. Приведу общий синтаксис запроса:
Как видно из структуры, агрегатов может быть сколь угодно много, и у каждого элемента может быть вложенный элемент без ограничений по глубине.
Используя вложенность, мы можем получить очень интересные статистические данные (пример в конце статьи).
Типы агрегатов
Типов агрегатов очень много, но все их можно объединить в 2 главных типа:
— Bucketing (Обобщение)
Для простоты понимания, это можно сравнить со всем знакомым инструментов «GROUP BY». Конечно, это довольно упрощенное сравнение, но принцип работы схож. Этот тип на основе фильтров обобщает документы, по какому-то определённому признаку, хороший пример это terms aggregation.
— Metric (Метрические)
Это агрегаты, которые высчитывают какие либо значение по определенному набору документов. Например sum aggregation
Думаю, для начало теории хватит, всем, кого интересует более фундаментальная информация по этому модулю, могут ознакомится с ней по этой ссылке.
Простой пример
Дамп наглым образом взят из этой прекрасной статьи
Давайте сгруппируем спортсменов по их виду спорта и узнаем сколько их в каждом спорте:
Тут мы используем агрегат «terms», который группирует документа по полю «sport».
«size» : 0 (0 заменяется на Integer.MAX_VALUE автоматически) говорит о том, что нам нужные все документы без исключения, в нашем случае не важна скорость, но надо учитывать, что более точный результат требует больше времени.
Отлично, бейсболистов больше всего.
Давайте отсортируем спортсменов по среднему значению их рейтинга, от большего к меньшему:
Тут отлично видно, что такое вложенный агрегат и как он может помочь нам выбрать документы максимально гибко.
Сначала мы указываем, что нужно сгруппировать спортсменов по имени, потом отсортировать по «rating_avg», который высчитывается в под агрегате «avg», по полю «rating». Заметьте, как элегантно ES работает с массивами ( «rating» : [10, 9] ) и с легкостью высчитывает среднее значение.
Начиная с версии 1.2.0 выполнение скриптов по умолчанию отключено. Вы можете его включить, при условии что у пользователей нет прямого доступа к ES (Надеюсь, что это так, иначе советую вам немедленно закрыть этот доступ ради безопасности ваших данных).
Агрегация во всей красе или что-то посложнее
Давайте найдём всех спортсменов, которые находятся в радиусе 20 миль от точки «46.12,-68.55»
Сгруппируем их по виду спорта и выведем подробную статистику по рейтингу спортсменов в этом виде спорта.
Звучит неплохо, а вот и пример.
Заключение
Надеюсь, я смог донести общие возможности этого прекрасного модуля. Всем, кого это тема заинтересовала, я советую ознакомиться со всем списком фильтров по этой ссылке.
Рад любым полезным замечаниям и дополнениям по теме.
Так же можно прочитать мою предыдущую статью по ES — ElasticSearch и поиск наоборот. Percolate API
И принять участие в голосование внизу статьи.
Агрегаты в БД — многомерные суперагрегаты
В прошлой статье мини-цикла о работе с агрегатами я рассказывал, как организовать эффективное многопоточное преобразование потока первичных данных в данные агрегированные. Там мы рассматривали задачу «свертки» продаж в агрегаты вида товар/дата/кол-во.
Сегодня мы рассмотрим более сложный вариант, который зачастую начинается со слов «А заказчик захотел…» и приводит нас к иерархичным агрегатам в нескольких одновременных разрезах, которые позволяют нам в СБИС практически мгновенно строить оперативные отчеты в подсистемах организации торговли, бухгалтерского учета и даже управления активными продажами.
Бизнес-требования
уметь быстро получить информацию не только по товарам, но и по складам
в том числе и сводка-TOP продаж товаров на интервале
в том числе с фильтром по складу. или без
а еще график динамики продаж за месяц по дням. и за год по месяцам. и за все время по годам
. и с любым из фильтров склад/товар
. и чтобы все быстро работало!
Итак, вычленяем ключевое для нас относительно предыдущей задачи:
нужны агрегаты для динамики (дневные/месячные/годовые) в разрезе любого фильтра
Структура новых агрегатов
Замечу, что тут для экономии размера данных мы использовали однобайтный спецтип «char». Например, такой тип имеет поле relkind (тип объекта) в системной таблице pg_class.
Неудобный NULL и удобный ноль
То есть для запроса «какие товары продавались лучше всего в таком-то месяце» будем использовать запрос вида:
В результате, за единственный Index Scan мы получим сразу все, что хотим, без какой-либо динамической агрегации на моменте получения данных.
Динамика в разрезе фильтра
Давайте теперь сконструируем запрос, который поможет нам нарисовать красивый график по динамике:
Сборка агрегатов
Вместе с этим мы вставляем во flow новую «первичку» для последующих «надагрегатов», заменяя нулем каждый из вариантов разрезов анализа.
Задача: «Вскипятить воду в чайнике»
И физик и математик: налить воду в чайник, зажечь плиту, поставить чайник на огонь и подогреть до 100*С.
Новая задача: «Вскипятить воду в чайнике. Чайник уже налит, огонь горит»
Физик: поставить чайник на огонь и подогреть.
Понятно, что при последующей обработке такого ключа, содержащего хотя бы один ноль, записи «надагрегатов» формировать уже не нужно.
Обходим блокировки
Мини-серия «Агрегаты в БД»:
