В предыдущих статьях мы пришли к выводу, что для того, чтобы код не превращался в легаси, необходимо получать оперативный фидбек о его правильности, а также использовать хорошие шаблоны программирования. При соблюдении этих двух условий у нас появится возможность легко вносить изменения.
Однако, есть проблемы с текущими подходами к созданию пользовательского интерфейса, которые затрудняют достижение этих двух условий.
Каждая компания непрерывно производит и хранит кучу данных, и это вызывает множество проблем. Объёмы хранилищ не бесконечны, как и ресурсы железа. Вот только оптимизация обработки и хранения данных не всегда приносит желаемые результаты. Как всё настроить так, чтобы значительно сократить объём занимаемый ими на диске?
У нас получилось! Мы снизили количество данных на диске в 3 раза, при этом ускорив их обработку. И сейчас расскажу как. Меня зовут Александр Маркачев, я Data Engineer команды Голосовой Антифрод в beeline. В статье затронем тему форматов ORC и Parquet, как их правильно использовать и хранить, чтобы всем было хорошо.
Всем привет! Меня зовут Саша, я тимлид в DS-команде дирекции по искусственному интеллекту и цифровым продуктам билайн бизнес, и хочу рассказать вам, как мы создали рейтинг компаний, которые занимаются искусственным интеллектом. Публикация рейтинга не преследует какие-либо коммерческие цели и не направлена на продвижение каких-либо компаний или услуг.
Идея проекта
Откуда вообще может появиться идея? Иногда она просто витает в воздухе и ждёт, пока её кто-нибудь подхватит. Честно говоря, мне бы никогда в голову не пришло отранжировать компании по их влиянию в сфере ИИ. Но ребята из нашего PR-отдела оказались более прозорливыми и пришли к нам с запросом о создании такого рейтинга. Забегая вперед, можно подчеркнуть, что весь проект сам по себе стал прецедентом с точки зрения взаимодействия представителей PR и специалистов по машинному обучению и анализу данных.
Привет! Меня зовут Андрей, я несколько лет занимаюсь разработкой, и за это время успел поработать с разными командами дизайнеров, посмотреть на разные подходы, кто где как делает, где какие есть сложности.
В этом посте как раз о подобных сложностях я и хочу поговорить, а именно — о проблеме в коммуникациях между разработчиками и дизайнерами. Я очень люблю делать личные кабинеты, поэтому и в качестве примера буду говорить именно о разработке ЛК в билайне за последние три года. О том, какие именно трудности возникали и как мы упростили работу на UI-китом, под катом.
Представьте ситуацию.
Вы приходите на новую работу, забираете ноут, начинаете работать над проектом, над которым поработало уже несколько поколений разработчиков до вас.
Написание кода похоже на соединение двух точек. Ожидаемо, что самым простым путем будет нарисовать прямую линию между точками А и Б.
Для большинства простых случаев это работает, но вот в реальной жизни, кроме соединения точек, вам придется еще и обходить различные препятствия. Но в целом — тут тоже никакой проблемы, кроме необходимости немного поманеврировать.
Давайте увеличим количество препятствий на порядок. Линия становится все более извилистой.
Теперь давайте заставим эти препятствия двигаться. Медленно, но достаточно для того, чтобы вызвать проблемы с необходимостью переподключения точек. Это уже не такая простая прямая линия, и начинает выглядеть куда серьезнее.
А если мы заставим двигаться не только препятствия, но и сами точки? Вдобавок убедимся, что эти точки не приклеены к линиям, и вам придется следить за ними, чтобы они оставались соединенными. Начинает немного бесить?
Немного душная, но важная вводная часть
Факт — большинство компаний озабочено повышением своей финансовой эффективности. Некоторые считают, что ключ к успеху — клиентоориентированность. Каждый день сотрудники штаб-квартир и региональных представительств оценивают экономику принимаемых решений и придумывают, как повысить лояльность клиента.
По сути, перед нами постоянно стоит множество разнообразных вопросов о том, как достичь роста доходности компании. Принимаемые решения могут быть управленческого уровня:
• Какую сумму инвестировать в бизнес-направление и когда вложения окупятся?
• Сколько мы зарабатываем на продукте 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, заточенный под мониторинг сложных технологических систем, сельское хозяйство, мониторинг окружающей среды и многое другое.
Следствием такого развития, как в количественном, так и в качественном плане, стал ощутимый рост того объёма данных, который все эти устройства генерируют. Ну и что нам с ними делать? Давайте разберемся на примере геоданных!
Зачем вообще кому-то нужны геоданные?
