Немного душная, но важная вводная часть

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

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

• Какую сумму инвестировать в бизнес-направление и когда вложения окупятся?

• Сколько мы зарабатываем на продукте A, и не каннибализирует ли он доходы с продукта B?

• Насколько капитализация нашего бизнеса изменилась за последний год?

Помимо этого, мы принимаем (преимущественно в автоматизированном режиме) множество операционных решений:

• Информацию о каком продукте направить клиенту в SMS-рассылке?

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

• Какую оптимальную цену предложить клиенту за потребляемые услуги?

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

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

В этой статье затронем тему организации процессов Machine Learning Operations (MLops) в beeline business, особое внимание акцентируем на тестировании моделей машинного обучения. Тестирование мы построили с использованием Gitlab (CI/CD), Mlflow и open-source фреймворка Seldon Core для деплоя REST API или gRPC сервисов с моделями в среде Kubernetes. А пока… 

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

В этом посте мы поговорим о том, как формат сообществ (чаптеров) помогает нам в работе. Для этого мы подробно побеседовали с Михаилом Благовым, лидером чаптера инженеров данных. Еще нам помогали Николай Безносов (чаптер Data Science) и Артём Смирнов (Data Analytics).

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

Почему масштабировать вообще сложно?

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

Основная причина тут в том, что как только вы начинаете изменять какую-то большую систему, она начинает разваливаться. Ну, за исключением тех случаев, когда у вас вообще всё на 100% покрыто тестами. Однако, в реальном мире история с покрытием тестами такова, что код современных приложений покрыт (в лучшем случае) примерно на 1%.

Может быть, 100% покрытие тестами — это реальность не только для библиотек, утилит или компиляторов (ведь мы можем формализовать их поведение математически), но и для веб-приложения? Да не, фигня какая-то...

Привет! Меня зовут Николай, я дизайнер в билайне. Как-то раз для устройства на одну из работ на своем жизненном пути мне нужно было сделать тестовое задание. И в отличие от множества других тестовых, это было на самом деле интересным.

В посте я расскажу, как разбирался для решения этой задачи с методом JTBD (Jobs To Be Done), когда его стоит применять, что можно из этого выжать и причем тут вообще дизайн.

Привет! 

Меня зовут Александр Маркачев, я 3,5 года работаю на позиции Data Engineer в билайне и люблю открывать для себя что-то новое и интересное в работе. Так случилось и с темой, которой я сегодня хочу с вами поделиться — со spill-ами.

Под катом мы поговорим о том, что такое Spill-ы в контексте Spark, и почему именно для Spark это не такая уж сильно плохая штука. Рассмотрим, из-за чего Spill-ы в принципе возникают, разберем несколько видов Spill-ов (и даже вызовем их намеренно), а затем будем решать эту проблему.

Что такое spill-ы в Spark

Вообще, Spill — это термин для обозначения процесса перемещения данных из памяти на диск, а затем снова обратно в память. По крайней мере, именно так гласит официальная трактовка. Если проще, то дело вот в чем — когда у Spark не хватает ресурсов для обработки, он перемещает данные на диск.

В процессе обработки существуют разные участки — есть Executor Memory, есть Storage Memory, и когда эти участки оба целиком заполнены, то они начинают переполняться и вызывать утечку данных. Причем в отличие от утечки в C, Java или еще где-то, в Spark это преднамеренное действие для того, чтобы ваша задача не падала. Собственно, именно поэтому при нехватке ресурсов данные и «проливаются».

Можно ещё сильнее упростить аналогию.

Привет! Меня зовут Сергей Грибков, я тимлид команды FM&RA в билайне, и в этом посте я хочу рассказать об одной фирменной особенности Scala под названием implicits. Это неявные параметры, неявные преобразования, неявные классы.

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

В Scala implicits широко распространены. Скорее всего, вы уже сталкивались с ними в различных библиотеках и фреймворках, например, Apache Spark. 

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

Итак, существует три основных категории implicits:

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

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

С 2015 по 2021 годы я работала в дирекции по продажам конвергентных продуктов Билайн аналитиком, можно сказать, «на все руки» – аналитиком продаж, продуктовым, финансовым. В мою зону ответственности входили операционная и ежемесячная отчетность, расчет планов продаж на квартал, бюджетирование расходов на продажи, расчеты кейсов по инициативам – для всего этого требовалось моделирование основных KPI развития бизнеса. 

