Системный и бизнес-анализ

Apache Superset — востребованное open-source решение для анализа данных, которое можно быстро установить и встроить в существующий технологический стек компании благодаря большому количеству коннекторов и видов визуализаций. Однако для высоконагруженных систем и сложных сценариев некоторые компании дорабатывают исходную версию, например внедряют инструменты автоматического кеширования и оптимизируют архитектуру хранения данных для построения графиков. По этому пути в своё время пошли и мы в VK.

Привет, Хабр. Меня зовут Никита Романов, лидирую разработку аналитических инструментов VK. В этой статье расскажу о нашем опыте оптимизации Apache Superset под свои задачи.

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

Пришло время еще раз оглянуться назад и вспомнить технологии, которые ушли в 2025 году. От таких столпов, как Skype, до устройств с ИИ, у которых не было ни единого шанса, все из этого списка отправилось на технологическую свалку за последние 12 месяцев.

Привет, Хабр! Меня зовут Артем Евтеев, я ведущий аналитик в МТС Web Services. Кажется, каждый бизнес-аналитик (и не только) хотя бы раз в жизни слышал о книге «Разработка требований к программному обеспечению» Карла Вигерса и Джой Битти.

В очередной раз собрался освежить в памяти теорию — и меня посетила мысль: а насколько изложенное в «инструкции бизнес-аналитика» действительно перекликается с реальностью? Как часто эта «настольная книга» подходит для решения рабочих задачах?

В жизни теория нередко сочетается с практикой. Но так ли это в профессии бизнес-аналитика в ИТ-компании — предлагаю разобраться. 

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

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

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

Самые интересные новости финансов и технологий в России и мире за неделю: ЦБ решил позволить неквалам покупать криптовалюту, на Роскомнадзор подали в суд за блокировку мессенджеров, Маску наконец вернули бонус за Теслу, новая цензура для китайских нейросетей, а также взлом браузерного расширения Trust Wallet.

Всем привет! Меня зовут Дмитрий Листвин, я занимаюсь аналитическим хранилищем данных в Авито.

В этой статье я собрал наш опыт построения Lakehouse поверх объектного хранилища, как реальная аналитическая нагрузка быстро превращает «обычный S3» в самый капризный элемент всей архитектуры. Будет много про извлечение максимума производительности из Ceph: как добиться высокой пропускной способности HDD, когда поверх данных хочется запускать тяжёлые аналитические запросы.

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

Меня зовут Евгений Пантелеев. Я занимаюсь аналитикой в Авито Авто в сегменте Resellers.

Каждый день мы с командой сталкиваемся с необходимостью измерения небольшого инкремента (в районе 1%) от CRM-коммуникаций на изменчивой выборке пользователей в условиях долгосрочного эксперимента (до 6 месяцев). При этом нам важно минимизировать размер контрольной группы, не жертвуя статистической значимостью результата.

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

Начало тут

По своей сути, каждая новая экселька это отдельный мирок. Я бы даже выразился "некая от отдельная приложуха"! И чтобы она была живой, понятной не только тебе и действительно стала полезным инструментом ты должен понять, а на какой вопрос она отвечает?

Это не совсем ТЗ. Тех.задание (пусть и самому себе) ты будешь продумывать в голове на следующем шаге. А это чуть более глубокий вопрос: какую именно потребность ты закроешь в самом конце, проделав кучу работы, всё собрав, подсчитав и отформатировав?

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

Подход Марковица, которому мы сегодня уделим внимание, был удостоен Нобелевской премии 1990 года.

Всем привет! Меня зовут Дмитрий Рейман, я техлид аналитической платформы Avito. Уже третий год мы занимаемся миграцией с Vertica на Trino. Изначально казалось, что это будет просто: перенесём запросы, перепишем коннекторы, чуть подправим пайплайны.

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

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

