Привет, Хабр! Меня зовут Михаил Сичалов, я руководитель проектов и эксперт практики Applied Intelligence в компании Axenix.

Это вводная статья из цикла работ, посвящённых реальным сценариям использования Apache Spark и сопутствующим техническим нюансам, с которыми я столкнулся за последнее десятилетие работы над проектами в области Data Engineering. Я решил систематизировать и переосмыслить свой опыт работы с этим фреймворком и поделиться с сообществом интересными и нестандартными аспектами, освоенными на практике.

Несмотря на выразительность модуля Spark SQL с точки зрения описания преобразований над данными, зачастую возникает необходимость в создании пользовательских функций (UDF). Для этого в Apache Spark есть целое подмножество API, с помощью которого можно реализовать пользовательскую функцию произвольной сложности. Но что делать в случае, когда код функции становится доступным только в рантайме, а Spark используется в связке с Java API?

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

Привет, Хабр! Меня зовут Максим Вишняков, я ведущий разработчик в Axenix. За время работы я накопил обширные знания в части оптимизации, развития и поддержки  различных решений на платформе 1С:Предприятие. В этой статье хотел бы рассказать об опыте оптимизации работы ERP-системы для лидера алкогольного рынка, который отгружает продукцию в режиме 24/7 и осуществляет огромный объем операций.

Привет, Хабр! Меня зовут Максим Вишняков, я ведущий разработчик в Axenix. За время работы я накопил обширные знания в части оптимизации, развития и поддержки различных решений на платформе 1С:Предприятие. В этой статье хотел бы рассказать об опыте оптимизации работы ERP-системы для лидера алкогольного рынка, который отгружает продукцию в режиме 24/7 и осуществляет огромный объем операций.

Привет, Хабр!

В последние годы все чаще в разговорах про современные дата-платформы звучит термин «семантический слой». Сама идея семантического слоя не нова: в разные годы под семантикой понимали и витрины данных, и презентационный слой хранилища, и пространства метрик внутри BI-платформ. Но развитие современных дата-платформ и появление AI-агентов заставляют заново переосмыслить этот концепт.

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

Семантический слой представляет собой промежуточный логический слой между областью физического хранения данных и каналами потребления данных: аналитическими приложениями, BI-системами, AI-агентами и бизнес-пользователями. В разных источниках его также называют Metrics Layer или Headless BI.

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

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

Всем привет! Меня зовут Владимир Зуев, я руководитель разработки JAVA-практики в компании Axenix. Сегодня я хочу представить новую часть из цикла статей о нотации ArchiMate. В этой части мы продолжим проектирование системы управления беспилотным грузовым автотранспортом для междугородних перевозок. Мы попытаемся получить ответ на главный вопрос – что же мы хотим получить? Для этого подробно разберем требования к системе, составим перечень прецедентов использования, а также сформируем техническое задание. Для решения всех задач будем использовать ИИ.

Привет, Хабр! Меня зовут Игорь Кайбанов, я эксперт СЭД/BPMS компании Axenix.

Cегодня я хочу поделиться практическим опытом реализации проекта для одного из наших заказчиков. Представьте ситуацию: в компании работают сотрудники из разных стран, а документы перемещаются между юрлицами и часовыми поясами, коммуникации могут деградировать, и в какой-то момент управляемость теряется. В таких условиях СЭД становится точкой консолидации процессов — слоем, где сходятся организационная структура, бизнес-логика и контроль.

Контекст: распределенная в нескольких странах компания с «несовпадающей» оргструктурой, с несколькими юридическими лицами и с разными бизнес-процессами

Заказчик — крупная производственная группа с десятками заводов и офисов в нескольких странах. В России у этой компании распределенная структура с более чем 1500 сотрудников в различных часовых поясах и сотни пользователей систем электронного документооборота (СЭД). В организационной модели компании одновременно существует несколько типов подчиненности: организационная (линейная), дисциплинарная и функциональная (по процессам и центрам ответственности). Это означает, что классическая «вертикаль согласования» не работает. Любой бизнес-процесс должен учитывать сразу несколько измерений оргструктуры.

В проекте стояла не просто задача автоматизации документооборота. Требовалось собрать в единый контур разные страны с собственными регуляторными особенностями, юридические лица с разными зонами ответственности, бизнес-функции, распределенные по нескольким центрам учета. Отдельно стоит упомянуть пользователей с локализованными данными (включая имена на разных языках), а также сотрудников, работающих в ERP, но не использующих СЭД напрямую.

Всем привет! Меня зовут Владимир Зуев, я руководитель разработки JAVA-практики в компании Axenix. Сегодня я хочу рассказать о нотации ArchiMate, используемой для разработки и моделирования информационных систем. Несмотря на свои уникальные возможности, нотация ArchiMate не получила широкого распространения. Даже среди практикующих архитекторов распространенность нотации не превышает 25%. Отчасти это связано со скудным описанием в официальной документации и отсутствием практических руководств. Я хочу исправить эту ужасную несправедливость и показать сильные стороны ArchiMate, подробно разобрав ее использование на практическом примере, а так же показать как применение ИИ может помочь архитектору.

