Data analysis

Несколько лет назад я задумался, что моя работа стала ремеслом. Для того, чтобы разнообразить серые будни повысить свою стоимость как специалиста я поступил в магистратуру и сразу стал вопрос ребром - как после 15 лет после окончания первого ВТУЗа по написать ВКР, за которую не было бы стыдно?

Введение

Так получилось, что практически все 15 лет с того момента, как стал инженером, я занимался обслуживанием теплосчётчиков, стоящих в подвалах многоквартирных жилых домов (МКД). Данных накопилось достаточно, чтобы их смело назвать big data.

Не буду расписывать подробно физику процесса теплопотерь зданий и сооружений, только напишу некоторые допущения, на которые пришлось пойти:

1. Температура внутри дома. Большая инженерная проблема. Где измерять правильно? сколько точек в каких местах? Я решил ввести "средний градус по больнице" и взял это как 24 градуса.

2. Температура на улице. Данные с Росгидромета получить можно только за деньги. Именно ей оперируют энергоснабжающие организации, когда ведут все свои расчёты. У нас в городе оказалось, что есть лаборатория оптической погоды, которая измеряет так же, но для науки данные даёт бесплатно. Написали письмо с научруком - получили данные.

3. Частота измерений. Тут думать не пришлось, решили что суточный архив теплосчётчика - будет достаточно. Жилой дом - достаточно стационарная штука, медленно греется, медленно остывает.

4. Данные должны быть очищены. Бывает так, что теплосчётчик "не работает". Иногда это связано с его неисправностью, иногда - с режимами наладки. Для моделирования лучше использовать валидные данные - например, когда он допущен к коммерческому расчёту.

5. Данные ограничены периодом с начала декабря 2013 по 27 марта 2017 года. As is.

6. Обработка данных в Statistica. Такую задачу мне поставил научрук, академическую лицензию я приобрёл.

Немного теории

Из мировой практики [1] выделим два подходящих для поставленной задачи метода измерения:

Анализ показаний приборов учета теплопотребления МКД. Основывается на долгосрочных измерениях энергопотребления всего здания в целом с помощью приборов учета.

Расчетно-экспериментальный метод на базе компьютерного моделирования. Основывается на проведении компьютерного моделирования энергопотребления, чаще всего здания в целом.

Мы оба метода объединили: вывели на основании показаний теплосчётчика удельную характеристику теплопотребления дома и создали простую математическую модель.

Потребление тепла МКД зависит от наружной температуры, больше перепад больше потребление. Так же, очевидно, потребление зависит от величины дома, энергоснабжающая организация в своих расчётах использует суммарную жилую площадь, мы привели полученные величины к жилой площади дома. Используя [2] уравнение теплового баланса, вывели формулу 1 коэффициента теплоотдачи [3]

где G коэффициент теплоотдачи, Вт/м²*С;

Q количество тепла за сутки из данных, ГКал;

Т_вн средняя температура в жилых помещениях МКД, принятая за плюс 24С;

Т_нар среднесуточная температура внешней среды за учитываемые сутки, С;

(Т_вн -Т_нар) тепловой напор, С;

S жилая площадь, м²;

t количество часов в сутках, 24 часа.

Очевидно, что коэффициент теплоотдачи является функцией от теплового напора, формула 2 :

Так как вид функции неизвестен, мы можем её попробовать найти её аналитическим путём.

Разработка методики расчётов

По полноте данных, 830 суточных записей - максимальное количество данных за вышеозначенный период был выбран дом : двухподъездный четырёхэтажный дом 1965 года постройки. Материал стен силикатный кирпич, кровля скатная, фасад утеплён минераловатной плитой и закрыт сайдингом.

На рисунке ниже изображена гистограмма вычисленного коэффициента теплоотдачи согласно формуле 1 с наложением среднесуточных температур на ось времени. Нужно отметить, что пиковые значения коэффициента приходятся на даты, когда температура наружного воздуха выше 0С.

Пропуск данных в отопительном сезоне 2015-2016 гг. объясняется неисправностью узла учёта, то есть данные за этот период удалены во время очистки как некорректные.

По формуле 2 построим облако точек [4] наблюдений используя программу Statistica, диаграмма рассеяния изображена на рисунке ниже.

Так как наблюдения на диаграмме рассеяния приведены за разные годы, очевидно, что распределение подчиняется некоторой зависимости. Программа Statistica позволяет на основании данных создать аппроксимирующие уравнения с разными степенями подгонки. Регрессионная граница - предсказанный интервал вокруг подогнанной (регрессионной) линии. Можно ввести значение вероятности (Уровень) того, что "истинная" подогнанная линия (для совокупности) попадет между границами. Стандартная ошибка для подогнанной линии (которая отражает прогнозируемые значения при данной линейной или полиномиальной подгонке) вычисляется на основе модели полиномиальной регрессии (предполагается, что данные и их полиномиальные преобразования распределены нормально).

Проверим распределение переменной G на нормальность:

А дальше программа аппроксимировала. Наиболее удачным вариантом мы сочли полином третьей степени, так как в предсказанный интервал попадает наибольшее количество точек:

Промежуточный итог

Само полученное уравнение регрессии является математической моделью теплопотребления выбранного МКД.

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

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

Буду благодарен за критику.

Ссылки на источники

1. Наумов, А. Л. Определение класса энергетической эффективности эксплуатируемых жилых многоквартирных домов / А. Л. Наумов, Д. В. Капко // Энергосбережение. 2015. 8. С. 2430.

2. Mukashev A., Dynamic method of the heating devices efficiency measurement // Mukashev A., Pugovkin A., Kuprekov S., Petrova N.,Abramchuk S, International Scientific Conference Environmental and Climate Technologies, CONECT2017,Riga.

3. П.А. Зорин Контроль энергоэффективности теплоснабжения зданий типовой застройки / П.А. Зорин, С.В. Купреков, А.В. Пуговкин, О.В. Стукач, сборник материалов XIV Международной научно-практической конференции Электронные методы и системы управления, Томск: Томск. гос. ун-т систем упр. и радиоэлектроники, 2018, том 2, С.302-305.

4. О.В. Стукач Программный комплекс Statistica в решении задач управления качеством: Учебное пособие; Национальный исследовательский Томский политехнический университет. Томск: Изд-во Томского политехнического университета, 2011. 163 с.

Добрый день, уважаемые читатели! Материал носит теоретический характер и адресован исключительно начинающим аналитикам, которые впервые столкнулись с BI-аналитикой.

Что традиционно понимается под этим понятием? Если говорить простым языком, то это комплексная система (как и, например, бюджетирование) по сбору, обработке и анализу данных, представляющая конечные результаты в виде графиков, диаграмм, таблиц.

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

В таком случае происходит следующее: сбор, обработка и анализ данных происходит силами единственного инструмента самой BI-платформой. При этом данные предварительно никак не очищаются, не проходят компоновки. Забор информации идет из первичных источников без участия промежуточного хранилища. Результаты такого подхода можно легко лицезреть на тематических форумах. Если постараться обобщить все вопросы касательно BI-инструментов, то в топ-3 попадут, наверное, следующие: как загрузить в систему плохо структурированные данные, как по ним рассчитать требуемые метрики, что делать, если отчет работает очень медленно. Что удивительно, на этих форумах вы практически не найдете обсуждений ETL-инструментов, описания опыта применения хранилищ данных, лучших практик программирования и запросов SQL. Более того, я неоднократно сталкивался с тем, что опытные BI-аналитики не очень лестно отзывались о применении R/Python/Scala, мотивируя это тем, что все проблемы можно решить только силами BI-платформы. Вместе с тем всем понятно, что грамотный дата инжиниринг позволяет закрывать массу проблем при построении BI-отчетности.

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

Data BI Самый простой вариант. Именно с него начинается прототипирование управленческих панелей. В роли источника данных часто выступает отдельный (-ые) статичный файл (csv, txt, xlsx и т. д.).

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

Минусы. Далеко не изо всех источников можно забрать информацию напрямую (пример, прикладные решения на платформе 1С). Если массивы плохо структурированы, то это потребует много дополнительных шагов по их обработке. Качество данных никак не проверяется (проблема дубликатов, пустых строк, некорректного написания значений и т. д.). При большом количестве строк заметно замедляется работа самой BI-платформы, вплоть до полной невозможности перестраивать графики и диаграммы. Нет возможности составить расписание на обновление исходников.

Data DB BI Вариант похож на предыдущий за тем исключением, что первоначальный массив напрямую заливается в базу в неизмененным виде, а уже к ней идет подключение. База данных может быть как развернута локальна, запущена в контейнере, так и представлена облачным хранилищем.

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

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

Data ETL DB BI Частичная автоматизация. В качестве ETL-инструмента может выступать как программный продукт с графическим интерфейсом, так и код написанный на R/Python/Scala и т. д. Все данные проходят предварительный предпроцессинг. Структура наполняемых таблиц прописывается заранее.

Плюсы. Возможность загружать только хорошо структурированную информацию, которая прошла предварительную верификацию. Экономия места в базе данных. Снижается количество доработок на BI-платформе.

Минусы. Аналитик должен уверенно владеть ETL-инструментом и языком запросов SQL. Процесс разработки и тестирования скриптов требует времени. Если источников информации много, то затрудняется синхронизация получения информации.

Для иллюстрации этого варианта я решил написать простейшие скрипты. В рамках игрушечного примера я использую SQLite. Это позволит прикрепить базу данных к публикации, чтобы каждый желающий мог попрактиковаться в написании скриптов (архив). Датасет для разбора это E-Commerce Data с сайта Kaggle.

# импорт библиотекimport pandas as pd# опции отображенияpd.set_option('display.max_columns', 10)pd.set_option('display.expand_frame_repr', False)path_dataset = 'dataset/ecommerce_data.csv'# Предварительная обработка датасетаdef func_main(path_dataset: str):    # Считываем датасет    df = pd.read_csv(path_dataset, sep=',')    # Приводим названия столбцов датасета к нижнему регистру    list_col = list(map(str.lower, df.columns))    df.columns = list_col    # Избавляемся от времени и трансформируем строку-дату в правильный формат    df['invoicedate'] = df['invoicedate'].apply(lambda x: x.split(' ')[0])    df['invoicedate'] = pd.to_datetime(df['invoicedate'], format='%m/%d/%Y')    # Рассчитываем сумму покупки по каждому товару    df['amount'] = df['quantity'] * df['unitprice']    # Удаляем ненужные для дальнейшего анализа столбцы    df_result = df.drop(['invoiceno', 'quantity', 'unitprice', 'customerid'], axis=1)    # Задаем порядок вывода столбцов для визуального контроля результата    df_result = df_result[['invoicedate', 'country', 'stockcode', 'description', 'amount']]    return df_result# Таблица Продажиdef func_sale():    tbl = func_main(path_dataset)    df_sale = tbl.groupby(['invoicedate', 'country', 'stockcode'])['amount'].sum().reset_index()    return df_sale# Таблица Страныdef func_country():    tbl = func_main(path_dataset)    df_country = pd.DataFrame(sorted(pd.unique(tbl['country'])), columns=['country'])    return df_country# Таблица Товарыdef func_product():    tbl = func_main(path_dataset)    df_product = tbl[['stockcode','description']].\        drop_duplicates(subset=['stockcode'], keep='first').reset_index(drop=True)    return df_product

В коде сочетается Extract и Transform. Считываем датасет, парсим столбец с датами. Рассчитываем сумму покупки по каждой строке и удаляем ненужные для дальнейшего анализа колонки. Так как датафрейм записывается в базу данных не монолитом, а разбивается на таблицы, то готовим три вспомогательные функции.

# импорт библиотекimport pandas as pdimport sqlite3 as sqfrom etl1 import func_country,func_product,func_salecon = sq.connect('sale.db')cur = con.cursor()## Таблица Страны# cur.executescript('''DROP TABLE IF EXISTS country;#                     CREATE TABLE IF NOT EXISTS country (#                     country_id INTEGER PRIMARY KEY AUTOINCREMENT,#                     country TEXT NOT NULL UNIQUE);''')# func_country().to_sql('country',con,index=False,if_exists='append')## Таблица Товары# cur.executescript('''DROP TABLE IF EXISTS product;#                     CREATE TABLE IF NOT EXISTS product (#                     product_id INTEGER PRIMARY KEY AUTOINCREMENT,#                     stockcode TEXT NOT NULL UNIQUE,#                     description TEXT);''')# func_product().to_sql('product',con,index=False,if_exists='append')## Таблица Продажи (основная)# cur.executescript('''DROP TABLE IF EXISTS sale;#                     CREATE TABLE IF NOT EXISTS sale (#                     sale_id INTEGER PRIMARY KEY AUTOINCREMENT,#                     invoicedate TEXT NOT NULL,#                     country_id INTEGER NOT NULL,#                     product_id INTEGER NOT NULL,#                     amount REAL NOT NULL,#                     FOREIGN KEY(country_id)  REFERENCES country(country_id),#                     FOREIGN KEY(product_id)  REFERENCES product(product_id));''')## Таблица Продажи (временная)# cur.executescript('''DROP TABLE IF EXISTS sale_data_lake;#                     CREATE TABLE IF NOT EXISTS sale_data_lake (#                     sale_id INTEGER PRIMARY KEY AUTOINCREMENT,#                     invoicedate TEXT NOT NULL,#                     country TEXT NOT NULL,#                     stockcode TEXT NOT NULL,#                     amount REAL NOT NULL);''')# func_sale().to_sql('sale_data_lake',con,index=False,if_exists='append')## Перегружаем данные из вспомогательной таблицы (sale_data_lake) в основную (sale)# cur.executescript('''INSERT INTO sale (invoicedate, country_id, product_id, amount)#                     SELECT  sdl.invoicedate, c.country_id, pr.product_id, sdl.amount#                     FROM sale_data_lake as sdl LEFT JOIN country as c ON sdl.country = c.country#                     LEFT JOIN product as pr ON sdl.stockcode = pr.stockcode#                     ''')## Очищаем вспомогательную таблицу# cur.executescript('''DELETE FROM sale_data_lake''')def select(sql):  return pd.read_sql(sql,con)sql = '''select *        from (select s.invoicedate,                      c.country,                      pr.description,                      round(s.amount,1) as amount               from sale as s left join country as c on s.country_id = c.country_id                            left join product as pr on s.product_id = pr.product_id)'''print(select(sql))cur.close()con.close()

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

