Data Engineering *

Обработка потоковых данных стала крайне важна в настоящее время. И на это есть веские причины, такие как:

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

Объемные неограниченные наборы данных, все чаще встречающиеся в современных бизнес процессах, могут быть легче обузданы применением систем, специально спроектированных для таких объемов информации

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

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

Как тот, кто работал над крупно‑масштабной системой потоковой обработки в Google на протяжении последний пяти с лишним лет (MillWheel, Cloud Dataflow), я, мягко говоря, в восторге от сложившихся тенденций. Я все также заинтересован в том, чтобы люди понимали, что именно системы потоковой обработки в состоянии выполнять, и как их использовать наилучшим образом, в частности, закрыв нехватку знаний, оставшуюся между существующими системами пакетной обработки и потоковыми. С этой целью замечательные ребята из O»Reilly пригласили меня предоставить письменную версию моего доклада «Say Goodbye to Batch» с конференции Strata + Hadoop World London 2015.

Привет, чемпионы! Сегодня рассмотрим, как облегчить себе жизнь, применяя 5 инструментов в своих проектах. Эти инструменты улучшат ваш код, сделают ваш pipeline более стабильным и позволят не писать один код по 10 раз. Круто? Погнали!

Привет, Хабр! На связи Александр Бобряков, техлид в команде МТС Аналитики. В предыдущих постах я рассказал, как собрать первое приложение Flink со Spring, реализовав пайплайн дедупликации сообщений Kafka-to-Kafka. В этом примере погружусь в использование таймеров в Flink, а в следующих статьях расскажу, как работать с более сложными состояниями, эволюционировать их схему и покрыть это все тестами.

Весь разбираемый исходный код есть в репозитории AlexanderBobryakov/flink-spring. В master-ветке представлен итоговый проект по всей серии. Эта статья соответствует релизной ветке с названием release/7_Trigger_Flink_Job.

Это восьмой материал из моей серии про Apache Flink. По мере выхода новых ссылки на них будут появляться ниже.

Последние пару лет не перестает сходить с первого плана вопрос импортозамещения софта ушедших вендоров. Мы занимаемся данными, поэтому и делимся опытом импортозамещения платформ данных у наших enterprise заказчиков.

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

Кстати, далеко не на последнем месте запрос команд разработки и поддержки на реализацию проектов на российском и open source технологическом стеке. Российский рынок вакансий на западном проприетарном вендорском ПО постепенно сужается, так как сейчас спрос российских компаний на такой софт стремится к нулю и такие системы постепенно превращаются в Legacy.

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

Разделим проблему на две части – подходящий апробированный технологический стек с формированием команды и сатисфакция бизнес-пользователей.

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

Меня зовут Петр. Я работаю инженером по данным в Okko и обожаю ClickHouse. 

Примерно в середине прошлого года мы начали переезжать с PostgreSQL на ClickHouse. Одной из главных причин переезда была низкая производительность: среднее время аналитического запроса составляло около минуты. Сейчас, после переезда, среднее время запроса в аналитическом кластере — около 2 с. И это не предел.

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

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

В этой статье не будет объяснений почему для переезда мы выбрали именно этот инструмент. Не будет и глубокой теории о его внутреннем устройстве. Отметим лишь: в правильных руках ClickHouse — одна из самых быстрых колоночных СУБД для OLAP запросов.

У нас было 4 нейросети, 2 опенсорсных датасета, 8 000 неразмеченных изображений, 5 333 аугментаций, 392 класса и 4 аккаунта на Roboflow. Не то, чтобы все это было категорически необходимо на проекте, но если уж начал анализировать телевизионное вещание, то к делу надо подходить серьезно. Единственное, что меня беспокоило — это Tesseract.

Привет, Хабр! Меня зовут Сергей Смирнов, я аналитик в продукте CVM в X5 Tech. Я занимаюсь разработкой инструмента анализа A/B экспериментов. Мы ежедневно считаем десятки метрик для сотен экспериментов на десятки миллионов клиентов –- это терабайты данных, поэтому наш инструмент разработан на Spark.

В последнее время мы заметили, что существенную часть времени работы наших Spark-приложений занимает обмен данными (Shuffle) между исполнителями. В этой статье я расскажу о том, какие оптимизации помогли нам избавиться от самых тяжёлых операций Shuffle. Речь пойдёт не только о BroadcastJoin, но и о двух других неочевидных методах – предварительное репартицирование и бакетирование.

Какими инструментами пользуются российские дата-инженеры в 2024-м? Как в реальности сравнить производительность Postgres и распределённых баз данных? Как строить RAG-системы, дающие нейросетям доступ к данным, которых не было в обучающей выборке? И как развивается сейчас космическая индустрия?

В сентябре мы проведём конференцию по дата-инжинирингу SmartData 2024. Сейчас её программа уже составлена полностью, и представляем её Хабру.

Привет, чемпионы!

AI решение, которые я разберу в этой статье - после запуска в телеграм привлекло почти органически внимание 70 000 новых пользователей за месяц, а всего было произведено 400 000 генераций. Разбираю, как реализовал сама ML модель. Погнали!

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

В этой статье я хочу показать как можно использовать Kafka в дата-инженерии и как её "пощупать".

Рекомендуется всем кто не знает что такое Kafka.

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

Вот тут-то и приходит на помощь наш добрый друг — Rust, а точнее его функции map, filter и fold. Они помогают не только приручить самых неугомонных data-котиков, но и сделать это без компромиссов по производительности.

Всем привет! На связи Business Intelligence GlowByte. Сегодня хотим поговорить о производительности системы бизнес-аналитики FineBI. Пару месяцев назад в нашем регулярном мероприятии FineTalks участвовали коллеги из ID360 и смотрели “под капот” FineBI 6.1. Хотим поделиться их инсайтами. Возможно, после сегодняшнего небольшого  “разбора” движка платформы вам тоже она понадобится. 🙂 Обращайтесь!

Вместе с Марией Жаровой, Data Scientist в Альфа-Банк, подготовили гайд по трансферному обучению.

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

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

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

Работа в современных реалиях требуют быстрой разработки и оценки моделей. Существует множество компонентов: изучение обучающих данных, обучение различных моделей, объединение обученных моделей в различные комбинации (ансамблирование) и т. д.

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

Именно здесь на помощь приходит W&B.

Всем читателям Хабра привет! На связи дата сайентисты стрима разработки моделей для корпоративного сегмента банка ВТБ — Андрей Бояренков, Иван Кондраков, Станислав Арешин и Андрей Трушин.

В этой статье мы хотим поговорить про конкретный кейс разработки процесса AutoML для моделей оценки вероятности дефолта клиентов (PD) в рамках экспресс-продуктов малого бизнеса. Расскажем, как выстроен наш процесс, как мы к этому пришли, с какими проблемами столкнулись, как их решили и как в дальнейшем планируем тиражировать на другие продукты банка.