Как стать автором
Обновить
12
0
Павел @Hubbitus

Архитектор ИТ

Отправить сообщение

Паттерн: Сага

Время на прочтение2 мин
Количество просмотров152K

Привет, Хабр! Представляю вашему вниманию перевод статьи "Pattern: Saga" автора Chris Richardson.


Ситуация


Есть приложение, к которому применялся паттерн Database per Service. Теперь у каждого сервиса приложения есть своя собственная база данных. Некоторые бизнес транзакции охватывают сразу несколько сервисов, так что нужен механизм, обеспечивающий согласованность данных между этими сервисами.


Например: давайте представим, что мы разрабатываем интернет магазин, где у клиента есть кредитный лимит. Приложение должно гарантировать, что новый заказ не превышает кредитный лимит клиента. Так как Заказы и Клиенты — различные базы данных, то приложение не может использовать локальные ACID транзакции.


Проблема


Как обеспечить согласованность данных между сервисами?


Решение


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


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


Читать дальше →
Всего голосов 11: ↑10 и ↓1+9
Комментарии10

Архитектура кеша DragonflyDB

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров4.3K

DragonflyDB - молодая in-memory база данных, написанная на C++ и совместимая с Redis (не форк). Под капотом используется многопоточная архитектура (в отличии от однопоточного Redis) для лучшей утилизации современных процессоров и более простого вертикального масштабирования.

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

Читать далее
Всего голосов 6: ↑6 и ↓0+6
Комментарии17

Краш, крипота или кринж? Тестирую 7 антисанкционных офисных пакетов — альтернатив Microsoft Office

Время на прочтение18 мин
Количество просмотров56K

Miss me? Из моих статей вы узнали о клонах иностранного софта в реестре отечественного ПО. Те публикации вызвали жаркую дискуссию о лицензиях, перетекшую из теплого и уютного хабра прямиком в высокие министерские кабинеты. Хабраэффект привел в том числе и к кадровым перестановкам. Опасаясь за свою карьеру, я был вынужден уйти в тень.

Наступил 2022 год. Кольцо врагов, о котором так долго говорили в телевизоре, наконец-то сомкнулось и проявило себя во всей красе — «наши западные партнеры» так нахлобучили родимую Россию санкциями, что импортозамещение, особенно в ИТ, фактически, стало жизненной необходимостью. Раз так, то давайте еще раз трезво посмотрим на текущую ситуацию с наиболее востребованным отечественным ПО — а именно с офисными программами, которые реально нужны всем без исключения государственным и коммерческим структурам.

Чем ответим Чемберлену
Всего голосов 325: ↑310 и ↓15+330
Комментарии226

Архитектура хранилищ данных: традиционная и облачная

Время на прочтение8 мин
Количество просмотров186K
Привет, Хабр! На тему архитектуры хранилищ данных написано немало, но так лаконично и емко как в статье, на которую я случайно натолкнулся, еще не встречал.

Предлагаю и вам познакомиться с данной статьей в моем переводе. Комментарии и дополнения только приветствуются!


(Источник картинки)
Читать дальше →
Всего голосов 11: ↑11 и ↓0+11
Комментарии7

Data Quality в банке — знаем цену каждой ошибки

Уровень сложностиПростой
Время на прочтение11 мин
Количество просмотров2.3K

Финансовый сектор уже давно одна большая "дата", когда банк принимает решение о том, выдать ли человеку или компании кредит, он анализирует сотни метрик. Я руковожу стримом Data Quality в Газпромбанке и расскажу о том, как мы решаем проблемы при интеграции с внешними источниками информации, какие оценочные метрики используем и как экспериментируем с моделями, прогоняя неверные данные.

Откуда берутся ошибки и чем внешние источники данных отличаются от внутренних

