Маппинг данных что это

Чернобровов Алексей Аналитик

Big Data Mapping: что такое маппирование больших данных

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

Что такое маппирование данных и где это используется

Представим, что в одной из корпоративных систем сведения о семейном положении сотрудника хранятся так, что «1» в поле «дети» означает их наличие. В другой системе эти же данные записаны с помощью значения «True», а в третьей – словом «да». Таким образом, разные системы для обозначения одних и тех же данных используют разные отображения. Чтобы привести информацию к единообразию, следует сопоставить обозначения одной системы обозначениям в других источниках, т.е. выполнить процедуру мэппинга данных (от английского map – сопоставление). В широком смысле маппирование – это определение соответствия данных между разными семантиками или представлениями одного объекта в разных источниках. На практике этот термин чаще всего используется для перевода или перекодировки значений [1].

Дисциплина управления данными, Data Management, трактует маппинг как процесс создания отображений элементов данных между двумя различными моделями, который выполняется в начале следующих интеграционных задач [2]:

Таким образом, маппирование данных представляет собой процесс генерации инструкций по объединению информации из нескольких наборов данных в единую схему, например, конфигурацию таблицы. Поскольку схемы данных в разных источниках обычно отличаются друг от друга, информацию из них следует сопоставить, выявив пересечение, дублирование и противоречия [3].

С прикладной точки зрения можно следующие приложения маппинга данных [4]:

В Big Data мэппинг выполняется при загрузке информации в озеро данных (Data Lake) и корпоративное хранилище (DWH, Data Warehouse). Чем Data Lake отличается от DWH, рассмотрено здесь. В этом случае маппинг реализуется в рамках ETL-процесса (Extract, Transform, Load) на этапе преобразования. При этом настраивается соответствие исходных данных с целевой моделью (рис. 1). В случае реляционных СУБД для идентификации одной сущности в разных представлениях нужно с ключами таблиц и настройкой отношений (1:1, *:1, 1:* или *:*) [5].

Рис.1. Маппирование данных при консолидации таблиц

В Data Science маппирование данных входит в этап их подготовки к ML-моделированию, когда выполняется формирование датасета в виде матрицы значений для обработки соответствующими алгоритмами. В частности, когда Data Scientist обогащает исходный датасет данными из сторонних источников, он занимается маппингом данных. Проводить процедуру дата мэппинга можно вручную или автоматически с помощью соответствующих подходов и инструментов, которые рассмотрены далее.

Особенности процесса дата мэппинга

На практике трудоемкость мэппинга зависит от следующих факторов [3]:

Облегчить процесс маппирования можно за счет метаданных – сведениях о признаках и свойствах объектов, которые позволяют автоматически искать и управлять ими в больших информационных потоках. В частности, если каждое приложение будет выполнять публикацию метаданных, что позволит создать их стандартизированный реестр, то маппинг будет полностью автоматизированным [2]. Однако в большинстве случаев процесс мапирования данных не полностью автоматизирован и состоит из следующих этапов [4]:

При работе с большими объемами данных выделяют 3 основных подхода к маппированию [2]:

Также стоит упомянуть полуавтоматическое маппирование в виде конвертирования схем данных, когда специализированная программа сравнивает источники данных и целевую схему для консолидации. Затем разработчик проверяет схему маппирования и вносит исправления, где это необходимо. Далее программа конвертирования схем данных автоматически генерирует код на C++, C # или Java для загрузки данных в систему приемник (рис. 3) [3].

Рис. 3. Конвертирование схем данных в процессе мэппинга

Далее рассмотрим, какие инструментальные средства реализуют вышеперечисленные подходы.

Инструменты маппирования больших данных

Как и большинство прикладных решений, все средства для маппинга данных можно разделить на 3 категории [6]:

Большинство перечисленных продуктов поддерживают все 3 подхода к маппированию: ручной (GUI и кодирование), data-driven и семантический. Однако, семантический мэппинг требует наличия реестров метаданных, что имеется далеко не в каждом предприятии. А публичные реестры метаданных, такие как национальные, отраслевые или городские репозитории [7] не всегда напрямую коррелируют, например, с задачами построения локального DWH. Но, наряду с открытыми государственными данными и другими публичными датасетами, их можно использовать в исследовательских DS-задачах.

При выборе конкретного инструмента для маппинга больших данных стоит учитывать следующие факторы:

Резюме

Итак, маппирование данных – это важная часть процесса работы с данными, в том числе и для Data Scientist’а. Эта процедура выполняется в рамках подготовки к ML-моделированию, в частности, при обогащении датасетов. В случае одноразового формирования датасета из нескольких разных источников сопоставление данных можно выполнить вручную или с помощью самописного Python-скрипта. Однако, такой подход не применим в промышленной интеграции нескольких информационных систем или построении корпоративных хранилищ и озер данных. Поэтому знание инструментов дата мэппинга пригодится как Data Scientist’у, так и Data Engineer’у. Наконец, сопоставление данных с целью избавления от дублирующихся и противоречивых значений входит в задачи обеспечения качества данных (Data Quality) [4]. В свою очередь, Data Quality относится к области ответственности стратега по данным и инженера по качеству данных. Таким образом, понимание процесса маппирования необходимо каждому Data-специалисту.

