Что делать, когда нет входных данных для вычислений и обработки системой? Как управлять процессом, когда точно неизвестно, как именно протекает процесс? На помощь приходят теоретические расчеты и кратковременные эксперименты...
Продолжаем разбирать подходы призеров Kaggle-соревнований от американской национальной футбольной лиги (NFL). Участники этого челленджа детектировали столкновения игроков в американском футболе, анализируя данные с видеокамер и датчиков, прикрепленных к форме футболистов. В продолжении первой части статьи расскажу про самые успешные подходы к этой задаче.
Привет, Хабр! Сегодня рассказываем, чем отличаются подходы к построению распределённых хранилищ данных Data Warehouse (DWH) и Data Lake и в чём специфика задач специалистов, работающих с данными.
В статье сначала опишем паттерны построения распределённых хранилищ, чтобы понимать, через какие процессы проходят данные. А после поговорим о задачах специалистов по работе с данными и необходимых для каждой позиции навыках.
P.S. На картинке спрятаны 6 инструментов для работы с данными. Узнали их?
Предположим: вы полны желания изучить манящий массив данных. К счастью, для этого достаточно вашего компьютера. Итак, вы открываете блокнот Python или REPL, чтобы начать работать: какую библиотеку использовать? Естественно, вы можете обратиться к старой доброй Pandas. А как насчет новой модной библиотеки фреймов данных, например Polars или datatable? А ещё, для разнообразия, можно попробовать встроенный SQL с помощью DuckDB.
Давайте погрузимся в прекрасную область фреймов данных, чтобы сделать выбор!
PS: Используйте DuckDB, если вам удобно работать с SQL, Polars или Pandas с поддержкой PyArrow, если вам не нужно какое-то специфическое расширение NumPy, и задействуйте PyArrow в том случае, если вы не против ручной оптимизации.
Привет, Хабр! Я недавно начал свой путь в data science, хочу поделиться реализацией алгоритмов по обработке матриц.
В этой статье хотелось бы погрузить вас в мир данных и вспомнить: какие встречались проекты, связанные с хранилищами и данными, какие задачи приходилось решать, а также какие навыки пригодились.
Но вначале придется разобрать извечные вопросы: кто же такие аналитики, что такое данные и понять – должны ли они быть вместе?
Всем привет! В предыдущих статьях (1 и 2) я рассказывал про концепцию индексирования данных смарт-контрактов на блокчейне в общем и в частности через средства The Graph, а также про то, как использовать готовые "сабграфы" на The Graph Hosted Service, чтобы, не написав ни строки кода, делать к ним GraphQL запросы и получать данные популярных децентрализованных приложений. Однако, если вы присматриваетесь к Web3 разработке, то вероятно вам и самим придется разрабатывать такие сабграфы для своего приложения. Эту тему (разработка собственных сабграфов стандарта The Graph) я бы и хотел осветить в данном материале. Чтобы пример был не сферический и в вакууме, будем рассматривать существующий смарт-контракт проекта TornadoCash.
Databricks — это аналитическая платформа для облачных вычислений, работы с большими данными и машинного обучения. Компания разрабатывает data lake и работает с фреймворком Apache Spark. Приводим перевод статьи Databricks о нововведениях Apache Spark 3.4, который вошел в релиз Databricks Runtime 13.0.
Приветствуем читателей Хабра! Мы, команда дата-сайентистов и дата-аналитиков компании «ДатаЛаб»* (ГК «Автомакон»), запускаем серию статей, в которых поднимем актуальные темы и предложим свои решения проблемных ситуаций онлайн-ритейла. Каждый день мы решаем бизнес-задачи ритейла по повышению продаж, сокращению издержек и управлению рисками.
Стартуем со статьи, в которой рассмотрим одну из самых распространенных проблем в онлайн-ритейле – отсутствие товара (out-of-stock) в моменте и поделимся рекомендациями по ее устранению.
Цифровая трансформация подобна ремонту: однажды начавшись, не заканчивается уже никогда. Разработчики и дата-сайентисты выискивают по цехам ЕВРАЗа — где бы ещё причинить пользу своими знаниями и умениями? На этот раз им на глаза попалось производство рельсов. И увидели они, что это хорошо, но можно ещё лучше…
Конечно, в действительности процесс принятия решений выглядит немного иначе. Однако термоупрочнение рельсов — действительно перспективный объект для цифровизации. Под катом вы сможете прочесть, как строилась математическая модель остывания рельса, а главное — зачем.
В последние годы растет сложность IT-инфраструктуры в компаниях и, соответственно, спрос на сервисы мониторинга ее работоспособности. Их все больше покупают, в них все чаще инвестируют. Но в данной статье мы расскажем о новом смежном тренде - Data Observability. Что это и чем она отличается от Infrastructure Observability?
Классический мониторинг - это наблюдение за работой инфраструктуры и приложений. А Data Observability позволяет осуществлять мониторинг потоков данных (и даже бизнес-процессов) и находить в них сбои.
Рассмотрим несколько примеров.
Всем привет! Представим, что вам нужен доступ к данным каких-либо смарт-контрактов на Ethereum (или Polygon, BSC и т.д.), например, Uniswap, SushiSwap, AAVE (или даже PEPE-coin) в реальном времени, чтобы анализировать их с помощью стандартных инструментов дата-аналитиков: Python, Pandas, Matplotlib и т.д. В этом туториале я покажу инструменты для доступа к данным на блокчейне, которые больше похожи на хирургический скальпель (сабграфы The Graph), чем на швейцарский нож (доступ к RPC ноде) или, скажем, молоток (готовые API от компаний-разработчиков). Надеюсь, мои неумелые метафоры вас не пугают. Кому интересно научиться, добро пожаловать под кат.
Скажите, если к вам придёт потенциальный клиент, но вместо красивого сайта, приложения или сотрудника его встретит чатик с текстовой нейросетью, которая что-то знает о вашем продукте и теоретически может его продать – вам будет комфортно? Это, может, нетипично для энтузиаста, закопавшегося по уши во всякие GPT и PaLM, но лично мне в такой ситуации будет очень страшно. А вдруг нейросеть продаст что-то несуществующее? Или вообще ничего не будет продавать? Или нагрубит клиенту?
Похоже что эти опасения разделяют многие: каждую неделю появляется ворох новых сервисов, пишущих нейросетью что-то для последующей обработки человеком (начиная с кода и заканчивая рекламными текстами), а вот примеров, в которых нейросеть "пускают" напрямую к клиентам далеко не так много. Но, как мне кажется, я нашёл способ от этих опасений в существенной степени избавиться. (Конечно, может быть, кто-то уже нашёл его раньше и я просто этого не заметил, но что уж поделаешь, сфера новая и очень быстро развивается.)
В этой статье я на примере простого сервиса для маршрутизации заявок в техподдержку покажу свой подход к созданию сервисов на нейросетях, которые не страшно напрямую использовать для общения с клиентами или в других важных процессах. А также приблизительно измерю процент случаев, в которых такой сервис сможет корректно отработать, и постараюсь отследить влияние различных особенностей запросов к нейросети на этот процент.
Меня поразил тот факт, что метод CFG Scale и позволил диффузным моделям родиться. До них были GAN-модели, которые совмещали в себе генератор и дискриминатор. Т.е. моделька сначала генерирует изображение, а потом вторая полноценная модель оценивает его на вшивость и корректирует вместе с первой.
Хорошо осенью любоваться на озёра… на озёра данных. Особенно когда про них говорит спикер Владимир Озеров. В общем, этой осенью, как и раньше, мы проведём конференцию SmartData обо всём, что важно в дата-инжиниринге: от отказоустойчивости до MLOps.
6-7 сентября пройдёт онлайн-часть, а 13-14 сентября встретимся в Москве (но все, кто не готов добраться на московскую площадку, смогут и во второй части поучаствовать удалённо).
Среди тем — и архитектура дата-платформ, и «внутренности» баз данных, и стриминг, и DataOps, и даже пара «космических» (в буквальном смысле) докладов. А среди спикеров есть те, чьи доклады уже хвалили участники прошлых SmartData — например, Максим Бабенко, Владимир Озеров, Дмитрий Аношин, Евгений Ермаков и Максим Стаценко. Все описания докладов — под катом.
Недавно закончилось соревнование от американской национальной футбольной лиги (NFL), которая объединилась с AWS, чтобы прокачать системы спортивной видеоаналитики.
Организаторы поставили простую, казалось бы, задачу — точно определить, в каких случаях игроки сталкиваются друг с другом во время матча по американскому футболу. Мы с коллегами приняли участие, но не успели реализовать все свои идеи. Зато изучили подходы других команд и поняли, что были на верном пути. В этой статье я рассмотрю некоторые из решений, которые принесли денежное вознаграждение и золотые медали участникам этого челленджа.
Всем привет! Недавно я на практике применил одно интересное решение, которое давно хотел попробовать, и теперь готов рассказать, как своими руками такое можно сделать для любой другой аналогичной задачи. Речь пойдет о создании своей кастомизированной версии ChatGPT, которая отвечает на вопросы, учитывая большую базу знаний, которая по длине не ограничивается размером промта (то есть вы бы не смогли просто добавить всю информацию перед каждым вопросом к ChatGPT). Для этого будем использовать контекстные эмбеддинги от OpenAI (для действительно качественного поиска релеватных вопросов из базы знаний) и сам СhatGPT API (для оборачивания ответов в натуральный человеческие ответы). При этом, также предполагается, что ассистент может отвечать не только на прямо указанные в Q&A вопросы, но и на такие вопросы, на которые смог бы отвечать человек, который ознакомился с Q&A. Кому интересно научиться делать простых ботов, отвечающих по большой базе знаний, добро пожаловать под кат.
