Рассказываем, какие задачи решают оркестраторы в проектах внедрения корпоративных хранилищ данных. Выясняем, в чем разница между инструментами, и почему Dagster становится все популярнее в DWH-проектах, чем Airflow.
В стриминговых пайплайнах всё чаще приходится иметь дело не только с бесконечным потоком данных, но и с состоянием, которое нужно хранить и восстанавливать без потерь. С выходом Spark 3.2 у разработчиков появилась возможность подключать RocksDB в качестве state store — и это открывает новые горизонты для работы с большими объёмами данных. В статье разбираем, как использовать этот подход на практике: от борьбы с дубликатами и пропущенными событиями до тонкостей конфигурации и устойчивости стриминга.
Привет, Хабр! Наверняка вы помните успех онлайн-школ во время пандемии — тогда каждый или кого-то учил, или чему-то учился. Однако за пять лет технологии шагнули вперед, а EdTech остался на том же уровне — и это привело к упадку. Зачем платить за курс, если нейросеть может научить чему угодно бесплатно (хоть к качеству обучения и возникают очевидные вопросики)?
В онлайн-школе IBLS смогли превратить ML из конкурента в союзника, и с его помощью осовременить процесс обучения для всех участников. Как это получилось — рассказываю под катом.
Формула-1 всегда была местом пересечения инженерии и инноваций. В последние годы эта область инноваций расширилась за счёт внедрения искусственного интеллекта и машинного обучения.
От стратегии по выбору шин до аэродинамического дизайна — эти технологии меняют то, как команды планируют работу, реагируют на вызовы и развиваются. Они не заменяют человеческих специалистов, принимающих решения, но трансформируют набор инструментов, с которыми ведут борьбу за результат.
Привет, Habr! Меня зовут Катя, я продакт-менеджер BigData в «Группе Лента» и отвечаю за развитие цифровых продуктов в направлении монетизации данных. В статье расскажу, как нам удалось уйти от Excel-файлов и ручного согласования сегментов к автоматизированному порталу, с помощью которого рекламные агентства теперь сами собирают нужные им сегменты и выгружают их в MyTarget.
Привет, Хабр!
Сегодня разберём фичу из PySpark — UDTF. Если раньше мы писали UDF и UDAF, то UDTF — это про функцию, которая запускается в секции FROM запроса и возвращает как бы несколько строк для каждой входной записи. Звучит круто.
UDTFs пригодятся, когда на один входной объект нужно получить множество выходных строк. Простой пример: у нас есть строка текста и мы хотим разделить её на слова так, чтобы каждое слово вышло отдельной строкой. Со стандартным UDF такое не сделать (он возвращает одно значение, например конкатенацию или длину). Но UDTF может делать цикл yield внутри и выдавать сколько угодно строк. Итак, приступим к делу.
Ivory — это бесплатный open-source инструмент с веб-интерфейсом, созданный для управления кластерами PostgreSQL, которые работают под контролем Patroni. Если раньше для таких задач приходилось использовать командную строку или Patroni API, то с Ivory всё можно делать через удобный браузерный интерфейс.
Цель проекта — упростить жизнь администраторам баз данных (DBA) и разработчикам:
tl;dr. Мы изучаем сублиминальное обучение — неожиданное явление, при котором языковые модели перенимают свойства из данных, сгенерированных другой моделью, даже если эти данные семантически никак не связаны с передаваемыми свойствами. Например, «студент» начинает предпочитать сов, если его обучить на последовательностях чисел, сгенерированных «учителем», который предпочитает сов. Тот же феномен способен передавать misalignment через данные, которые выглядят абсолютно безобидными. Этот эффект проявляется только в том случае, если учитель и студент основаны на одной и той же базовой модели.
Исследование проведено в рамках программы Anthropic Fellows. Эта статья также опубликована в блоге Anthropic Alignment Science.
Привет, хабр! 👋
Позвольте представиться: я - Настя, Data Scientist и TeamLead в одной вполне себе серьезной компании (когда чистишь данные в 3 ночи, чувствуешь себя совсем не серьезно, но это детали). Веду свой скромный телеграм-канальчик, где делюсь болью, радостью и абсурдом нашей необъятной профессии. И вот сегодня хочу вынести на ваш суд тему, которая не дает спать спокойно не только мне, но и многим моим коллегам.
Помните тот трепетный момент, когда вы только начинали свой путь в Data Science? Я — очень хорошо. Картинка была радужной: ты — повелитель нейросетей, твои модели творят магию, а бизнес-задачи падают к ногам, поверженные точностью в 99.9% (ну или хотя бы 97%).
Курсы, будь то знаменитые онлайн-платформы или университетские программы, учат нас прекрасному: бустинги, метрики, градиентный спуск, SVM, k-means, сверточные слои... Это наш фундамент, наш джентельменский набор. И да, именно за этим набором охотятся 90% рекрутеров на собеседованиях. Создается стойкое ощущение, что я и интервьюер одновременно загуглили «Топ-50 вопросов на DS собеседовании» и теперь ритуально их отрабатываем. Ну, must have, что уж тут.
Но потом ты выходишь из уютного мира clean data и идеальных датасетов в дикие джунгли реального проекта. И здесь начинается магия настоящей работы. Та самая, про которую не снимают вдохновляющие ролики. А порой многие именно тут и бросают этот, казалось бы увлекательный и перспективный карьерный путь в мир ML...
Всем привет! Меня зовут Мурад Арфанян, я разработчик информационных систем в Ozon Tech. Наша команда работает с данными жизненного цикла товаров в логистике. Объём продаж растет стремительными темпами и нешардированный ClickHouse уже не справляется с постоянно увеличивающимися потоками данных. Чтобы решить эту задачу, мы построили шардированный кластер, преодолев на пути несколько интересных технических вызовов. В этой статье я расскажу о нашем опыте и решениях, которые помогли масштабировать систему и обеспечить стабильную работу при росте нагрузки.
Помните старую поговорку про семь раз отмерь? В мире AI-кодинга она обрела новый смысл.
Сегодня расскажу о практике AI-Driven разработки (AIDD), которую мы у себя в команде ежедневно применяем для разработки ИИ-решений. Она успешно зарекомендовала себя в различных проектах и задачах — будь то стартапы или легаси, приложения на Python, Java или даже 1C.
Разбирать методику будем в AI редакторе Cursor, но повторить ее вы сможете в любом кодовом ассистенте. Поехали...
В самом начале проекта Manus перед нашей командой встал ключевой вопрос: обучать ли end-to-end агентную модель, используя open-source foundation-модели, или же строить агента поверх возможностей in-context learning у frontier models?
В моё первое десятилетие в NLP у нас и выбора-то такого не было. В далёкие времена BERT (да, прошло уже семь лет) модели приходилось fine-tune'ить и тестировать, прежде чем они могли переноситься на новую задачу. Этот процесс часто занимал недели на одну итерацию, даже при том, что тогдашние модели были крошечными по сравнению с сегодняшними LLM. Для быстроразвивающихся приложений, особенно на этапе до PMF, такие медленные циклы обратной связи — смертный приговор. Это был горький урок из моего прошлого стартапа, где я обучал модели с нуля для open information extraction и семантического поиска. А потом появились GPT-3 и Flan-T5, и мои внутренние модели стали не актуальны буквально за ночь. Ирония в том, что именно эти модели положили начало in-context learning — и открыли совершенно новый путь развития.
Из этого болезненного опыта выбор был очевиден: Manus делает ставку на context engineering. Это позволяет выпускать улучшения за часы, а не за недели, и держит наш продукт ортогональным по отношению к базовым моделям: если прогресс моделей — это прилив, то мы хотим, чтобы Manus был лодкой, а не сваей, вбитой в морское дно.
Тем не менее context engineering оказался далеко не тривиальным делом. Это экспериментальная наука — и мы перестраивали наш агентный фреймворк четыре раза, каждый раз находя более удачный способ формировать контекст. Мы с любовью называем этот ручной процесс перебора архитектур, подбора промптов и эмпирических догадок «Stochastic Graduate Descent». Это не изящно, но работает.
В этом посте я делюсь локальными оптимумами, к которым мы пришли через собственный «SGD». Если вы создаете своего AI-агента, надеюсь, эти принципы помогут вам сойтись к решению быстрее.
Привет, Хабр! Я Станислав Габдулгазиев, архитектор департамента поддержки продаж Arenadata. Кажется, ещё вчера мы радовались возможностям Apache Spark 3.0, разбирались с Adaptive Query Execution и наслаждались улучшениями Pandas API. Но мир больших данных не стоит на месте, и вот уже на подходе Apache Spark 4.0. Новый мажорный релиз — это всегда событие: он обещает новые фичи, прирост производительности и, конечно же, новые вызовы при миграции.
Apache Spark де-факто стал стандартом для распределённой обработки данных. От классических ETL-пайплайнов и SQL-аналитики до сложного машинного обучения и стриминга — Spark так или иначе задействован во многих современных data-платформах. Поэтому каждый новый релиз вызывает живой интерес у комьюнити: что там под капотом? Какие проблемы решены? Не сломается ли то, что работало годами?
Материализованные представления в StarRocks упрощают моделирование данных, ускоряют запросы и повышают актуальность данных в lakehouse‑архитектуре. Разбираем базовые возможности MV, три практических сценария — моделирование, прозрачное ускорение и «lake + warehouse» — и даём ссылки на актуальные рекомендации для StarRocks 3.5.
Это четвертая статья специалиста по архитектуре ИТ-систем и трансформации ИТ-ландшафта Дениса Прилепского из серии «Строим корпоративную GenAI-платформу: от концепции до ROI». Он объясняет, какие бывают guardrails, как они встроены в архитектуру платформы и зачем нужны: от защиты пользователей до соответствия требованиям регуляторов.
Книг по Data Science в последние годы выходит просто море — от толстых академических учебников, перегруженных формулами, до популярных «лайтовых» пособий, обещающих образно говоря, за неделю научить предсказывать курс биткоина. Но далеко не каждая книга способна удержаться в золотой середине: быть одновременно достаточно практичной, понятной и при этом содержательной. Русское издание «Изучаем Data Science» как раз из таких примеров, на которые можно порекомендовать обратить внимание (хотя формул здесь тоже хватает).
Хабр, привет! Меня зовут Вячеслав Демин, я больше четырёх лет работаю в сфере Data Science. Сейчас руковожу направлением аналитики данных в Сбере и преподаю на курсе «Специалист по Data Science» в Яндекс Практикуме. Начинал с этого же курса в 2020 году, после чего работал в сфере страхования и нефтехимии.
В этом материале расскажу, чем стажёр отличается от джуниора, а джуниор от джуниора-плюс — и какие требования к дата-сайентистам начальных грейдов предъявляют работодатели.
Всем привет! Сегодня хотим поделиться историей нашего эксперимента, который начался с простого вопроса: а можно ли с помощью краудсорсинга воссоздать рейтинг нейросетей, который мы получаем от тысяч реальных пользователей на нашем сайте LLM Arena?
Причём не в жёсткой парадигме «оцени по инструкции», а приближаясь к реальному user preference, когда пользователь выбирает то, что ему субъективно больше нравится.
TL/DR:
* Мы можем за 3 дня воспроизвести пользовательский рейтинг LLM с точностью 90%+;
* У нас есть отобранная команда аннотаторов и автоматический фильтр качества;
* Мы научились фильтровать фрод и мусорные промпты лучше, чем стандартные крауд-платформы;;
* Теперь мы можем быстро тестировать новые модели и выдавать предрейтинг до массового запуска.
Не так давно в блоге компании Arenadata был опубликован материал тестирования поведения различных распределенных файловых систем при работе с маленькими файлами (~2 Мб). Краткий вывод: по результатам проверки оказалось, что лучше всего с задачей маленьких файлов справляется старый-добрый HDFS, деградируя в 1.5 раза, S3 на базе minIO не тянет, замедляясь в 8 раз, S3 API над Ozone деградирует в 4 раза, а наиболее предпочтительной системой в при работе с мелкими файлами, по утверждению коллег, является Greenplum, в том числе для компаний «экзабайтного клуба». Коллеги также выполнили огромную работу по поиску «Теоретических подтверждений неожиданных показателей».
Результаты тестирования в части S3 minIO показались нашей команде неубедительными, и мы предположили, что они могут быть связаны с:
• недостаточным практическим опытом эксплуатации SQL compute over S3 и S3 в целом;
• отсутствием опыта работы с кластерами minIO. В частности в высоконагруженном продуктивном окружении на 200+ Тб сжатых колоночных данных Iceberg/parquet, особенно в сценариях, где проблема маленьких файлов быстро становится актуальной.
• особенностями сборок дистрибутивов;
Мы благодарны коллегам за идею и вдохновение провести аналогичное тестирование. Давайте разбираться.
Мы провели рандомизированное контролируемое исследование (RCT), чтобы оценить, как инструменты искусственного интеллекта начала 2025 года влияют на продуктивность опытных open-source разработчиков, работающих в своих собственных репозиториях. Неожиданно оказалось, что при использовании ИИ-инструментов разработчики выполняют задачи на 19% дольше, чем без них — то есть ИИ замедляет их работу.
Мы рассматриваем этот результат как срез текущего уровня возможностей ИИ в одном из прикладных сценариев. Поскольку системы продолжают стремительно развиваться, мы планируем использовать аналогичную методологию в будущем, чтобы отслеживать, насколько ИИ способен ускорять работу в сфере автоматизации R&D[1].
Подробности — в полной версии статьи.
