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

Постоянное развитие сервисов для пользователей и конкуренция среди операторов предъявляет всё более высокие требования по скорости пакетной передачи данных и задержкам. Задача оптимизатора — максимально раскрыть потенциал имеющихся ресурсов и эффективно их использовать. 

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

Сеть билайна имеет в своем ресурсе свыше 100 тысяч элементов транспортной сети с 24 уникальными типами транспортных узлов. Управлять ими, проектировать и развивать их достаточно сложно и трудоемко. Чтобы упростить работу проектировщикам и другим пользователям сети, мы создали уникальный программный продукт, аналогов которому нет на рынке, TN Map — интерактивную карту, которая помогает визуально оценивать состояние сетей связи филиалов.

В статье подробно расскажем о функциях и внутреннем устройстве TN Map: разберем сценарии использования продукта и его отличительные особенности.

Пользовательский ввод

Результат генерации QR-кода

Привет! Как и обещала в первой части — теперь про ребалансировки и не только.

Выделяют безотлагательную и совместную ребалансировки. 

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

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

Всем привет! Сегодня расскажу про Confluent Kafka. Ее любят, ненавидят, но мало кто остается равнодушным.

О себе

Меня зовут Алена, я ведущий разработчик, занимаюсь развитием референсной архитектуры в компании билайн. К основным областям профессиональных интересов можно отнести проблемы распределенных систем, event sourcing и DDD.

В двух словах о Kafka

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

Привет, меня зовут Иван, и я зануда.

Сразу скажу, что в моем понимании зануда в тестировании — не тот человек, который всех достал и которого все хотят удушить, а тот, который умеет показать людям, что нужно делать хорошо и не делать плохо, и добиться от них этого. Я считаю, что QA должно расшифровываться как Quality Assistant. Это даже не про Assurance, когда вы обеспечиваете качество, это именно про то, что вы как тестировщик и участник команды помогаете на каждом этапе от требований до выкатки в прод и работы с сопровождением и вашими коллегами добиться того, чтобы каждый этап проходил все лучше и лучше.

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

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

Первая часть — здесь.

Data lineage

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

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

Всем привет! Меня зовут Дмитрий Ермилов, и сегодня я хочу рассказать про то, как мы в билайне использовали один data catalog-инструмент для того, чтобы построить прозрачные связи между моделями машинного обучения и признаками, от которых эти модели зависят, то есть от фич. Из доклада вы узнаете, зачем и кому это бывает нужно, а также один из способов решения этой задачи.

Для начала немного о себе. Я более десяти лет в разработке и анализе данных, имею научный бэкграунд, принимал участие в различных проектах от построения высоконагруженных сервисов с использованием моделей машинного обучения и глубоких нейронных сетей до построения корпоративных хранилищ данных и ETL-процессов. В настоящий момент работают в билайн, в дирекции билайн бизнес (Big Data&AI). 

Департамент DS состоит из двадцати специалистов. Билайн сегодня в первую очередь — технологичная компания, мы любим говорить, что мы технологичны снаружи и технологичны внутри. У нас трудится более 3500 IT-специалистов, более 200 продуктовых команд, которые разбиты на различные сегменты (внутренние продукты, продукты B2C, B2G и B2B). Дирекция Big Data&AI сфокусирована на B2B-сегменте, у нас 13 продуктовых команд, 200 IT-специалистов, это ML, DS, дата аналитики, фронт, бек, DevOps и другие функции.

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

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

Так же, как и Spark, Table API использует свой диалект SQL, который можно использовать над таблицами. Таблицу мы можем зарегистрировать в каталоге Table API и обращаться к ней с помощью SQL, используя команду Execute SQL. Все преобразования можно делать как обращаясь к таблице напрямую, через метод, так и при помощи SQL, то есть при помощи Select можно создать новую таблицу. Может запускаться как приложение, так и интерактивно SQL-запросами. То есть если у вас развернут Flink-кластер, то можно к нему подключиться при помощи Flink SQL, вбивать команды, создавать каталоги, подключаться к каталогам и проворачивать, например, батчевые SQL-запросы, которые перетягивать данные.

Главная фишка: источники и приемники могут создаваться и конфигурироваться при помощи DDL SQL.

