В середине 2000 я купил Psion 3c для коллекции. Лет через 10 увидел, что его комплектный диск называется SSD — Solid State Disk. На волне тестирования NVME возникла идея, а не протестировать ли скорость SSD-1993? И спустя 20 лет после покупки на этой машинке была написана первая программка.
Разработчики часто сталкиваются с задачами, в которых одна функция должна работать с разными типами данных и количеством аргументов. Чтобы каждый раз не создавать множество функций с разными именами, существует перегрузка (overload). Она позволяет использовать одно имя операции для обработки различных комбинаций входных данных. Благодаря перегрузке одна функция может адаптироваться под различные сценарии и делать код лаконичным и понятным.
В статье разберемся, как работает перегрузка в статических и динамических языках программирования. В конце покажу, как и зачем мы реализовали перегрузку на Python своим собственным способом.
Так повелось, что по итогам своих опытов с различными технологиями подключения дискового пространства писал сюда небольшие заметки:
Попытка разогнать сеть для БД со 100 до 200Гб/c или «failure is always an option».
Настройка iScsi в L3-сети для эффективной утилизации возможностей канала и СХД.
Поскольку появился новый свежий опыт по настройке и тестированию подключения еще одним способом, и все уже собрано для внутренней wiki-статьи, решил продолжить традицию.
Сеть билайна имеет в своем ресурсе свыше 100 тысяч элементов транспортной сети с 24 уникальными типами транспортных узлов. Управлять ими, проектировать и развивать их достаточно сложно и трудоемко. Чтобы упростить работу проектировщикам и другим пользователям сети, мы создали уникальный программный продукт, аналогов которому нет на рынке, TN Map — интерактивную карту, которая помогает визуально оценивать состояние сетей связи филиалов.
В статье подробно расскажем о функциях и внутреннем устройстве TN Map: разберем сценарии использования продукта и его отличительные особенности.
У билайна есть разношерстный парк Unix-серверов: это AIX, Solaris, где-то есть даже HPUX на итаниуме. Они достаточно надежны, но так как они начали эксплуатироваться давно, вероятность их выхода из строя по мере расходования запаса надежности увеличивается. Часто на таких серверах работают критичные программные продукты, а данные с них хранятся на системах хранения данных (СХД), которые тоже не молодеют.
Сервера питаются электричеством, которое, хотя и резервируется, иногда может дать нестандартный вольтаж, определив который системы защиты обесточат оборудование. Еще возможен внезапный глюк системного софта, например, дисковой подсистемы.
В общем, мы знаем, что если что-то может пойти не так, оно обязательно когда-нибудь так сделает. Для таких случаев у нас есть планы действий в аварийных ситуациях, которые значительно отличаются от типичного плана из интернета. В этой статье расскажу, как мы их разработали и какие корректирующие действия предусмотрены в аварийно-восстановительных работах (АВР).
Эта статья была написана для конкурса Технотекст-7 «Тот момент, когда происходит изменение». Тема адаптации UI к меняющимся деталям была выбрана, так как связана с темой конкурса.
Современная UI-разработка живет быстрыми темпами. Мы постоянно создаем и меняем код, чтобы соответствовать новым трендам, но часто это делается «на коленке» и без долгосрочного видения. В итоге уже через пару месяцев все, что казалось суперсовременным, превращается в легаси из-за смены моды фреймворков и других деталей реализации.
В статье расскажу, почему традиционное долгосрочное планирование уже не работает, как можно отделить основную логику от конкретных технологий и какие инструменты помогут быть более гибкими в будущем.
Привет! Как и обещала в первой части — теперь про ребалансировки и не только.
Выделяют безотлагательную и совместную ребалансировки.
При безотлагательной ребалансировке пользователи прекращают потребление из партиции, которые им назначены, затем отказываются от права владеть этими партициями, после снова присоединяются к consume group, получают совершенно новое назначение партиций и после этого возобновляют потребление. По сути, это короткое окно недоступности для всей consume group. Длина этого окна зависит от количества пользователей и некоторых параметров конфигурации.
Совместная ребалансировка - это инкрементная ребалансировка, при которой переназначается лишь некоторое подмножество партиций, и пользователи продолжают потребление из тех партиций, которые не были переназначены. Координатор уведомляет пользователей, что они должны будут отказаться от права владения некоторым подмножеством партиций, они прекращают потребление и отказываются от права владения. Затем эти партиции назначаются новым владельцам. Подход может включать несколько итераций, пока не будет достигнуто равномерное распределение. В отличие от безотлагательного подхода, мы не получаем полной недоступности. Это важно для больших consume groups, где балансировка может занять значительное количество времени.
Всем привет! Сегодня расскажу про Confluent Kafka. Ее любят, ненавидят, но мало кто остается равнодушным.
О себе
Меня зовут Алена, я ведущий разработчик, занимаюсь развитием референсной архитектуры в компании билайн. К основным областям профессиональных интересов можно отнести проблемы распределенных систем, event sourcing и DDD.
В двух словах о Kafka
Kafka - это распределенная платформа для обработки потоков данных, которая используется для построения высоконагруженных решений и обработки данных в реальном времени. По сути, это система, которая может очень быстро и эффективно передавать ваши события. Kafka может работать как на одной машине, так и на нескольких, образующих между собой кластер и повышающих общую эффективность системы. Событием в Kafka может быть любой тип данных, для Kafka это всего лишь последовательность байт. На картинке представлены сущности, которые участвуют в процессе работы с точки зрения архитектуры.
Привет, меня зовут Иван, и я зануда.
Сразу скажу, что в моем понимании зануда в тестировании — не тот человек, который всех достал и которого все хотят удушить, а тот, который умеет показать людям, что нужно делать хорошо и не делать плохо, и добиться от них этого. Я считаю, что QA должно расшифровываться как Quality Assistant. Это даже не про Assurance, когда вы обеспечиваете качество, это именно про то, что вы как тестировщик и участник команды помогаете на каждом этапе от требований до выкатки в прод и работы с сопровождением и вашими коллегами добиться того, чтобы каждый этап проходил все лучше и лучше.
В тестировании я уже семь лет, для кого-то это маленький срок, для кого-то — большой, я очень впечатлен коллегами, которые работают уже по 15-20 лет, но развиваюсь, стараюсь нести добро в массы. Одна из моих основных специализаций заключается в том, что я прихожу на проекты, которые начинаются с большой бизнес-идеи, движущейся через много команд. Мне нравятся все вопросы межкомандного тестирования, интеграционного взаимодействия, выстраивания стендов, как драйвить коллег, чтобы мы двигались в одном направлении и не словили на проде кучу ошибок — этим я и занимаюсь.
В связи с этим я часто замечаю, что многие команды и коллеги приходят на интеграционные стенды, мы выкатываемся на те стенды, где начинают работать настоящие сервисы на тестовых средах. Я у коллег вижу такие банальные ошибки, которые нельзя было бы пропустить, если бы мы тестировались изолированно на каком-то отдельном кусочке, проверяя свои интеграции еще до поездки на тестовый стенд. Естественно, чем позже мы находим ошибку, тем больше стоимость ее исправления, поэтому нам нужны моки, чтобы мы все это проверяли.
Наша команда Unix — распределённая: коллеги работают из Санкт Петербурга, Воронежа, Москвы, Ярославля, Нижнего Новгорода, Архангельска, Ижевска и Владивостока. Чтобы коммуникация была комфортной, система организации онлайн-конференций должна хорошо и быстро работать на звонках 1:1 и командных встречах разного размера.
Рабочие места у команды организованы на mac/linux/windows/vdi-windows/vdi-linux. Выбирали отечественное решение для онлайн-встреч из нескольких вариантов — некоторые из них до сих пор используются в разных командах и находятся на стадии испытаний. Нам достался Контур Толк, или ktalk.
Если после стресс-испытаний для NVME дисков или сети принято делиться опытом, почему бы мне не рассказать про использование программного продукта? В статье будет пользовательский опыт команды Unix и немного внутренней кухни про предотвращение и устранение сбоев.
Первая часть — здесь.
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 и другие функции.
Спектр продуктов широкий - от платформы видеоаналитики и системы транскрибации и анализа речи до классических продуктов в области банковского скоринга. Мы любим машинное обучение, и это взаимно.
Привет! Продолжаю знакомить вас с библиотекой Prophet в качестве инстурмента прогнозирования продаж. Первая часть тут.
Функции для критериев качества в нашей прогнозной модели будут выглядеть следующим образом:
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 для целей ежедневной отчетности.
Начнем с того, что мы понимаем под продажами ШПД и конвергенции.