В заключении нам остается лишь выполнить тестовый запрос SQL, чтобы проверить корректность всех операций. Если все сделано правильно, запускаем BI-платформу.

Так как BI-инструмент не может из коробки напрямую подключиться к SQLite напишем простейший скрипт на Python.

import pandas as pdimport sqlite3 as sqcon = sq.connect('C:/Users/Pavel/PycharmProjects/test/sale.db')cur = con.cursor()def select(sql):  return pd.read_sql(sql,con)sql = '''select *        from (select s.invoicedate,                      c.country,                      pr.description,                      replace(round(s.amount,1),'.',',') as amount               from sale as s left join country as c on s.country_id = c.country_id                            left join product as pr on s.product_id = pr.product_id)'''tbl = select(sql)print(tbl)

После загрузки данных в систему и проверки корректности распознанных форматов можно приступать к непосредственному построению дашборда.

Data Workflow management platform + ETL DB BI Полная автоматизация. Оркестратор скриптов берет на себя контроль за своевременным выполнением всех вспомогательных процессов в системе.

Плюсы. Возможность оптимально настроить время сбора данных из разрозненных источников. Можно мониторить ошибки и перезапускать упавшие задачи.

Минусы. Усложнение инфраструктуры. Рост требований к квалификации аналитика BI. Необходимо осваивать дополнительные инструменты или языки программирования.

Data Workflow management platform + ELT Data Lake Workflow management platform + ETL DB BI Самый сложный вариант, где информация проходит двухступенчатый конвейер: сначала это неструктурированные данные (Data Lake), а затем уже хранилище (DB), где информация отсортирована и преобразована к требуемому виду.

Плюсы. Возможность разнести во времени сбор информации и ее обработку. Если на этапе проектирования таблиц учтены не все требования, возможно обращение за дополнительными данными в Data Lake.

Минусы. Аналогичны предыдущему варианту. Если выбранная платформа Data Lake платная, как следствие рост расходов на аналитику компании.

Краткие выводы.

• Построение BI-аналитики без даты инжиниринга возможно лишь на старте.

• Если аналитик BI работает в единственном числе и система постоянно усложняется, то он обязан подменять собой сразу несколько специалистов.

• Понимание базовых принципов построения хранилищ данных, уверенное владение SQL, программирование на каком-либо языке и, конечно, дизайнерские навыки вот далеко не полный перечень требований к сотруднику, которому делегируется проектировать управленческие панели.

На этом все. Всем здоровья, удачи и профессиональных успехов!

В преддверии супер-интенсива "ELK" подготовили для вас перевод полезной статьи.

Данные Twitter можно получить множеством способов но кому хочется заморачиваться и писать код? Особенно такой, который будет работать без перебоев и перерывов. В Elastic Stack вы можете с легкостью собирать данные из Twitter и анализировать их. Logstash может в качестве входных данных собирать твиты. Инструмент Kafka Connect, которому посвящена недавняя статья, тоже предоставляет такую возможность, но Logstash может отправлять данные во многие источники (включая Apache Kafka) и проще в использовании.

В этой статье мы рассмотрим следующие вопросы:

• Сохранение потока твитов в Elasticsearch через Logstash

• Визуализации в Kibana (сравнение Xbox и PlayStation)

• Удаление HTML-тегов для ключевого слова с использованием механизма стандартизации

Окружение Elastic Search

Все необходимые компоненты находятся в одном Docker Compose. Если у вас уже есть кластер Elasticsearch, вам понадобится только Logstash.

version: '3.3'services:  elasticsearch:    image: docker.elastic.co/elasticsearch/elasticsearch:7.9.2    restart: unless-stopped    environment:      - discovery.type=single-node      - bootstrap.memory_lock=true      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"    ulimits:        memlock:            soft: -1            hard: -1    volumes:      - esdata:/usr/share/elasticsearch/data    restart: unless-stopped    ports:      - 9200:9200  kibana:    image: docker.elastic.co/kibana/kibana:7.9.2    restart: unless-stopped    depends_on:      - elasticsearch    ports:      - 5601:5601  logstash:    image: docker.elastic.co/logstash/logstash:7.9.2    volumes:      - "./pipeline:/usr/share/logstash/pipeline"    environment:      LS_JAVA_OPTS: "-Xmx256m -Xms256m"    depends_on:      - elasticsearch    restart: unless-stoppedvolumes:  esdata:    driver: local

Конвейер Logtash

input {        twitter {        consumer_key => "loremipsum"        consumer_secret => "loremipsum"        oauth_token => "loremipsum-loremipsum"        oauth_token_secret => "loremipsum"        keywords => ["XboxSeriesX", "PS5"]        full_tweet => false        codec => "json"        }}output {        elasticsearch {            hosts => ["elasticsearch:9200"]            index => "tweets"        }}

Чтобы получить токены и ключи, вам понадобится аккаунт разработчика и приложения Twitter. Этим кодом вы улаживаете все формальности.

Конфигурация самого конвейера очень проста. Поток твитов будет подбираться по словам вkeywords. Если вам нужно больше метаданных, просто присвойте параметруfull_tweet valueзначениеtrue.

Данные

Спустя некоторое время после выполнения командыdocker-compose up -d в индексе tweets появляются данные. На момент написания этой статьи мои данные собирались примерно два дня. Весь индекс весил около 430МБ, что не так уж и много. Возможно, другая лицензия позволила бы получить больший поток данных. Визуализации в этой статье отображают данные, собранные за два дня.

Итак, у нас уже есть индексtweets. Чтобы иметь возможность использовать собранные данные в Kibana, необходимо добавить шаблон индекса.

Облако тегов Xbox и PlayStation

Простое облако тегов с агрегациейhashtags.text.keyword. PS5, судя по всему, выигрывает, но рассмотрим и другие варианты визуализации.

Линейный график Xbox и PlayStation

Тут у меня тоже складывается впечатление, что PlayStation встречается чаще, чем Xbox. Чтобы узнать наверняка, попробуем сгруппировать хештеги. Некоторые пишутPS5, другиеps5, а ведь это один и тот же продукт.

Однако прежде чем двигаться дальше, обратим внимание на один момент. Важен ли порядок бакетов? Разумеется. Вот что произойдет, если изменить гистограмму изTerms.

Чтобы сгруппировать хештеги, мы можем использовать агрегированные фильтры. Добавим еще несколько хештегов, намеренно опустив наименее популярные. В поле Filter используется синтаксис KQL Lucene, только мощнее.

Используем фильтрыhashtags.text.keyword: (PS5 OR ps5 OR PlayStation5 OR PlayStation) иhashtags.text.keyword: (XboxSeriesX OR Xbox OR XboxSeriesS OR xbox). Теперь мы точно знаем, что PlayStation популярнее в Twitter.

Timelion

XBOX И PLAYSTATION

Еще более полную информацию можно получить с помощью Timelion. Этот интересный инструмент позволяет визуализировать временные ряды. В отличие от предыдущего он может визуализировать данные сразу из множества источников.

К синтаксису сперва надо привыкнуть. Ниже приведен код, сгенерировавший эту диаграмму.

.es(index=tweets, q='hashtags.text.keyword: (PS5 OR ps5 OR PlayStation5 OR PlayStation)').label("PS"),.es(index=tweets, q='hashtags.text.keyword: (XboxSeriesX OR Xbox OR XboxSeriesS OR xbox)').label("XBOX")

Смещение

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

.es(index=tweets, q='hashtags.text.keyword: (PS5 OR ps5 OR PlayStation5 OR PlayStation)').label("PS"),.es(index=tweets, q='hashtags.text.keyword: (PS5 OR ps5 OR PlayStation5 OR PlayStation)', offset=-1d).label("PS -1 day")

Вариативность функции (дельта)

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

.es(index=tweets, q='hashtags.text.keyword: (PS5 OR ps5 OR PlayStation5 OR PlayStation)')    .subtract(        .es(index=tweets, q='hashtags.text.keyword: (PS5 OR ps5 OR PlayStation5 OR PlayStation)', offset=-1h)    )    .label("PS 1h delta"),.es(index=tweets, q='hashtags.text.keyword: (XboxSeriesX OR Xbox OR XboxSeriesS OR xbox)')    .subtract(        .es(index=tweets, q='hashtags.text.keyword: (XboxSeriesX OR Xbox OR XboxSeriesS OR xbox)', offset=-1h)    )    .label("XBOX 1h delta")

Круговая диаграмма типы клиентов

Так себе диаграмма

Теперь давайте выясним, какие клиенты используют для написания твитов. Это, оказывается, не так-то просто. Поле с типом клиента содержит HTML-тег, что уменьшает наглядность диаграммы.

Хорошая диаграмма

У Elasticsearch множество возможностей для обработки текста. Так, фильтрhtml_strip позволяет удалять HTML-теги. К сожалению, нам он ничего не даст, поскольку анализаторы можно использовать только для полей типаtext, а нас интересует поле keyword. Для полей этого типа можно использовать агрегацию.

Для полей keyword можно использоватьнормализаторы. Они работают аналогично анализаторам, но на выходе выдают одиночный токен.

Ниже представлен код, добавляющий нормализатор в индексtweets. Поскольку использовать html_strip нельзя, пришлось прибегнуть к регулярным выражениям. Для изменения настроек анализатора в индексе нужно его закрыть. Следующие фрагменты кода вы можете использовать в инструментах разработчика в Kibana.

POST tweets/_closePUT tweets/_settings{  "analysis": {    "char_filter": {      "client_extractor": {        "type": "pattern_replace",        "pattern": "<a[^>]+>([^<]+)</a>",        "replacement": "$1"      }    },    "normalizer": {      "client_extractor_normalizer": {        "type": "custom",        "char_filter": [          "client_extractor"        ]      }    }  }}POST tweets/_open

Добавив нормализатор, мы можем обновить свойство с типом клиента и добавить новое поле значения.

PUT tweets/_mapping{  "properties": {    "client": {      "type": "text",      "fields": {        "keyword": {          "type": "keyword",          "ignore_above": 256        },        "value":{          "type":"keyword",          "normalizer":"client_extractor_normalizer"        }      }    }  }}

К сожалению, это еще не все. Данные индексируются при их добавлении в индекс (интересно, кстати, почему нельзя было назвать его коллекцией, как вMongoDB? ). Мы можем осуществить повторную индексацию документов с помощью механизма Update By Query.

POST tweets/_update_by_query?wait_for_completion=false&conflicts=proceed

Эта операция возвращает task id. Она может отработать небыстро, если у вас много данных. Найти задачу можно с помощью командыGET _cat/tasks?v.

После обновления шаблона индекса в Kibana мы получим значительно более удобочитаемую диаграмму. Здесь мы видим, что примерно одинаковое количество пользователей используют iPhone и устройства Android. Меня крайне заинтриговал клиентBot Xbox Series X.

Что дальше?

У меня были планы разобраться соSpark NLP, но сначала, пожалуй, займусь потоком данных Twitter. Я собираюсь использовать готовые модели Spark NLP для определения языка, тональности текста и других параметров с помощьюSpark Structured Streaming.

Репозиторий

Ссылка

Подробнее об интенсиве "ELK" можно узнать здесь

Сегодня, 4 мая, в день Звездных войн мы подготовили для Вас подробный гайд по основным функциям библиотеки dplyr. Почему именно в день Звездных войн? А потому что разбирать мы все будем на примере датасета starwars.

Ну что, начнем!

Если Вы хотите получать еще больше интересных материалов по программированию, Data Science и математике, то подписывайтесь на нашу группу ВК, канал в Телеграме и Инстаграм. Каждый день мы публикуем полезный контент и вопросы с реальных собеседований.

Кстати говоря, а Вы знаете, почему день Звездных войн отмечается именно 4 мая? Все очень просто - знаменитая фраза May the fource be with you крайне созвучна с May, the 4th, т.е. 4 мая :)

Знакомство с датасетом

Для начала, давайте подключим библиотеку dplyr. Делается это с помощью функции library.

Вместе с этой библиотекой нам становится доступен и датасет starwars. Давайте выведем первые несколько строк на экран и посмотрим, какую информацию он в себе хранит.

1. name - имя или прозвище героя вселенной Звездных войн. Например, Оби-Ван Кеноби.

2. height - высота персонажа

3. mass - масса персонажа

4. hair_color - цвет волос

5. skin_color - цвет кожи

6. eye_color - цвет глаз

7. birth_year - год рождения (до битвы на Явине)

8. sex - биологический пол (есть существа без пола и гермафродиты)

9. gender - поведенческий пол персонажа (например, на какой пол запрограммированы дроиды)

10. homeworld - из какой вселенной существо

11. species - биологический вид

12. films - список фильмов, в которых появилось существо

13. vehicles - список транспорта, которым существо управляло

14. starships - список космических кораблей, которыми существо управляло

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

Знакомство с dplyr

dplyr - это один из основных пакетов семейства tidyverse. Его ближайший аналог в Python - библиотека Pandas. Библиотека dplyr служит для манипуляции с данными: фильтрация, сортировка, создание вычислимых столбцов и так далее.

По своему функционалу библиотека dplyr очень похожа на стандартный синтаксис SQL. Немного ранее мы вместе с Алексеем Селезневым из Netpeak делали карточки: сравнение глаголов dplyr и операторов SQL. Вы можете посмотреть их здесь.

