Всем привет! Меня зовут Вадим, я старший разработчик по направлению Flutter в компании STM Labs. В этой статье я хочу поделиться нашим опытом внедрения единой биометрической системы в приложение, написанное на Flutter.
Меня зовут Андрей Комягин, я СТО компании STM Labs. Мы занимаемся разработкой очень больших распределённых высоконагруженных систем для различных отраслей и в своей работе широко используем open-source решения, в том числе СУБД Redis. Недавно я подробно рассказывал об этой системе на конференции Saint HighLoad++, а теперь с удовольствием поделюсь основной информацией с читателями Хабра. Итак, поехали.
С необходимостью переноса данных из Oracle столкнулись многие российские компании: в июле 2022 года корпорация, создавшая этот продукт, ушла с российского рынка из-за санкций, как и множество других зарубежных IT-компаний. У пользователей из нашей страны больше нет поддержки вендора, а значит со временем система может перестать корректно работать.
Система хранения Oracle была очень популярна в России: данные в ней хранили и обрабатывали даже компании из государственного сектора. И всем нам предстояло быстро решить, куда и каким образом перенести огромные объёмы ценной информации, ничего не потеряв в процессе переноса.
Привет =) На связи снова Анастасия-аналитик из команды STM Labs со своей любимой темой «мягких» навыков. В статье про собеседования (первая часть тут, вторая тут) я сравнила аналитика с переводчиком с бизнесового языка на разработческий. Или наоборот.
Недавно у нас на работе произошел случай, на примере которого можно в шутливой форме раскрыть это сравнение и наглядно показать, почему же аналитику важно понимать, с кем он разговаривает, и как доносить одну и ту же информацию до людей с разными ролями в проекте.
Вторая часть масштабной статьи про собеседования. Первая — тут. В прошлый раз мы поговорили об идеальном кандидате в вакууме, а также о презентационной части собеседования. Здесь же будем говорить про техническую часть и про то, в каком направлении бы хотелось развивать тему с собеседованиями.
В конце добавила секцию с бонусными рубриками — советами и наблюдениями для тех, кто проводит собеседования или приходит на них как кандидат =)
Я работаю в компании STM Labs, где мы строим большие высоконагруженные системы класса Big Data. Эта статья написана по мотивам моего выступления на конференции Saint Highload 2023. Хочу рассказать вам увлекательную историю про то, как мы искали лучшее решение по синхронизации аналитического и оперативного хранилищ в реальном времени. Нам важно было сделать это без потерь, потому что на кону стояли сотни и более терабайт данных.
Сразу обозначу, чего в этой статье не будет:
• Я не буду подробно говорить о типах СУБД и их различиях.
• Я не буду делать обзор аналитических СУБД. Тут каждый выбирает сам.
• Я не буду подробно останавливаться на архитектуре, отказоустойчивости и масштабировании СУБД MongoDB.
• Я не буду делать обзор отличий OLAP и OLTP.
• Я не буду делать обзор и сравнение реализаций CDC в различных СУБД.
Про собеседования, аналитиков и не только, на различных IT и не очень ресурсах написано достаточно много. Но ведь это не повод не рассказать, как они происходят у нас — вдруг что-то новое для читателя да и проскользнет? =)
Сегодня речь пойдет о mediation-системах — системах обработки больших данных класса OSS/BSS (Operations / Business Support System). Они получают данные из разнородных источников, обрабатывают в зависимости от требований и передают в нужном формате в другие системы-потребители. Чаще всего их применяют в телеком-сфере: они собирают информацию об абонентском трафике, который условно можно разделить на две группы: голосовой и передача данных (интернет), преобразуют, а затем отправляют в биллинговую систему для выставления счетов. Поэтому такие системы называют предбиллинговыми.
Но их возможности также применяют для автоматизации в логистике, сфере коммунальных услуг или финансов. И вообще везде, где нужно собирать большие объемы разнородных данных, а потом в преобразованном виде отправлять в другие системы. В этой статье поговорим именно о телекоме, а в будущих я расскажу и про стриминг-платформы, и про интернет вещей, и про другие сферы.
Мечтал ли я когда-либо ворочать миллиардами? Честно признаюсь, да. И нельзя сказать, что Вселенная меня не услышала. Вот только я никак не имел в виду миллиарды записей в базе данных...
Ранее я уже писал о нашем опыте использования ScyllaDB в качестве архивного хранилища. Разумеется, исследования и открытия, связанные с новой базой данных, для нас на этом не закончились... Создавая архив для данных, вероятность обращения к которым близка к нулю, мы, конечно, допускали, что время от времени клиенты будут просить вернуть данные обратно в оперативное хранилище. Но запрос на извлечение из архива сразу всех записей стал для нас неожиданностью. Хорошо ещё, что клиента интересовал только ключ записи, а не вся запись целиком. Тем не менее достать 10 млрд. ключей из ScyllaDB за приемлемое время звучало как челлендж. Ну надо так надо.
Мы в STM Labs разработали ПроЧек — лучшее (конечно же, по нашему мнению) приложение для хранения и анализа чеков. ПроЧек все делает сам: автоматически загружает чеки, сортирует покупки с помощью ИИ и строит отчеты. А мы продолжаем его развивать и дополнять функциями.
В этой статье — список из пяти других приложений для чеков, которые мы нашли полезными: одни просто хранят чеки, другие следят за тратами, ищут скидки или помогают зарабатывать на кэшбэке.
Как системный аналитик может улучшить юзабилити проекта. Разбираем простые, но неприятные недоработки на примере китайских систем для поступления в ВУЗы.
Совсем недавно наша аналитик рассказывала о том, как выиграть хакатон, сохранив моральное и физическоездоровье.
За пару дней до выхода статьи эта же аналитик подговорила наших ребят участвовать в командном хакатоне. Результат не самый приятный — 38 место из 60. Однако, этот опыт, как и любой другой, не прошел даром (а еще был очень веселым).
В этой статье каждый участник команды поделится своим опытом и персональной рефлексией. Ну и лулзами, пойманными в процессе.
Раньше аналитиков звали разве что на хакатоны в составе команд. Но относительно недавно — наконец-то — стали появляться специализированные контесты и хакатоны для системных аналитиков. С 2021 года я ввязывалась в целых три: в первом заняла третье место, во втором седьмое, а в последнем — первое.
В статье расскажу, как этим летом прошел хакатон Sovcombank Challenge 2022. И порефлексирую, как не надо участвовать в соревнованиях.
Сегодня у нас — экшен, основанный на реальных событиях. Будем переобуваться в воздухе и на лету менять архитектуру высоконагруженной системы.
Действие разворачивается на базе очень большой track & trace системы класса big data. В ней давно откладывали переход на шардированную архитектуру хранилища. Поэтому главному герою предстоит справиться справиться со злом, пробудившимся в системе под нагрузкой: деградацией производительности, полкой по блокировкам и алертами о перегрузке.
В конце — как обычно, хэппи-энд. Наш герой бесстрашно меняет архитектуру решения на лету без downtime (DT) и обеспечивает штатную работу системы. Зло повержено, а отважный инженер купается в овациях!
Статья написана по мотивам доклада на конференции Saint Highload++ 2022. Если не хотите читать — можно посмотреть видео-версию выступления.
Привет, я Никита. Вообще я инженер интеграции. Но, похоже, судьба мне быть тревел-блогером.
В начале прошлого лета я пять недель работал в Конго. Как результат — статья «Как айтишнику выжить в Африке». Почитайте, там несколько лайфхаков, как вернуться живым.
В этом году работать я отправился в Австрию. Уже не Африка, но экстрима я ожидал не меньше: белому русскому гетеросексуальному мужчине в месяц Прайда в 2022 могут быть рады не все и не везде.
Предположим, вы в системных аналитиках недавно, например, на позиции джуна. Вы уже представляете, в чем заключается работа, и планируете развиваться в этой сфере. Еще с вами багаж общих IT-знаний, умение гуглить и/или грамотный ментор.Через какое-то время вы осваиваетесь в изначальном проекте. Но системная аналитика, как оказалось, штука очень интересная. Поэтому вы начинаете искать, во что бы еще вляпаться — в своей статье говорю про развитие soft skills. Случаи, когда базовых hard skills нет совсем, здесь не рассматриваются.
Короче, как жить и набраться опыта аналитику, когда почти научился жить и еще не сошел с ума!
Немного контекста о том, как возникло это исследование...
В один из тех летних дней, когда на улице стояла ясная, солнечная, жаркая погода, когда стрижи быстро пролетали за окном, распространяя веселые звуки, мы закончили очередную задачу по проекту (в нашем проекте используется Python). Задача заключалась в получении различными способами (очередь, сервисы, файловая система и т.д.) входящих документов (JSON формат), обработке этих документов и сохранении обработанных документов обратно в JSON формате в архивную базу данных. Завершив кодирование и юнит тесты, мы выкатили решение на одно из тестовых окружений и стали ждать результатов. По функциональности решение работало отменно, но, оценив скорость работы решения, я задался вопросом, а можно ли его ускорить?
Критериям выбора архивного хранилища она соответствовала идеально. Оптимизированная под запись, легко масштабируемая, совместимая с привычной уже Cassandra, только в разы быстрее… Имя же её — Сцилла (греч. Σκύλλα — «лающая») — напоминая о мифологическом чудовище, рисовало в воображении картины молниеносного поглощения гигантских объемов данных. Сложно было устоять и не попробовать.
Про конечные автоматы (finite state machine, fsm) много кто слышал, но используют их явно в реальных проектах редко. Чаще встречаются конструкции, которые поведением напоминают КА, но ими не являются.
Почему же автоматы обходят стороной и/или изобретают велосипеды, превращая код в спагетти?
По-моему, тут дело в стереотипе: мол, автоматы — это что-то сложное из теоретической математики и к реальной жизни не относится. А применять их можно только в лексических анализаторах или еще чем-нибудь специфичном.
На самом деле, область применения КА куда шире и понятнее. Давайте разберем на примере автоматизации процессов в любимом кровавом enterprise.
