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

Меня зовут Станислав Свириденко и я DWH-разработчик AXENIX. В этой статье хочу рассказать об опыте миграции витрины данных с проприетарной СУБД Teradata на свободную СУБД GreenPlum. Поговорим о задачах, подводных камнях, на которые мы периодически натыкались, и способах решений, найденных  в процессе.

Всё, что сложно или невозможно объяснить, называют магией. Ещё в 1997 году суперкомпьютер Deep Blue обыграл чемпиона мира по шахматам. Шок, недоверие и теории заговора. В 2016 году другой суперкомпьютер AlphaGo обыграл топового игрока в самую сложную в мире игру Го. Восстание машин и разнообразные фобии. Сейчас нейросети уже снимают кино, пишут песни и сценарии, делают научные открытия и ловят мошенников. И уже мало кому кажется шуткой то, что скоро они заменят программистов. Но, несмотря на все достижения и перспективы — эти технологии всё ещё кажутся магией. А люди, которые в этом понимают — магами. Но магам, как и всем остальным, нужно делиться заклинаниями, новыми свитками и рецептами зелий. Поэтому в этом году откроется первая школа волшебства Прикладная техническая конференция по Data Science AiConf 2024.

Общение незаменимо даже в кругу магов. Кто, если ни другой маг, лучше всего расскажет про новых жучков-древоточцев, которые пожирают даже самые новые свитки. Или про то, каким маслом смазывать волшебный котёл перед тем, как варить зелье. Про CV, NLP, Automotive, AutoML, Predictive analytics, Reinforcement Learning, Artificial General Intelligence и другие заклинания. Это ли не лучший повод передать свой бесценный магический потенциал и опыт?

Готовьте мётлы и телепорты! Встречаемся 26 и 27 сентября 2024 года в Москве на Красном Октябре.

Все вы знаете, зачем посещать конференции. По крайней мере, на всех рекламных баннерах и других рекламных материалах пишут что-то похожее. Это обновление знаний, обмен опытом, soft skills, новые контакты и «тусовка». На самом деле это не всё, что даёт нам посещение профессиональной конференции. Давайте посмотрим, что ещё вы можете получить на примере DevOpsConf 2024:

Изучение реальных кейсов

Получение обратной связи

Поиск вдохновения и мотивации

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

Мы очень любим Kubernetes и мечтаем чтобы все современные технологии поскорее начали использовать его замечательные паттерны.

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

Да, вы могли бы возразить что Kubernetes для этого не предназначен и почему бы не использовать OpenStack для Bare Metal-серверов а внутри него запускать Kubernetes как положено. Но поступив так, вы просто переложите ответственность с ваших рук на руки OpenStack администраторов. Что добавит как-минимум ещё одну сложную и неповоротливую систему в вашу экосистему.

Зачем так всё усложнять? - ведь на данный момент Kubernetes уже имеет всё необходимое для запуска Kubernetes кластеров.

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

В данной статье мы рассмотрим процесс интеграции Keycloak в наше приложение Spring Boot 3 в качестве сервера авторизации с использованием протокола OAuth2. Обсудим смысл OAuth2, его механизм работы и сравним его с другими протоколами. Кроме того, мы настроим Keycloak с использованием Docker Compose, воспользовавшись PostgreSQL в качестве базы данных для Keycloak. Затем мы интегрируем Keycloak с нашим приложением Spring Boot 3, используя протокол OAuth2. Также мы подключим Keycloak Admin Client и, наконец, проверим функциональность всей системы.

Привет, Habr!

Меня зовут Остапенко Настя, я лидирую направление BI в компании Axenix. Год назад мы выпустили статью с большим обзором Российского рынка BI. На этот раз мы проведем сравнение трех популярных Open-Source BI-платформ: Apache Superset, Metabase и относительно нового участника - Yandex Datalens, который совсем недавно стал доступен в качестве Open-Source продукта.