Меня зовут Нина Фещенко, с 2022 года в департаменте аналитики розничного бизнеса (B2C) я в большей степени занимаюсь работой с данными и BI-аналитикой, но без моделирования тоже не обходится. В этом посте я опишу свой опыт построения модели прогнозирования продаж конвергентных продуктов (2019-2021), а также прогнозирования оттока мобильных абонентов в 2022 году. Расскажу, как работала модель в относительно стабильный период до 2020-го года, и какие корректировки пришлось внести впоследствии. 

Привет! Меня зовут Филипп Кондрашов, я руковожу разработкой DS-решений в бигдата билайн. Как-нибудь расскажу вам, как наша команда строит лучшие модели скоринга. 

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

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

С чем поможет материал из статьи:

• Освободиться от вертикальных взаимоотношений

• Найти общий язык с менеджментом

• Управлять командой во времена хаоса и гармонии

• Не сойти с ума

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

Так как же объяснить концепцию «плохого кода» обывателю?

В одном из предыдущих постов мой коллега Юрий рассказывал об устройстве нашего мониторинга.

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

Для ленивых или занятых — переходите сразу на последний раздел: там краткая выжимка.

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

Основные способы коммуникаций внутри продуктовой команды

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

Чаще всего речь идет о электронных письмах, чатах, видео/аудио-конференциях, реже — очных встречах.

Итак, по порядку. 

Привет! В рамках своей работы в beeline tech мы часто взаимодействуем с геоданными. Для решения проблем, связанных с хранением, обработкой и анализом большого объема распределенных пространственных данных, мы используем Apache Sedona (бывший Geospark). Мы — Денис Афанасьев, аналитик больших данных, и Женя Рыбалкин, инженер больших данных, под катом расскажем, почему выбрали именно этот инструмент и что он умеет. А чтобы показать, зачем вообще работать с геоданными, давайте возьмем пример расчета посещаемости хоккейных матчей в Москве, как-никак плей-офф в разгаре.

Давайте по порядку. Почти любой доступный смартфон, умные часы, фитнес-браслеты, оборудование для IoT — всё это может получать и передавать данные о собственном местоположении. Кроме потребительского железа серьезную эволюцию прошёл и интернет вещей в целом, причем как классический IoT для умного дома и других полезностей, так и индустриальный IIoT, заточенный под мониторинг сложных технологических систем, сельское хозяйство, мониторинг окружающей среды и многое другое.

Следствием такого развития, как в количественном, так и в качественном плане, стал ощутимый рост того объёма данных, который все эти устройства генерируют. Ну и что нам с ними делать? Давайте разберемся на примере геоданных!

Зачем вообще кому-то нужны геоданные?

Меня зовут Павел Корчагин, сейчас я дата-аналитик в билайне. В этом посте я расскажу историю своего профессионального становления в формате небольшой ретроспективы с элементами RPG.

Всё началось в 2016 году, я тогда находился в активном поиске работы. Это были полгода безуспешных попыток устроиться хоть куда-то в приличное место молодому человеку без образования (из университета отчислили), еще и после окончания срочной службы.

В мае я увидел объявление о наборе сотрудников call-центра в билайн. Решил идти и устраиваться, так как жил один, да еще и вдали от родственников и, конечно же, на самообеспечении. Пора было что-то менять. И я поменял.

Все говорят про webpack-module-federation - микрофронты тут, микрофронты там.
— "А мы уже внедрили", "а мы уже построили микрофронтовую-архитектуру", "мы релизим независимо".

Но начинаешь расспрашивать, "а что сделали", "а как связали" - выходит что за всеми этими броскими фасадами скрывалось добавление вызова ModuleFederationPlugin(...) на уровне рядового потребителя, в лучшем случае с подстройкой конфигурации под локальный и продуктовый стенды. А независимые релизы - обычный авто деплой trunk'а.

На этом фоне доклады, повествующие о динамическом развертывании k8s pod'ов с версиями микрофронтов, указанных в заголовках браузера (на базе argo-cd) производят вау-эффект. Но даже все эти истории имеют один общий недостаток.

На вопрос:
— А как вы реализовали SSR?

Следует ответ:
— Мы не стали этого делать, у нас админка / дэшборд / MVP / *.

Привет! Меня зовут Михаил Благов, я руководитель департамента «Чаптер инженеров данных и разработчиков» в beeline tech. В этом посте я хочу поделиться способом, с помощью которого можно выбрать подходящую архитектуру для конвейера данных в зависимости от требований к нему. В частности, обсудим паттерн CDC (change data capture, aka «захват изменений»), основная идея которого — быстрая репликация какого-то источника в аналитическое хранилище. 

Под катом мы:

- познакомимся с вариантами архитектуры конвейеров данных: из каких компонентов и как его можно собирать,

- рассмотрим и сравним четыре разные архитектуры конвейеров.

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

Начнем с матчасти