Processing

Что такое #codevember и зачем он нужен? В последние пару лет каждый ноябрь я натыкался в соцсетях на интересные произведения искусства, созданные ИИ, отмеченные этим хэштегом. Согласно информации с codevember.xyz:

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

В этом году я решил попробовать поучаствовать и в ноябре изучить Processing (p5.js) и побаловаться созданием графики, которая создана не для какой-то определённой задачи.

Подготовительной работой лучше заниматься в фоновом режиме

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

Я раньше читал Природу кода Дэниэла Шиффмана. Он начинал с броуновского движения и текучих форм, которые, как я думал, могли быть использованы в точке размещения пера для рисования.




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

Темп важен

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





Использование текучих форм как инструмента для рисования

Легко впишется в твой день, но не в каждый

Я был довольно-таки постоянным, но несколько дней я пропустил и наверстал на следующий день, сделав два скетча. Был и день, который я не наверстал. Имея семью и работу с полным рабочим днём, втиснуть новую привычку, которая может занять до 30 минут, не всегда возможно.


Цвет волны на картине Хокусая отбирается и перерисовывается в виде рисунка брызгами и проецируется в случайные 3D плитки, отсортированные по осветлённости

Ежедневные скетчи не лучший способ изучения нового языка

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


Перисто

Я отдаю предпочтение одной цветовой гамме

Что мне нравилось в работе с цветами в p5, так это цветовое пространство HSB (тон насыщенность яркость). Оно куда более интуитивно понятно, чем RGB (кто-то вообще задумывается о том, сколько красного, зелёного и синего в цвете?) или HEX. Несмотря на доступ к новым методам кодирования цветов, меня постоянно тянуло назад к моим обычным цветовым привычкам. Не то что бы это было плохо, просто вещь, которую я для себя осознал.


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

(И теперь я понимаю, что годами упускал из виду цветовые режимы HSB/HSL в d3.js)

Комплексные системы золотая середина

Несколько дней спустя я нашёл онлайн курс, который называется Generative Art and Computational Creativity from Philippe Pasquier, который до сих пор прохожу. История ИИ искусства куда глубже и шире, чем я мог себе представить, и есть формализованная систематика, что хорошо. Эта диаграмма форм поведения ИИ систем как раз донесла до меня, что я искал и почему мне порой нужно столько времени, чтобы решить, что скетч готов.



Фиксированные системы (fixed) формируют единственный статический вывод; периодические системы (periodic) колеблются между двумя или более состояниями; хаотичные системы (chaotic) не формируют никакого предсказуемого образа (я думаю, не считая вещей, типа странных аттракторов), но комплексные системы (complex) дают нам структуру и стабильность периодических систем и координированную рандомность хаотичных систем.

Неправильное использование тоже стратегия

Порой я застревал на некоторых моментах, пытаясь создать что-то в 3D. И чисто возясь с кодом я создавал, в конце концов, что-то далёкое от того, что я пытался сделать, но достаточно интересное, чтобы назвать это скетчем. Вместо того чтобы передвигать 3D фигуру во времени, я рисовал поверх ещё одну слегка изменённую фигуру, и получалась многослойная фигура.



Ошибки сделаны

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


David Hockney, The Scrabble Game, 1983

Я прорываюсь к координированному разрушению красивой математики

Совершенные формы хороши, но оторваны от жизни. Интрига кроется в изъянах: что пошло не так с этим прекрасным планом действий?

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



Забавно наблюдать за тем, как эти скетчи рисуют сами себя.

Посмотреть всю коллекцию можно на гитхабе.

Если вы хотите попробовать еще что-то или начать с более простых проектов:

• Создание эффекта быстрого полета сквозь космос (или падающего снега) за 10 минут на p5.js
• Как воссоздать эффект муарового узора в библиотеке p5.js для новичка (быстрый гайд)
• Наложение 2d-текстуры на 3d-объект с использованием p5.js (часть 1 создание паттерна)
• Наложение 2d-текстуры на 3d-объект с использованием p5.js (часть 2 наложение паттерна на куб)
• Создание треугольников после 3 часов изучения p5.js

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

Этот пост не о языке и не о фреймворке. Мы будем говорить только о технике.

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

