Все потоки

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

Анализ аудиоданных (часть1) - https://habr.com/ru/post/668518/

Характеристики аудиофайлов для разных аудио записей.

В наборе аудиоданных есть Human files - 10322 файла ( записи “живого” голоса (класс 1)) и Spoof files - 39678 файлов ( записи синтетического/конвертированного/перезаписанного голоса (класс 2)) . В одном аудиофайле (3 - 6 сек) голос мужской или женский что-то говорит на каком-то языке (английском, русском, немецком, китайском)

Вот так выглядят характеристики аудиофайлов для разных аудио записей:

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

С развитием информационных технологий у их пользователей все сильнее и сильнее появляется желание автоматизации рутинных операций, в том числе и автоматической генерации кода. Где это уже возможно?

Я расскажу об автоматической генерации ETL-кода, которая реализована в Сбере на примере одной из использующихся платформ. Поток трансформаций данных в нашем решении называется графом. Этот граф является ориентированным ациклическим графом (DAG, directed acyclic graph). Автоматическую генерацию графов оказалось возможно реализовать благодаря наличию специального инструмента spec-to-graph, который как раз для этого и предназначен. Он позволяет формировать трансформации графа согласно написанному коду, служащему шаблоном. В этом шаблоне указывается, какие трансформации с какими параметрами следует использовать и в каком порядке нужно их соединить. Мы используем подход по генерации графов из базовых субграфов (стандартизированных маленьких графов). Т.е. мы разбиваем ETL-процесс на элементарные операции, каждую из которых реализует некоторый базовый субграф. А из субграфов формируется итоговый граф, осуществляющий загрузку данных. Данные мы грузим из Hive в Hive, дополнительно используя промежуточные индексные структуры в HBase.

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

Доброго времени суток! Меня зовут Алексей. Сейчас я обучаюсь на аналитика данных в "Яндекс Практикум". Дело для меня непривычное, совершенно не связанное с моей предыдущей деятельностью (пока что работаю врачом, иногда пишу рассказы и повести), так что порой некоторые темы даются с большим трудом.

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

И мой главный совет: "сделайте себе шаблон"!

Не важно, в чём вы пишете код: "Google colaboratory", "Jupiter notebook" или в какой-то иной среде. Не важно, сколько вы пока знаете: если осваиваете профессию с нуля, вносите в шаблон всё, что уже умеете - позже всегда можно удалить лишнее. Шаблон поможет вам быстро сориентироваться в любой новой задаче, напомнит о необходимых манипуляциях. 

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

Лично я большую часть учебных проектов выполнил в "Google colaboratory" (далее по тексту просто "колаб"), где предпочитаю следующую структуру шаблона.

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

На платформе ODS.ai прошло  соревнование по машинному обучению Data Fusion Contest 2022 от банка ВТБ.

Мы, команда Лаборатории ИИ Сбера и Института искусственного интеллекта AIRI, приняли решение поучаствовать в контесте, когда увидели, что тема соревнования сильно пересекалась с нашими исследованиями. Мы заняли первое место на private leaderboard в основной задаче Matching. Здесь я хотел бы описать решение, которое у нас получилось.

В рамках соревнования предлагались: датасет, содержащий транзакции, совершенные клиентами ВТБ по банковским картам, кликстрим (данные о посещении web-страниц) клиентов Ростелекома и разметка соответствия между клиентами из этих двух организаций. Соответствие устанавливается если два клиента – это один и тот же человек. Все данные были обезличены, а сами датасеты синтезированы на основе реальных данных таким образом, чтобы сохранить информацию о поведении пользователей.

В программу мероприятия входило пять задач разной сложности с разным призовым фондом. Мы решили сосредоточится на главной задаче Matching, как на самой сложной и самой интересной.

Apache Kafka широко используется в самых разных сферах автопрома. В этой статье мы рассмотрим реальные примеры развёртывания в разных контекстах, включая подключенные транспортные средства, умное производство и инновационные услуги перевозок, и в разных компаниях, включая автопроизводителей, вроде Audi, BMW, Porsche и Tesla, и провайдеров сервисов мобильности — Uber, Lyft и Here Technologies.

Недавно наши интеграционные тесты Jest упали из-за недостатка памяти. Как оказалось, это не было аномалией, и тесты постоянно аккумулировали на себе столько памяти, что единственный процесс Node.js достиг стандартного предела в 4 ГБ, установленного в V8 для размера кучи. У нас около 450 тестов, объединенных в 50 сьютов, которые в основном являются интеграционными: имитированные HTTP-запросы обрабатываются на сервере, который взаимодействует с базой данных Postgres, запущенной в Docker. По этой причине мы используем последовательный запуск, поскольку у нас нет изолированного хранилища для каждого сьюта. После того, как мы обнаружили несколько проблем с Jest, соответствующих нашим диагнозам, одним из действий, которые мы предприняли, было выяснить, сможет ли миграция на альтернативный фреймворк решить наши проблемы.