Перед тем, как переходить к рассмотрению глаголов библиотеки dplyr, нужно упомянуть, что все пакеты tidyverse основаны на концепции tidy data. Если коротко, то аккуратные данные - это способ организации датафреймов по трем основным постулатам:

1. Каждая переменная находится в отдельном столбце

2. Каждое измерение находится в отдельной строке

3. Каждое значение находится в отдельной ячейке

Кстати говоря, наш датасет starwars не совсем соответствует этим правилам. Нам это не помешает, но сможете ли Вы найти, в чем именно несоответствие? ;)

Если Вы хотите поподробней познакомиться с tidy data, рекомендуем нашу статью.

Итак, вернемся к глаголам dplyr. Пакет dplyr позволяет делать несколько основных операций:

• Отбор столбцов

• Фильтрация строк

• Сортировка строк

• Группировка

• Агрегирование

• Создание вычислимых столбцов

• Объединение таблиц

Давайте переходить к практике - хватит теории!

Отбор столбцов

Давайте начнем с самого простого - как выбрать только определенные столбцы из таблицы? Очень просто - с помощью функции select.

А что если нам проще указать, какие столбцы не надо отбирать? Например, в таблице 20 столбцов, а нам нужно исключить только первый столбец. Или столбец с определенными названиями. Не проблема - просто добавьте знак минус:

Но и это не все возможности функции select. Мы можем воспользоваться вспомогательными функциями, чтобы кастомизировать отбор столбцов. Вот список этих функций:

• contains: название столбца содержит

• ends_with: название столбца заканчивается на

• matches: название столбца соответствует регулярному выражению

• num_range: поиск занумерованных столбцов, например, V1, V2, V3...

• one_of: название столбца соответствует одному из вариантов

• starts_with: название столбца начинается с

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

Теперь отберем столбцы, название которых является одним из указанных.

И в заключение - поиск по регулярному выражению: отбираем столбцы, в названии которых буква t стоит на любом месте, но после нее обязательно идет хотя бы 1 символ.

Обратите внимание, все наши запросы возвращали таблицу tibble. А что, если мы хотим отобрать столбец и сразу начать работать с ним, как с вектором? Мало кто знает, но для этого в dplyr есть специальная функция pull. Она возвращает не таблицу, как остальные глаголы dplyr, а вектор.

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

Фильтрация строк

Фильтрация строк по значениям - это аналог привычного оператора WHERE в SQL. В синтаксисе dplyr же для этого используется глагол filter (как неожиданно, правда?).

Использовать filter очень просто - задаем некое логическое выражение и функция вернет только те строки, для которых это выражение True. Например:

Вы можете комбинировать несколько условий с помощью & и |:

Логические выражения Вы можете конструировать не только с помощью >/<, но и с помощью других логических операторов:

• >=

• <=

• is.na

• !is.na

• %in%

• !

Например:

Помимо функции filter, отбирать строки можно и с помощью других глаголов. Например, функция distinct позволяет исключить дублирующиеся значения в определенном столбце.

Другая функция, sample_n, отбирает n случайных строк.

Функция slice же, например, позволяет отбирать строки по их индексу:

Функция sample_frac делает случайную подвыборку из таблицы. Нужно указать долю строк из общего числа, которые должны быть в итоговой таблице. Например, при параметре 0.5 вернется половина строк из таблицы, выбранные случайным образом.

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

Сортировка строк

За сортировку строк в SQL отвечает оператор ORDER BY. В dplyr для этого существует функция arrange.

Синтаксис максимально прост - достаточно указать столбец, по которому выполняется сортировка.

Чтобы отсортировать строки по убыванию, достаточно добавить функцию desc.

А если отсортировать нужно по нескольким столбцам? Легко, просто указываем их названия :)

Кстати говоря, с arrange Вы можете также использовать вспомогательные глаголы, которые мы обсуждали в блоке с select. Для этого нужно использовать функцию across. Например:

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

Группировка и агрегатные функции

Группировка - базовая операция, которая необходима для расчета различных характеристик - средних значений, медиан, сумм, количества строк в группе и так далее. В SQL для этого используется оператор GROUP BY и агрегатные функции sum, min, max и так далее. В dplyr же все то же самое :) Ну, почти.

Давайте для начала сгруппируем наши строки по полю eye_color:

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

Давайте посчитаем для каждой группы среднюю массу, максимальную массу, минимальную массу, медианную массу, самую первую массу в группе и количество элементов в каждой группе.

Обратите внимание, здесь мы дополнительно воспользовались функцией drop_na из пакета tidyr, чтобы удалить строки, в которых есть пропуски. Сделали мы это, чтобы при расчете наших максимальных/минимальных/других агрегатных значений не вылезали значения NA.

На выходе мы получили 4 группы (во всех остальных были пропуски, по всей видимости) и рассчитанные для них характеристики. Также каждому столбцу присвоено то имя, которое мы дали ему в функции summarise.

Мы с Вами здесь использовали только несколько агрегатных функций, но вообще говоря, их больше:

• n_distinct - считает количество уникальных элементов в группе

• last - возвращает последнее значение в группе

• nth - возвращает n-ое значение из группы

• quantile - возвращает заданную квантиль

• IQR - межквартильный размах, inter-quartile range

• mad - медианное абсолютное отклонение, median absolute deviation

• sd - стандартное отклонение

• var - вариация

Хорошо, с базовой группировкой мы разобрались. А что если пойти дальше

Продвинутая группировка

А как Вам такая задача - рассчитать все те же самые характеристики, что и в прошлый раз, но сразу для нескольких столбцов? Например, мы делали для mass, а теперь давайте сделаем для mass и height.

Без проблем - достаточно применить уже известную функцию across.

Видно, что характеристики рассчитались по полю mass и height для каждой группы в отдельности. Если не устраивает название столбцов, которое система дала по умолчанию (столбец_характеристики), то можно менять шаблон с помощью параметра .names.

Итак, на этом закончим раздел группировки и перейдем к вычислимым столбцам.

Вычислимые столбцы

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

Для начала базовая вещь - создадим вычислимый столбец отношения веса к росту.

А если нам нужно применить одну и ту же функцию к нескольким столбцам? Без проблем - снова нас выручит across. Например, давайте умножим на 10 все столбцы с численным типом данных. При этом мы не будем создавать новые столбцы - мы модифицируем старые.

Видно, что в столбцах с весом, ростом и возрастом все значения умножились на 10.

Давайте и с текстом немного поработаем - ко всем строковым значениям добавим суффикс _new. Для этого нам понадобится библиотека stringr все из того же семейства tidyverse.

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

Помимо всего прочего, mutate позволяет реализовать аналог оконных функций в SQL. Например, давайте проранжируем строки без разрывов по полю mass с помощью функции dense_rank:

Видно, что в конец таблицы добавился новый столбец rnk с рангами для каждой строки.

Таких функций, на самом деле, масса. Вот некоторые из них:

• lag

• lead

• cumsum

• dense_rank

• ntile

• row_number

• case_when

• coalesce

Это, пожалуй, самые популярные и все они на 100% перекликаются с SQL. Приведем несколько примеров.

Ну что, давайте переходить к последнему пункту - к объединению таблиц.

Объединение таблиц

Пожалуй, последняя необходимая для полноценной работы с датафреймами операция - объединение таблиц. Операция объединения в dplyr тесно связана с джоинами в SQL. Вот перечень основных функций:

• left_join

• right_join

• inner_join

• full_join

Аналогичные глаголы присутствуют и в стандартном SQL. Давайте создадим новую таблицу - возьмем датасет starwars и оставим только те строки, где вид существа - человек. А после попробуем различные виды джоинов.

Обратите внимание, мы воспользовались функцией rename и переименовали поле name. Сделали мы это намеренно, чтобы показать работу аргумента by (аналог ON в SQL) для связи столбцов при джоине.

Делаем inner_join, на выходе получаем только 35 строк, т.к. в таблице df строк именно 35. Аргумент by позволил нам указать, через какие столбцы таблицы связаны между собой.

Если сделать full_join аналогичным образом, то строк в итоговой таблице будет 87, т.к. в таблице starwars их 87.

Внимательный читатель может заметить, что при джоине одни и те же столбцы продублировались из двух таблиц. Т.е. столбец mass, например, в итоговой таблице фигурирует с суффиксом .x и .y. Как от этого избавиться?

1 вариант:

Если название столбцов позволяет, то Вы можете убрать аргумент by из джоина. Тогда соединяться таблицы будут по всем столбцам, у которых совпадает названием. В нашем случае этот вариант подходит - названия одинаковые и в результат добавится только один столбец - new_name.

2 вариант:

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

Помимо различных джоинов, в dplyr есть еще другие функции для соединения таблиц:

• bind_rows - помещает одну таблицу под другой

• bind_cols - ставит одну таблицу справа от другой

• intersect - находит пересекающиеся строки

• setdiff - разность таблиц, т.е. строки из первой таблицы, которых нет во второй

• union - возвращает строки, которые есть в любой из таблиц (дубликаты исключаются)

• union_all - аналогично union, но оставляет дуликаты

Эпилог

Мы с Вами рассмотрели все основные операции библиотеки dplyr и почти все основные функции. Все остальное - практика, практика и еще раз практика. Если у Вас будут вопросы - рады будем помочь и ответить в комментариях :)

Если Вы хотите получать еще больше интересных материалов по программированию, Data Science и математике, то подписывайтесь на нашу группу ВК, канал в Телеграме и Инстаграм. Каждый день мы публикуем полезный контент и вопросы с реальных собеседований.

А, и совсем забыли. May the fource be with you!

P.S. Здесь Вы можете найти официальную шпаргалку по всем функциям dplyr. Все удобно и компактно собрано в одном месте :)

Перевод подготовлен в рамках курса "Machine Learning. Basic".

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

Не знаете, какой инструмент визуализации использовать? В этой статье мы подробно расскажем о плюсах и минусах каждой библиотеки.

Это руководство было дополнено несколькими подробными примерами. Вы также можете отслеживать актуальные версии этой статьи здесь.

Мотивация

Если вы только собираетесь начать работу с визуализацией в Python, количество библиотек и решений вас определенно поразит:

• Matplotlib

• Seaborn

• Plotly

• Bokeh

• Altair

• Folium

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

Мы будем использовать один и тот же набор данных, на примере которого будем рассматривать каждую библиотеку, уделяя особое внимание нескольким показателям:

Интерактивность

Хотите ли вы, чтобы ваша визуализация была интерактивной?

Визуализация в некоторых библиотеках, таких как Matplotlib, является простым статичным изображением, что хорошо подходит для объяснения концепций (в документе, на слайдах или в презентации).

Другие библиотеки, такие как Altair, Bokeh и Plotly, позволяют создавать интерактивные графики, которые пользователи могут изучать, взаимодействуя с ними.

Синтаксис и гибкость

Чем отличается синтаксис каждой библиотеки? Библиотеки низкого уровня, такие как Matplotlib, позволяют делать все, что вы захотите, но за счет более сложного API. Некоторые библиотеки, такие как Altair, очень декларативны, что упрощает построение графиков по вашим данным.

Тип данных и визуализации

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

Данные

Чтобы было проще сравнивать библиотеки, здесь представлены реальные данные с Github из этой статьи:

I Scraped more than 1k Top Machine Learning Github Profiles and this is what I Found

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

Вы можете скачать файл csv здесь, либо получите данные напрямую из Datapane Blob.

import datapane as dpdp.Blob.get(name='github_data', owner='khuyentran1401').download_df()

Не забудьте залогиниться со своим токеном авторизации в Datapane, если вы хотите использовать Blob. Это займет менее минуты.

Matplotlib

Matplotlib, вероятно, является самой популярной библиотекой Python для визуализации данных. Все, кто интересуется data science, наверняка хоть раз сталкивались с Matplotlib.

Плюсы

1. Четко отображены свойства данных

При анализе данных возможность быстро посмотреть распределение может быть очень полезной.

Например, если я хочу быстро посмотреть распределение топ 100 пользователей с наибольшим количеством подписчиков, обычно Matplotlib мне будет вполне достаточно:

import matplotlib.pyplot as plttop_followers = new_profile.sort_values(by='followers', axis=0, ascending=False)[:100]fig = plt.figure()plt.bar(top_followers.user_name,       top_followers.followers)

Даже что-то вроде этого:

fig = plt.figure()plt.text(0.6, 0.7, "learning", size=40, rotation=20.,         ha="center", va="center",         bbox=dict(boxstyle="round",                   ec=(1., 0.5, 0.5),                   fc=(1., 0.8, 0.8),                   )         )plt.text(0.55, 0.6, "machine", size=40, rotation=-25.,         ha="right", va="top",         bbox=dict(boxstyle="square",                   ec=(1., 0.5, 0.5),                   fc=(1., 0.8, 0.8),                   )         )plt.show()

Минусы

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

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

correlation = new_profile.corr()fig, ax = plt.subplots()im = plt.imshow(correlation)ax.set_xticklabels(correlation.columns)ax.set_yticklabels(correlation.columns)plt.setp(ax.get_xticklabels(), rotation=45, ha="right",         rotation_mode="anchor")

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

Seaborn

Seaborn - это библиотека Python для визуализации данных, построенная на базе Matplotlib. Она более высокоуровневая, что упрощает ее использование.

Плюсы

1. Меньше кода

Предоставляет интерфейс более высокого уровня для построения похожих графиков. Другими словами, seaborn обычно строит графики, аналогичные matplotlib, но с меньшим количеством кода и более красивым дизайном.

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

correlation = new_profile.corr()sns.heatmap(correlation, annot=True)

Мы получаем лучший график пользовательской активности без возни x и y!

2. Делает стандартные графики красивее

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

sns.set(style="darkgrid")titanic = sns.load_dataset("titanic")ax = sns.countplot(x="class", data=titanic)

