Мапить что это значит

Практичные способы маппинга данных в 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-тестирование
— опасен
— может негативно сказаться на производительности

Выводы

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

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

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

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

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

Источник

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

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-специалисту.

Источник

java-object-merger — больше чем просто маппер объектов

Всем привет! Хотел бы представить вам новую библиотеку на java для маппинга/мержинга объектов, которую я “скромно” позиционирую как возможную альтернативу dozer-у. Если вы разрабатываете enterprise приложения на java, вам не безразлична эффективность вашей работы, и хочется писать меньше скучного кода, то приглашаю почитать дальше!

UPD. Выложено в центральный репозиторий мавена

Для чего нужны мапперы объектов?

Простой ответ: чтобы копировать данные автоматически из одного объекта в другой. Но тогда вы можете спросить: зачем нужно это копирование? Можно усомниться, что это нужно очень часто. Значит следует дать более развернутый ответ.
В мире энтерпрайз приложений принято бить внутреннюю структуру на слои: слой доступа к базе, бизнес и представление/веб сервиса. В слое доступа к базе как правило обитают объекты мапящиеся на таблицы в базе. Условимся называть их DTO (от Data transfer object). По хорошему, они только переносят данные из таблиц и не содержат бизнес логики. На слое представления/веб сервисов, находятся объекты, доставляющие данные клиенту (браузер / клиенты веб сервисов). Назовем их VO (от View object). VO могут требовать только часть тех данных, которые есть в DTO, или же агрегировать данные из нескольких DTO. Они могут дополнительно заниматься локализацией или преобразованием данных в удобный для представления вид. Так что передавать DTO сразу на представление не совсем правильно. Так же иногда в бизнес слое выделяют бизнес объекты BO (Business object). Они являются обертками над DTO и содержат бизнес логику работы с ними: сохранение, модифицирование, бизнес операции. На фоне этого возникает задача по переносу данных между объектами из разных слоев. Скажем, замапить часть данных из DTO на VO. Или из VO на BO и потом сохранить то что получилось.

Если решать задачу в лоб, то получается примерно такой “тупой” код:

Знакомо? 🙂 Если да, то могу вас обрадовать. Для этой проблемы уже придумали решение.

Мапперы объектов

Придуманы конечно-же не мной. Реализаций на java много. Вы можете ознакомится, к примеру тут.
Вкратце, задача маппера — скопировать все свойства одного объекта в другой, а так же проделать все то же рекурсивно для всех чайлдовых объектов, по ходу делая необходимые преобразование типов, если это требуется.
Мапперы из списка выше — все разные, более или менее примитивные. Самый мощный пожалуй dozer, с ним я работал около 2 лет, и некоторые вещи в нем перестали устраивать. А вялый темп дальнейшей разработки дозера побудили написать свой “велосипед” (да, я знакомился с другими мапперами — для наших требовний они еще хуже).

Чем плох dozer

Какими качествами должен обладать маппер?

Почему merger а не mapper?

java-object-merger отличает от других мапперов одна особенность. Основополагающая идея была в том, чтобы дать возможность создавать снимки объектов (Snapshot) на некоторый момент времени, и потом, сравнивая их, находить различия (Diff) подобно тому, как находим diff между двумя текстами. Причем должна быть возможность просмотра снапшотов и диффов в понятном для человека текстовом виде. Так, чтобы раз взглянув на дифф сразу стали ясны все отличия, а так же как будет изменен целевой объект после применения диффа. Таким образом добиваемся полной прозрачности процесса. Никакой магии и черных ящиков! Создание снапшотов открывает еще один интересный сценарий. Можно сделать снапшот объекта, потом как-то изменив его, сделать новый снапшот — проверить что изменилось, и, при желании, откатить изменения. Кстати дифф можно обойти специальным visitor-ом, и пометить только те изменения, которые хочется применить, а остальные проигнорировать.
Так что можно сказать, что merger — это нечто большее чем просто mapper.

Использование

Программа “Hello world” выглядит примерно так:

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

Посмотрим же как реализован метод map. Это поможет понять многие вещи о библиотеке.

