Big Data *

Привет, Хабр! Мы уже неоднократно поднимали вопросы оптимизации запросов к СУБД ClickHouse, которую все чаще используют как универсальное высокопроизводительное хранилище для аналитических задач. В случае с Visiology этот вопрос приобретает двойную ценность, так как мы используем оптимизацию для эффективного выполнения запросов в языке DAX.

Сегодня мы поговорим о применении группировок GROUP BY с учетом их производительности для относительно больших таблиц, например, с миллионами записей. Таким образом, речь пойдет об оценке кардинальности одного или нескольких столбцов. Эта задача, кстати, является достаточно нетривиальной. Но если Вы можете ее решить, появляется возможность для эффективных оптимизаций SQL. О них мы и поговорим сегодня.

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

Сегодня я хочу поговорить о том, без чего не обходится практически ни один серьёзный проект с большими данными (да и с не слишком большими тоже) — о промежуточных витринах (или более привычно – staging, core, data mart).

Давайте представим стратегию, зародившуюся в военной сфере, где команды притворяются врагами друг друга, чтобы проверить оборонительные механизмы. Этот подход, известный как red teaming, оказался чрезвычайно ценным и теперь нашёл новое применение. Сегодня, когда искусственный интеллект занимает всё больше места в нашей повседневной жизни, использование метода red teaming для тестирования этих систем становится необходимым. Red teaming для моделей-LLM помогает убедиться, что они не только эффективны в работе, но и безопасны и надежны.

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

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

Всем привет! Меня зовут Саттар Гюльмамедов и я работаю в команде ETL платформы DataOps в МТС. Марк Твен как-то написал «Слухи о моей смерти сильно преувеличены» — про Big Data сейчас можно сказать то же самое. Волна хайпа, которую многие пытались оседлать, прошла. Но, как и значительная часть инженерных достижений, работа с большими данными стала рутиной, помогающей развиваться другим направлениям в ИТ. 

В экосистеме МТС мы строим для Big Data отдельную платформу, где есть инструменты для хранения и оценки данных, анализа и построения отчетов. Но все начинается с их загрузки и обработки. Получение и преобразование данных — как раз задача библиотек и сервисов, которые делает моя команда. Многие знают мем о перекладывании JSON. А мы как раз делаем инструменты для тех случаев, когда такие задачи уже не столь тривиальны и нужно разобраться с разными типами данных, разными структурам, хранящимися к тому же в разных форматах, и все это нужно сделать в рамках одного процесса.

В этом материале я расскажу про наши решения и условия, лежащие в их основе. Одним наш опыт поможет спланировать эволюцию своих инструментов, другим снимет страх перед сложным стеком технологий Big Data, а третьи просто развлекутся. 

Дисклеймер:
чтобы не отклоняться от темы, я не буду подробно описывать концепции ETL и ELT (они хорошо разобраны тут, тут и тут). Наши инструменты следуют парадигме «E[TL]+», т. е. позволяют выполнять трансформации данных как в процессе переноса, так и в целевом хранилище.

Про нашу платформу в общих чертах писал мой коллега Дмитрий Бодин в своей публикации «Customer Happiness: как не только разработать, но и внедрить новый продукт внутри крупной компании». Я продолжу начатый им рассказ и добавлю подробностей о компоненте ETL, его составляющих и нашей команде.

Привет, Habr! Мы Катя и Оля, продакт-менеджеры BigData в компании «Лента», отвечаем за развитие цифровых продуктов блоков «Ассортимент» и «Ценообразование».

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

Привет! Меня зовут Марк Паненко, и я Chief Data Science в Ozon Банке. Сегодня я хочу поговорить про книги, которые научат писать код. В современной экосистеме Data Science недостаточно просто знать алгоритмы машинного обучения и статистические методы — необходимы прочные инженерные навыки для создания масштабируемых, поддерживаемых решений.

Это третья часть серии статей о главных книгах для data-специалистов. В первой части «От комиксов до нейросетей» я писал о литературе для джунов. Во второй — «Код устареет, принципы — останутся» — для мидлов и сеньоров.

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

От идеи до работающего Telegram бота за 2 часа, от 112 кг до 102 кг за 2 месяца. Это история о том, как использование Cursor, v0.dev и современных AI-инструментов помогает решать личные проблемы с помощью кода — и как это личное решение превращается в бизнес-возможность.

Как определить, влияет ли то или иное событие на ключевые метрики, если полноценный A/B-тест недоступен?

В этой статье мы разберём метод Propensity Score Matching (PSM): узнаем, как компенсировать отсутствие рандомизации, выровнять группы по ключевым признакам и избежать ложных выводов при оценке эффектов.

Привет, Хабр! Это снова команда «МосТрансПроекта». Мы постоянно работаем с информацией и знаниями, которые храним в служебных презентациях. Чтобы ими было удобней пользоваться и извлекать данные, мы решили создать удобный сервис хранения документов с поиском. Задача оказалась непростой, и в этой статье мы расскажем, как её решили. Текст будет интересен всем, кто занимается структурированием данных, поисковыми машинами и ИИ.

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

Мы, ребята из Центра эксплуатации Блока ИТ Страхового Дома ВСК, занимаемся управлением автоматизации ИТ-процессов. И у нас, как у всех — куча прикладных задач, которые хочется закрыть быстро дешево и качественно. Недавний хайп по Deepseek не обошел нас стороной, и мы решили протестировать платформу по парочке гипотез в надежде на чудо.

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

Гипотеза 1: Оценка тенденций ключевых показателей технической поддержки