Чем больше данных, тем больше проблем, связанных с их качеством, причем к ошибкам может привести огромное количество причин.  Некоторые — банальные. Например, оператор при вводе персональных данных неправильно перепечатал ФИО из паспорта. Есть ошибки в проектировании систем. Скажем, разработчики проигнорировали требование к длине поля ввода данных. Например, поле «Паспорт выдан» ограничили 35 символами. Понятно, что нужно больше, но в системе сохраняются только первые 35 введенных символов: «ФМС Тверского района по городу Моск». Бывает, не учли, что какие-то данные вообще надо сохранять, а они потом потребовались. Например, пол клиента. Могут возникнуть сложности, связанные с потерей части данных при передаче информации из системы в систему в ходе ETL/ELT-процессов. При этом стоит разделять проблемы с качеством внутренних данных, которые находятся во внутрикорпоративных системах, и внешних, поступающих из сторонних источников. У нас в банке отлажены процессы по улучшению качества данных (КД), поэтому оно постоянно растет и стабильно выше, чем КД из внешних источников.

еще про данные
Всего голосов 4: ↑2 и ↓20
Комментарии1

Сравнение производительности YDB, CockroachDB и YugabyteDB на бенчмарке YCSB

Уровень сложностиСредний
Время на прочтение11 мин
Количество просмотров6.6K

Привет! Меня зовут Евгений Иванов, я разработчик YDB. Мне очень нравится заниматься задачами, связанными с производительностью: бенчить, анализировать, оптимизировать. И в YDB мы придаем очень большое значения тому, чтобы быть эффективными. В этом посте я хочу представить Вашему вниманию перевод нашей свежей статьи "YCSB performance series: YDB, CockroachDB, and YugabyteDB".

Реализовать распределённую систему управления базами данных (СУБД), высокопроизводительную, масштабируемую и консистентную, — настоящий вызов. В YDB успешно с ним справились, и наши пользователи могут это подтвердить. Мы ещё не делились показателями нашей производительности на широкую аудиторию, но понимаем их значимость. Поэтому сегодня мы расскажем о результатах нашего исследования производительности.

YDB — это распределённая реляционная СУБД. Производительность распределённых транзакций в TPC-C и других сложных бенчмарках во многом зависит от реализации хранения данных по ключу. В этом посте посте мы сравним результаты тестов YCSB для YDB и двух других известных распределённых SQL-баз данных — CockroachDB и YugabyteDB. Спойлер: YDB превзойдёт конкурентов по многим нагрузкам YCSB.

Читать далее
Всего голосов 14: ↑14 и ↓0+14
Комментарии2

Git subtree в деталях

Время на прочтение29 мин
Количество просмотров36K

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


Целью настоящей работы является практическое изучение средства управления поддеревьями Git.



Начиная с ревизии 1.7.11 upstream-репозиторий Git, в каталоге contrib/subtree, содержит средство автоматизации работы с поддеревьями.


Сервис git-subtree(1) фактически является полезной надстройкой, использующей функции git-read-tree(1) и git-write-tree(1). Поэтому ссылки в командах git-subtree(1) add/pull/push:

  git subtree add --prefix=<subdir> <remote> <ref>

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


Кроме того, если заранее добавить удаленный репозиторий в конфигурационный файл локального репозитория .git/config, с помошью команды:


bash-4.4$ git remote add build-system ../../remote/build-system.git

где build-system является именем удаленного репозитория ../../remote/build-system.git, то в дальнейшем, при использовании команд git-subtree(1) add/pull/push, мы сможем ссылаться на upstream-репозиторий remote/build-system.git по имени.


На данный момент git-subtree(1) практически не развивается, а лишь поддерживается в актуальном состоянии для текущей степени развития проекта Git.


Однако git-subtree(1) является наиболее популярным и мощным средством работы с поддеревьями.


Читать дальше →
Всего голосов 21: ↑19 и ↓2+17
Комментарии6

OAuth 2.0 -> OAuth 2.1. Что дальше?

Время на прочтение11 мин
Количество просмотров16K
Архитекторы ничего не выдумывают. Они трансформируют реальность.

Алваро Сиза Виэйра