Если исходный снапшот это бин, и если у него есть identifier, тогда пытаемся найти целевой бин для класса destinationClass используя IBeanFinder-ы [тут createSnapshot(destinationClass, identifier); ]. Мы такие не регистрировали, да и identifier-а нет, значит идем дальше. В противном случает бин создается используя подходящий IObjectCreator [тут createSnapshot(destinationClass) ]. Мы таких тоже не регистрировали, однако в стандартной поставке имеется создатель объектов конструктором по умолчанию — он и используется. Далее у целевого снапшота берется дифф от снапшота источника и применяется к целевому объекту. Все.

Кстати, дифф, для этого простого случая, будет выглядеть так:

Основные аннотации

Преобразования типов

Категории объектов

Производительность

Честно говоря, пока писал библиотеку — о производительности особо не задумывался. Да и изначально в целях высокой производительности не было. Однако, решил замерять время маппинга N раз на один тестовый объект. Исходный код теста. Объект довольно сложный, с полями значениями, дочерними бинами, коллекциями и мапами. Для сравнения взял dozer последней на текущий момент версии 5.4.0. Ожидал, что дозер не оставит никаких шансов. Но получилось совсем наоборот! dozer замапил 5000 тестовых объектов за 32 секунды, а java-object-merger 50000 объектов за 8 секунд. Разница какая-то дикая — в 40 раз…

Применение

java-object-merger был опробован на текущем проекте с моей основной работы (osgi, spring, hibernate, сотни мапящихся классов). Чтобы заменить им дозер полностью ушло менее 1 дня. По ходу находились некоторые явные косяки, но, после исправления, все основные сценарии работали нормально.

Ленивые снапшоты

Источник

Свой mapper или немного про ExpressionTrees

Сегодня мы поговорим про то, как написать свой AutoMapper. Да, мне бы очень хотелось рассказать вам об этом, но я не смогу. Дело в том, что подобные решения очень большие, имеют историю проб и ошибок, а также прошли долгий путь применения. Я лишь могу дать понимание того, как это работает, дать отправную точку для тех, кто хотел бы разобраться с самим механизмом работы «мапперов». Можно даже сказать, что мы напишем свой велосипед.

Отказ от ответственности

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

Что называют словом «mapper»?

Это подсистема, которая отвечает за то, чтобы взять некий объект и преобразовать (скопировать его значения) его в другой. Типичная задача: преобразовать DTO в объект бизнес слоя. Самый примитивный mapper «бежит» по свойствам (property) источника данных и сопоставляет их со свойствами типа данных, который будет на выходе. После сопоставления происходит извлечение значений из источника и их запись в объект, который будет результатом преобразования. Где-то по пути, скорее всего, нужно будет ещё создать этот самый «результат».

Для потребителя mapper — это сервис, который предоставляет следующий интерфейс:

Подчеркиваю: это наиболее примитивный интерфейс, который, с моей точки зрения, удобен для объяснения. В реальности мы, скорее всего, будем иметь дело с более конкретным маппером (IMapper ) или с более общим фасадом (IMapper), который сам подберет конкретный mapper под заданные типы объектов входа-выхода.

Наивная реализация

Ремарка: даже наивная реализация mapper’a требует элементарных знаний в области Reflection и ExpressionTrees. Если вы ещё не прошли по ссылкам или ничего не слышали об этих технологиях — сделайте это, прочтите. Обещаю, мир уже никогда не будет прежним.

Впрочем, мы с вами пишем свой mapper. Для начала давайте получим все свойства (PropertyInfo) того типа данных, который будет на выходе (далее я буду называть его TOut). Это сделать достаточно просто: тип мы знаем, так как пишем имплементацию generic-класса, параметризированного типом TOut. Далее, используя экземпляр класса Type, мы получаем все его свойства.

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