Завалить важный проект из-за Agile, уронить огромную CRM и потерять всю БД маркетплейса — это не страшный сон в ИТ, а реальность. Мы устали от «успешного успеха» и уже делились факапами СберМаркета на F*ckup Meetup. А сегодня мы расскажем о пяти громких провалах других компаний.

Все мы хотим быть продуктивнее и успевать делать больше работы. Но как это реально сделать на практике?

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

И только когда дедлайн уже вовсю маячит на горизонте, и начинает пахнуть жареным, я сажусь наконец за написание кода или анализ пулл-реквестов коллег. Знакомая картина? Увы, в этом я не одинок. Я долго пытался бороться с собой и пробовал разные методики, пока один из коллег не порекомендовал мне познакомиться с книгой «Глубокая работа».

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

В чем его секрет? В той самой пресловутой глубокой работе. Итак, вдохновившись примером Кэла Ньюпорта (а кто не хочет тоже стать монстром продуктивности?), я решил попробовать работать глубоко по его системе.

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

При всех достоинствах Kafka как распределенного хранилища потока сообщений, боль вызывало раздельное хранение метаданных (топологии разделов, конфигурации кластера и прочего) и необходимость запуска в кластере рядом с Kafka еще и Apache Zookeeper. Побочным эффектом такого соседства (кроме дополнительных забот об администрировании и мониторинге) является долгое время восстановления после сбоя при больших размерах кластера, значительном количестве разделов или сложной топологии групп. Но ситуация улучшается и отличная новость появилась полторы недели назад в KIP-833, что в ближайшей версии Kafka 3.3 новый протокол согласования метаданных (KRaft), работающий внутри Kafka без Zookeeper, будет признан Production-Ready и далее постепенно зависимость от Zookeeper будет помечена как deprecated и удалена. В этой статье мы поговорим об особенностях протокола KRaft и разберемся как настроить новый кластер Kafka без необходимости установки Zookeeper.

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

Специально для тех, кто ищет альтернативу Unreal Engine или Unity, мы продолжаем цикл статей про безболезненный переход на UNIGINE с зарубежных движков. В третьем выпуске рассмотрим миграцию с Unreal Engine 4 с точки зрения программиста.

Под катом: написание игровой логики, триггеры, ввод, рейкастинг и другое.

Об оптимизации закупочной деятельности мы впервые задумались ещё в 2019 году. Создавать облачный сервис для некоммерческих закупок (закупок для нужд компаний) B2B Altis мы решили в нестандартном для российского рынка партнерстве, когда ритейлер выступает не просто заказчиком решения, но и его соразработчиком. В качестве партнера была выбрана крупнейшая коммерческая площадка электронных торгов B2B-Center. Партнерство открывало доступ к проверенной базе российских поставщиков - 574,6 тысячам контрагентов.

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

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

Эта статья предназначена, прежде всего, для тех, кто является либо управленцем (то может быть человек, который управляет проектом, коллективом, взаимодействует с каким-либо заказчиком, с внешней стороной), либо она также может быть интересна для тех, кто хочет разобраться и вообще более-менее понимать, что такое классовая теория и как её можно использовать на практике.  

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

Это история о первой из двух катастроф связанных с межконтинентальной баллистической ракетой Titan II.

В далёком 1965 году, 9 августа, в штате Арканзас на стартовом комплексе 373-4 всё шло своим чередом. Ракета Titan II находилась в пусковой шахте под землёй, персонал занимался её обслуживанием. Комплекс 373-4, расположенный недалеко от города Сирси, проходил программу модификации под названием YARD FENCE. YARD FENCE имел призвание облегчить техническое обслуживание системы и повысить её надёжность, а также устойчивость шахты в случае ближнего ядерного взрыва. Согласно плану, Titan II должна была находиться в шахте полностью заправленной без боеголовки. На своих рабочих местах находилось около 50 человек. Работа кипела как в бункере, так и на поверхности. Гидравлическая система №2, которая приводила в действие рабочие платформы и взрывные клапаны шахты промывалась. Резервуар с гидравлической жидкостью и насос для неё располагались на поверхности. Их задача — прогонка гидравлической жидкости через 8-дюймовый канал (20.5 см). Крышка бункера была закрыта. Для проведения работ требовались кислород-ацетиленовая и электродуговая сварка. Всё оборудование располагалось на 2 — 7 уровнях шахты. Работы включали в себя покраску люков доступа с Т-образными замками на первом уровне, а также установку стальных крышек на акустические модули на уровне 7 и несколько выше.