Много всего уже сказано и написано про фреймворк авторизации OAuth 2.0 с 2012 года. И, казалось бы, все давно его знают, используют, все должно работать надежно и безопасно.
Но, как обычно, на практике все иначе. В работе в реальности приходится сталкиваться с небезопасными реализациями процессов авторизации и аутентификации. Огорчает, что по статистике Россия занимает непочетное первое место по своей уязвимости.
Почему же так получается? Предлагаю вместе со мной и авторами драфта OAuth 2.1 от июля 2020 года сделать небольшую работу над ошибками. Это и будет отражением, на мой взгляд, того, по какому пути развития идет фреймворк OAuth 2.

Также спешу предупредить строгого читателя, что в данной статье я затрону только вопросы и сложности, связанные с реализациями по OAuth 2.0. Я не ставлю цели обозначить все проблемы с безопасностью в России в ИТ, и почему этот вопрос требует особого пристального внимания сегодня.
Читать дальше →
Всего голосов 22: ↑22 и ↓0+22
Комментарии23

Пока, ФИАС! Рассказываем, как устроен адресный справочник ГАР

Время на прочтение10 мин
Количество просмотров93K

1 сентября 2021 года ФНС перестала обновлять свой адресный справочник в формате ФИАС. Относительно новый ГАР внезапно стал единственным государственным адресный реестром, доступным общественности. Рассказываем, что из себя представляет новый справочник и чем он отличается от ФИАС.

Читать далее
Всего голосов 20: ↑17 и ↓3+19
Комментарии18

Цикл постов про Keycloak. Часть первая: Внедрение

Время на прочтение18 мин
Количество просмотров66K

Цикл постов про Keycloak (часть 1): Внедрение.

О чем речь?

Это первая часть серии статей о переходе на Keycloak в качестве SSO в условиях кровавого enterprise.

Читать далее
Всего голосов 26: ↑24 и ↓2+25
Комментарии6

Load Average в Linux: разгадка тайны

Время на прочтение18 мин
Количество просмотров227K


Средние значения нагрузки (Load averages) — это критически важная для индустрии метрика. Многие компании тратят миллионы долларов, автоматически масштабируя облачные инстансы на основании этой и ряда других метрик. Но на Linux она окутана некой тайной. Отслеживание средней нагрузки на Linux — это задача, работающая в непрерываемом состоянии сна (uninterruptible sleep state). Почему? Я никогда не встречал объяснений. В этой статье я хочу разгадать эту тайну, и создать референс по средним значениям нагрузки для всех, кто пытается их интерпретировать.

Читать дальше →
Всего голосов 127: ↑125 и ↓2+123
Комментарии25

Введение в Data Vault

Время на прочтение6 мин
Количество просмотров135K


Большинство компаний сегодня накапливают различные данные, полученные в процессе работы. Часто данные приходят из различных источников — структурированные и не очень, иногда в режиме реального времени, а иногда они доступны в строго определенные периоды. Все это разнообразие нужно структурированно хранить, чтоб потом успешно анализировать, рисовать красивые отчеты и вовремя замечать аномалии. Для этих целей проектируется хранилище данных (Data Warehouse, DWH).

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

Кому будет интересна эта статья?


  • Ищете более функциональную альтернативу схеме «звезды» и Третьей Нормальной Форме?
  • У Вас уже есть хранилище данных, но его тяжело дорабатывать?
  • Нужна хорошая поддержка историчности, а текущая архитектура для этого не подходит?
  • Возникают проблемы при сборе данных из нескольких источников?

Если на какой-либо из этих вопросов Вы ответили утвердительно, и при этом не знакомы с Data Vault — прошу заглянуть под кат!
Читать дальше →
Всего голосов 9: ↑9 и ↓0+9
Комментарии2

Одиннадцать важных функций ONLYOFFICE, которых нет ни в MS Office Online, ни в Google Docs