Источник

Маппинг данных из реляционной БД

Иногда возникают ситуации, когда решение задачи выборки данных из реляционной БД не укладывается в возможности используемой в проекте ОРМ, например, либо из-за недостаточной скорости работы самой ОРМ, либо не совсем оптимальных SQL запросов генерируемых ею. В таком случае обычно приходится писать запросы вручную.

Проблема в том, что данные из БД (в т.ч. в ответ на JOIN запрос) возвращаются в виде “плоского” двухмерного массива никак не отражающего сложную “древовидную” структуру данных приложения. Работать с таким массивом дальше крайне неудобно, поэтому требуется более-менее универсальное решение, позволяющее привести этот массив в более подходящий вид по заданному шаблону.

Решение было найдено, удобное и достаточно быстрое.

На сколько быстрое

Для оценки скорости работы библиотеки я собрал небольшой испытательный стенд на котором скорость работы моей библиотеки сравнивается со скоростью работы Eloquent. Для замеров использовался пакет phpbench.

Для того чтобы развернуть стенд у себя:

Здесь я использовал инструмент описанный в моей предыдущей статье.

Затем в меню выбираем: 1 Develop, затем: 1 Build, затем 2 Deploy and Up;
Затем запускаем тесты 5. Run tests

В базе 3000 книг. Результаты получились следующие:

benchEloquent — вытаскивает все книги с авторами с использованием Eloquent
benchEloquentId — вытаскивает определенную книгу с авторами с использованием Eloquent (10 раз)

benchProc — вытаскивает все книги с авторами с использованием библиотеки
benchProcId — вытаскивает определенную книгу с авторами с использованием библиотеки (10 раз)

Возможно приведенные тесты недостаточно репрезентативны, но разница заметна, как по времени выполнения, так и по расходованию памяти.

Как это работает

Далее, для примера (крайне простого), представим, что у нас имеется БД книг и авторов со следующей структурой.

Задача — вытащить все книги с их авторами.

Запрос будет выглядеть как-то так:

В ответ мы получим примерно такой массив данных.

Для этого немного изменим наш запрос:

Здесь мы в секции SELECT задали алиасы: для полей с данными о книгах алиасы с префиксом ‘book_’, а для полей с информацией об авторах с префиксом ‘author’.

Далее преобразуем ответ БД

$rows — ответ БД в виде массива объектов /stdClass()
$config — ассоциативный массив отражающий структуру данных итогового массива

Источник

Практичные способы маппинга данных в Kotlin

Маппинг данных – один из способов для разделения кода приложения на слои. Маппинг широко используется в Android приложениях. Популярный пример архитектуры мобильного приложения Android-CleanArchitecture использует маппинг как в оригинальной версии (пример маппера из CleanArchitecture), так и в новой Kotlin версии (пример маппера).

Маппинг позволяет развязать слои приложения (например, отвязаться от API), упростить и сделать код более наглядным.

Пример полезного маппинга изображен на схеме:

Для примера модели упрощены. Person содержит Salary в обоих слоях приложения.

В настоящем коде, если у вас одинаковые модели, возможно, стоит пересмотреть слои приложения и не использовать маппинг.

Метод №1: Методы-мапперы

Самый быстрый и простой метод. Именно он используется в CleanArchitecture Kotlin (пример маппинга).

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

Еще проблема может возникнуть если по требованиям архитектуры слои приложения не могут знать друг о друге: т.е. в классе Src слоя нельзя работать со слоем Dst и наоборот. В этом случае такой вариант маппинга использовать не получится.

В рассмотренном примере слой Src зависим от слоя Dst и может создавать классы этого слоя. Для обратной ситуации (когда Dst зависим от Src ) подойдет вариант со статическими методами-фабриками:

Маппинг находится внутри классов Dst слоя, значит эти классы не раскрывают все свои свойства и структуру использующему их коду.

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

Резюме метода маппинга:

+ Быстро писать код, маппинг всегда под рукой
+ Легкая модификация
+ Низкая связность кода
— Затруднено Unit-тестирование (нужны моки)
— Не всегда позволено архитектурой

Метод №2: функции-мапперы

Размещение маппера и классов, с которыми он работает, в разных местах проекта не всегда удобно. При частой модификации класса придётся искать и изменять разные файлы в разных местах.

Резюме метода маппинга:

+ Простое Unit-тестирование
— Затруднена модификация
— Требуются открытые поля у классов с данными

Метод № 3: Функции-расширения

При этом стоит учесть, что функции расширения могут приводить к неожиданному поведению из-за своей статической природы: https://kotlinlang.org/docs/reference/extensions.html#extensions-are-resolved-statically

Резюме метода маппинга:

+ Простое Unit-тестирование
— Затруднена модификация
— Требуются открытые поля у классов с данными

Метод №4: Классы-мапперы с интерфейсом