Минусы

Seaborn более ограничен и не имеет такой широкой коллекции графиков, как matplotlib.

Вывод: Seaborn это версия Matplotlib более высокого уровня. Несмотря на то, что коллекция графиков не настолько большая, как в Matplotlib, созданные с помощью seaborn широко используемые графики (например, столбчатая диаграмма, прямоугольная диаграмма, график пользовательской активности и т. д.), при меньшем количестве кода будет выглядеть визуально приятнее.

Plotly

Python библиотека Plotly упрощает создание интерактивных графиков типографского качества. Он также может создавать диаграммы, аналогичные Matplotlib и seaborn, такие как линейные графики, точечные диаграммы, диаграммы с областями, столбчатые диаграммы и т. д.

Плюсы

1. Похож на R

Если вы поклонник графиков в R и вам не хватает его функционала при переходе на Python, Plotly даст вам такое же качество графиков с использованием Python!

Мой любимая версия - Plotly Express, потому что с ней можно легко и быстро создавать отличные графики одной строчкой в Python.

import plotly.express as pxfig = px.scatter(new_profile[:100],          x='followers',          y='total_stars',          color='forks',          size='contribution')fig.show()

2. Простота создания интерактивных графиков

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

Помните столбчатую диаграмму, которую мы показывали ранее в matplotlib? Давайте посмотрим, как она получится с помощью Plotly

import plotly.express as pxtop_followers = new_profile.sort_values(by='followers', axis=0, ascending=False)[:100]fig = px.bar(top_followers,              x='user_name',              y='followers',            )fig.show()

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

3. Легко делать сложные графики

С помощью Plotly достаточно легко создавать сложные графики.

Например, если мы хотим создать карту для визуализации местоположения пользователей GitHub, мы можем найти широту и долготу их расположения как показано здесь, а затем использовать эти данные чтобы отметить местоположение пользователей уже на карте:

import plotly.express as pximport datapane as dplocation_df = dp.Blob.get(name='location_df', owner='khuyentran1401').download_df()m = px.scatter_geo(location_df, lat='latitude', lon='longitude',                 color='total_stars', size='forks',                 hover_data=['user_name','followers'],                 title='Locations of Top Users')m.show()

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

Вывод: Plotly отлично подходит для создания интерактивных и качественных графиков при помощи всего нескольких строк кода.

Altair

Altair - это библиотека Python декларативной статистической визуализации, которая основана на vega-lite, что идеально подходит для графиков, требующих большого количества статистических преобразований.

Плюсы

1. Простая грамматика визуализации

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

Например, для данных о Титанике выше мы хотели бы подсчитать количество людей в каждом классе. Все, что нам нужно, это использовать count() в y_axis

import seaborn as snsimport altair as alt titanic = sns.load_dataset("titanic")alt.Chart(titanic).mark_bar().encode(    alt.X('class'),    y='count()')

2. Простота преобразования данных

Altair также упрощает преобразование данных при создании диаграммы.

Например, мы хотим определить средний возраст каждого пола на Титанике и вместо того, чтобы выполнять преобразование заранее, как в Plotly, в Altair есть возможность выполнить преобразование в коде, описывающем диаграмму.

hireable = alt.Chart(titanic).mark_bar().encode(    x='sex:N',    y='mean_age:Q').transform_aggregate(    mean_age='mean(age)',    groupby=['sex'])hireable

Логика здесь состоит в том, чтобы использовать transform_aggregate() для взятия среднего значения возраста (mean(age)) каждого пола (groupby=['sex']) и сохранить его в переменной mean_age). За ось Y мы берем переменную.

Мы также можем убедиться, что класс - это номинальные данные (категорийные данные в произвольном порядке), используя :N, или что mean_age - это количественные данные (меры значений, такие как числа), используя :Q.

Полный список преобразований данных можно найти здесь.

3. Связывание нескольких графиков

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

Например, мы хотим визуализировать количество людей из каждого класса в пределах значений, ограниченных выделенным интервалом в точечной диаграмме по возрасту и плате за проезд. Тогда нам нужно написать что-то вроде этого:

brush = alt.selection(type='interval')points = alt.Chart(titanic).mark_point().encode(    x='age:Q',    y='fare:Q',    color=alt.condition(brush, 'class:N', alt.value('lightgray'))).add_selection(    brush)bars = alt.Chart(titanic).mark_bar().encode(    y='class:N',    color='class:N',    x = 'count(class):Q').transform_filter(    brush)points & bars

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

Минусы

Если вы не задаете пользовательский стиль, простые диаграммы, такие как, например, столбчатые, не будут оформлены стилистически так же хорошо, как в seaborn или Plotly. Altair также не рекомендует использовать наборы данных с более чем 5000 экземплярами и рекомендует вместо этого агрегировать данные перед визуализацией.

Вывод: Altair идеально подходит для создания сложных графиков для отображения статистики. Altair не может обрабатывать данные, превышающие 5000 экземпляров, и некоторые простые диаграммы в нем уступают по стилю Plotly или Seaborn.

Bokeh

Bokeh - это интерактивная библиотека для визуализации, предназначенная для презентации данных в браузерах.

Плюсы

1. Интерактивная версия Matplotlib

Если мы будем будем составлять топы интерактивных библиотек для визуализации, Bokeh, вероятно, займет первое место в категории сходства с Matplotlib.

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

Например, круговой график Matplotlib,

import matplotlib.pyplot as pltfig, ax = plt.subplots()x = [1, 2, 3, 4, 5]y = [2, 5, 8, 2, 7]for x,y in zip(x,y):     ax.add_patch(plt.Circle((x, y), 0.5, edgecolor = "#f03b20",facecolor='#9ebcda', alpha=0.8))#Use adjustable='box-forced' to make the plot area square-shaped as well.ax.set_aspect('equal', adjustable='datalim')ax.set_xbound(3, 4)ax.plot()   #Causes an autoscale update.plt.show()

который, в Bokeh, может быть создан с лучшим разрешением и функциональностью:

from bokeh.io import output_file, showfrom bokeh.models import Circlefrom bokeh.plotting import figurereset_output()output_notebook()plot = figure(plot_width=400, plot_height=400, tools="tap", title="Select a circle")renderer = plot.circle([1, 2, 3, 4, 5], [2, 5, 8, 2, 7], size=50)selected_circle = Circle(fill_alpha=1, fill_color="firebrick", line_color=None)nonselected_circle = Circle(fill_alpha=0.2, fill_color="blue", line_color="firebrick")renderer.selection_glyph = selected_circlerenderer.nonselection_glyph = nonselected_circleshow(plot)

2. Связь между графиками

В Bokeh также можно достаточно просто связывать графики. Изменение, примененное к одному графику, будет применено к другому графику с этой же переменной.

Например, если мы создаем 3 графика рядом и хотим наблюдать их взаимосвязь, мы можем связанное закрашивание

from bokeh.layouts import gridplot, rowfrom bokeh.models import ColumnDataSourcereset_output()output_notebook()source = ColumnDataSource(new_profile)TOOLS = "box_select,lasso_select,help"TOOLTIPS = [('user', '@user_name'),            ('followers', '@followers'),            ('following', '@following'),            ('forks', '@forks'),             ('contribution', '@contribution')]s1 = figure(tooltips=TOOLTIPS, plot_width=300, plot_height=300, title=None, tools=TOOLS)s1.circle(x='followers', y='following', source=source)s2 = figure(tooltips=TOOLTIPS, plot_width=300, plot_height=300, title=None, tools=TOOLS)s2.circle(x='followers', y='forks', source=source)s3 = figure(tooltips=TOOLTIPS, plot_width=300, plot_height=300, title=None, tools=TOOLS)s3.circle(x='followers', y='contribution', source=source)p = gridplot([[s1,s2,s3]])show(p)

Минусы

Поскольку Bokeh - это библиотека, которая имеет интерфейс среднего уровня, она часто требует меньше кода, чем Matplotlib, но требует больше кода для создания того же графика, чем Seaborn, Altair или Plotly.

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

Если мы не добавим ширину столбцов графика, то он будет выглядеть так:

from bokeh.transform import factor_cmapfrom bokeh.palettes import Spectral6p = figure(x_range=list(titanic_groupby['class']))p.vbar(x='class', top='survived', source = titanic_groupby,      fill_color=factor_cmap('class', palette=Spectral6, factors=list(titanic_groupby['class'])      ))show(p)

Таким образом, нам нужно вручную настраивать параметры, чтобы сделать график более красивым:

from bokeh.transform import factor_cmapfrom bokeh.palettes import Spectral6p = figure(x_range=list(titanic_groupby['class']))p.vbar(x='class', top='survived', width=0.9, source = titanic_groupby,      fill_color=factor_cmap('class', palette=Spectral6, factors=list(titanic_groupby['class'])      ))show(p)

Если вы хотите создать красивую столбчатую диаграмму, используя меньшее количеством кода, то для вас это может быть недостатком Bokeh по сравнению с другими библиотеками

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

Folium

Folium позволяет легко визуализировать данные на интерактивной встраиваемой карте. В библиотеке есть несколько встроенных тайлсетов из OpenStreetMap, Mapbox и Stamen

Плюсы

1. Очень легко создавать карты с маркерами

Несмотря на то, что Plotly, Altair и Bokeh также позволяют нам создавать карты, Folium использует открытую уличную карту, что-то близкое к Google Map, с помощью минимального количества кода

Помните, как мы создавали карту для визуализации местоположения пользователей Github с помощью Plotly? Мы могли бы сделать карту еще лучше с помощью Folium:

import folium# Load datalocation_df = dp.Blob.get(name='location_df', owner='khuyentran1401').download_df() # Save latitudes, longitudes, and locations' names in a listlats = location_df['latitude']lons = location_df['longitude']names = location_df['location']# Create a map with an initial locationm = folium.Map(location=[lats[0], lons[0]])for lat, lon, name in zip(lats, lons, names):      # Create marker with other locations    folium.Marker(location=[lat, lon],                  popup= name,                  icon=folium.Icon(color='green')).add_to(m)    m

Живой вариант карты можно посмотреть в оригинале: https://towardsdatascience.com/top-6-python-libraries-for-visualization-which-one-to-use-fe43381cd658

2. Добавление потенциального местоположения

Если мы хотим добавить потенциальные местоположения других пользователей, Folium упрощает это, позволяя пользователям добавлять маркеры:

# Code to generate map here#....# Enable adding more locations in the mapm = m.add_child(folium.ClickForMarker(popup='Potential Location'))

Живой вариант карты можно посмотреть в оригинале: https://towardsdatascience.com/top-6-python-libraries-for-visualization-which-one-to-use-fe43381cd658

Кликните на карту, чтобы увидеть новое местоположение, созданное прямо там, где вы кликнули.

3. Плагины

У Folium есть ряд плагинов, которые вы можете использовать со своей картой, в том числе плагин для Altair. Что, если мы хотим увидеть карту пользовательской активности общего количества звездных пользователей Github в мире, чтобы определить, где находится большое количество пользователей Github с большим количеством звезд? Карта пользовательской активности в плагинах Folium позволяет вам это сделать:

from folium.plugins import HeatMapm = folium.Map(location=[lats[0], lons[0]])HeatMap(data=location_df[['latitude', 'longitude', 'total_stars']]).add_to(m)

Живой вариант карты можно посмотреть в оригинале: https://towardsdatascience.com/top-6-python-libraries-for-visualization-which-one-to-use-fe43381cd658

Уменьшите масштаб, чтобы увидеть полное отображение пользовательской активности на карте.

Вывод: Folium позволяет создавать интерактивную карту в несколько строк кода. Он дает вам ощущения близкие к использованию Google Map.

Заключение

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

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

Не стесняйтесь форкать и использовать код для этой статьи из этого репозитория на Github.

Мне нравится писать об основных концепциях data science и пробовать различные алгоритмы и инструменты анализа данных. Вы можете связаться со мной в LinkedIn и Twitter.

Отметьте этот репозиторий, если хотите изучить код всех статей, которые я писал. Следите за мной на Medium, чтобы быть в курсе моих последних статей по data science.

Узнать подробнее о курсе "Machine Learning. Basic"

Смотреть онлайн-интенсив Data Science это проще, чем кажется

Содержание

1. Введение

2. Про эксперименты

3. Что такое сетевой эффект?

4. Почему switchback помогает?

5. Зачем так сложно, может, у вас нет сетевого эффекта?

6. Убедили, как подобрать окно переключения по расстоянию и времени?

7. Слабые стороны Switchback

8. О следующей статье

Введение

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

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