Идём далее. Было бы неплохо уметь создавать экземпляр типа TOut, то есть того самого объекта, в который мы «мапим» входящий объект. В C# это можно сделать несколькими способами. Например, мы можем сделать так: System.Activator.CreateInstance(). Или даже просто new TOut(), но для этого вам нужно создать ограничение для TOut, чего в обобщенном интерфейсе делать не хотелось бы. Впрочем, мы с вами что-то знаем об ExpressionTrees, а значит можем сделать вот так:

Почему именно так? Потому что мы знаем, что экземпляр класса Type может дать информацию о том, какие у него есть конструкторы — это весьма удобно для случаев, когда мы решим развить свой mapper настолько, что будем передавать в конструктор какие-либо данные. Также, мы ещё немного узнали про ExpressionTrees, а именно — они позволяют налету создать и скомпилировать код, который потом можно будет многократно использовать. В данном случае это функция, которая на самом деле выглядит как () => new TOut().

Теперь нужно написать основной метод mapper’a, который будет копировать значения. Мы пойдем по самому простому пути: идём по свойствам объекта, который пришёл к нам на вход, и ищем среди свойств исходящего объекта свойство с таким же названием. Если нашли — копируем, если нет — идём дальше.

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

Производительность и boxing

Reflection отличная, но медленная штука. Более того, её частое использование увеличивает memory traffic, а значит нагружает GC, а значит ещё больше замедляет работу приложения. Например, только что мы использовали методы PropertyInfo.SetValue и PropertyInfo.GetValue. Метод GetValue возвращает object, в которой завернуто (boxing) некое значение. Это значит, что мы получили аллокацию на пустом месте.

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

Компилируемый mapper

На самом деле, всё относительно просто: мы уже делали new с помощью Expression.New(ConstructorInfo). Наверное вы заметили, что статический метод New называется точно так же, как и оператор. Дело в том, что почти у всего синтаксиса C# есть отражение в виде статических методов класса Expression. Если чего-то нет, то это значит, что вы ищите т.н. «синтаксический сахар».

Вот несколько операций, которые мы будем использовать в нашем mapper’e:

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

Для начала мы создаем объектное представление параметра нашей функции. Так как она принимает на вход object, то и параметром будет объект типа object.

Далее мы создаем две переменные и список Expression, в который будем последовательно складывать выражения присваивания. Порядок важен, ведь именно так команды будут выполнены, когда мы вызовем скомпилированный метод. Например, мы не можем присвоить значение переменной, которая ещё не объявлена.

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

Важный момент: после того, как мы создали все операции присваивания нам нужно вернуть результат из функции. Для этого последним выражением в списке должно быть Expression, содержащее экземпляр класса, который мы создали. Я оставил комментарий рядом с этой строчкой. Почему поведение, соответствующее ключевому слову return в ExpressionTree выглядит именно так? Боюсь, что это отдельная тема. Сейчас я предлагаю это просто запомнить.

Ну и в самом конце мы должны скомпилировать все выражения, которые мы построили. Что нам тут интересно? Переменная body содержит «тело» функции. У «обычных функций» ведь есть тело, верно? Ну, которое мы заключаем в фигурные скобки. Так вот, Expression.Block — это именно оно. Так как фигурные скобки — это ещё и область видимости, то мы должны передать туда переменные, которые там будут использоваться — в нашем случае sourceInstance и outInstance.

Почему не будет boxing? Потому что скомпилированный ExpressionTree это настоящий IL и для runtime он выглядит также (почти), как и ваш код. Почему «скомпилированный mapper» работает быстрее? Снова: потому что это просто обычный IL. Кстати, скорость мы можем легко подтвердить с помощью библиотеки BenchmarkDotNet, а сам бенчмарк можно посмотреть тут.

В колонке Ratio «скомпилированный mapper» (CompiledMapper) показал очень неплохой результат, даже по сравнению с AutoMapper (он baseline, т.е. 1). Впрочем, давайте не будем радоваться: AutoMapper обладает значительно большими возможностями по сравнению с нашим велосипедом. Этой табличкой я лишь хотел показать, что ExpressionTrees значительно быстрее, чем «подход классического Reflection».

Резюме

А что mapper? Mapper — отличный пример, на котором всему этому можно научиться.

Источник