В вопросах производительности BI обычно приходится искать компромисс между скоростью работы аналитики и объемами данных, над которыми она реализована. Впрочем, существуют способы “убить двух зайцев” сразу, и сегодня я хочу поделиться нашим опытом интеграции Visiology с платформой Arenadata при построении гибридной модели работы BI.
Привет, Хабр! Меня зовут Артемий Козырь.
За последние годы у меня накопился довольно обширный опыт работы с данными и тем, что сейчас называют Big Data.
Не так давно также разгорелся интерес к сфере интернет-маркетинга и Сквозной Аналитики, и не на пустом месте. Мой друг из действующего агентства снабдил меня данными и кейсами реальных клиентов, и тут засквозило понеслось.
Получается довольно интересно: Azure SQL + dbt + Github Actions + Metabase.
Уэс МакКинни, о котором писали в Quartz как о человеке, «создавшем наиболее важный инструмент в области Data Science» (речь о пакете для анализе данных Pandas), отправляется в новое плавание – он запускает стартап под названием Ursa Computing.
Делюсь собственным опытом, т.к., наверняка, это будет интересно таким же как я, но может и не только.
Заранее предупрежу, многие термины и сокращения будут понятны только тем, кто имеет базовые знания и какой-то опыт в Data Science и Машинном обучении.
Итак, в наличии на август 2020:
Я – выскочка. По крайней мере, так я себя иногда ощущаю. Закончив второй курс политологии и журналистики в университете, я увидел американский рейтинг профессий по уровню оплаты труда. Журналист в этом рейтинге был на последнем месте, а на первых местах были data scientists и data engineers (политолога в этом списке, почему-то, не было). Я не знал, кто составлял этот список, и понятия не имел, кто такие эти data-челы с первых строк, но он меня впечатлил. Я бросил пить и начал проходить курсы на Coursera, а потом каким-то чудом заполучил студенческую подработку в стартапе. Так я сделал своё «войти в IT».
Когда человек, не имеющий университетской подготовки, пытается начать программировать, то он чувствует себя несчастным, который, увидев из окна солнце, вышел на улицу и попал под неожиданный в столь прекрасный день град: шаблоны проектирования, функции, классы, ООП, инкапсуляция, протоколы, потоки, ACID… Хочется прокричать, как Виктор Фёдорович в своё время:
Привет, Хабр!
Меня зовут Артемий, я занимаюсь дата-инжинирингом в команде аналитики Wheely. А конкретнее — построением аналитических решений, начиная с основ и до конечного результата: подключение источников, очистка и трансформация данных, организация хранилища и детального слоя, формирование витрин и дашбордов.
В этом посте я сделал верхнеуровневый обзор решений, подходов и фреймворков, которые мы используем для развития Wheely: оптимизации операционной деятельности, построения отчетности, планирования и проверки гипотез. И еще немного похвастаться (куда без этого), потому что инструменты, которые мы используем в Wheely, сегодня набирают большую популярность на Западе, но в России пока далеко не каждая компания готова их адаптировать.
Несмотря на всю пользу DVC, об этом инструменте знает катастрофически мало разработчиков. Поэтому, думаю, не лишним будет для начала вас познакомить. DVC – это open-source система контроля версий данных, которая отлично подходит для машинного обучения. И основное отличие DVC от Git’a в том, что он: во-первых, имеет более широкий и удобный инструментарий для ML-проектов; во-вторых, создан для контроля версий данных, а не кода. И по большей части здесь их основные различия заканчиваются. А далее я постараюсь описать, чем же так хорош DVC, и почему Git'а не достаточно для ML.
На момент написания этой статьи в компании Cardsmobile, которая разрабатывает мобильное приложение «Кошелёк», работает 195 человек: 8 аналитиков и 187 потенциальных заказчиков аналитиков. Мы делаем приложение для конечных пользователей, а также работаем с ритейлом, банками, брендами и другими партнерами. Долгое время работа аналитика в Кошельке состояла не только из исследований поведения пользователя, но и из различных выгрузок, типовых анализов для партнеров и прогнозов для потенциальных клиентов. Конечно, дашборды сильно спасали нам жизнь и позволяли всей компании следить за показателями продукта. Но мы всё ещё тратили время на остальную текучку, и с ростом команды (заказчиков) и бизнеса упёрлись: Ad-hoc задач стало слишком много, а исследования, желание развиваться и светлое будущее простаивали в отсутствие у нас времени.
В постах на Хабре тема структурного логирования упоминается часто, но вскользь. Поэтому, когда я наткнулся на эту подробную статью Brandur Leach из Stripe, я решил перевести её и поделиться с сообществом.
В Badoo мы оценили пользу структурного логирования в частности для группировки ошибок. Хеш сообщения об ошибке часто содержит динамические данные — например, id пользователя, — которые мешают корректно группировать такие сообщения. Поэтому мы перешли на структурное логирование, где текст ошибки — это некий шаблон, а вся динамическая информация передается в контексте и не влияет на группировку.
В статье Brandur Leach предлагает идею, как открыть еще больше возможностей в структурном логировании. Есть и описание практической пользы от использования такого подхода — в Stripe даже сделали продуктовый функционал на основе данных, полученных из логов, — и детали реализации такого решения (без ухода в дебри конкретного стека технологий).
Приятного чтения!
Вряд ли у кого вызывает сомнение, что современную экономику можно назвать экономикой данных, поскольку данные превратились в валюту, товар и новый природный ресурс, своего рода топливо для инноваций. Однако объем данных безудержно растет. Данные содержат в себе огромную ценность, они все чаще нужны нам в небывало больших объемах и на высокой скорости. Как нам кажется, организациям следует меньше беспокоиться о затратах на управление данными и больше думать о новых возможностях, которые дает это управление. Как лучше всего раскрыть потенциал этих возможностей?
Наша статья посвящена компонуемой архитектуре данных на основе мультиоблака, которая будет расти вместе с бизнесом и автоматически доставлять данные туда, где они принесут больше всего пользы. Она позволит достичь главной цели мультиоблака — создать комбинированную среду с упрощенным управлением с одной стороны и доставкой сервисов по требованию — с другой.
Как преуспеть в экономике данных?
Современную экономику можно назвать экономикой данных, поскольку данные превратились в валюту, товар и новый природный ресурс, своего рода топливо для инноваций. Питер Норвиг, директор по исследованиям в Google, однажды так объяснил успех своей организации: «Наши алгоритмы не лучше, чем у других. Просто у нас больше данных».
Однако объем данных безудержно растет. В основном это созданные машинами, неструктурированные, хаотичные и разрозненные данные, которые используются недостаточно продуктивно — или не используются вовсе. При этом они все чаще нужны нам в небывало больших объемах и на высокой скорости.
Как добиться успеха в экономике данных? Как нам кажется, достаточно соблюдать три правила:
При проведении разового анализа логирование вам не понадобится. Но в случае разработки скриптов, которые будут по расписанию запускаться в пакетном режиме, логирование упростит вам процесс определения и исправления возникающих в работе скрипта ошибок.
По умолчанию скрипты которые запускаются командой R CMD BATCH логируются в одноимённые файлы с расширением .Rout. Но такие логи неудобно читать, а анализировать невозможно.
Есть целый ряд пакетов, которые берут на себя процесс логирования. В этой статье мы рассмотрим один из наиболее функциональных и новых пакетов — lgr.