Время на прочтение9 мин
Количество просмотров47K
Нас часто спрашивают, а чем мы вообще лучше других онлайн-редакторов документов. Вместо того, чтобы использовать опробованный Лордом Вейдером прием удушения Силой на всех, кто этот вопрос задает, мы решили написать о том, чем же хороши наши редакторы и чем они отличаются от, пожалуй, основных своих конкурентов — Office Online от Microsoft и Google Docs.

Начнем с текстовых редакторов.


Читать дальше →
Всего голосов 34: ↑23 и ↓11+12
Комментарии140

Yargy-парсер и библиотека Natasha. Извлечения структурированной информации из текстов на русском языке

Время на прочтение12 мин
Количество просмотров87K
В 2020 году библиотека Natasha значительно обновилась, на Хабре опубликована статья про актуальную версию. Чтобы использовать инструменты, описанные в этом тексте, установите старую версию библиотеки pip install natasha<1 yargy<0.13.

Раздел про Yargy-парсер актуален и сейчас.


Есть стандартная задача извлечения именованных сущностей из текста (NER). На входе текст, на выходе структурированные, нормализованные объекты, например, с именами, адресами, датами:



Задача старая и хорошо изученная, для английского языка существует масса коммерческих и открытых решений: Spacy, Stanford NER, OpenNLP, NLTK, MITIE, Google Natural Language API, ParallelDots, Aylien, Rosette, TextRazor. Для русского тоже есть хорошие решения, но они в основном закрытые: DaData, Pullenti, Abbyy Infoextractor, Dictum, Eureka, Promt, RCO, AOT, Ahunter. Из открытого мне известен только Томита-парсер и свежий Deepmipt NER.

Я занимаюсь анализом данных, задача обработки текстов одна из самых частых. На практике оказывается, что, например, извлечь имена из русского текста совсем непросто. Есть готовое решение в Томита-парсере, но там неудобная интеграция с Python. Недавно появилось решение от ребят из iPavlov, но там имена не приводятся к нормальной форме. Для извлечения, например, адресов («ул. 8 Марта, д.4», «Ленинский проезд, 15») открытых решений мне не известно, есть pypostal, но он чтобы парсить адреса, а не искать их в тексте. C нестандартными задачами типа извлечения ссылок на нормативные акты («ст. 11 ГК РФ», «п. 1 ст. 6 Закона № 122-ФЗ») вообще непонятно, что делать.

Год назад Дима Веселов начал проект Natasha. С тех пор код был значительно доработан. Natasha была использована в нескольких крупных проектах. Сейчас мы готовы рассказать о ней пользователям Хабра.
Natasha — это аналог Томита-парсера для Python (Yargy-парсер) плюс набор готовых правил для извлечения имён, адресов, дат, сумм денег и других сущностей.
В статье показано, как использовать готовые правила из Natasha и, самое главное, как добавлять свои с помощью Yargy-парсера.
Читать дальше →
Всего голосов 87: ↑86 и ↓1+85
Комментарии33

Review- или динамические окружения. Теория и практика в Kubernetes

Время на прочтение10 мин
Количество просмотров14K

Статья посвящена так называемым review-окружениям, реализуемым в рамках кластеров Kubernetes. Ранее эта тема затрагивалась, например, в нашем докладе «Лучшие практики CI/CD с Kubernetes и GitLab», но не была там основной темой, поэтому раскрывалась не во всех деталях. Попробую восполнить этот пробел, рассказав, для чего нужны и/или обычно используют review-окружения, как сделать pipeline c review-окружением в GitLab CI/CD, какие могут быть потенциальные проблемы и способы их решения.

Читать далее
Всего голосов 38: ↑38 и ↓0+38
Комментарии10

Модерация изображений: уроки этикета от Data Scientist’a, часть 2

Время на прочтение6 мин
Количество просмотров2.9K
Привет, Хабр!

Мы продолжаем серию статей про модерацию контента на площадках Центра Развития Финансовых Технологий Россельхозбанка. В прошлой статье мы рассказывали, как решали задачу модерации текста для одной из площадок экосистемы для фермеров “Свое Фермерство”. Почитать немного о самой площадке и о том какой результат мы получили можно здесь.