Всем привет! Меня зовут Евгений Оселедец, я ведущий разработчик в компании Axenix. В этой статье расскажу, как мы упаковали React и Java в единое автономное desktop-приложение с помощью Electron для Windows, Linux и macOS — без Docker, без предустановленной Java у пользователя и без необходимости интернет-соединения. Расскажу, с какими техническими вызовами мы столкнулись и какие решения сработали на практике.

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

В статье разберем подход Documentation as Code, почему OpenAPI давно показал его ценность и как развитие ИИ делает структурированную документацию практически обязательной.

Анализируем структуру файлового формата parquet и читаем метаданные через thrift и python: индексы, страницы и их типы, кодировки (encodings). Статья является хорошим дополнением и иллюстрацией к документации формата parquet. С помощью кода из репозитория любой желающий сможет самостоятельно проанализировать метаданные файла в формате parquet на самом низком уровне.

460 тысяч рублей за ошибку: как пропуск бизнес-анализа увеличивает стоимость сбоя в 8 раз.

Введение

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

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

Стоя на деревянных перекрытиях, которые должны были быть гранитной брусчаткой, задаете себе вопрос «Зачем я вообще в это ввязался? Для чего был нужен мост?..   Точно, два раза в год отправлять 15 кг груза!»

И начинаете подозревать, что проблема изначально решалась не мостом.

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

Эволюция профессии

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

CEO Shopify Тоби Лютке недавно предложил термин context engineer на замену понятия prompt engineer — и это оправдано. От постановки задачи и способов ее исполнения мы перешли к необходимости ограничивать и задавать контекст решения. В этом помогают как экспертные промты и ИИ-агенты, так подключение к системе специализированного массива данных.

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

Ключевой задачей аналитика становится гибридная экспертиза, то есть синтез ИТ-знаний плюс понимание возможностей/рисков ИИ (особенно в security-sensitive отраслях). На этом уровне аналитик становится «проводником» между данными и стратегией, где ГенИИ — не замена, а мультипликатор эффективности.

Представьте: ваш Python-код работает на 30% быстрее благодаря JIT-компиляции, обработка запросов масштабируется на все ядра процессора без ограничений GIL, а отладка высоконагруженных систем происходит в реальном времени, без остановки продакшена. Это не футуристический сценарий “what-if” — это реальность Python 3.14, релиза, который переосмысливает саму природу разработки с высокой производительностью на Python.

Всем привет! Меня зовут Антон Лосев, и я QA Lead в компании AXENIX.

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

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

В данной статье я продемонстрирую подход к анализу и вычислению рекуррентных соотношений. В качестве примера будет представлена реализация на базе Apache Spark и Python метода экспоненциальной скользящей средней с использованием DataFrame API. Мы рассмотрим метод агрегации данных, совместимый со Spark Connect, который был добавлен в версию 3.1 (для Scala - начиная с версии фреймворка 3.0), а именно – функцию aggregate.

Миллиарды строк кода, сотни интеграций и бесчисленные микросервисы — таков современный ИТ-ландшафт крупнейших компаний страны. В периоды пиковых нагрузок даже минута простоя может обойтись бизнесу в десятки и сотни миллионов рублей и обернуться подрывом доверия клиентов. В этом свете тестирование ПО превращается из формального контрольного этапа в гарантию непрерывности работы сервисов. Вместе с новой ролью возникает и потребность в специальных метриках, способных объективно измерять качество продукта по множеству критериев.

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

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

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

Мы все чаще сталкиваемся с парадоксом: с одной стороны, растут требования к скорости вывода продукта на рынок, с другой — увеличивается сложность приложений. При этом, разработчики тратят большое количество времени на рутинные задачи, такие как интеграция с API и написание boilerplate-кода. Именно здесь на помощь приходит автоматизация рутинных задач во фронтенде на основе OpenAPI-спецификаций и она может очень сильно упростить нам, фронтендерам, жизнь!

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

Технологии ИИ способны улучшить взаимодействие пользователя с MDM-системой, а также повысить эффективность его труда. При этом не стоит забывать о том, что сами по себе практики управления данными, а в частности — мастер-данными, в свою очередь создают фундамент для корректной работы алгоритмов искусственного интеллекта. Достоверность результатов ИИ определяется тем, насколько качественные данные используются как при обучении моделей, так и в процессе их эксплуатации. Тут как никогда кстати можно вспомнить русскую пословицу: «Что посеешь, то и пожнешь».

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

Рассмотрим процесс проектирования на конкретном примере выполнив серию промптов,а так же проверим как GenAi умеет рисовать диаграммы в форматах UML и Mermaid.

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