Разработка алгоритма это творческий процесс, поэтому в своей работе мы генерируем и проверяем много гипотез, часть из которых потом-таки попадают в продовую версию алгоритма. Каждая такая идея проходит путь от аналитики и dry-mode (так мы называем что-то вроде backtesting'а) до экспериментов на реальных городах и, в лучшем случае, раскатки на всю Россию.

Про эксперименты

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

До середины 2019 года чаще всего мы проводили рандомизированные A/B-тесты сосплитованием по hash (id), реже W2W (week-to-week, то есть когда производится сравнение выборок за одно время и один день недели, но в разные периоды), или diff-in-diff (подробнее см. здесь) эксперименты. Но все эти подходы для наших задач имеют ряд больших недостатков.

В W2W и diff-in-diff оценках может быть сложно обеспечить сопоставимые условия в тестовой и контрольной группах. Как-то мы хотели провести W2W-оценку, а в нашем тестовом городе на второй неделе была песчаная буря.

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

С рандомизированными A/B-тестами проблемы не такие очевидные. Когда вы запускаете рандомизированный А/В-тест в двух-трёх-n-стороннем маркетплейсе, то у вас может возникнуть сетевой эффект (не бойтесь, об этом термине поговорим в следующем разделе), который ставит под вопрос валидность теста в целом.

В итоге мы пришли к использованию геохроносплитования (в переводе со сложного означает разбиение районов города на экспериментальные группы, с перемешиванием каждые n минут), а затем обнаружили, что этот подход популярен, и называется этот загадочный зверь switchback. К нему мы ещё вернёмся.

Что такое сетевой эффект?

Главное условие валидности А/В-теста stable unit treatment value assumption (SUTVA), которое говорит, что измененные условия воздействуют только на группу, к которой они были применены, и не воздействуют на пользователей из других групп.

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

Слишком сложная схема, давайте на примере:

Пусть Миша с Колей живут в соседних домах напротив друг друга и каждое утро примерно в одно время едут на такси до метро. Наша команда динамического ценообразования начала эксперимент, и так получилось, что Миша и Коля оказались в разных группах. Для Коли цена будет рассчитываться старым алгоритмом, а для Миши новым, который по каким-то причинам снизил утром на 5 % цену поездки до метро. Наступает очередное утро, и Миша с Колей заказывают такси примерно в одно время. Цена у Миши ниже обычного, и он принимает решение о заказе такси быстрее, тем самым отнимая водителя у Коли. Коля оказывается без машины, и мы вынуждены изменить для него цену, чтобы он отказался от поездки, так как свободных машин в округе больше нет. Получается, что конверсия Коли занижена из-за Миши, то есть измененные условия повлияли не только на решение Миши, но и на Колю, и SUTVA не выполняется.

Это и есть сетевой эффект. Если формулировать более научно, то:

Сетевой эффект это ситуация в экспериментах, когда поведение одного потребителя услуги или товара может влиять на характеристики или даже возможность предоставления услуги/товара для другого потребителя. Этот эффект особенно актуален для двустороннего маркетплейса, потому что предположение об отсутствии влияния (SUTVA) здесь не может быть принято.

Спасительный Switchback

SUTVA не выполняется, рандомизированный А/В-тест под угрозой. Как же нам теперь проводить честные эксперименты?

Здесь нам на помощь приходит тип эксперимента, который называется Switchback.

Switchback метод геохроносплитования контрольных и тестовых групп с гиперпараметрами в виде длительности применения группы на все наблюдения и площади применения группы.

Суть метода Switchback заключается в следующем:

1. Имеющиеся районы разбивают на контрольные и экспериментальные группы. К экспериментальным применяется тестируемый алгоритм.

2. Через короткий промежуток времени районы случайно изменяются (мы считаем районами группы гексагонов, используем гексагональную сетку от Uber; подробнее читайте здесь). Затем они снова меняются, и так далее. Процесс перестановки продолжается в течение всего эксперимента.

3. Показатели за время, когда алгоритм действовал и бездействовал, считаются в разные корзины.

4. Показатели из двух корзин сравниваются, что позволяет оценить влияние алгоритма на различные ситуации.

Теперь Миша и Коля с бОльшей вероятностью оказались бы в одной группе, так как они близко друг к другу по расстоянию и времени. Решение они принимали бы в одинаковых условиях, и SUTVA не нарушилось бы.

Почему Switchback помогает?

В какой ситуации сетевой эффект максимален? Когда пассажиры могут забирать друг у друга машины, то есть близки друг к другу по времени и расстоянию. А теперь попробуем визуализировать сетевой эффект и посмотрим, что делает Switchback. Обозначим взаимное влияние между пассажирами через линию. Она есть, если пассажиры относятся к разным группам то есть влияют своим измененным поведением на неизменных участников; и линии нет, если пассажиры относятся к одной группе. В первом случае пользователи разбились на группы случайно, и внутри одной геозоны есть пользователи из разных групп; во втором случае вся геозона полностью относится к одной группе. Как видите, во втором случае количество взаимодействия (сиреневых линий) резко сократилось, это и есть главный эффект Switchback.

Мы даже можем оценить сокращение взаимодействия численно!

Взаимное влияние пассажиров друг на друга

Пусть пассажир определяется вектором:

где

• t время, в которое клиент зашел в приложение;

• latitude долгота точки заказа;

• longtitude широта точки заказа.

Тогда взаимное влияние пассажиров друг на друга interaction введем следующим образом: как будто и мы считаем расстояние между точками, только одну из координат заменили на время:

Почему interaction это дробь?

Interaction обратно пропорционален расстоянию между клиентами и временем между калькуляциями, то есть чем "дальше" друг от друга клиенты по расстоянию или времени, тем меньше они влияют друг на друга.

Поэтому подходящие виды зависимостей для определения interaction могут быть следующие:

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

Зачем нужны веса?

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

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

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

Сравним, как пассажиры влияют друг на друга в рандомизированном А/В и Switchback.

Теперь поступим так же, как в примере с кругами. Если пользователи относятся к разным группам, то взаимное влияние между ними есть, и мы его считаем по формуле для interaction выше. Если к разным, то считаем, что его нет. По сути, мы проставляем веса на черные линии из картинки выше и суммируем их для некоторого промежутка времени. Стоит отметить, что также для упрощения и ускорения подсчетов мы ограничили дельту между клиентами, когда учитываем их взаимное влияние, 6 минутами и 3 км, их также получили на реальных данных.

Если такое проделать на Москве в течение одного дня и сравнить уровень взаимодействия для рандомизированного эксперимента и Switchback, то Switchback снижает сетевой эффект более чем на 70%.

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

Зачем так сложно, может, у вас нет сетевого эффекта?

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

Убедили, как подобрать окно переключения по расстоянию и времени?

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

Сформулируем, что есть Bias, а что Margin of Error.

Разница в средних между нашими группами при семплирования назовем Bias смещение. Например, когда мы делаем АА-тест нам бы очень хотелось, чтобы разница в средних между группами А1 и А2 не было, иначе мы не сможем запустить наш тест. Имеется в виду, конечно, что не будет статистически значимой разницы.

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

Теперь опустимся на практику и поговорим про параметры сплитования, и как они связаны с Bias и Margin. Для более удобных формулировок введем понятие Unit. Unit кусочек времени и пространства, который отсекается определенным промежутком времени и геозоной.

Теперь обсудим связь размера Unit'a c Bias. Когда мы уменьшаем географическую зону и промежуток переключения групп, выборка уменьшается, и мы с большей вероятностью соберем нерепрезентативные смещенные данные. Представим ситуацию, где мы хотим протестировать два алгоритма, один из которых обрабатывает заказы по мере поступления, а другой - обрабатывает сначала короткие поездки, а уже потом все остальные. Тогда при слишком быстром переключении мы можем получить ситуацию, при которой один алгоритм будет обрабатывать только короткие поездки, а другой будет пытаться исправить ситуацию после выбора другого алгоритма. При этом сделать какие-то обобщающие выводы мы не сможем, так как в данных по поездкам будет заложено смещение, которое возникло из-за слишком частой смены групп. То есть при уменьшении размера Unit'a (уменьшаем окно сплитования, например, было 20 минут стало 10, и уменьшении геозоны стали работать с более маленькими гексагонами) растет Bias.

С Margin капельку сложнее, но мы справимся. Margin зависит от двух вещей от разброса данных, с которыми мы работаем и от их количества (снова см. подробнее тут).

где дисперсия выборки, а сколько Unit'ов у нас есть. При уменьшении периода переключения или работе с более мелкими геозонами растет количество Unit'ов, с которых мы собираем наблюдения. Но при этом растет и дисперсия нашей выборки маленькие Unit'ы менее похожи друг на друга и содержат больше выбросов. При увеличении сплита и, как следствие, объема данных внутри него эти выбросы сглаживаются, дисперсия снижается.

Зависимость, конечно, не однозначная, но на практике всё-таки дисперсия растёт не так быстро, как количество зон, потому что города ведут себя относительно стабильно, за исключением, каких-то особых периодов, например, дождя или вечера 31-го декабря. Поэтому в целом можно сказать, что при уменьшении размера Unit'а Margin падает. Но важно иметь ввиду, что природа этой зависимости на ваших данных может оказаться другой.

Получается вот такая сложная зависимость, с которой нам нужно как-то жить, если хотим запустить Switchback):

Как же жить с такой сложной зависимостью на практике:

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

CookBook для запуска первого в вашей жизни Switchback-теста такой (такие вводные работают для нас):

• держим тест около 2 недель в зависимости от объема рынка;

• проводим сплитование по гексагонам размером 6 (то есть по районам площадью 36 кв. км.);

• переключение происходит раз в 20 минут.

Выглядит это примерно так:

Теперь самое время пойти и запустить с первыми вводными AA-тест в Switchback на исторических данных для своего маркетплейса!

Слабые стороны Switchback

Конечно, Switchback не безгрешен и имеет несколько особенностей, с которыми стоит быть внимательными.

Сохранение сетевого эффекта

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

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

Осторожно, вы в эксперименте

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

Бороться с этим можно такой же очисткой данных, как и в предыдущем случае.

Мощность ниже

Чистка может негативно повлиять на мощность эксперимента. Кроме этого, на мощность switchback негативно влияет и единица рандомайза пара регион+время.

Сложность экспериментов с визуальными изменениями

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

Долгосрочный эффект

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

Сходимость групп

АА-тест стоит использовать не только для подбора окна или геозоны агрегации, но даже если вы уже проводили тест на городе и точно знаете, какие периоды переключения вас устраивают. Не стоит пренебрегать АА-тестом для проверки равномерности разбиения на группы.

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

Завести А/А-тест в дизайн вашего эксперимента можно двумя путями. Если вы уверены, что ваш маркетплейс стабилен во времени, то можно подержать А/А-тест перед А/В-тестом и убедиться, что разбиение на группы равномерное. Если же такой уверенности нет, то можно сразу провести А/А/В-тест. Но здесь хорошо бы проверить, что вам хватит данных, чтобы честно сравнить группы А1 и А2 между собой.

Если всё-таки ваш выбор пал на А/А/В-тест, то распределение по группам лучше держать 25 %/25 %/50 %, так в теории мощность вашего теста будет выше (по сравнению с менее сбалансированными группами), подробнее об этом можно почитать вот тут.

О следующей статье

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

В подготовке статьи участвовали Артём Солоухин, Ксения Мензорова, Николай Ишмаметьев. Также выражаем благодарность за помощь в подготовке статьи ребятам из expf.ru, Искандеру Мирмахмадову и Виталию Черемисинову.

Как отдельная профессия Big Data Engineering появилась довольно недавно. И даже крупные компании очень часто путают, чем занимается этот специалист, каковы его компетенции и зачем он вообще в организации.

Поэтому в сегодняшней статье мы разберёмся, кто такой Big Data Engineer, чем он занимается и чем отличается от Data Analyst и Data Scientist. Этот гайд подойдёт людям, которые хотят работать с большими данными и присматриваются к профессии в целом. А также тем, кто просто хочет понять, чем занимаются инженеры данных.

Кто такой Big data engineer

Задачи, которые выполняет инженер больших данных, входят в цикл разработки машинного обучения. Его работа тесно связана с аналитикой данных и data science.

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

Инженер данных востребован в самых разных сферах: e-commerce, финансах, туризме, строительстве в любом бизнесе, где есть поток разнообразных данных и потребность их анализировать.

К примеру, при разработке умного дома. Создание подобной системы требует считывания и обработки данных с IoT-сенсоров в режиме реального времени. Необходимо, чтобы данные обрабатывались с максимальной быстротой и минимальной задержкой. И даже при падении системы данные должны продолжать накапливаться, а затем и обрабатываться. Разработка системы, которая удовлетворяет этим требованиям, и есть задача инженера данных.

С технической стороны, наиболее частыми задачами инженера данных можно считать:

Разработка процессов конвейерной обработки данных. Это одна из основных задач BDE в любом проекте. Именно создание структуры процессов обработки и их реализация в контексте конкретной задачи. Эти процессы позволяют с максимальной эффективностью осуществлять ETL (extract, transform, load) изъятие данных, их трансформирование и загрузку в другую систему для последующей обработки. В статичных и потоковых данных эти процессы значительно различаются. Для этого чаще всего используются фреймворки Kafka, Apache Spark, Storm, Flink, а также облачные сервисы Google Cloud и Azure.

Хранение данных. Разработка механизма хранения и доступа к данным еще одна частая задача дата-инженеров. Нужно подобрать наиболее соответствующий тип баз данных реляционные или нереляционные, а затем настроить сами процессы.

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

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

В иерархии работы над данными инженер отвечает за три нижние ступеньки: сбор, обработку и трансформацию данных.

Что должен знать Data Engineer

• Структуры и алгоритмы данных;

• Особенности хранения информации в SQL и NoSQL базах данных. Наиболее распространённые: MySQL, PostgreSQL, MongoDB, Oracle, HP Vertica, Amazon Redshift;

• ETL-системы (BM WebSphere DataStage; Informatica PowerCenter; Oracle Data Integrator; SAP Data Services; SAS Data Integration Server);

• Облачные сервисы для больших данных Amazon Web Services, Google Cloud Platform, Microsoft Azure;

• Кластеры больших данных на базе Apache и SQL-движки для анализа данных;

• Желательно знать языки программирования (Python, Scala, Java).

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

Data Engineer сильнее в программировании, чем дата-сайентист. А тот, в свою очередь, сильнее в статистике. Сайентист способен разработать модель-прототип обработки данных, а инженер качественно воплотить её в реальность и превратить код в продукт, который затем будет решать конкретные задачи.

Инженеру не нужны знания в Business Intelligence, а вот опыт разработки программного обеспечения и администрирования кластеров придётся как раз кстати.

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

Плюсы и минусы профессии инженера больших данных

Плюсы:

• Отрасль в целом и специальность в частности ещё очень молоды. Особенно в России и странах СНГ. Востребованность специалистов по BDE стабильно растёт, появляется всё больше проектов, для которых нужен именно инженер больших данных. На hh.ru, по состоянию на начало апреля, имеется 768 вакансий.