Привет! Меня зовут Александр Булатов, я старший инженер данных в Блоке Данных билайна. В этой серии статей я расскажу, как выглядит создание Source и Sink для Table API & SQL и как Table API взаимодействует с DataStream API.

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

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

Так вот, мы принимаем данные в csv и должны их сохранять в Hive в колоночных форматах, чтобы впоследствии аналитики и Data Scientists могли пользоваться этими данными. У нас принято использовать либо ORC, либо Parquet. Мы попробовали оба формата, пришли к Parquet. 

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

В этом посте подойдем к проблеме пошире и начнем с архитектуры. Вот для примера довольно стандартная архитектура.

Большинство нормально структурированных приложений придерживается ее высокоуровнево, но на деле она вас не особо ограничивает. Есть много сходств со стандартной MVC-архитектурой:

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

Но в основном сначала получается та самая картина с балконом.

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

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

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

И в дополнение расскажу, как мы эту проблему решали в своем продукте. 

Но прежде всего давайте определим для чего нам это, в принципе, нужно.

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

В большой бренд билайна входят достаточно большое число юрлиц, такие как Вымпелком, Датафорт, который реализует публичное облако билайна, и другие. И мы поняли, что IT у нас абсолютно распределённая и существует во всех юрлицах, во всех подразделениях и во всех командах, которые внутри этих юридических лиц. И внутри Вымпелкома есть отдельное подразделение, которое  возглавляю я, в котором сосредоточена экспертиза DevOps, мы его называем "DevOps Governance".

Делим мы его на две части. 

Всем привет! Сегодня поговорим про дашборды — что это за инструмент такой и как с помощью него взаимодействовать с бизнесом.

Меня зовут Дарья Еськова, я аналитик данных в компании билайн. Если быть точнее, то в команде CLTV, лидирую направление автоматизации визуализации данных. Хочу поделиться с вами своим опытом и наработками. 

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

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

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

На сайте платформы по цифровой грамотности для детей и подростков с нарушениями зрения и моторики появился новый раздел — «Вебинары». Это очередное обновление платформы beelineforkids.ru. 

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

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

На сегодняшний день общее количество пользователей платформы составило более 58 тыс. человек, материалами курса воспользовались более 12 тыс. человек и более 10 тыс. участников полностью прошли курсы по цифровой грамотности.

Одним из героев наших вебинаров стал Владимир Васкевич. Будучи незрячим с самого детства, он посетил уже 30 стран и 75 регионов России. На вебинаре «Летим куда хотим» Владимир рассказал, как искать недорогие билеты, строить маршрут своего путешествия и что нужно учитывать, чтобы поймать самую выгодную цену, а на вебинаре «Дом вдали от дома» объяснил разницу сервисов для бронирования жилья и дал советы, как сэкономить.

Мы решили подробнее поговорить с Владимиром о его тяге исследовать этот мир, развиваться и наслаждаться жизнью, несмотря ни на что. В интервью 

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

Именно так произошло с Unix, который изначально был написан Кеном Томпсоном на языке ассемблера более пятидесяти лет назад. Первые версии Unix писались для платформы PDP-7, а для портирования его на PDP-11 нужно было переписывать код. Когда Дэннис Ритчи создал язык программирования C, и вместе с Томпсоном они переписали на нём основную часть кода Unix, внезапно оказалась возможной портируемость ПО. Тому были две главные причины. Во-первых, код, написанный на языке высокого уровня, не зависит от платформы, потому что компиляторы транслируют его в язык ассемблера целевой архитектуры. Это ещё важнее для целевых платформ на основе процессоров RISC, так как они требуют написания гораздо большего количества ассемблерных команд, чем процессоры CISC. Даже при портировании Unix на другую платформу основная сложность заключалась лишь в адаптации зависящих от архитектуры частей кода. С другой стороны, сама операционная система абстрагирует все особенности оборудования от пользовательской программы.

Программистам не нужно реализовывать многозадачность, управление памятью и драйверы для используемых ими устройств, потому что всё это часть ядра ОС и работает в адресном пространстве ядра. Пользовательские программы работают в пользовательском адресном пространстве и получают доступ ко всем предоставляемым ОС функциям при помощи интерфейса системных вызовов. В ОС реального времени, например, в Zephyr OS ситуация немного отличается, но принцип изоляции и защиты памяти для пользовательских программ сохраняется. Это приводит к двум выводам:

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

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

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

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