Ведущий принцип: моделируйте свои работы на основе реальности

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

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

Линии

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

1. Выбрать начальную точку
2. Выбрать конечную точку
3. Провести черту между точками

В результате получается что-то такое:



По-моему, слишком идеально!

Случайный наклон

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

Волнообразное колебание

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

Например, это можно сделать так:

1. Выбрать N точек между конечными точками отрезка, чтоб создать новую линию.
2. Сместить каждую точку.
3. Смягчить линию и нарисовать её.

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

Влияние соседних точек

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

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



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

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

Текстурирование линий

Теперь наша линия выглдяит достаточно естественно. Но мы всё ещё рисуем идеально точной ручкой, когда мы вызываем функцию stroke(). В реальном мире, когда мы используем различные инструменты для рисования, у них есть различия в текстуре. Один из способов внести эти различия использовать технику песчаных сплайнов, популяризованную Андерсом Хоффом (a.k.a inconvergent). Идея проста:

1. Совсем чуть-чуть скорректируйте каждую точку линии, используя нормальное распределение.
2. Сгенерируйте ещё несколько точек, между каждой соседней парой точек, и нарисуйте их в виде крошечных точечек.
3. Повторите несколько раз.

Если ваши точки супер маленькие, то получится такая текстура:



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


Сон о пустыне (2018) Текстурированные линии основа многих моих работ.

Формы

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

Мы можем просто нарисовать квадрат.



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



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



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



Ничего из этого не ново. Мы здесь, по сути, говорим только о замкнутых отрезках, поскольку мы просто сглаживаем углы. А что насчёт заполнения пространства? Мы можем использовать функцию fill(), но это немного скучно.



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



* Примечание: можно это сделать, поделив квадрат на 2 треугольника и сгенерировав точку в каждом при помощи равномерного распределения.

Хотя выглядит это немного неаккуратно, поскольку равномерное распределение не настолько интуитивно понятно, как кажется. Для более естественного распределения точек, можем взять значения из одной из моих любимых последовательностей Последовательности Хальтона (2.3)[можно почитать про нее в классной статье].

Последовательность Хальтона (2.3) генерируют точки в промежутке (0, 1) (0, 1) в R2. Чтобы заполнить квадрат точками, сгенерированными в этой последовательности, мы можем:

1. Найти минимальный ограничивающий квадрат, содержащий в себе Прямоугольник.
2. Сгенерировать N точек в (2.3) последовательности Хальтона.
3. Градуировать каждую точку по ширине (или высоте) минимального ограничивающего квадрата.
4. Переместить точку по верхней левой координате квадрата.
5. Отфильтровать все точки, которые не лежат в Квадрате.

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

В общем, (2.3) последовательность Хальтона генерируется просто; прочитайте про псевдокод в википедии (eng). Вот заполнение штрихом на 10000 точек.



Поскольку (2.3) последовательность Хальтона генерируется не рандомно, она создаёт одинаково выглядящие текстуры. Пара способов обойти это:

1. Градуирование и (по желанию) лёгкое раскачивание ограничительного квадрата, чтобы сместить центр последовательности.
2. Отбрасывание N точек с начала последовательности.
3. Рандомное отбрасывание малой части точек из последовательности (но осторожно, это создает больше шума).

Конечно, эти подходы можно совмещать. Экспериментируйте!

Ещё один привычный способ генерации таких текстур использование избыточной выборки сглаживания. Это стохастический процесс, но он ещё и более требователен к ресурсам для вычисления и внедрения. Но он очень хорош. Я использовал этот способ в моей серии Провод, вот одна из работ.


Провод Т


Конечно же, это не единственный подход к текстурированию.

Цвет

Чувствовать, какие цвета сочетаются друг с другом очень, очень сложно. Легко выбрать цвета, которые по твоему мнению хорошо сочетаются, но потом понять, что они совершенно не сочетаются и заставляют твою работу выглядеть в 10 раз хуже, чем в чёрно-белом варианте.

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

