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

Кому пришла в голову идея отправлять SQL запросы в data lake? Оказывается, это позволяет компаниям более гибко и эффективно анализировать свои данные за счёт уменьшения потребности в ETL и снижения нагрузки на корпоративное хранилище. Рассмотрим, какие популярные SQL-движки умеют это делать и как им это удаётся.

Меня зовут Владимир Озеров, я руковожу компанией Querify Labs. Мы уже порядка 10 лет занимаемся распределённым SQL, делаем всевозможные SQL-движки, в частности CedrusData — коммерческий движок на основе опенсорс проекта Trino. Сегодня поговорим про то, каким образом устроен ряд SQL-движков, которые обрабатывают данные от data lake.

По образованию я инженер разгонных блоков и космических аппаратов, и погружение в производство началось еще в институте. Меня учили разрабатывать ракеты и спутники. А дальше оказалось, что в России это крайне малооплачиваемая отрасль. В итоге хобби админство в институте, стало работой, но знания полученные в ходе обучения очень помогают в текущих задачах. В производстве у меня было много проектов. Я реализовывал системы по техосмотрам и ремонтам в энергетике, участвовал в проектах на Уралхиммаше и на Дальневосточных распредсетях и много где ещё. Был даже опыт управления командой на рынке оптовых продаж электроэнергии России. А потом друзья позвали присоединиться к команде цифровизации в СИБУР.

Меня зовут Максим Горозий. Я тимлид в Т-Банке, работаю над нашей образовательной платформой, которая служит для разных направлений бизнеса. В ИТ больше 10 лет и успел поработать в двух GameDev-компаниях, где управление памятью занимало весомое время в оптимизации производительности кода. Люблю строить системы и взаимосвязи между ними, а также EdTech и преподавание, а еще больше — работать над инструментами обучения. Хотя начинал с C, я идеологический фанат Go, DDD и Agile.

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

В прошлой статье мы начали историю создания одного из компонентов платформы экспериментов в компании Okko — сервис сплитования трафика.

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

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

Привет, Хабр! Это Александр Капитанов и Александр Нагаев из Sber Devices. Мы занимаемся задачами компьютерного зрения: генерацией, матированием и редактированием изображений, сегментацией, портретной гармонизацией, заменой лиц, распознаванием жестов. А с недавних пор ещё и распознаваниtv русского жестового языка.

Поговорим о том, что заставило нас решать данную проблему. Затронем теорию жестового языка — подозреваю, что мало кто с ней знаком. Расскажем, как мы собирали собственный датасет для распознавания русского жестового языка и затронем тему обучения моделей для решения данной задачи. Также поделимся с вами результатом и немного расскажем про семейство наших моделей signflow. 

Всё началось в 2018 году, я сопровождал и развивал проекты американских стартапов из реальной отрасли экономики. Потом меня пригласили в крупнейший в России ритейл запчастей. Там было 250 СТО, 120 городов и 150 складов. Это были реальные склады, реальные продукты, реальные люди. Всё это мы сопровождали командой в 20 человек, и я понял, что объёмы — это интересно. Но в ритейле, в отличие от промышленности, очень короткий горизонт планирования. Я быстро достиг стеклянного потолка и понял, что надо двигаться дальше.

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

Когда-то я работал системным инженером в одном из крупнейших российских системных интеграторов. Там внедрял и сопровождал системы электронного документооборота. В 2010 году «Гринатом» искал специалиста с моим опытом, чтобы сопровождать свою отраслевую систему документооборота. Мне понравились условия и возможность развивать новые продукты фактически с нуля, и я согласился. С тех пор работаю там, и за 14 лет работы развитие не останавливается. Растёт мое подразделение, и внедряемые технологии, и компетенции. Мы постоянно привносим новые решения, и это не останавливающееся движение очень мотивирует.

Привет, Хабр! Меня зовут Ирина Николаева и я — руководитель R’n’D отдела машинного обучения в компании Raft Digital Solution. Я внедряла различные ML-модели: от анализа временных рядов и Computer Vision до высоконагруженных дата-инженерных сервисов. Эта статья написана по мотивам моего доклада на Highload ++ 2023.
В статье вас ждёт: обзор LLM-моделей, техники работы с ними через призму MLOps, разбор лицензий и требований к железу. А так же трюки с квантизацией и файн-тюнингом «на сладкое». Главный дисклеймер статьи в том, что данные лидербордов и технических требований актуальны на момент выступления на Highload, то есть ноябрь 2023, но не всё из них актуально до сих пор. Но если бы я обновила всю статью, была ли бы это та же самая статья — вопрос риторический, поэтому было принято решение оставить всё как есть.

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

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

Если говорить про кофе, то он есть))

Работа в Яндексе ставит огромное количество технических вызовов, которые интересно решать. И один из них — это производительность основной очереди сообщений YDB Topics. Посмотрим, может ли опенсорсный продукт от Яндекса конкурировать с Apache Kafka по производительности.