Это заключительная часть серии «23 фичи Luxms BI, которыми мы гордимся». В первой мы говорили о платформенности и архитектуре, о фундаменте системы. Во второй – о классическом BI-функционале. В третьей – о возможностях, выходящих за рамки привычной бизнес-аналитики.

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

Привет, Хабр!  Меня зовут Юлианна Валиуллина и я главный эксперт по развитию BI в банке Уралсиб.

Для начала немного о нас: мы практикуем self-service подход, в банке более 200 разработчиков, из них 150 имеют опубликованные дашборды, остальные делают аналитику для себя. Более 1200 опубликованных дашбордов, MAU около 1500. Большая часть дашбордов в нашем банке работает в spider(extract) режиме, доля direct 15-20%.

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

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

Эта статья всего лишь крик души специалиста, который устал. Дико устал. Чудовищно устал от того, что ему каждый день приходится смотреть на десятки ужасных таблиц в его любимейшем Экселе (ну и Гугл доксе заодно). Ещё больше его удручает, что даже на курсах по повышению грамотности экселя об элементарных вещах сказать забывают. Как результат – текущие от боли глаза. Ну почему?! Почему такие простые вещи никто нигде не рассказывает?!

Добрый человек, не поленись. Дочитай. И твои таблицы станут на порядок лучше и понятнее не только для тебя, но и для всех окружающих!

Сегодня мы, Павел Ефремов и Мухаммед Пашаев (разработчики аналитических систем в Лемана Тех), поговорим об оптимизации моделей данных в Power BI Desktop — конкретно о движке Tabular. Небольшая вводная: в нашей компании Power BI — основной BI-инструмент (лучшие для лучших😏). Используем локальную версию Power BI Report Server, поэтому вопрос производительности моделей и отчетов стоит особо остро. Мы регулярно проводим ревью моделей (подробнее в нашей прошлой статье), стараясь придерживаться лучших практик — минимальная нужная гранулярность данных, никаких избыточных связей, двунаправленных связей, скрытых автоматических календарей и прочее. Тем не менее отчеты все равно порой залипают и работают медленно. Казалось бы, уже много где поковырялись, все оптимизировали, и все равно фрустрация не уходит. Так, вместе с коллегой мы взялись копать глубже, шерстить интернет и Microsoft-документацию и наткнулись на почти незаметное, но важное свойство табличной модели. Что, если мы скажем, что у Tabular Model есть свойство, благодаря которому можно уменьшить размер модели до 30%, ускорить обновление данных, снизить нагрузку на сервер и при этом не менять ни одной таблицы, связи или строку DAX?

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

🤖 Тысячи копий одного и того же алгоритма от Claude/Grok/ChatGPT торгуют друг против друга. Это создаёт спираль смерти, на которой зарабатывает только биржа через комиссии

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

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

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

Всем привет! Меня зовут Дмитрий Рейман, я техлид аналитической платформы Авито. Мы строим систему общего назначения, которая одновременно обслуживает ETL, витрины, BI, ad-hoc аналитику и продуктовые платформы.

И в какой-то момент мы столкнулись с неприятным эффектом: объём данных начал расти заметно быстрее, чем органический рост, на который мы ориентировались раньше. Модель классического on-prem DWH перестала масштабироваться линейно: борьба за ресурсы мешала давать гарантии готовности данных; локальные оптимизации давали всё меньший эффект; любой рост требовал масштабирования “по месту” и приводил к длительным простоям аналитики.

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

Чем больше данных в компании, тем критичнее становится понимание того, где именно они хранятся и как изменяются при обновлениях. В «Островке» мы пользуемся дата-каталогами, но в какой-то момент решили пойти чуть дальше: объединили DataHub с генеративным ИИ через Model Context Protocol, чтобы сделать работу с метаданными более интерактивной и быстрой.

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

Под катом делимся опытом внедрения связки DataHub + MCP, рассказываем об архитектуре решения и показываем реальные примеры, как ИИ становится практическим помощником в управлении метаданными.