Относительно маппинга в функции у этого примера только один недостаток – необходимость писать немного больше кода.

Резюме метода маппинга:

+ Лучше типизация
— Больше кода

Как и функции-мапперы:

+ Простое Unit-тестирование
— Затруднена модификация
— требует открытые поля у классов с данными

Метод 5: Рефлексия

Метод черной магии. Рассмотрим этот метод на других моделях.

В данном примере EmployeeSrc и EmployeeDst хранят имя в разных форматах. Мапперу нужно только составить имя для новой модели. Остальные поля обработаются автоматически, без написания кода (вариант else в when ).

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

Большая проблема возникнет, например, если вы добавите обязательные поля в Dst и его случайно не окажется в Src или в маппере: cлучится IllegalArgumentException в runtime. Также рефлексия имеет проблемы с производительностью.

Резюме метода маппинга:

+ меньше кода
+ простое Unit-тестирование
— опасен
— может негативно сказаться на производительности

Выводы

Такие выводы можно сделать из нашего рассмотрения:

Методы-мапперы — наглядный код, быстрее писать и поддерживать

Функции-мапперы и функции расширения – просто тестировать маппинг.

Классы мапперы с интерфейсом — просто тестировать маппинг и яснее код.

Рефлексия – подходит для нестандартных ситуаций.

Источник

ElasticSearch — mapping и поиск без сюрпризов

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

Всем, кому интересен современный поисковый движок ElasticSearch, прошу под кат.

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

Зачем нужен mapping?

Mapping похож на определение таблицы в sql базах данных. Мы явно указываем тип каждого поля и дополнительные параметры, такие как анализатор, дефолтное значение, source и так далее. Подробнее ниже.

Мы можем указать mapping при создании индекса, тем самым за один запрос определить для всех типов в индексе.

Так же можем указать mapping напрямую для определённого типа в индексе:

А можем указать mapping сразу для нескольких индексов:

Так ли он нужен?

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

Базовые типы данных

Думаю, все уже догадались, о чём пойдёт речь. Базовых типов всего 7: string, integer/long, float/double, boolean, null

Примечание: По умолчанию _source = true и весь документ хранится в индексе в исходном состояние и возвращается по запросу. И это работает быстрее, чем хранить в индексе отдельные поля, при условии, что ваш документ не огромен. Тогда хранение только необходимых полей может дать профит. Поэтому я не рекомендую трогать это поле без веской на то причины.

Типы array/object/nested

Мы можем указать не только тип массив для поля, но и указать тип для каждого поля внутри массива, вот пример:

Nested(вложенный) type

По сути, мы определяем документ внутри документа. Зачем это нужно? Отличный пример из документации:

Если мы будем искать name = blue && count>5 то этот документ будет найден, что бы избежать такого сценария, стоит использовать nested тип.
Пример:

Указывать properties для элементов объекта не обязательно, ES сделает это автоматически.
Для поиска по nested типу следует использовать nested query или nested filter.

Multi-fields

Начиная с версии 1.0 этот прекрасный параметр был добавлен ко все базовым типам (кроме nested и object).
Что он делает? Этот параметр позволяет указать разные настройки маппинга для одного поля.
Зачем это может быть нужно? например, у вас есть поле, по которому вы хотите и искать и группировать. Если отключить анализатор, поиск будет работать не на полную катушку, а если включить, то группировать мы будем не по сырым данным, а по обработанным. Например, Санкт-Петербург после анализатора будет «Санкт» и «Петербург» (возможно слегка по-другому, но для примера сойдёт). Если мы будет группировать по этому полю, то получим не то, что хотели.

Теперь мы можем обращаться к «title» за поиском и к «raw» за группировкой и любыми другими видами сортировки.

Остальные типы

Надеюсь, что я смог доходчиво рассказать о главных функциях mapping’a в ES. Если у вас есть вопросы, рад буду ответить.

Источник

Мэппинг в бюджетировании. Что это, и зачем он нужен?

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

Мэппинг – это сопоставление, определение связей и соответствия между различными объектами системы. Говоря по-русски, это картирование, когда вы составляете «карту системы», описываете маршрут процесса получения данных. Разберем сегодня, как этот инструмент пригодится в бюджетировании.

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

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

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

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

Суть мэппинга:

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

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

Возможны ситуации, когда всё будет один к одному: одна статья бюджета равна одной статье первичного учета, например, расхода. Это нормально. Многие так работают. Просто очень часто это неэффективно.

Важно:

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

Если ваше множество данных по какой-то статьей включает А, Б и ещё что-то, то условия должны включить их все:

— например, вы для одной статьи выбираете «А», для второй статьи выбираете «Не А»;

— либо вы можете выбрать для одной статьи «А», для второй «Б», для третьей «Не А и Не Б».

Т.е. должна быть учтена вся совокупность данных.

Если вы выберете только А и Б, то получите дыру в части данных из области «ещё что-то…».

Пока попробуйте понять написанное, а в следующей статье разберем пример, чтобы было понятнее, что это за зверь такой.

Источник