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

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

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.

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

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 и другие функции.

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

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

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

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

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

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

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

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

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

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

Привет! В этом посте мы расскажем про то, почему вообще выбрали именно Zabbix для мониторинга, для чего его используем, и как решились обновиться сразу с версии 4.4 до 6.0.

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

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

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

Может ли хобби стать второй работой или это только про любовь? Заглянем через плечо в объектив наших фотографов и узнаем :)

Мария Сподина: «Я за живые эмоции!»

Привет! Меня зовут Сподина Мария, я аналитик SM Lab, занимаюсь внедрением механизмов и процессов, связанных с обеспечением НТП. В свободное время я увлекаюсь фотографией, о чем и хочу рассказать сегодня :)

Привет! Меня зовут Данил Глушков, я руководитель технической поддержки Плюса (Яндекс Фантех). В этом посте я расскажу вам о нашей работе. 

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

Для затравки — немного «до» и «после».

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

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

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

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

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

Меня зовут Александр Федюнин, я Product Lead команды интернет-магазина «Спортмастер» 3.0. В свободное время увлекаюсь водными видами спорта: катаюсь на вейкборде и занимаюсь дайвингом. И сегодня я хотел бы поделиться опытом освоения этих видов спорта, курьезными случаями и советами новичкам. 

Как я пришел к своим увлечениям

Можно сказать, что я водяной человек. Первое знакомство с большой водой случилось у меня в возрасте одного года, когда родители привезли на море, в Крым, где жили бабушка с дедушкой. И так со временем я научился сносно плавать. В 10–11 лет пошел в спортивную секцию по плаванию и дошел до первого взрослого разряда. Но в старшей школе карьера пловца застопорилась под влиянием двух факторов: я готовился к институту и мой замечательный тренер переехал в другой город.

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

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

Привет! Меня зовут Савва Степурин, я старший разработчик в группе рекомендательных продуктов в Фантехе Яндекса. Сегодня расскажу вам про то, как мы сделали «Незнакомое» для Моей волны — специальный режим для активного поиска музыкальных открытий.

«Незнакомое» позволяет вам получать от Моей волны те треки, которые вы ещё не слушали (возможно, даже не знаете про их существование), но которые с большой долей вероятности могут попасть в ваши музыкальные предпочтения. Если Моя волна в чистом виде — это идеальный баланс между любимыми композициями и чем-то новым, то «Незнакомое» помогает выйти из музыкального информационного пузыря и послушать новые треки. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Начнем.

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

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

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

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

Лирическое отступление. Дорогие читатели, мы продолжаем рассказывать о том, как работать в SM Lab! Ознакомьтесь с нашей предыдущей статьей, чтобы узнать больше о нашей культуре и принципах работы Как QA собеседование проходил. Следите за обновлениями, впереди еще много интересного!