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

В данной статье будет описана структура PostgreSQL-базы данных и реализация данной задачи с помощью SQL в варианте PL/pgSQL. Реализация на Apache Spark будет описана в следующей статье.

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

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

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

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

Я решил это проверить.

В данной статье будет описана задача и выбранные технологии.

Во второй части будет описана база данных для хранения правил и результатов.

В третьей части будет создано решение на базе Apache Spark и его функций по работе с графами.

Бонусом получится сравнить скорость выборки результирующих данных из Postgres с помощью рекурсивных запросов и запросов к Apache Spark с помощью GraphFrame.

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

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

Будет использоваться машинное обучение в Apache Spark.

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

Один из получаемых типов будет вызывать увеличение загрузки процессора.

Необходимо найти, какой тип файлов вызывает загрузку процессора, применив машинное обучение.

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

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

Для реализации выбран абстрактный бизнес-процесс запроса абстрактных ресурсов. Пример придуман максимально общим. Необходимо реализовать обработку бизнес-процесса с несколькими стадиями.

Это часть 2. Первую часть смотреть по ссылке.

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

Описание создаваемого ТЕСТОВОГО / ТРЕНИРОВОЧНОГО приложения и базовые сокращения можно найти в начале первой части.

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

Что такое аутентификация и ее отличие от авторизации можно уточнить по этой ссылке.

«Talk is cheap. Show me the code.»

Недавно мне в руки попала книга «Искусство неизменяемой архитектуры: теория и практика управления данными в распределенных системах». В ней описаны довольно радикальные, но логичные подходы к проектированию: полный отказ от UPDATE и DELETE в пользу INSERT, идентификация сущностей через хеш-суммы и построение распределенных систем без боли.

Чтобы не быть голословным и проверить, работают ли эти концепции в реальном коде, а не только в теории, я написал небольшой тестовый проект. Это не продакшен-решение, а скорее полигон для проверки идей.

В этой статье разберем, как выглядит REST-сервис на Kotlin + Spring Boot, живущий по законам неизменяемости, и к каким результатам это привело.