Если коротко, то нами использовался ансамбль из наивного классификатора (фильтр по словарю) и BERT’a. Тексты, прошедшие фильтр по словарю, пропускались на вход в BERT, где они также проходили проверку.

А мы, совместно с Лабораторией МФТИ, продолжаем улучшать нашу площадку, поставив перед собой более сложную задачу премодерации графической информации. Эта задача оказалась сложнее предыдущей, так как при обработке естественного языка можно обойтись и без применения нейросетевых моделей. С изображениями все сложнее — большинство задач решается с помощью нейронных сетей и подбором их правильной архитектуры. Но и с этой задачей, как нам кажется, мы неплохо справились! А что у нас из этого получилось, читайте далее.

image

Читать дальше →
Всего голосов 10: ↑8 и ↓2+14
Комментарии1

Five Methods For Database Obfuscation

Время на прочтение20 мин
Количество просмотров7.4K
ClickHouse users already know that its biggest advantage is its high-speed processing of analytical queries. But claims like this need to be confirmed with reliable performance testing. That's what we want to talk about today.



We started running tests in 2013, long before the product was available as open source. Back then, just like now, our main concern was data processing speed in Yandex.Metrica. We had been storing that data in ClickHouse since January of 2009. Part of the data had been written to a database starting in 2012, and part was converted from OLAPServer and Metrage (data structures previously used by Yandex.Metrica). For testing, we took the first subset at random from data for 1 billion pageviews. Yandex.Metrica didn't have any queries at that point, so we came up with queries that interested us, using all the possible ways to filter, aggregate, and sort the data.

ClickHouse performance was compared with similar systems like Vertica and MonetDB. To avoid bias, testing was performed by an employee who hadn't participated in ClickHouse development, and special cases in the code were not optimized until all the results were obtained. We used the same approach to get a data set for functional testing.

After ClickHouse was released as open source in 2016, people began questioning these tests.

Read more →
Всего голосов 7: ↑5 и ↓2+7
Комментарии4

Как мы писали книгу про управление данными

Время на прочтение7 мин
Количество просмотров4.1K

Замысел

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

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

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

Сообразно сменилась и концепция – теперь мы хотели уже научпоп, который бы растолковал «даже домохозяйкам» все премудрости управления данными. Какое-то время мы жили в этой концепции, стремясь упростить и несколько примитивизировать научные постулаты. Еще одним вариантом было создать «DMBOKдля чайников», но мы быстро (и совершенно оправданно) ушли от этого. 

Читать далее
Всего голосов 11: ↑7 и ↓4+8
Комментарии8

Битва при MERGE. Хроника с выводами и моралью

Время на прочтение11 мин
Количество просмотров26K
Несколько недель перед важным комитфестом — последним перед feature freeze версии PostgreSQL 11 — читатели рассылки hackers, сжимая в левой пакет с чипсами, следили за триллером MERGE. Режиссер триллера, глава компании 2ndQuadrant Саймон Риггс (Simon Riggs), с впечатляющей настойчивостью и изобретательностью пытался протащить в версию патч, реализующий синтаксис команды MERGE. Риггс комитер с 2009 года, а со статусом комитера можно самому утверждать патчи. Ему противостояли не менее уважаемые комитеры и ветераны PostgreSQL. Страсти кипели явно и подспудно, до прямых оскорблений все же не дошло — факт удивительный для завсегдатаев многих отечественных форумов. Однако некоторое напряжение осталось до сих пор, когда вопрос утрясли, и спорить уже не о чем.
Читать дальше →
Всего голосов 23: ↑23 и ↓0+23
Комментарии18

PostgreSQL отложенные SQL ограничения

Время на прочтение10 мин
Количество просмотров21K
На Хабре уже было несколько статей упоминающих deferred constraints.


Но хочется рассказать о них подробнее.

PostgreSQL deferred constraint
Читать дальше →
Всего голосов 15: ↑15 и ↓0+15
Комментарии4

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Зарегистрирован
Активность