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

Давайте начнем с краткого обзора рынка антиспам-услуг.

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

Плюсы и минусы

Какие у нас есть сильные стороны?

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

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

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

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

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

Всем привет. Сегодня я хочу рассказать о том, как мы прошли наш путь от хаоса к нашим 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 ситуация немного отличается, но принцип изоляции и защиты памяти для пользовательских программ сохраняется. Это приводит к двум выводам:

У нас есть прекрасно работающая стандартная конфигурация серверов. RAID1 для системных дисков, 2 карты по два 25Гб/с порта под сеть. Итого 100 Гб/с, которые мы научились выжимать в предыдущей заметке про iScsi (https://habr.com/ru/companies/beeline_tech/articles/821855/) под цели СУБД.

В то же время сетевое оборудование, расположенное между сервером и СХД, может значительно больше, чем 100Гб/c, как и СХД. Поэтому захотелось посмотреть, можно ли выжать на стороне сервера 200Гб/c

! Спойлер: Можно, но вы этого не захотите.

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

Дифференциальный диагноз почечно-клеточной карциномы

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

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

Об одном таком направлении мы (команда ИИ и BigData в билайне) и расскажем в этом посте, а именно о том, как при помощи ИИ и цифровой патологии можно значительно расширить классические возможности лечения рака почки.

Под катом будет много врачебных терминов, но без этого никак.

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

Мы - это команда билайна: Александр Арутюнян и Виктор Гринин.

И наши коллеги-ученые из Сеченовки: Елена Иванова, Алексей Файзуллин, Пётр Тимашов и Анатолий Шехтер. 

Начнем.

На хабре переодически появляются статьи про библиотеки для построение своего WYSIWYG редактора. Такая потребность появилась и в моей команде - «билайн дом», для создания новостей. В этой статье взглянем на них более общим взглядом и дополнительно разберем библиотеку LexicalJs. 

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

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

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

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

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

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

Я даже предположил, что Elm MVU — это тот путь, который данные потребности закроет.

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

Под словом «естественный» я подразумеваю нечто, что коррелирует с языком, который мы используем в повседневной жизни. Функциональное программирование не всегда можно описать таким языком (например, несмотря на то, что монады, включая Observable streams, являются относительно простым понятием, мы вряд ли сможем выразить это понятие на таком языке). Я убедился, что программирование, которое лучше коррелирует с естественным языком — это многопарадигменное программирование, где вещи не строго OOP и не строго функциональны, а то или другое в зависимости от ясности и удобства работы.

После тестирования NVME over TCP, описанной тут https://habr.com/ru/companies/beeline_tech/articles/770174/, решили проверить, насколько хорошо iScsi в L3-сети работает по сравнение со специализированным решение на FC.

Настройки iScsi

TL/DR

Машина в Bios переведена на профиль HPC (был пустой).

На уровне OS и iscsid сделаны такие изменения

Привет. Меня зовут Николай Шувалов, я занимаюсь коммерческим программированием около семи лет, владею Rust, JavaScript, PHP. Сейчас я работаю в отделе данных билайна. Наша платформа позволяет делиться с партнерами данными, не раскрывая их. Например, можно расширить данные с помощью фильтра Блума. 

Arrow в сравнении со строковыми форматами

Возьмём простую таблицу, которая состоит из трех столбцов: телефона, даты и имени. Рассмотрим, как она будет выглядеть в строковом и столбчатом форматах. Для строкового формата мы возьмем csv и json, для столбчатого формата структура будет одинаковой. Если же таблица состоит, например, из миллиона строк, а нужно получить имя на строке с номером 10 000, то придется бежать по всей строчке. В json то же самое. А в столбчатом формате ситуация иная — значения привязаны к столбцам. Когда мы хотим получить имя на строке 10 000, то сразу обращаемся к этому столбцу и получаем все его данные. 

Существуют RA (random access) файлы, в которых можно пропускать заданное количество строк, но все равно парсеру нужно читать и анализировать пройденные строчки.

Привет, Хабр! Меня зовут Сергей Евсеев, сегодня я расскажу, как в Apache NiFi настраивается ETL-пайплайн на задаче с JSON’ами. В этом мне помогут инструменты Jolt и Avro. Пост пригодится новичкам и тем, кто выбирает инструмент для решения схожей задачи.

Что делает наша команда

Команда работает с данными по рекрутингу — с любой аналитикой, которая необходима персоналу подбора сотрудников. У нас есть различные внешние или внутренние источники, из которых с помощью NiFi или Apache Spark мы забираем данные и складируем к себе в хранилище (по умолчанию Hive, но есть еще PostgreSQL и ClickHouse). Этими же инструментами мы можем брать данные из хранилищ, создавать витрины и складывать обратно, предоставлять данные внутренним клиентам или делать дашборды и давать визуализацию.

Описание задачи

У нас есть внешний сервис, на котором рекрутеры работают с подбором. Сервис может отдавать данные через свою API, а мы эти данные можем загружать и складировать в хранилище. После загрузки у нас появляется возможность отдавать данные другим командам или работать с ними самим. Итак, пришла задача — нужно загрузить через API наши данные. Дали документацию для загрузки, поехали. Идем в NiFi, создаем пайплайн для запросов к API, их трансформации и складывания в Hive. Пайплайн начинает падать, приходится посидеть, почитать документацию. Чего-то не хватает, JSON-ы идут не те, возникают сложности, которые нужно разобрать и решить.

Ответы приходят в формате JSON. Документации достаточно для начала загрузки, но для полного понимания структуры и содержимого ответа — маловато. 

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

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

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

Давайте представим, что у вас в компании большое количество моделей машинного обучения, каждая из которой может зависеть от нескольких десятков до нескольких тысяч признаков (фич). Причем разные модели могут зависеть от одних и тех же фич. Неожиданно случается несчастье, и одна из популярных фич ломается. Может произойти поломка на уровне подготовки данных, могут измениться внешние источники, отвалиться интеграции и прочее. Что делать с этим знанием? Конечно, бежать в продуктовые команды и кричать, что модели, которые зависят от этой фичи, могут деградировать, то есть их метрики качества могут снизиться. Вопрос только в том, какие модели могут деградировать и в какие команды бежать?

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

Привет! Меня зовут Андрей Чучалов, я работаю в билайне, и в этом посте я расскажу про оптимизацию параметров запуска приложений в Spark, поиск проблем и повышение производительности. Разберем запуск приложений Spark в базовой и расширенной версиях, покажу методы расчёта основных параметров работы приложения для производительности и эффективности использования доступных ресурсов кластера. Бонусом — о том, как всё это привязано к деньгам, и где сэкономить можно, а где — не стоит.

Для чего это вообще нужно

Спараметризировать приложение — это не такая уж грандиозная задача, а вот попытаться понять взаимосвязь эффективности работы приложения со стоимостными параметрами такой работы — это уже сложнее. Тут вам пригодится своеобразное «боковое зрение».

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

Эта статья описывает, как из прогнозов ряда ML-моделей получить ценность клиента с горизонтом в 5 лет. Напомним, что показатель CLTV представляет из себя композицию прогнозов ее компонент (подробнее в статье). В нашей реализации максимальный период прогнозирования моделей - 24 месяца. Важно отметить, что чем выше горизонт прогнозирования, тем менее точный прогноз способна сделать модель. А показатель CLTV интересен бизнесу на более длинном горизонте, в нашем случае - пять лет. Как же из прогнозов на два года получить прогноз на пять лет? Ответ прост: экстраполировать прогнозы.

Основная идея продления (экстраполяции) прогнозов - это разбиение пользователей на несколько групп, а в каждой группе единообразно продлить ряд прогноза. 

Далее мы обсудим:

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

Всем привет! Меня зовут Владимир Земсков, я работаю в B2C билайна, в команде билайн Про, где пишу бэк-офис для нашей системы. Мы помогаем нашей рознице продавать лучше и больше. Для соблюдения нужного уровня качества кода в билайне мы используем и ESlint, и тесты, и ревью, и особый тип — внутренние договорённости. 

Когда я пришёл в компанию, то мне захотелось найти ESlint-плагин, который бы помог автоматизировать часть работы. Я поискал, не нашёл, и в итоге решил написать свой. Из всей этой истории и родился сегодняшний рассказ. В первой части мы обсудим договорённости и их важность для разработки. А во второй — поговорим про то, как эти договорённости переносить в ESLint, как это упростит жизнь и действительно ли это это так сложно, или можно что-то упростить по пути.