Меня зовут Зевайкин Александр. Я уже практически 20 лет в IT. Начинал с преподавания в вузе, запускал множество стартапов, руководил командами разработки. В текущий момент я работаю в Яндексе в отделе, занимающимся одной из высоконагруженных систем. Это разработка распределённой базы YDB, в частности, функциональности YDB Topic.

Разработчики, которые используют Go, сталкиваются с задачей выжать максимальную производительность из каждой строки кода. Но что делать, если оптимизировать уже нечего, а увеличивать скорость всё равно надо?

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

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

Меня зовут Константин, я работаю в Газпромбанке. Занимаюсь транзакционными системами: платежами, переводами, также участвовал в разработке системы СБП в Газпромбанке. В своей практике столкнулся с десятками языков программирования, но в настоящий момент остановился на Java и Kotlin. Поэтому я буду рассказывать про проблемы backend разработки на этих языках.

Привет, Хабр! Меня зовут Георгий Меликов, я из VK Cloud и руковожу там инфраструктурной разработкой (IaaS) облака, где мы создаём SDN (Software Defined Networks) — программно определяемые сети; SDS (Software Defined Storages) — программно определяемые хранилища; и другие решения.

А ещё на досуге я — контрибьютор файловой системы OpenZFS с 2016 года.

В этой статье поговорим о наших подходах к разработке на примере создания нашего SDN. Мы ставим перед собой несколько целей:

1) Разрабатывать быстро, чтобы итерации были явно очерченными  и понятными. Хотим, чтобы у нас вырабатывался дофамин от закрытия спринтов, и было понятно, как жить дальше.

2) Эксплуатировать системы без людей — полностью автоматически.

3) Использовать принцип «Дизайн на отказ». Система должна уметь переживать любой возможный сбой и проблему, т.е.обладать так называемым качеством самовосстановления (self-healing).

Предлагаю пройтись эволюционно от простого примера "облака на минималках" до нашей production среды на несколько ЦОДов, собрав по пути проблемы из нашей реальной жизни.

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

Много интересных кейсов связано с применением ИИ. Например, интеллектуальная видеоаналитика для оценки процента шлака в ковше и качества заготовки. С помощью ИИ нам удалось достичь точности 99,98% и низкого показателя ложных срабатываний. Нейросеть пропускает брак лишь в 0,02% случаев. Конечно, благодаря этому качество продукта выросло. Кроме того, мы получили объективный инструмент анализа. Система помогает человеку обнаружить отклонения и подсказывает об этом своевременно, что повышает выход годного. Если одна за другой идут бракованные заготовки, значит, где-то на предыдущем этапе нарушен техпроцесс, и коллегам нужно об этом сообщить.

Привет, Хабр. Меня зовут Владимир Утратенко, я — Head of Infrastructure and Security в Uzum Market. У меня богатый опыт найма DevOps-инженеров, ведь последние 6 лет я — нанимающий менеджер. А ещё много лет подряд занимаюсь DevOps как моделью разработки. Сегодня мы поговорим про боли в CI/CD, которые часто упускают из вида DevOps-специалисты, лиды и CTO.

Миграция СУБД с одной технологии на другую — сложный процесс, который связан не только с конвертацией кода и переливкой данных из одной системы в другую, хотя и здесь есть неочевидные нюансы. Это часто и вопросы, связанные с совместимостью функциональности, производительностью, безопасностью данных, архитектурными особенностями новой системы и многими другими аспектами.

Меня зовут Станислав Свириденко и я DWH-разработчик AXENIX. В этой статье хочу рассказать об опыте миграции витрины данных с проприетарной СУБД Teradata на свободную СУБД GreenPlum. Поговорим о задачах, подводных камнях, на которые мы периодически натыкались, и способах решений, найденных  в процессе.

У нас производство с небольшой город, и целая куча направлений: одно подразделение собирает роботов, другое занимается видеоаналитикой, кто-то делает лайтовый анализ данных, а кто-то шаманит с хардкорными дата-сетами. Работы всегда больше, чем рук. С точки зрения IT у нас большая ERP-система. Там крутятся закупки, планы производства, CRM, заказы, поставки и тому подобное. ERP отправляет запрос в MES, систему управления производством, которая формирует задания для смен. MES соединена с АСУТП, которая автоматизирует всё, вплоть до правильного раскроя металла. Далее контроллеры, исполнительные механизмы и датчики. Вокруг этого автоматизация кадров, электронные журналы и прогнозы спроса. Поэтому куда сейчас без IT? IT везде. Никто уже на бумажках работать не хочет и не может. И металл без IT не плавится. Чем сложнее установка, тем больше IT внутри.

Привет, Хабр! На связи программный комитет FrontendConf. Расскажем, как мы составляем программу нашей конференции и боремся за её актуальность — проводим исследования и общаемся с аудиторией.

FrontendConf = доклады + общение + опыт

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