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-архитектурой:

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

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

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

Меня зовут Нина Фещенко, я работаю в команде аналитики продаж FTTB-FMC (или иначе – ШПД и конвергентных продуктов) Билайн. В данной статье мы рассмотрим прогнозирование продаж FTTB-FMC для целей ежедневной отчетности.  

Начнем с того, что мы понимаем под продажами ШПД и конвергенции. 

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

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

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

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

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

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