Если вы пишете SQL-запросы, то наверняка сталкивались с ситуацией, когда данные исчезают, отчеты не сходятся, а бизнес теряет деньги. И виновник этого — маленькое, но очень коварное слово NULL. В 1974 году Эдгар Кодд, создатель реляционной модели данных, ввел это понятие, чтобы обозначить отсутствие информации. Он хотел, как лучше, но спустя пятьдесят лет NULL продолжает «терроризировать» разработчиков по всему миру. Важно усвоить раз и навсегда: NULL — это не значение. Это состояние неизвестности.

Поэтому:

·       NULL ≠ 0 (ноль - это число);

·       NULL ≠ '' (пустая строка - это строка);

·       NULL ≠ ' ' (пробел - это символ).

Но всегда есть нюансы и исключения. Например, в Oracle INSERT INTO table (col) VALUES ('') запишет NULL. Это поведение отличается от других СУБД и часто становится сюрпризом при миграции.

Мы выпустили NEOMSA APIM 4.6.0. Основной фокус этого релиза — повышение безопасности состава поставки платформы.

В рамках процессов безопасной разработки (SSDLC) мы сформировали SBOM, проверили компоненты и их зависимости на известные уязвимости (SCA), сопоставили результаты с БДУ ФСТЭК России и обновили проблемные библиотеки. По итогам повторной проверки количество зарегистрированных находок сократилось с 57 до 7. Уязвимостей уровней Critical и High в финальной сборке не осталось.

В статье рассказываем, как устроена проверка NEOMSA APIM перед выпуском и какой критерий безопасности мы используем для принятия решения о готовности релиза.

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

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

Аналитика DWH всегда казалась мне чем‑то интересным, но недосягаемым. Я видела её со стороны — через вакансии, которые закрывала, через людей, которых нанимала. И в какой‑то момент пришло понимание: хочу не просто искать таких специалистов, а стать одной из них.

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

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

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

К июню 2026 года в России доступно несколько зрелых отечественных решений. В этом обзоре разберём три, по которым чаще всего идёт сравнение: NEOMSA APIM от компании Neoflex, Platform V Synapse API Mesh от СберТех и MWS Octapi от МТС Web Services. Все три входят в реестр российского ПО, но задачу управления API закрывают по разному, и понимание этих различий важнее, чем сравнение отдельных функций.

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

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

1. Введение. Trino: ключевые задачи и главные преимущества

В современной архитектуре управления данными ETL‑процессы рассматриваются не как вспомогательный инструмент, а как базовый механизм интеграции, трансформации и подготовки данных, поступающих из множества гетерогенных источников. Ключевая цель этих процессов — избавиться от хаоса и разрозненности данных, которые почти всегда появляются в больших распределенных компаниях [1].

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

ETL возник как вынужденная мера, так как во время его появления (1970–1990-е) не было ни высокоскоростных сетей, ни мощных распределенных движков аналитики, ни концепции Data Lake. Единственным надёжным способом построить аналитическую отчетность было физически извлекать данные из операционных систем и копировать их в отдельную специализированную базу. Именно поэтому ETL закрепился как основной архитектурный паттерн аналитических систем на долгие десятилетия.

Увы, такой подход породил и массу проблем: это дублирование данных, долгие пайплайны, сложные зависимости, задержки обновления и огромные затраты на поддержку. Традиционным ETL‑процессам становится всё труднее справляться с постоянно растущим объемом поступающих данных. Более того, большие сложности возникают при работе с уже накопленной информацией, ведь её требуется хранить на протяжении многих лет, а значит — сохранять возможность глубокого анализа по всей доступной истории.

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

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

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

Работу аналитика хранилищ данных можно разделить на две части:

1. Организация интеграции данных от какого‑либо источника к какому‑либо приемнику;

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

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

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

В статье речь пойдет об ETL-процессе, когда с источника данных «протянут» информационный поток со своей логикой преобразований, который «кладет» некорректные данные в приемник.

Привет, сообществу Habr!

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

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

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

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

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

«Широкие» таблицы

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

Однако у этой простоты обнаружилась обратная сторона — избыточность. Представьте, что данные о сотрудниках и их работодателях хранятся в одной таблице. Если компания меняет название, то необходимо обновлять каждую запись, которая связана с изменяемой информацией. Это не только расточительно с точки зрения хранения, но и чревато аномалиями в данных. Также при увеличении количества данных в «широких плоских» таблицах возрастает и риск нарушения консистентности информации.

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

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

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

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

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

 На данный момент банки предоставляют в Банк России порядка 100 различных форм отчетов. В связи с таким разнообразием отчетных форм возникает вопрос эффективной автоматизации процессов формирования обязательной банковской отчетности. Недостаточность автоматизации данных процессов создаёт дополнительные сложности, увеличивает трудозатраты и снижает качество предоставляемых отчетов.

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