• Пока что конкуренция на позиции Big Data Engineer в разы ниже, чем у Data Scientist. Для специалистов с опытом в разработке сейчас наиболее благоприятное время, чтобы перейти в специальность. Для изучения профессии с нуля или почти с нуля тоже вполне хорошо (при должном старании). Тенденция роста рынка в целом будет продолжаться ближайшие несколько лет, и всё это время будет дефицит хороших спецов.

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

Минусы

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

  Уже сейчас есть целых шесть платформ, которые распространены в большинстве проектов.

  Spark популярный инструмент с богатой экосистемой и либами, для распределенных вычислений, который может использоваться для пакетных и потоковых приложений.
  Flink альтернатива Spark с унифицированным подходом к потоковым/пакетным вычислениям, получила широкую известность в сообществе разработчиков данных.
  Kafka сейчас уже полноценная потоковая платформа, способная выполнять аналитику в реальном времени и обрабатывать данные с высокой пропускной способностью. ElasticSearch распределенный поисковый движок, построенный на основе Apache Lucene.
  PostgreSQL популярная бд с открытым исходным кодом.
  Redshift аналитическое решение для баз/хранилищ данных от AWS.
  

• Без бэкграунда в разработке ворваться в BD Engineering сложно. Подобные кейсы есть, но основу профессии составляют спецы с опытом разработки от 12 лет. Да и уверенное владение Python или Scala уже на старте это мастхэв.

• Работа такого инженера во многом невидима. Его решения лежат в основе работы других специалистов, но при этом не направлены прямо на потребителя. Их потребитель это Data Scientist и Data Analyst, из-за чего бывает, что инженера недооценивают. А уж изменить реальное и объективное влияние на конечный продукт и вовсе практически невозможно.Но это вполне компенсируется высокой зарплатой.

Как стать Data Engineer и куда расти

Профессия дата-инженера довольно требовательна к бэкграунду. Костяк профессии составляют разработчики на Python и Scala, которые решили уйти в Big Data. В русскоговорящих странах, к примеру, процент использования этих языков в работе с большими данными примерно 50/50. Если знаете Java тоже хорошо.

Хорошее знание SQL тоже важно. Поэтому в Data Engineer часто попадают специалисты, которые уже ранее работали с данными: Data Analyst, Business Analyst, Data Scientist. Дата-сайентисту с опытом от 12 лет будет проще всего войти в специальность.

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

Дальнейшее развитие для специалистов Big Data Engineers тоже довольно разнообразное. Можно уйти в смежные Data Science или Data Analytics, в архитектуру данных, Devops-специальности. Можно также уйти в чистую разработку на Python или Scala, но так делает довольно малый процент спецов.

Перспективы у профессии просто колоссальные. Согласно данным Dice Tech Job Report 2020, Data Engineering показывает невероятные темпы роста в 2019 году рынок профессии увеличился на 50 %. Для сравнения: стандартным ростом считается 35 %.

В 2020 году темпы замедлились, но всё равно они многократно опережают другие отрасли. Спрос на специальность вырос ещё на 24,8 %. И подобные темпы сохранятся еще на протяжении минимум пяти лет.

Так что сейчас как раз просто шикарный момент, чтобы войти в профессию Data Engineering с нашим курсом Data Engineering и стать востребованным специалистом в любом серьёзном Data Science проекте. Пока рынок растёт настолько быстро, то возможность найти хорошую работу, есть даже у новичков.

Узнайте, как прокачаться и в других областях работы с данными или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс "Machine Learning и Deep Learning"

• Курс "Алгоритмы и структуры данных"

Что делать с данными в 2021 году, если вы финансовая компания с традиционной инфраструктурой и не смотрели дальше BI? Как и зачем договариваться разным бизнесам в B2B и что можно найти среди маленьких данных?

Мы расскажем про опыт НРД центрального депозитария РФ. НРД хранит активы на сумму более 60 трлн руб. и аккумулирует практически весь рынок ценных бумаг в России. Основной бизнес сфокусирован на надежности: хранение, проведение расчетов, отчетность.

Если вы тоже задаетесь похожими вопросами или вам знакомы слова финансовый бэк-офис, добро пожаловать под кат.

Согласно Big Data Executive Survey 2020, 98,8% опрошенных компаний, входящих в список Fortune-1000, инвестировали в создание дата-центричного бизнеса. Две трети опрошенных компаний инвестировали больше 50 млн долл., а каждая пятая больше 500 млн долл. Но то же исследование из года в год показывает: примерно две трети опрошенных руководителей признают, что их бизнес так и не стал дата-центричным. А трое из четверых замечают, что эта тема стала для них настоящим вызовом. Что делать с этой информацией, если последние 15 лет вы прицельно не занимались данными и наконец решили, что пора?

Данные, или что мы делали позапрошлым летом

Сначала задали себе ряд ключевых вопросов:

1. Сколько у нас данных? Как быстро они прирастают или обновляются? Какие они? Где хранятся?

2. Какие из наших данных уникальны?

3. Как устроены процессы работы с данными? Как данные появляются в системах, где дублируются и теряются?

4. С какой задержкой мы получаем информацию? Сколько занимает и стоит типичный запрос или сложная аналитика?

5. Что нам на самом деле нужно от данных?

Ответы на них не статичны и могут и будут меняться на разных стадиях зрелости компании. Например, мы ориентируемся на классификацию Google и Deloitte, а можно рассчитать data maturity index по аналогии с BCG. Сейчас мы считаем, что идеи ниже актуальны как минимум до уровня mature.

Чтобы понять картину в НРД, мы начали с аудита. Аудит данных и процессов работы с ними занял 3 месяца. Команда на этом этапе: продакт и техлид, занятые на 30-50%, по 1-2 представителя каждого бизнеса для интервью и по одному лиду ключевых систем для единичных запросов.

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

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

В целом если учитывать только объем и скорость прироста структурированной информации, то НРД при всём масштабе бизнеса раз в 10 не дотягивает до традиционной границы big data. Но если смотреть на ценность и уникальность наших данных, мы в топе.

1. Проблемы с данными, с которыми часто встречаются наши коллеги в индустрии:

2. Внутренних данных мало, доступные внешние данные не используются.

3. Не все доступные данные надлежащим образом собираются, обрабатываются и хранятся.

4. Те, что собираются, содержат ошибки и не всегда появляются вовремя.

5. Те, что собраны и почищены могут дублироваться незаметно для бизнес-процессов и критично для аналитики или наоборот.

6. Аналитика ассоциируется с ошибочным выбором метрик или возможностей монетизации.

Мы поймали все проблемы в разном объеме. Тут главное не отчаиваться. Если данных не хватает, проверьте открытые. Kaggle, тестовые датасеты вендоров, прямые запросы партнерам, открытые API интернет-сервисов. Проверьте на истории, насколько вам подходит сет. Как только вы поняли, что конкретные данные ценны для вас и работают, можно покупать. Если данные нужно разметить и они не конфиденциальные, привлекайте студентов, придумывайте исследование. Если данные дублируются, выбирайте мастер источник, которому будете доверять. Если в данных есть ошибки, оцените трезво, насколько они влияют на результат и вносят вклад в конечную точность анализа. Важно исправляйте, неважно смиритесь.

Кстати, бюрократический ответ на аудит и концепцию KYD (know your data; понимание профиля данных, которыми вы оперируете) каталог данных. Но, по-честному, тут все зависит от масштаба: если можете описать данные в простом виде и вам все понятно, пункт выполнен. Если нет, усложняйте постепенно. Начните с таблички и, если действительно потребуется, добавляйте документы и спецрешения. По поисковому запросу data catalogue есть варианты на любой кошелек :) Для себя мы остановились на Amundsen, но об этом в следующей серии.

Технологии: копать, не копать, делать вид, что копаешь?

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

Для ответа на вопрос про размер данных можно ориентироваться на концепцию 3V Gartner: volume, velocity, variety. И добавить любые слова на V, которые кажутся вам подходящими для классификации (например, Спутник V к данным не относится, но если очень хочется, тоже можно использовать для классификации).

Очень условно стадии развития инфраструктуры работы с данными можно описать так:

1. 1C/Excel все понятно. Данных мало, хоть мелом на заборе графики рисуй.

2. BI-решения. Могут быть витринами и собирать данные из нескольких БД, могут основываться на DWH. Сюда же Tableau, Cognus, Qlik и аналоги.

3. Специализированные решения для хранения и анализа больших или быстрых данных. Сюда попадает все дорогое и не всегда полезное и условно бесплатное, но требующее классной команды: in-memory БД, кластерные решения на основе Hadoop/Spark/Kafka/Hive/NiFi и другие.

4. Облачные решения: Amazon Athena/Redshift, Google BigQuery, Data Lake Analytics. Интересно, но страшно для финансовых компаний с точки зрения информационной безопасности. Как альтернатива возникают внутренние облака для группы компаний.

5. Платформы данных, комбинирующие пункты 2-4, виртуализация данных.

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

Мы стартовали с технологического уровня 2 (работающий BI) и надеялись не переходить к следующим пунктам в ближайшие 2 года. Команда на этом этапе: 1 продакт, 1 дата-аналитик, 1/2 тимлида, 1 стажер. Плюс 1 человек от каждого бизнес-линии и от каждой системы для периодических консультаций.

Ключевые вопросы к технологиям на этом этапе входят в категории как сделать и действительно ли нам это нужно. Как быстро аналитик получит доступ к новым данным? Сколько человек действительно потребуется, чтобы выгрузить данные для аналитики? Можно ли сделать новый отчет или получить доступ к данным в новом разрезе без разработки? Что мешает? Какую задержку в задачи вносит data mining? Какие технологические ограничения есть у разных систем?

На первый взгляд, схема BI плюс прямые запросы к источникам под задачу работала. Но через полгода мы поняли, что с текущими технологиями получение данных, не включая очистку и разметку, занимает 75% времени аналитики. Основные ограничения: legacy мастер систем со сложными структурами баз данных, не унифицированные API и множественные интеграции систем, последовательное согласование между разными бизнес-линиями и ИТ-функциями и привязка ролей доступа к конкретным системам, а не данным.

Мы вернулись к вопросу централизованной инфраструктуры по работе с данными. Три важных для нас элемента: каталог данных для поиска нужной информации, ETL и, собственно, хранилище. А основной риск делать инфраструктурные проекты больно, а переделывать еще больнее.

Поэтому мы начали с proof of concept (POC). На POC стоит проверять максимальное количество технологий на реальной задаче. Задача должна включать в себя максимально разнообразные данные и проверять самые архитектурно сложные места. Как референс можно использовать riskiest assumption test из продуктовой разработки. То есть если вы больше всего сомневаетесь в работе с объемными данными, пробуйте на объеме. Если в сохранности данных прогоняйте все риск-сценарии для нагруженных систем. Если в объединении данных из разных источников и доступности для аналитики подключайте максимум источников и ограничивайте объем. Если в гибкости пробуйте радикальные изменения. Например, мы выбрали для тестирования работу с профилем клиента и предсказание вероятности покупки дополнительных продуктов из линейки с учетом того, что часть данных обезличена.

Команда на этом этапе: 1 продакт, 2 дата-аналитика/дата-сайнтиста, 1 ИТ тимлид, 1 дата-инженер, 1 ML-разработчик, 1/2 аналитика. С этого момента все завязано на людей.

Люди, или у нас другие cultural references

По большому счету вся работа с данными вопрос людей: их компетенций, открытости, культуры, участия. Поэтому люди, выстраивание процессов и культуры работы с данными ключевая часть дата-стратегии НРД.

До пандемии мы думали, что можно не инвестировать, пока не проверим гипотезы и не поймем, как монетизировать. Это полуправда. Чтобы проверить гипотезу, нужны как минимум:

1. Аналитик(и).

2. Сервер или облако для экспериментов (Сюрприз! Даже если данные пролезают в 1 скрипт или на ПК, совместной работы не получается и времени на коммуникации уходит больше, чем на анализ).

3. Дата-инженер настраивать доставку данных не больше, чем за 30% времени задачи.

4. Участие бизнеса владельцев данных и дата-стюардов.

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

Такая структура матрицы дает взгляд на развитие с трех сторон: сам бизнес, ИТ-архитектура, управление данными (на C-level это управляющие директора, CIO и CDO) и подходит для текущего уровня зрелости компании.

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

Короче, сейчас мы понимаем data friendliness как открытость. Открытость для сотрудников компании: каждый может посмотреть задачи в работе, раз в 5-6 недель проводится демо и обсуждение с дата-стюардами и всеми, кому интересны данные. Открытость к идеям: идеи приходят из несвязанных областей, от студентов на конференциях, из самих данных. Открытость к людям: в финансы сложно нанимать звезд data science за разумные деньги, проще растить внутри.

Быть открытым значит понимать и принимать риски. И risk taking культура в разумных количествах должна быть на каждом уровне. Например, мы не можем снижать контроль за конфиденциальными данными, но можем работать со студентами на открытых датасетах с похожей структурой. Не можем рисковать основным бизнесом, но можем проверить 10 новых гипотез, чтобы найти классную. Risk taking в нашем случае значит, что лучше решать задачу и ошибиться, чем не решать вообще. Право на ошибку на этапе исследований есть у каждого: дата-стюарда, дата аналитика, дата-инженера.

И финальный совет: не отдавайте работу с данными на аутсорс. Да, растить или собирать команду внутри дорого на горизонте года, но стоит того, если смотреть на данные как на актив на ближайшие 5-10 лет.

Эта статья, как ни странно, про российское вино.

Она абсолютно пятничная и по смыслу, и по духу. Почему же я публикую её сегодня? Потому что завтра в это время я буду пить вино, а значит мне будет не до статей. Так что держите пятничную статью в четверг. Надеюсь, она будет интересна любителям вина. Особенно российского.