API-First — один из популярных подходов к проектированию серверных приложений. Для обеспечения этого подхода создано множество программных продуктов. Однако сложно найти продукт, который поможет реализовать этот подход для серверных приложений, использующих брокеры сообщений в качестве средства интеграции —  такие, как Apache Kafka, RabbitMQ, Apache ActiveMQ. Мы решили это исправить и представляем вам свое решение AxenAPI.

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

Всем привет. Меня зовут Добрый Кот Telegram.

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

Вошли и вышли, приключение на 20 минут)

От коллектива FR-Solutions и при поддержке @irbgeo Telegram : Продолжаем серию статей о K8S.

Этот материал для тех, кто хочет эффективно погружаться в проекты большого масштаба и следить за состоянием их здоровья. В статье расскажу, как максимально быстро разобраться в стандарте OMG Essence и начать применять его в работе.

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

Привет. Меня зовут Григорий Рочев. Хотел бы поделиться сравнением Prometheus like агентами для сбора метрик (нигде я такого определения не встречал, но почему бы их так не назвать?). Рассматривать буду prometheus в режиме agent mode, grafana agent, VictoriaMetrics agent (далее vmagent) и немножко пройдусь по netdata agent.

Добрался тут изучить ряд статей на тему Data Fabric, последнее время довольно много публикуется материала на эту тему: как про Data Fabric в целом, так и сравнения этого подхода с такими модными понятиями как Data Lake и Data Mesh. Собственно говоря, целью этого материла является кристаллизация основной составляющей концепции DF, в которой хочется оставить только саму суть.

Итак, что такое Data Fabric?

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

Ну или чуть более длинно: “A data fabric is a modern, distributed data architecture that includes shared data assets and optimized data management and integration processes that you can use to address today’s data challenges in a unified way.” - тут и переводить не надо и таĸ все ĸрасиво написано :)

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

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

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

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

Многие методологии требуют сначала описать требования к системе как черному ящику и лишь затем переходить к проектированию и построению моделей. Способам такого описания посвящена инженерия требований. Однако, это присуще и Agile-методам, ведь User Story тоже описывает систему как черный ящик. Целью такого подхода была гарантия, что разработанная система будет пригодна для использования, внедрение пройдет гладко. Проблема в том, что так — не работает. А значит, нет смысла чересчур углубляться в требования, а стоит быстро переходить к моделям системы, которые можно строить по-разному.

Первый сервис в Nomad я запустил в сентябре 2016 года. На данный момент пользуюсь как программист и занимаюсь поддержкой как администратор двух Nomad кластеров — один "домашний" для своих личных проектов (6 микро-виртуалок в Hetzner Cloud и ArubaCloud в 5 разных датацентрах Европы) и второй рабочий (порядка 40 приватных виртуальных и физических серверов в двух датацентрах).

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

Ямальский кочевник делает Continous Delivery инстанса вашего ПО © National Geographic Россия

Введение

В этой статье хочу рассмотреть возможности Asciidoc в части обеспечения требований соответствия документов требованиям единой системы конструкторской документации (ЕСКД), конкретно ГОСТ Р 2.105—9 (далее ГОСТ ЕСКД). Почему именно Asciidoc, я писал здесь.

Сразу уточню. Вопрос форматирования документа здесь не рассматривается. Создающий документацию не должен задумываться о форматировании. Как системный аналитик я создаю содержание и контролирую его структуру. Для получения документа, соответствующего ГОСТ ЕСКД или другому аналогичному стандарту, я должен нажать кнопку и получить корректно отформатированный документ в любых требуемых вариантах: pdf, Open Document (Libre
Office/Open Office), Open XML (Microsoft Word) и прочих.

После работы над https://github.com/CourseOrchestra/asciidoctor-open-document уверен,
что все проблемы форматирования решаются адекватными усилиями.

Рассмотрим структуру документа Asciidoc, соответствующего требованиям
ГОСТ ЕСКД.