Вот мой подход, который я переделал из идеи Джошуа Дэвиса [https://joshuadavis.com/]. Вся суть:

1. В отдельной программе (я, например, использую AutoDesk SketchBook) сконструировать горизонтальную градиентную линию и сохранить в png.
2. Открыть png как пиксели в программе для создания генеративного искусства, и интерполировать между началом и концом градиента, используя функции плавности (функции с диапазоном выхода [0,1])

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

Мы будем использовать вот этот градиент для закрашивания точек в предыдущем примере (только точек в 20 раз больше).



Используемая нами функция плавности линейна по значению y. 0 обозначен на значении y верхней части квадрата, а 1 в нижней. Стоит заметить, что результат функции плавности (между 0 и 1) слегка смещается вместе с нормально распределённым случайным значением. Это помогает сформировать менее однородную структуру.



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

Используем шум с пользой

Раз уж мы говорим о функциях плавности, а что там с шумом? Шум Перлина не совсем соответствует подходит для этой функции, так как его значения варьируются от -1 до 1. Но с умным mapping`ом, ограничением посторонних значений, модульной арифметикой с плавающей запятой и/или другими хитростями, конечно, мы можем сузить диапазон до [0,1].

Вот одна из моих серий Modular, в которой я использовал 2D шум как функцию плавности в цвете.



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

Если взглянуть внимательно, то можно заметить, что штрихованная структура тоже часть шума.



Стоит отметить, что простой шум Перлина может начать казаться безжизненным со временем. Попробуйте поэкспериментировать с фрактальным броуновским движением или разработать свою собственную шумовую функцию, с которой можно будет поиграться. Эссе Flow fields Тайлера Хобба хорошая вещь для углубления в тему (шум Перлина формирует бесконечные векторные поля, текучие поля это полезное обобщение).

Ощутимость

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

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

Например, в картине Слащавая сыворотка на мяч влияет гравитация, который скачет по каждому квадратику в сетке. Направление гравитации определено дополнительным полем шума, и шарик оставляет след.



В основе Пылевой чаши лежит симуляция рвущейся резинки.



Как по мне, эти картины живые. И неудивительно, правда. Они тесно связаны с нашим ведущим принципом:

Моделируйте свои работы на основе реальности

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

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

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

Как известно, в 2015 году мы запустили в эксплуатацию платежную систему Мир, и карты Мир в России принимаются повсеместно. Это, конечно, очень здорово, но сейчас набирает популярность использование мобильных кошельков для оплаты покупок. Согласно статистике, в 2019 году 19% всех операций составляют платежи при помощи смартфона. В 2017 году их было всего 3%. В 2018 году собственное платёжное приложение Mir Pay представила и платежная система Мир. Mir Pay написан на Kotlin, может работать на телефонах с поддержкой NFC и операционной системой Android 6.0 и выше.



Меня зовут Богданов Валерий, я являюсь руководителем группы тестирования в команде мобильных платежей департамента информационных технологий НСПК, и я расскажу о том, как работают мобильные кошельки на примере нашего приложения Mir Pay.

Сначала рассмотрим, как работает оплата с использованием пластиковой карты. В классическом случае карта выдается держателю банком-эмитентом. При этом карта в защищенной области памяти хранит общий с эмитентом ключ MK-AC (Application Cryptogram Master Key). Во время совершения оплаты (при online-операции) карта генерирует на основе MK-AC сессионный ключ SK-AC (Application Cryptogram Session Key) и на нем, с использованием данных карты и данных об операции, полученных с терминала, генерирует криптограмму ARQC (Authorization Request Cryptogram). В основе генерации криптограммы лежит алгоритм 3DES (Triple DES). В общем случае данные по операции поступают от карты к терминалу, далее на хост банка-эквайрера (т.е. обслуживающего торговую точку), затем к платежной системе и на самом последнем этапе к банку-эмитенту (т.е. выдавшему карту) для авторизации.



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

А теперь рассмотрим, чем отличается оплата с помощью мобильного кошелька. Здесь банк-эмитент ничего держателю кошелька не выдает (кроме карты, конечно, но она непосредственного участия в оплате не принимает), вместо этого держатель карты вносит ее данные в кошелек, и она в нем появляется, точнее не она, а специальный токен-профайл, сгенерированный на базе этой карты. Уже сейчас понятно, что организовать оплату, как в классическом случае не получится, так как в телефоне отсутствуют карточные данные и ключ эмитента MK-AC вместо них используется токен-профайл и его специальные ключи. Перед тем как разбираться с оплатой, давайте поймем, что происходит, когда карта добавляется в мобильный кошелек.



Держатель карты вводит данные в приложение (1), которое передает их в зашифрованном виде (об этом чуть позже) через хосты поставщика услуг мобильного кошелька (WSP Wallet Service Provider) в платежную систему. В случае с Mir Pay поставщиком услуг кошелька является НСПК, поэтому данные сразу попадают в платежную систему (2). Далее обработка происходит на платформе мобильных платежей (ПМП). ПМП расшифровывает данные, по номеру карты определяет, каким эмитентом она была выдана, и запрашивает у него подтверждение на возможность добавления карты в кошелек (3). В случае положительного ответа (4) для данной карты происходит процедура генерации токен-профайла (5) и отправка его на телефон (6). Таким образом, вместо карточных данных на мобильном устройстве будет храниться токен-профайл, привязанный к данной карте и данному устройству. Отметим, что преобразование токен-профайла в исходные карточные данные вне платформы мобильных платежей невозможно. После сохранения токен-профайла на устройстве пользователя Mir Pay запрашивает у ПМП (7) пачку одноразовых ключей, которые будут использоваться приложением при совершении покупки в качестве сессионных ключей, аналогичных упомянутым выше SK-AC. Как видно из названия, одноразовый ключ не может быть применен более одного раза, поэтому в процессе использования приложение Mir Pay периодически подгружает из ПМП новые порции ключей. На этом добавление карты в приложение завершается.

Теперь рассмотрим, как изменился процесс оплаты по сравнению с оплатой по пластиковой карте.



Первый этап почти такой же, только вместо данных карты используются данные токен-профайла, а криптограмма ARQC генерируется на одноразовом ключе, полученном от ПМП в качестве сессионного SK-AC. Еще одно отличие Mir Pay от пластиковых карт состоит в том, что при генерации криптограммы вместо 3DES используется более современный симметричный алгоритм блочного шифрования AES (Advanced Encryption Standard).

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

В Mir Pay используется схема с одноразовыми ключами, но существует и другой подход хранение одного ключа на устройстве. Такой подход требует наличия элемента безопасности на устройстве и некоторые кошельки могут его применять с учетом того, что на определенных устройствах такой элемент безопасности присутствует. В нашем случае, учитывая огромное многообразие телефонов с ОС Android это просто не достижимо. Данная специфика и объясняет выбранную схему.

Рассматривая процесс токенизации, описанный выше, можно заметить один тонкий момент: при оплате кошельком используются данные токен-профайла, однако при добавлении карты ее данные отправляются на хосты платежной системы, а эти данные являются строго конфиденциальными. Для защиты карточных данных в Mir Pay предусмотрена многоступенчатая система защиты. При запуске автоматически включается механизм контроля целостности приложения и проверки окружения, не допускающий использование подложного приложения, модифицированного посторонними лицами. В случае обнаружения существенного риска, приложение сообщает об этом пользователю и автоматически удаляет все хранимые токен-профайлы. Дополнительно результаты данных проверок анализируются еще и на стороне ПМП.

Для обмена конфиденциальными данными ПМП и Mir Pay генерируют ключевые пары и обмениваются публичными компонентами. В силу того, что мы не можем на 100% доверять встроенному хранилищу ключей, была разработана схема с хранением разных ключевых компонент в разных местах: как в ключевом хранилище, так и в оперативной памяти. То есть для инициирования мошеннической операции необходимо, во-первых, извлечь криптограммы всех этих ключей, а во-вторых их нужно еще и расшифровать! Но это не так-то просто и не особо эффективно, поскольку для проведения операций используются строго одноразовые ключи. И только после того, как Mir Pay и ПМП обменялись публичными ключами, то есть фактически создали защищенный канал, допускается передача чувствительных данных, которые шифруются крипто-стойкими алгоритмами. По этому механизму на устройство пользователя доставляются и токен-профайл, и одноразовые ключи для проведения операций, и данные по уже совершенным операциям.

Как видно из этого описания, безопасность платежей на базе мобильных кошельков не только сохраняется на уровне пластиковых карт, а в некоторых случаях даже его превосходит! Приложение Mir Pay соответствует международным и отечественным требованиям к безопасности и позволяет держателям карт Мир использовать мобильный телефон для оплаты, не опасаясь утечки личных данных.

На текущий момент разработка Mir Pay продолжается выпустив в сжатые сроки первые версии, мы уже внедряем новые разработки в приложение, не забывая улучшать то, что уже сделано.

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

Друзья, привет!

Я Никита Климов, Platform Owner Oracle FlexCube (FCUBS) для процессинга операций корпоративных депозитов, межбанковских кредитов, валютных операций и деривативов в Росбанке. Сегодня я расскажу, как мы внедряли платформу FCUBS и в чем уникальность этого проекта для российского рынка. Все подробности под катом.

Начну с того, что мы стали первыми в России, кто рискнул адаптировать западную систему к реалиям российского учета в такой сложной продуктовой линейке, как финансовые рынки и рынки капитала. Задача усложнялась тем, что мы внедряли систему не с нуля, а на замену существующей системы, работающей в банке порядка 20 лет. Более того, система была обособленно расположена в периметре банка, а это значит, что нам предстояло разработать интеграцию со всеми внешними и внутренними системами.

Архитектура

Архитектура системы это классическая трехзвенка. В нашем случае backend это Oracle 12c (правда, он на текущий момент уже снят с поддержки, и мы переходим на 19сно это уже совсем другая история) и frontend IBM WebSphere. Искушенный читатель сразу задаст вопрос а почему не использовать нативный для Oracle Weblogic? И, безусловно, будет прав, потому что это первое, что рекомендовал нам сам Oracle. Но, так вышло, что для банка стандартом является именно сервер приложений IBM WebSphere, к тому же у нас ULA на этот продукт, и было принято решение адаптировать слой приложения под особенности WebSphere. Не сказать, что это было очень трудной задачей, однако ряд особенностей организации внутренних очередей все же имелся, и нашей команде пришлось провести немало часов на трехсторонних конф-коллах с поддержками Oracle и IBM.


В то время как мы пытались настроить тестовое окружение и показать проектной команде интерфейс, наши бизнес-аналитики проводили GAP анализ, описывали требования к функциональности и продумывали миграцию данных из старой системы. Не буду фокусироваться на миграции данных, т.к. по сути это процесс заполнения промежуточных, транспортных таблиц внутри FlexCube. Все это действо сводилось к итерационному наполнению и выверке данных до успешного выполнения миграции- ведь главное передать нужное значение в нужное поле таблицы.
Отличительная особенность нашего внедрения заключалась в том, что на замену системы с полным ручным приводом и постоянным пользовательским участием, мы создавали событийную систему на STP процессах, где предусматривалось минимальное вовлечение бизнес-пользователей. Предусмотрены лишь checkpoint для контроля процессинга. Для этого нам пришлось ломать старые бизнес-процессы и выстраивать новые.

Функциональность

Как я уже отметил ранее, система из коробки была совершенно не готова к российским реалиям, начиная с отсутствия плана счетов и заканчивая налоговым учетом. По сути это было просто ядро с набором событийных моделей, из которого надо строить космический корабль. Следовательно, вооружившись функциональными требованиями от бизнеса, мы приступили к разработке своего custom слоя на основе ядра системы. Мы разработали свой Accounting engine для генерации двадцатизначных счетов и приступили к реализации STP процессов. Исключить ручное вмешательство пользователей оказалось нетривиальной задачей, и не решалось лишь с помощью триггеров на уровне СУБД. Пришлось строить событийную логику на JOB и вводить расписание заданий. Этого тоже оказалось недостаточно, и мы вынуждены были использовать Quartz, на основе которого мы и автоматизировали наш workflow. В результате у нас в полностью автоматическом процессе происходит следующее:

• Контракт попадает к нам из фронтовой системы Kondor+, и в зависимости от его суммы он либо автоматически авторизовывается, либо уходит на авторизацию к бизнесу;
• После успешной авторизации система анализирует клиента является ли он клиентом головного офиса, а значит его счета лежат в GL1, либо это клиент регионов, а значит его счета лежат в GL2. Есть еще случай, когда это совершенно новый клиент, и тогда мы должны запросить его в нашей CRMсистеме и на основании полученной информации инициировать ему открытие необходимых счетов в соответствующей GL;
• В результате процессинга система в режиме онлайн запрашивает остатки по счетам и при наличии таковых генерирует и передает в соответствующую GL необходимые проводки, формирует и отправляет SWIFT сообщения и платежки в ЕРЦ;
• Внутри дня в системе происходят стандартные операции погашения, начисления процентов, досрочное закрытие и т.д;
• Различную информацию о движениях по счету, контрагентах и контрактах мы автоматически передаем в ФНС, AML, Nostro. Также не забыли и об Интернет-Клиент Банке, через который клиенты видят, что происходит с их счетами после открытий и погашений депозитов;
• Подготавливаем различную информацию для обязательной и управленческой отчетности и отдаем ее в DWH тут стоить отметить, что мы как делаем классические view для забора информации, так и генерируем транзакционные логи для IBM CDC, который в режиме онлайн забирает и агрегирует эту информацию.

Интеграция

Тут я для наглядности приложу нашу архитектуру и скажу лишь, что в связи с выбором frontend IBM WebSphere, было принято решение отказаться от стандартного для FCUBS Gateway, который разворачивается как дополнительное приложение и работает по старинке с листнерами и очередями, и перейти на работу c MDB Activation Specification. В результате чего мы разработали дополнительные интеграционные приложения, опубликовали их на нашем сервере и подключили к банковской интеграционной шине для взаимодействия с другими системами.
Кроме этого, у нас так же используется интеграция по средствам Systematica Modullar на основе TIBCO Rendezvous, общающийся с нашим фронтом и являющейся входной точкой для всех контрактов и ETL средство IBM DataStage. При этом функциональность на DataStage используется для интеграций, не связанных с DWH. Для одной из GL cпециально разработана логика батчевой загрузки\выгрузки данных, с проверкой статусов и breakpoints для ожидания вычислений.

ИТОГИ

1. Заменили морально и технически устаревшую систему
2. На основе ядра FlexCube создали свою платформу с неограниченными возможностями по параметризации и вариациям учета
3. Минимизировали участие пользователей в процессе обработки дня
4. Оптимизировали время выполнения EOD 15 минут вместо 3 часов ранее.
5. Создали внутри банка центр компетенций и можем поддерживать и развивать платформу независимо от поставщика
6. Практически неограниченно можем изменять usability пользовательского интерфейса и создавать любые проверочные экраны консолидированной информации для удобства контроля
7. Внедрили систему мониторинга контрольных точек для беспрерывного процесса обработки
8. Создали платформу, на которой готовы реализовать любой банковский продукт

TiSpark это подключаемый модуль Apache Spark, который работает с платформой TiDB и отвечает на запросы сложной интерактивной аналитической обработки (OLAP). Этот плагин Spark широко используется для пакетной обработки больших объёмов данных и для получения аналитических инсайтов. Я старший архитектор решений в PingCAP и бывший разработчик TiSpark. В этом посте я объясню, как он работает и почему TiSpark лучше традиционных решений для пакетной обработки.

---

Пакетная обработка: традиции и TiSpark

Давайте сначала посмотрим на традиционную архитектуру пакетной обработки.

Традиционная архитектура пакетной обработки

Традиционная система пакетной обработки сначала получает необработанные данные, которые могут оказаться файлами CSV или данными из TiDB, MySQL и других разнородных баз данных. Затем необработанные данные делятся на небольшие пакеты подзадач. В каждом пакете данные обрабатываются отдельно, а затем фиксируются и записываются в TiDB. Однако у такой системы есть одна фатальная проблема: она не может гарантировать атомарность, согласованность, изолированность и стойкость (ACID) транзакций через базу данных.

Приложение должно представлять сложный механизм таблиц задач, чтобы отслеживать, успешно ли выполняются задачи и подзадачи. Если подзадача не выполнена, система может откатить её всю. В крайнем случае требуется вмешаться руками. И вот результат: этот механизм замедляет всю задачу обработки данных. Иногда задача замедляется настолько, что коммерческие банки не могут принять транзакцию. Так происходит потому, что пакетная обработка в банковском деле должна закончиться в течение дня; иначе она повлияет на открытие следующего дня. Но если говорить о TiSpark, тут происходит нечто иное.

Пакетная обработка с помощью TiSpark

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

После обработки данные конкурентно записываются на сервер TiKV с помощью протокола двухфазной фиксации [коммита, commit], не проходя через сервер TiDB. Подводя итог, можно сказать, что пакетная обработка с помощью TiSpark имеет следующиее преимущества:

• Он очень быстрый. TiSpark обходит TiDB и конкурентно записывает данные в TiKV в режиме многие ко многим. Это даёт горизонтальную масштабируемость. Если узкое место TiKV или Apache Spark, вы можете просто добавить ещё один узел TiKV или Spark, чтобы сделать хранилище больше или увеличить вычислительную мощность.
• Его легко конфигурировать. Единственное, что вы настраиваете, указание Spark о том, как использовать TiSpark. Логика пакетной обработки в TiSpark в основном совместима с DataSource API в Spark, поэтому вы настроите TiSpark без труда, как только разберётесь с DataSource API и DataFrame API.
• Транзакции гарантируются. Запись данных будет успешной или неудачной. Реальный кейс показывает, что TiSpark может записать 60 миллионов строк данных TPC-H LINEITEM за 8 минут.

Что под капотом?

Архитектура

Рисунок ниже показывает роль TiSpark во всём кластере TiDB:

Компоненты кластера TiDB

Компоненты на рисунке маркированы цветами:


Когда TiSpark получает задачу и обрабатывает данные, перед записью данных он блокирует таблицы. Это предотвращает откат TiSpark его собственной транзакции из-за конфликтов с другими транзакциями. Нам не хочется никаких откатов вроде этого, потому что TiSpark обычно обрабатывает сотни миллионов строк данных и это отнимает много времени. Такое поведение блокировки таблицы применимо только к TiDB 3.0.14 и выше. В версии 4.0.x TiDB мы изменили протокол транзакций, и теперь он поддерживает крупные транзакции до 10 GB. Когда TiSpark совместим с модификацией протокола, нет необходимости блокировать таблицы. Далее TiSpark классифицирует, подсчитывает, сэмплирует и рассчитывает данные для записи и оценивает, сколько новых регионов должно генерироваться при пакетной записи. Затем он передаёт информацию в TiDB. TiDB взаимодействует с другими компонентами и предварительно разделяется на нужное количество регионов. Предварительное разделение регионов позволяет избежать таких проблем, как:

• Горячие точки (hot spots).
• Деградация производительности TiSpark при записи, вызванная разбиением региона в то же самое время.

Записывая данные, TiSpark также взаимодействует с PD двумя способами:

• Получает мета-информацию. TiKV хранит пары ключ значение, поэтому перед записью TiSpark преобразует все строки данных в пары ключ значение. TiSpark должен знать, в какой регион записывать пары, то есть ему нужно получить соответствующий адрес региона.
• Запрашивает временную метку от PD для гарантии транзакций. Вы можете рассматривать эту временную метку как идентификатор транзакции. Чтобы конкурентно записывать сгенерированные пары в TiKV, TiSpark использует Spark Worker.

Реализация

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

Во-первых, чтобы реализовать клиент TiKV в TiSpark, мы воспользовались Java. Этот клиент богат функциональностью и может отдельно использоваться Java-приложениями, чтобы взаимодействовать с TiKV.

• Клиент реализует интерфейс сопроцессора. Он может взаимодействовать с TiKV или TiFlash и выполнять некоторые вычисления, такие как вычисления лимита, порядка и агрегации. Клиент также обрабатывает некоторые предикаты, индексы и поля ключ значение. Например, он может оптимизировать запрос с индексом, чтобы не сканировалась вся таблица.
• Клиент реализует протокол двухфазной фиксации, гарантируя, что записи TiSpark соответствуют ACID. Клиент также поддерживает некоторую статистику и информацию об индексах, которые, когда создаётся план выполнения, помогают Spark выбрать лучший путь, чтобы выполнить запрос.

Клиент TiKV позволяет TiSpark взаимодействовать с TiKV и TiFlash. Другая ключевая проблема как сообщить Spark результат этого взаимодействия.

TiSpark использует Extensions Point в Spark как входную точку, что снижает стоимость поддержки полного набора кода Spark и позволяет настраивать оптимизатор Spark Catalyst. Например, в план выполнения Spark можно легко внедрить логику доступа к TiKV или TiFlash.

TiSpark гарантирует транзакциям ACID-свойства как для записи одной и нескольких таблиц. Для записи в одну таблицу TiSpark полностью совместим с Spark DataSource API, потому что фрейм данных Spark подобен одной таблице. Для записи нескольких таблиц вы можете использовать дополнительный интерфейс, поддерживаемый TiSpark, для сопоставления таблиц базы данных со Spark DataFrame. Например, вы можете сопоставить таблицу с фреймом данных через имя базы данных и имя таблицы, а затем поместить эту информацию в сопоставление. Предположим, вам нужно записать три таблицы, тогда в сопоставлении должно быть три элемента.

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

Если вы знакомы со Spark, вы можете задаться вопросом: DataFrames в Spark похожи на одну таблицу. Не сложно ли будет объединить их из-за несовместимой структуры таблиц? Что ж, не волнуйтесь. Формат данных TiKV это пары ключ значение. Во время записи нескольких таблиц они объединяются только после преобразования DataFrames в пары ключ значение.

Приложение

Как TiSpark сочетается с вашей существующей системой распределённых приложений?
Предположим, у вас есть распределённая система, состоящая из трёх частей:

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

Вы можете интегрировать TiSpark во фреймворк пакетного приложения, чтобы планировать и обрабатывать пакетные задачи.

TiSpark обрабатывает данные через интерфейсы DataFrame или Spark SQL.

Допустим, есть таблица пользователей, в которой хранятся кредиты и процентные ставки пользователей. На основе этих данных нам необходимо рассчитать проценты, которые пользователи должны заплатить в текущем месяце. В следующем блоке кода показано, как реализовать логику пакетной обработки с использованием интерфейсов DataFrame и Spark SQL отдельно:

// DataFrame API implementationval dfWithDeducted = df.withColumn("toBeDeducted",                    df("loan") * df("interestRate"))val finalDF = dfWithDeducted                    .withColumn("balance",                        dfWithDeducted("balance")                        - dfWithDeducted("toBeDeducted"))                    .drop("toBeDeducted")// Spark SQL implementationval df = spark.sql("select *, (balance - load * interestRate) as newBala from a").drop("balance")val finalDF = df.withColumnRenamed("newBala", "balance")

1. Найти столбцы ссуды и процентной ставки с помощью интерфейса DataFrame.
2. Воспользоваться простой арифметической операцией, чтобы вычислить проценты.
3. Создать новый столбец с именем toBeDeducted при помощи интерфейса withColumn.
4. Вычесть значение toBeDeducted из исходного баланса и получить новый баланс.
5. Удалить столбец toBeDeducted.

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

• Таблица бонусных баллов: хранит текущие баллы пользователя.
• Таблица расходов: хранит ежемесячные расходы пользователя.
• Таблица правил: хранит правила скидок. У разных продавцов правила скидок различаются. Скидка в ювелирных магазинов 1:2; то есть 1 доллар это 2 балла.

Чтобы создать новый DataFrame, мы можем объединить три таблицы в Spark. Затем мы выполняем некоторые арифметические вычисления с использованием соответствующих имён столбцов DataFrame, например, умножая объем потребления на коэффициент в таблице правил. После этого выполняем пакетную задачу.

Когда выполнение завершено, мы можем обработать DataFrame в соответствии с различными структурами таблиц. Наконец, TiSpark быстро записывает обработанные данные в TiKV, а TiDB не участвует в записи.

Визуализация

Отправляя задачу в TiSpark, вы можете следить за её выполнением. Рисунок ниже показывает пакетную обработку, которая записывает 4 миллиона строк данных:

Мониторинг задач в TiSpark

На странице монитора можно посмотреть, какая обрабатывается задача и что она должна быть выполнена примерно за 5 минут. В таблице приводятся сводные данные по каждому идентификатору задания и задаче:



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

---

• Курс по Data Engineering
• Профессия Data Scientist
• Профессия Data Analyst