Мы решили проверить, насколько DeepSeek способен анализировать динамику показателей. В качестве данных взяли выгрузку по основным метрикам техподдержки: SLA, количество заявок (поступило/решено), количество негативных отзывов и пр.  Скармливали выгрузку Excel, в общем то, простая таблица со следующими показателями (столбцы):

Привет, Хабр! Сегодня я хочу поговорить о возможностях и ограничениях функций Time Intelligence в Visiology. Это очень интересный раздел языка DAX, который позволяет быстро делать показательные расчеты, например, сравнивая показатели текущего периода с предыдущими. Однако в его реализации для Visiology и Power BI есть некоторые различия (впрочем, не влияющие на результат). В этой статье мы поговорим об этой разнице, а также я наглядно покажу, как чат-бот ViTalk GPT помогает разобраться с особенностями работы различных функций.

Привет! Меня зовут Кирилл Сергеев, я ML-инженер в Циане. В этой статье я расскажу, как мы решили задачу дедупликации объявлений о недвижимости, разработав систему на основе трёх моделей. Эта система автоматически находит и объединяет дублирующиеся объявления, помогая пользователям видеть только актуальную и уникальную информацию.

Материал будет полезен ML-инженерам и специалистам по обработке данных, которым интересно, как мы подошли к решению этой задачи: какие методы использовали, какие проблемы возникли и как мы их преодолели.

Казалось бы, стандартная задача: взять 20 000 объявлений, определить в них модель товара и сгруппировать по карточкам – легкий проект, который можно закрыть за пару месяцев.

Но на деле все усложняют многоязычные названия, аббревиатуры, субъективные решения аннотаторов и нюансы классификации. Как мы выстроили процесс, чтобы обеспечить точность группировки, как мы валидировали данные и какие решения помогли нам справиться с вызовами? Рассказываем в этой статье.

Если говорить про Data Governance, то это, в первую очередь, не продукты, а огромная методология управления жизненным циклом данных, и только потом – технологии. Близко к идеалу считается методология DAMA-DMBOK, и у любого специалиста по данным это должна быть настольная книга. К сожалению, в подавляющем большинстве случаев, когда люди начинают задумываться про управление данных, она попросту неприменима, так как она показывает «правильное» управление данными больших предприятий, до неё еще надо «дорасти», при этом точечно применяя сначала простые приемы, с возможностью расширения методик управления данными как «вширь», на другие отделы, так в «вглубь» на все процессы, связанные с управлением данными (Data Management): получением («добычей»), обработкой, хранением, извлечением и использованием информации. Без подобного управления жизненным циклом данных получим картину как в последнем исследовании Makves, что 40% данных никогда не используется: к ним не зафиксировано ни одного обращения за 5 лет.
Найти «Ценность в данных» становится искусством, так как на предприятии растут «Кладбища данных» вместо «Хранилищ данных».

Сейчас зачастую под Data Governance имеют в виду две части, это Data Quality – управление качеством данных, и Data Linage – «понять, откуда пришли данные, как они изменялись и можно ли им доверять». Если данные методологии использовать «в лоб», то это очень сильно замедлит разработку и перегрузит команду по управлению данными.

Всем привет! Это DS-ы Павел Парфенов и Максим Шаланкин из команды Финтеха Big Data МТС. Мы и наши коллеги Data Scientists и Data Analysts ежедневно обрабатываем огромные массивы информации, строим модели и выделяем целевые сегменты, чтобы принимать обоснованные решения. Наши рутинные задачи — предварительный анализ данных (EDA), обучение ML-моделей и сегментация аудитории — часто отнимают кучу времени и ресурсов. 

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

Привет! Меня зовут Денис Березуцкий, я старший инженер по разработке ПО искусственного интеллекта в YADRO. В ML-команде мы разрабатываем системы, которые облегчают работу нашим заказчикам с помощью текстовых генеративных нейросетей: реализуем RAG, создаем чат-ботов, агентные системы и другие решения.

Как и многие в индустрии, мы сталкиваемся с проблемами галлюцинаций LLM, которые портят ответы виртуальным ассистентам и способны подорвать доверие к ним. В статье я расскажу об одном не совсем стандартном методе, перенесенном из «классического» программирования, который мы применяем для борьбы с галлюцинациями и улучшения поисковой выдачи.

В статье приводятся оригинальные модули Python и даётся пояснение по их применению в задачах распределённой децентрализованной сети по типу блокчейн или, другими словами, в процессах самоорганизованной критичности (SOC). В научных публикациях чаще встречается физический термин SOC в качестве концепции, включающей процессы турбулентности, детонации, землетрясения, нейросети, фондовая волатильность, социальный рейтинг и другие.

Для процессов SOC характерно отсутствие управляющих параметров и масштабная инвариантность. Универсальность сложных процессов SOC со степенным законом Power law имеет тот же характер, как и универсальность простых линейных систем, не обладающих масштабной инвариантностью, по отношению к закону нормального распределения вероятности.

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

Значительные достижения в анализе Big data заставляют предположить связь с распределением вероятности Пуассона: чем больше данных, тем чаще должны встречаться пуассоновские события и вопрос лишь в поиске подходящей метрики и системы счисления.

Воркшоп для тех, кто впервые сталкивается с распределёнными системами.

В этой статье на примере решения несложного архитектурного кейса я покажу, что ответов только на 3 вопроса при проектировании систем распределённой параллельной обработки данных будет достаточно для обеспечения жёстких нефункциональных требований.