Месяц назад Роскачество презентовало очередной выпуск ежегодника "Винный гид России". Он посвящен (внезапно!) российским винам. Но не всем, а лишь находящимся в ценовом сегменте до 1000 рублей и широко представленным в обычных продуктовых сетях. В общем, винные снобы могут сразу пройти мимо, речь пойдет о самом что ни на есть масс-маркете.

Гид доступен в печатном и электронном виде. Последний представляет собой, по сути, рейтинг вин, которые можно отфильтровать по различным критериям. Это позволяет легко найти конкретное вино, его оценку и прочую информацию о нем. Но вот на более общие вопросы с помощью этого сайта я ответить не смог. А именно:

1. Какова картина в целом? Большинство вин откровенно плохи? Или наоборот прекрасны?

2. Не хочу запоминать и искать конкретные вина. Какие винодельни стабильно показывают достойное качество?

3. Как цена влияет на качество? Есть ли разница между вином за 150 рублей и за 500? А за 500 vs 1000?

Но раз есть сайт с данными, значит их можно спарсить и ответить на все свои вопросы самостоятельно.

Так что все те, кому интересен мир российского вина, и кто не воротит нос при фразе "вино дешевле 1000 за бутылку", добро пожаловать под кат!

Помните, что чрезмерное употребление алкоголя, в том числе вина, вредит вашему здоровью. Употребляйте ответственно или не употребляйте вовсе.

Оглавление

Пара слов о методологиях

Общая картина

Рейтинг виноделен

Как влияет цена на оценку?

Итоги

Пара слов о методологиях.Ю

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

Подробная методология исследования изложена на сайте Роскачества. Для тех кому лень читать, приведу ее вкратце ниже. Кому лень читать даже это просто запомните:

дегустация была слепой, вино оценивалось до 100-балльной шкале (не Паркера, но похожей). Чем выше балл, тем лучше: 81 балл и больше очень хорошо, 71 и меньше очень плохо. Всё вино российское, из масс-маркета, ценник <=1000 рублей. Исследовались: тихие красные, белые, розовые; игристые, ликерные.

Все данные были взяты мною с сайта Роскачества, никак не изменялись и не модифицировались. Исключение названия брендов, они были приведены к единообразию (удалил разные варианты названий одного и того же бренда: например, "ZB" и "Золотая балка" стали просто "ZB" и т.д.). Гид доступен за три года 2018-2020, я брал данные всех трех лет, поскольку вина в разных годах не повторяются.

Говнокод и исходные датасеты выложены тут, при желании можете брать и пользоваться.

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

Напоследок стандартное для моих статей примечание:

Общая картина

Для начала посмотрим, какие вообще вина участвовали в исследовании:

Больше всего, как и ожидалось, красных, белых и игристых (суммарно почти тысяча образцов). Откровенно сладких среди них почти не встречается, а вот полусладких еще достаточно. Особенно среди игристых (традиционно для российского рынка). Тем не менее, две трети белых/розовых и 80% красных вина сухие, что не может не радовать.

Какие же оценки ставились этим винам?

Ликерные в среднем получают оценки чуть выше (вероятно, связано с многолетним опытом виноделов в этой сфере Солнечная долина, Массандра занимаются креплёными винами с позапрошлого века). У остальных все четко: 1-2 квартили простые вина, 2-3 повседневные, 4 хорошие. Согласно трактовке оценок от Роскачества, конечно же.

На первый взгляд всё адекватно. Но меня очень смущает, что ни одно вино не добралось даже до 88 баллов. Почему?

Может, оценки ГОСТа настолько жесткие, что 90 это уже великое вино, а всё что выше недостижимые высоты, вин для которых еще не создали? Но на самом деле, согласно самому ГОСТу (а не Роскачеству) градация оценок следующая:

• 71 и выше хорошо

• 86 и выше очень хорошо

• 100 превосходно (я не понял, зачем делать целый уровень под одну оценку, ну да ладно).

То есть лишь единицы из рассматриваемых вин дотянулись хотя бы до уровня "очень хорошо", если пользоваться трактовкой из ГОСТа.

Тогда, может, вина у нас в исследовании больно дешевые, а потому посредственные, вот и не смог ни один образец из 1000 дойти даже до 90 баллов?

На первый взгляд, адекватная гипотеза, ибо подавляющая часть вин имеет цену ниже 500 рублей за бутылку, а медиана 350, что даже меня, крайне демократичного в подобных вопросах, немного смущает:

Но вот, например, трехсотрублевый брют от Фанагории получает 90 баллов на авторитетном Decanter World Wine Awards (к вопросу о том, что недорогие вина не бывают хорошими). А в нашем рейтинге он получает всего 80.73! Почти 10 баллов разницы! И если посмотреть результаты конкурса, можно найти и кучу других примеров недорогих российских вин с высокими оценками (например, Саперави от Шато Тамань за те же 300рэ с теми же 90 баллов).

Итак, у меня нет ответа на вопрос, почему оценки Гида настолько консервативны. Лишь гипотезы:

• система оценок ГОСТа очень жесткая. Настолько, что никто никогда не дотягивает до уровня "очень хорошо" и это нормально. Чтобы это проверить, надо найти результаты других винных конкурсов, использовавших эту систему, но я таковых не нашел;

• недорогие вина в большинстве своем очень средние и ожидаемо не дотягивают до уровня "очень хорошо". На международные конкурсы при этом посылается какое-то особое вино, которое берет медали. В эту гипотезу верится слабо: уж из 1000 образцов хоть парочка, да должна быть за 90, а про "подложные вина" и вовсе похоже на теорию заговора;

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

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

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

Рейтинг виноделен

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

Белое вино

В топе не нуждающиеся в особенном представлении "зубры" с юга материковой России Мысхако, многострадальная Юбилейная (надеюсь, недавнее вхождение в концерн Абрау даст ей новую жизнь), Фанагория и Шато Тамань. Выделяется Поместье Голубицкое, ибо по объемам производства оно сильно уступает вышеозвученным конкурентам. Первая крымская винодельня встречается на 6 месте и замыкает число тех, кто перевалил за 80 баллов. Причем, обратите внимание, какой высокий относительно остальных у Alma Valley разброс оценок. Связано это с их заигрываниями с полусладкими и сладкими винами, которые и "тянут вниз" в плане оценок (зато, уверен, "тянут вверх" в плане выручки). Поэтому на второй вкладке я отдельно составил рейтинг без учета сладких и полусладких вин, так сравнение будет более честным. Альма сразу же и поднимается повыше, и СКО уменьшает.

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

Товарищи по дну рейтинга Коктебель, до сих пор находящийся в процессе модернизации и перехода собственности, а также Усадьба Саркел их вина я вообще был удивлен обнаружить в Гиде, совсем небольшая частная винодельня.

Красное

Знакомые всё лица! На этот раз в топе еще одни крымчане Esse, а также Усадьба Мысхако. Её не стоит принимать за обычное "Мысхако". "Усадьба..." старое название новой гравитационной винодельни Chateau Pinot. Я был у них недавно на экскурсии (остался очень доволен увиденным), и именно поэтому знаю об этих перипетиях с названиями, иначе точно запутался бы.

А среди сухих в лидеры вышла уже известная нам винодельня Альма (кстати, тоже "гравитационщики"). И снова с не стабильными оценками (на этот раз даже среди сухих). На ней я тоже побывал и был приятно удивлен производством и планами развития. Кроме объема вложенных в производство сил и денег винодельня интересна тем, что производит айсвайны (единственные в России по классической технологии) и TBA (не помню, единственные ли в России или нет).

Розовое вино

Розовых вин мало, поэтому разбивать на отдельные вкладки не буду. Комментировать тоже не буду.

Игристые

Без сюрпризов, в топе Шато Тамань, знаменитое Абрау-Дюрсо, Фанагория. Новое лицо Aristov (на самом деле это подбренд Кубань-вино, но объединять их я посчитал неправильным). Крымчане Инкерман и Золотая Балка замыкают ТОП "восьмидесятников" наравне с Мысхако.

Ликерные

Позволил себе в этом рейтинге включить в ТОП крупных производителя всего с 4 образцами, ибо такие высокие и стабильные баллы от производителя из Дагестана для меня открытие.

Остальные строчки без особых сюрпризов недавно сменившая владельцев (и потому вызывающая тревожные чувства) Массандра и вполне себе стабильная Солнечная долина берут многолетним качеством и многолитровым количеством.

Итого

Если вам лень запоминать какая винодельня в каком вине хороша, то абсолютными чемпионами во всех основных категориях (красное, белое, игристое) являются идущие ноздря-в-ноздрю Фанагория, Мысхако и Шато Тамань:

.

Зависимость оценки от цены

Зависит ли оценка от цены за бутылку? Линейная регрессия говорит нам, что очень слабо:

У розового и ликерного коэффициенты и вовсе не значимы, у других вин хоть и значимы, но R-squared нигде не поднимается выше 0.1

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

Более того, в принципе нельзя ожидать связи "вино в 7 раз дороже значит будет в 7 раз лучше". Минимальная граница не дефектного вина по ГОСТу 56 баллов. А максимально можно набрать не более 100. Получается, что наибольшая разница в оценке, которую мы можем зафиксировать между минимально приемлемым и великим вином 2 раза. При том, что цена на них может отличаться на порядки.

Это так же автоматически означает, что наилучшее соотношение цена-качество всегда будет у дешевых вин и использовать его "в лоб" не стоит. На первом графике распределение оценок вин по ценовым сегментам с шагом в 200 рублей, на втором сколько баллов рейтинга приходится на 1 рубль.

Такой артефакт можно попробовать полечить отнормировав рейтинг (чтобы самое плохое вино имело 0 баллов, а самое хорошее 100) и поиграв с ценой (например, логарифмируя). Но принципиально картину на наших данных это не изменит я проверял. Да и смысл, плачу в магазине то я рублями, а не ln(RUB).

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

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

Хоть связь между ценой и рейтингом мне достоверно обнаружить и не удалось, но зато удалось найти влияние другого фактора. Это, конечно же, сахар.

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

Различия стат значимы (t-test, MW, p_value<0.01; правда, для белых вин t-тест выдал p_value=0.03, но не будем придираться).

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

Итоги

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

В этом году Гид так же вышел и в печатной версии (счастливым обладателем которой я стал благодаря тг-каналу "Вино и люди"). К ней тоже лично у меня нет нареканий ни по качеству печати, ни по содержимому. Её приятно и просто держать в руках, и читать.

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

Если же говорить об утилитарных целях исследования, то абсолютными лидерами в общем зачете стали такие винодельни как Фанагория, Мысхако и Chateau Tamagne. Что не исключает лидерства других производителей в отдельных категориях Голубицкое, Альма, Абрау-Дюрсо и др.

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

Так что идеальный выбор вина на основании представленных данных бутылка сухого от Фанагории за 500 рублей. Шучу, конечно. Идеальный выбор у каждого свой.

Надеюсь, моя статья была познавательна и подогрела чей-нибудь интерес к российским винам. У нашего виноделия несомненно куча проблем, но оно самобытно, интересно и, я верю, имеет огромный потенциал.

Спасибо за внимание. Пейте российское любое хорошее вино и помните: in vino veritas, in aqua sanitas!

Повод