Избыточность ручного труда: формирование части форм отчетности требует ручной обработки больших объемов данных, агрегации выгрузок из различных АБС в один отчет

Автор: Кристина Паревская, Neoflex

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

Погружаемся в тему пожаров и возгораний

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

Такие компании, как Johnson Controls, Honeywell International, Inc., GENTEX CORPORATION, Siemens, Robert Bosch GmbH, Halmaplc, Eaton, Raytheon Technologies Corporation уделяют свое внимание исследованиям в области распознавания возгораний объектов и предлагают свои решения по устранению пожаров. Этими компаниями движут желание помочь людям, быстрое развитие беспроводных технологий и развитие строительной отрасли, охватившей весь мир.

1. Тревожный звонок

Был хмурый лондонский вечер, когда в нашу скромную квартиру на Бейкер-стрит ворвался взволнованный инспектор Лестрейд.

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

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

Определим несколько видов тестирования:

1.     Технические тесты

Техническими тестами легко можно проверить корректность сборки витрины. Из основных видов технических тестов можно выделить:

·       Дубли - проверка на наличие дублей по ключу

·       Разрывы - проверка на разрывы в истории

·       Перекосы - проверка наложения исторических записей друг на друга

·       Даты - проверка корректности формирования дат

·       NULL в ключе - проверка NULL в ключевых и обязательных к заполнению полях

Подробно на этих тестах останавливаться не будем, информация по ним есть в открытом доступе.

2.     Бизнес-тесты

Это набор тестовых запросов, направленных на выявление ошибок в бизнес-данных. Как правило набор бизнес-тестов предоставляет владелец объекта.

Бизнес-тестов может быть великое множество, здесь все зависит от вашего бизнес-домена и от конкретных требований к витрине.

Приведу примеры некоторых бизнес-тестов:

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

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

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

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

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

Небольшое интро, в котором многие себя узнают

Как часто, листая продуктовый каталог в интернет-магазине одежды, вы не находили товар нужного вам оттенка?

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

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

И вопрос работы с оттенками является важным не только при подборе гардероба.

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

Цифровой дизайн работает с логотипами, баннерами, интерфейсами, в которых также важна колористика;

Индустрия красоты: подбор оттенков косметики, которые будут гармонировать с кожей и одеждой клиента;

Искусство: анализ цветовой палитры произведений искусства, реставрация картин, создание новых произведений с учетом цветовых гармоний;

Реклама: создание ярких и запоминающихся  материалов с учетом психологии восприятия цвета;

Автомобили и мотоциклы: поиск краски для маскировки царапин или полной перекраски, чтобы цвет точно соответствовал оригиналу; выбор аксессуаров  — диски, накладки, коврики и чехлы, которые соответствуют цвету транспортного средства.

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

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

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

Neoflex — компания‑интегратор (некоторые «хаброэксперты» с оттенком пренебрежения называют такие компании «галерами»), которая решает конкретные проблемы заказчиков, занимается прикладной разработкой «под ключ». У нас в работе находится одновременно много проектов на разном стеке и постоянно появляются новые, так что сотрудники обычно не скучают, разгребая годами тонны легаси или разрабатывая очередное широко известное в узких кругах мобильное приложение.

Эта статья, надеюсь, будет интересна тем, кто работает на проектах, но не знает, с чего всё начинается и что предшествует старту проекта. А может быть, вы грустите над своими задачами и хотите присоединиться к команде с более прогрессивными идеями? :)

Чтобы проект успешно завершить, нужно его начать :‑). А чтобы начать, нужно его продать. Я вхожу в пресейл‑команду внутри центра компетенций Big Data Solutions в качестве технического консультанта (архитектор, разработчик, иногда и системный аналитик) и уже накопил интересный опыт наших «болей» на этом пути пред‑продаж и даже разработал с коллегами общий алгоритм действий для подобных команд.

С чего вообще начинается наша работа? Сейлз‑менеджеры общаются с действующему и потенциальными заказчиками, если находят что‑то по профилю нашего центра компетенций (построение/миграция DataLake/хранилищ или витрин данных и/или BI‑отчётности), приходят к нам с более или менее (чаще «менее», чем «более») чётко сформированными требованиями. Центр кометенций назначает одного ответственного за пресейл (пресейл‑консультанта), тот запрашивает себе в помощь экспертов от DevOps, аналитики, разработки и тестирования (как правило, пресейл‑консультант сам является экспертом в одной из этих областей), возможно, кого‑то ещё. Желательно, чтобы эксперты обладали большим проектным опытом и могли посвятить пресейлу несколько следующих дней: сроки на подготовку ответного предложения, как правило, очень сжатые.

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

В данной статье рассмотрены некоторые особенности использования языка SQL в реляционных СУБД и Apache Hive. Кроме того, проведен сравнительный обзор возможностей и подходов, а также применение партиционирования на практике.

Материал будет полезен специалистам младших и средних грейдов, которые используют в своей практике SQL, но имеют мало опыта в Hive или Postgres.