Пару месяцев назад в рамках сотрудничества Amazon и Formula 1 исследователи с использованием мощностей облачных технологий выкатили сравнение скорости пилотов всех времен и народов (https://ru.motorsport.com/f1/news/formula-1-sostavila-rejting-bystrejshikh-pilotov-v-istorii-vyshlo-neodnoznachno/4858954/ ). Естественно, материал был рекламно-хайповый, и цели своей он достиг. Во всем формульном мире еще пару дней только и было разговоров в духе а почему в рейтинге нет пилота N? и да как M может быть быстрее K, если K сделал его в сезоне L. Мне стало интересно более-менее повторить это исследование и, по возможности, обойтись без всей мощи облачных технологий.

Задача

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

Как любят говорить в F1, пилот это лишь 10% успеха в гонке, остальные 90% - машина и работа команды. Поэтому с хоть какой-то степенью достоверности можно сравнивать только напарников по команде между собой, т.к. это, в теории, нивелирует фактор машины. Здесь тоже всегда есть масса домыслов и слухов, что при необходимости команда может топить одного своего пилота, либо просто не иметь возможности привозить последние обновления сразу на обе машины и отдавать лучшее своему быстрейшему гонщику. Но, в рамках нашей задачи, будем считать болиды сокомандников одинаковыми.

Идея

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

Еще один неприятный момент. Сравнить так уж прям всех пилотов за всю историю, к сожалению, не удастся. Даже используя все попарные мостики, не удастся добраться до всех пилотов, выступавших в Ф1. Возможны как отдельные пары пилотов, всю карьеру выступавшие только в одной команде друг с другом, так и более сложные закрытые кластера пилотов, не пилотировавшие ни с кем из общего кластера одновременно в одной команде.

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

Т.о. скорость прохождения круга в квалификации V = V₀*k_p*k_c*Tr, где k_c такой же коэффициент скорости болида конкретной команды в конкретной гонке, а Tr некая константа, характерная для трассы в конкретных условиях.

После серии преобразований можно вывести, что в каждой квалификации ln(k_i)-ln(k_j)=ln(t_j)-ln(t_i) для болидов гонщиков одной команды.

Получаем систему линейных уравнений. Систему довольно просто представить как матрицу m*(n+1), где n число пилотов, m суммарное число гонщиков в квалификациях. В каждой строке есть коэффициенты 1 и -1 в столбцах, соответствующих пилотам, и логарифм обратного отношения их времен в столбце свободных коэффициентов.

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

Более того, по похожей схеме посчитаем и рейтинг болидов F1. Год от года в связи с изменением правил и техническим прогрессом машины меняются. Последние годы регламент составляется так, что в начале года команда выставляет новую машину, большую часть года ее дорабатывает, а на следующий год вынуждена делать машину, подходящую под новый регламент. Понять, насколько прогрессирует машина по ходу году довольно сложно, поэтому допустим, что она более-менее стабильна.

Здесь мы будем фиксировать пилота и трассу и смотреть, насколько на одной машине он прошел ее быстрее, чем на другой в перспективе 2 лет. У этого подхода есть 3 больших минуса. 1 машина может быть быстрой, но не подходить пилоту. Мы же увидим, что она хуже. Второй трассы постоянно ротируются. Добавляются новые, уходят либо перестраиваются старые. Нам же для этого подхода нужен некоторый набор стабильных трасс. И третий дождь. Если в один год он был, а в другой нет, то мы можем списать это на скорость машины.

Решение

Данные квалификаций спарсим из Википедии, откуда еще. Формат квалификации менялся много раз, в разные периоды она состояла из 1, 2 и как теперь 3 фаз. Хоть это и не до конца верно, будем считать, что итоговое время пилота было показано в последней доступной фазе квалификации.

import sysimport reimport urllib.requestdef get_wikipedia_page(title, lang='en'):    url = 'https://'+lang+'.wikipedia.org/wiki/'+(title.replace(' ', '_'))    fp = urllib.request.urlopen(url)    mybytes = fp.read()        mystr = mybytes.decode("utf8")    fp.close()    return mystrtitle = 'List of Formula One Grands Prix'try:    print('process: '+title)    th = get_wikipedia_page(title)    r1 = re.findall(r'href="http://personeltest.ru/aways/habr.com/wiki/[\d][\d][\d][\d]_[\w]*_Grand_Prix"',th)    list_of_GP = list(set(r1))except:    print("Unexpected error:", sys.exc_info()[0])titles = list(map(lambda x: x[12: -1].replace('_', ' '), list_of_GP))for title in titles:    try:        print('process: '+title)        th = get_wikipedia_page(title)        with open('texts/'+title+'.txt', 'w', encoding='utf8') as the_file:            the_file.write(th)            the_file.close()    except:        print("Unexpected error:", sys.exc_info()[0])

Из полученных html файлов регулярками выпарсим квалификационные таблицы. Также слегка стандартизируем текстовую часть данных. Приведем названия треков к одному виду (иногда встречаются несколько написаний одного и того же трека), сохраним его длину (это поможет различить разные версии одного и того же трека), поудаляем цифры и прочий мусор из имен пилотов. Сохраним итоговые данные в удобную csv.

Считаем полученный DataFrame. Создадим несколько столбцов, которые сильно нам помогут в дальнейшем:

Название трека + его длина. Этоот столбец нам понадобится, чтобы не путать разные версии одного и того же автодрома

Имя пилота + год будем считать, что в течение 1 года пилот сохраняет один и тот же уровень формы, в течение 2 лет изменяет его незначительно

Машина = Конструктор + год. Вообще говоря, это не очень верно. На заре автоспорта производители могли использовать несколько разных версий машины в одном чемпионате и наоборот, несколько лет подряд использовать одну и ту же машину. Сейчас топ-команды умудряются привозить несколько крупных обновлений аэродинамики за год, малые команды пользуются этим реже.

qual_df = pd.read_csv('qual_results.csv')qual_df['Track_pl_len'] = qual_df['Track'] + '_' +qual_df['Track_len'].apply(str)qual_df['Car'] = qual_df['Constructor'] + '_' +qual_df['Year'].apply(str)qual_df['Driver_pl_year'] = qual_df['Driver']+'_'+qual_df['Year'].apply(str)qual_df_2 = qual_df.copy()qual_df_2['Driver_pl_year'] = qual_df_2['Driver']+'_'+((qual_df_2['Year'].apply(int)-1)).apply(str)double_df = pd.concat([qual_df, qual_df_2])del qual_df2

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

А дальше произведем небольшую манипуляцию с данными. Произведем 2 раза для разных рейтингов, но подробно разберу для рейтинга пилотов.

• Посчитаем логарифм из времени на круге

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

• Соответственно, просто мерджим 2 одинаковых датафрейма между собой по машине и гонке и получаем большую простыню нужных нам попарных сравнений

• Фильтруем полученный датасет, чтобы каждый мостик из сравнения двух пилотов был достаточно надежен - я выставил лимит в 6 и более совместных квалификаций и разницу в скорости не более 2%. Также оставляем только пилотов, отметившихся в главной линии пилотов Ф1 в той, что были основные чемпионы. Некоторое количество пилотов просто не пересекались с ними ни через кого в одной команде, поэтому узнать их скорость этим методом невозможно

• Выворачиваем 2 столбца с именами пилотов One Hot Encoding так, чтобы пилот x оказался с коэффициентом = 1 в столбце со своей фамилией, пилот y с -1

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

• Вытаскиваем посчитанные коэффициенты линейной регрессии. По нашей задумке они будут равны ln(k) - логарафму от коэффициента скорости пилота.

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

Результаты

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

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

Последний столбец пересчитал исходя из того, чтобы точкой отсчета был Сенна

Это 18 первых пилотов, если составлять рейтинг без учета динамики по ходу карьеры. Опять же, параметров довольно много + ошибки парсинга + оговорки, какое время брать в многоуровневых квалификациях. Серым я затемнил пилотов, которых нет в официальной лучшей 10. Если их не учитывать, то рейтинги очень похожи. Все те же люди на похожих расстояниях. Ниже Ферстаппен, выше Феттель.

Самое интересное здесь как в топе появился перспективный дебютант Рассел. Появился за счет 2019 года, в котором разнес вернувшегося после кучи пропущенных лет и тяжелейшей травмы некогда быстрого поляка Роберта Кубицу. Роберт весь год жаловался на машину, воевал с командой и на следующий год ушел из Ф1.

Сравнивать с ним Рассела некорректно. Столь длинное отсутствие не могло не сказаться на форме Рассела. В сравнении же мы считаем, что это одинаково быстрый пилот. Видимо, так же посчитали аналитики Ф1 и подчистили рейтинг. Как из него исчезли сверстабильные Боттас и Риккьярдо для меня загадка. Много лет в Ф1, точно пересекались с Хэмильтоном и Ферстаппеным и смотрелись/смотрятся на их фоне отлично.

А вот что получается, если построить рейтинг год к году:

И расширить его в перспективе времени (для всех пилотов здесь первый отмеченный год предваряет дебют или возвращение после перерыва, т.е. фактически в Ф1 пилота еще не было):

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

И такой же рейтинг для машин:

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

На графике бросается в глаза, как Renault сбросило секунду за счет нового двигателя не только на заводских машинах, но и на клиентах. Невероятно быстрый Racing Point, сбросивший почти 2 сек за межсезонье, Alpha Tauri 2020, неприлично похожая на Red Bull 2019 и провал двигателя Ferrari 2020, из-за которого команда откатилась на уровень 2018 года вместе со своими клиентами.

Интересно, что по этой графике быстрейшей машиной 2019 года была не Mercedes, которая взяла 10 поулов, а Red Bull и только более быстрый Хэмилтон позволял команде завоевывать поулы и титул. Леклер же, который взял поулов больше, чем Хэмилтон и Боттас каждый, творил просто чудеса, не вписывающиеся в модель.

Здесь во всей красе проявляется несовершенство самого метода попарных сравнений. Если у пилота есть длительные периоды стабильных выступлений с одним и тем же сокомандником, построить по нему статистику крайне тяжело. Сравнения получаются через много-много лет и пилотов, а каждое лишнее звено добавляет неточности. То же самое касается рейтинга машин. Чудо, что он вообще строится и выглядит адекватно.

Поскольку абсурдность и низкое качество полученной модели уже понятны, приложу ее предсказания на предстоящий этап в Имоле (результаты Уильямсов предсказать не получится, т.к. в команде 2 молодых пилота, не пересекавшихся с остальными пилотами в Ф1):

Выводы

Формула 1 и Amazon добились своей цели и привлекли внимание к себе. Так же они подкинули интересную задачку: как разделить влияние пилота и машины в таком своеобразном виде спорта.

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

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

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

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

https://github.com/molec1/f1_analysis

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

Статистические гипотезы и области их применения

Статистическая гипотеза - это предположение о каких-либо характеристиках случайной величины. Например: существенно ли изменение числа AI-стартапов в Европе в два разных года и т. д.

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

Случайная величина - это величина, которая в зависимости от той или иной ситуации принимает конкретные значения с определенными вероятностями. Примеры: отметка на экзамене; результат игры в кости; количество AI-стартапов по странам Европы. В общем, почти все что угодно!

Генеральная совокупность - совокупность всех объектов для анализа. Например: все AI-стартапы в Европе в 2019-м году.

Выборка - часть данных из генеральной совокупности. Например: официально зарегистрированные AI-стартапы в некоторых странах Европы в 2019-м году.

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

Для проверки статистических гипотез зачастую применяются статистические тесты, о которых будет рассказано далее.

Алгоритм проверки статистической гипотезы

В обобщенном виде алгоритм выглядит таким образом:

1. Формулировка основной (H0) и альтернативной (H1) гипотез

2. Выбор уровня значимости

3. Выбор статистического критерия

4. Определения правила принятия решения

5. Итоговое принятие решения на основе исходной выборки данных

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

Пример проверки статистической гипотезы

Итак, как вы, наверное, догадались по вышеприведенным примерам, будем проверять гипотезу о том, что имеется существенное различие между числом созданных европейских AI-стартапов в 2019-м и 2020-м годах. Пример достаточно простой, чтобы было проще разобраться в ходе работы алгоритма.

Сначала обратим внимание на исходную выборку (рис. 1): датасет представлен для 30-ти Европейских стран, внесены только официально зарегистрированные в стране стартапы. Данные количественные по двум годам. Стоит отметить, что выборки - парные, то есть мы наблюдаем один и тот же показатель для одних и тех же стран с разницей в год.

Сразу стоит отметить, что будут проверены две статистические гипотезы подряд. Для того, чтобы применять критерий для сравнения средних выборок двух лет нужно сначала определить закон распределения данных. Таким образом, шаг 1 - проверка статистической гипотезы о законе распределения данных. Шаг 2 - проверка статистической гипотезы о равенстве между средними.

Проверка гипотезы о законе распределения

Для данных 2019-го года проверим нормальность распределения.

1. H0: случайная величина распределена нормально

   H1: случайная величина не распределена нормально

2. Пусть уровень значимости alpha = 0.05 (как и в 95-ти процентах статистических тестов). Определение уровня значимости достойно отдельного поста, так что не будем заострять на нем внимание.

3. Будет использован критерий Шапиро-Уилка.

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

   , , , ;

   Как видно, формула не слишком простая, плюс существует непростой механизм определения параметра a, поэтому в таких случаях проще пользоваться онлайн-калькуляторами для расчета статистики. Я, например, воспользуюсь хорошим статистическим онлайн-ресурсом - https://www.statskingdom.com/320ShapiroWilk.html.

   Итак, калькулятор показал нам, что p-value =1.20005e-9 , W = 0.435974; Что же делать дальше? Есть два варианта:

   Можно сравнить статистику W с критическим значением Wкрит. Критическое значение чаще всего приведено в готовых таблицах (по строкам/столбцам там отмечен объем выборки и уровень значимости, а на пересечении как раз-таки и лежит Wкрит.). Если W>Wкрит., то не отвергаем H0 и наоборот. Но это не очень удобно, поэтому чаще используется второй способ.

   Можно сравнить p-value с alpha (выбран на 2-ом шаге). Если p-value < alpha, то отвергаем H0. Если нет, то НЕ отвергаем H0. В нашем случае p-value < alpha, следовательно с 95%-ой уверенностью отвергаем H0.

5. H0 отклонена, распределение выборочных данных за 2019-й год не подчинено нормальному закону распределения.

Для данных 2020-го года проверим нормальность распределения. Здесь шаги абсолютно те же самые. Получилось, что p-value = 3.41343e-9. Значение p-value < alpha, следовательно отвергаем H0.

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

Проверка гипотезы о различии в числе AI-стартапов в европейских странах для 2019-го и 2020-го годов

1. H0: отсутствует статистически значимое различие между числом AI-стартапов в Европе в двух годах.

   H1: признается статистическая значимость изменения показателя числа AI-стартапов в Европе между 2019-м и 2020-м годами.

2. Пусть уровень значимости alpha = 0.05.

3. Будет использован критерий Вилкоксона.

4. На этом шаге необходимо разобраться, как работает критерий. Безусловно, для данного критерия также существуют онлайн-калькуляторы, но его достаточно просто посчитать и вручную. Алгоритм очень прост:

   Шаг 1 - Для каждой страны нужно вычислить разность между значениями двух лет.

   Шаг 2 - Далее понять, какие из разностей являются типичными, то есть соответствуют преобладающему по частоте направлению изменения показателя.

   Шаг 3 - Далее в порядке возрастания проранжировать разности пар по их абсолютным значениям. Меньшему абсолютному значению разности приписывается меньший ранг.

   Шаг 4 - Рассчитать сумму рангов, соответствующих нетипичным сдвигам. Это и будет значением T-критерия.

   Пример расчета для двенадцати стран приведен на рисунке ниже (рис. 2). Не пугайтесь, приведенные ранги рассчитаны по всем 30-ти элементам выборки, двенадцать стран приведены лишь для иллюстрации. Проведя такой расчет по всем 30-ти странам и сложив ранги для стран с нетипичными изменениями, получилось, что T = 28.

   Сравним T и Tкрит.=163. T < Tкрит, значит с 95-ой уверенностью изменение числа стартапов статистически значимо.

5. H0 отвергается, различия между числом европейских AI-стартапов в 2019-м и 2020-м годах существенны.

Разнообразие статистических критериев

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

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