Русский
Русский
English
Статистика
Реклама

Big data

Обогащение данных что это и почему без него никак

15.04.2021 06:04:33 | Автор: admin

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

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

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

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

Заметим, что обогащение данных термин широкий, и получать данные из внешних источников можно весьма разнообразными способами. Например, представим бизнес-процесс регистрации нового клиента. Если в данных этого клиента отсутствует e-mail, то взаимодействие с внешним источником в этом случае может быть буквально следующим: взяли телефон, позвонили клиенту, узнали его e-mail. Получается, этот процесс может включать в себя такие совершенно не автоматизированные операции, как обычный телефонный разговор со всеми этими эс как доллар, "а" как русская. Это тоже можно считать обогащением данных, но данный пласт проблем в этой статье мы затрагивать не будем. Нас интересуют вполне конкретные случаи, когда данные хранятся в базе данных и именно БД служит внешним источником данных для обогащения.

Источниками сырых исходных данных могут быть:

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

  • Логистическая система, которая отслеживает движение товара: id транспорта и его водителя, gps-координаты в заданные моменты времени, статус, маршрут и т.д.

  • Телеметрия с датчиков интернета вещей.

  • Система мониторинга инфраструктуры.

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

Таким образом, типовую задачу можно сформулировать следующим образом: на вход поступают данные вида <таймстамп, идентификатор источника, содержимое пакета>, а конечному потребителю требуется соединить (в смысле join) справочную информацию об источнике из хранилища данных с идентификатором источника из сырых данных.

Как обогащаем данные

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

Другой вариант использовать инструменты потоковой обработки данных. В этом случае нужно определиться, где же всё-таки хранить справочную информацию и что будет являться Single Source of Truth (SSOT), или единым источником истины для справочных данных. Если хранить справочные данные в хранилище, то к нему придется каждый раз обращаться, и это может быть накладным, так как к сетевым издержкам добавится ещё и обращение к диску. Вероятно, оптимальнее хранить справочную информацию в оперативной памяти или другом горячем хранилище, например, в Tarantool.

Мы, очевидно, отдаём предпочтению именно последнему варианту, и наша схема приобретает завершенный вид.

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

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

Преимущества потокового обогащения данных:

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

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

Недостатки:

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

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

Какие технологии используем

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

Выбранный стек технологий:

  • Apache Kafka источник данных и брокер очередей;

  • Apache Spark потоковый обработчик данных;

  • Apache Ignite горячее хранение справочной информации;

  • Greenplum и Apache Hadoop хранилище данных.

В выборе Greenplum мы немного поступились совместимостью. Связать его со Spark не совсем тривиальная задача, для этого не существует стандартного open source коннектора (подробнее рассказывали в этой статье). Поэтому мы разрабатываем такой коннектор сами.

В остальном набор достаточно стандартный. Hadoop держим на всякий случай, например, чтобы использовать тот же Hive поверх HDFS вместо Greenplum.

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

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

Версии, которые используем:

  • Apache Spark 2.4.6.

  • Apache Ignite 2.8.1.

  • Apache Kafka 2.4.1.

  • Greenplum 6.9.0.

  • Apache Hadoop 2.10.1.

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

Что в результате

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

Но есть и ограничения, связанные с тем, что source of truth, по сути, находится в оперативной памяти. Поэтому при редактировании справочной информации надо напрямую работать с Ignite через интерфейсы самого Ignite. Кроме этого, нужен аккуратный механизм синхронизации, чтобы кэш Ignite был персистентным. У Ignite есть собственный механизм для записи на диск, но все же Ignite больше ориентирован на работу в ОЗУ, поэтому для резервирования справочной информации в хранилище данных лучше использовать что-нибудь специально для этого предназначенное, например, Airflow.

Полезные ссылки, чтобы понять, как строить взаимодействие между Spark и Ignite и насколько это уже проработанный механизм:

Пользуясь случаем: мы расширяем отдел систем обработки данных. Если вам интересно заниматься с подобного рода задачами, пишите мне в личку, в телеграм @its_ihoziainov или на job@itsumma.ru с пометкой data engineering.

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

Подробнее..

Google Earth Engine (GEE) ищем золото по всему миру с помощью больших данных и машинного обучения

05.04.2021 08:09:25 | Автор: admin

В предыдущих статьях Google Earth Engine (GEE) как общедоступный суперкомпьютер и Google Earth Engine (GEE) как общедоступный каталог больших геоданных мы познакомились со способами удобного и быстрого доступа к каталогу космических снимков и их обработки. Теперь мы можем искать питьевую воду, различные минералы и вообще много всего. А еще можем вооружиться методами машинного обучения (ML) и сделать свою собственную карту сокровищ прогноз для поиска золотых месторождений в любом месте мира. Как всегда, смотрите код и исходные данные (синтетические, конечно, ведь реальные данные буквально на вес золота!) на GitHub: AU Prediction (ML)



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


Введение


Задача поиска коренных (первичных) и сопутствующих россыпных (вторичных) месторождений по ортофото и космоснимкам давно известна и хорошо изучена. Порядок работы примерно такой: смотрим геологическое строение территории, выбираем те породы, которые содержат интересующие нас минералы, берем для этих пород известные спектральные отклики из соответствующих каталогов и анализируем многоспектральные (или гиперспектральные, если таковые есть) космоснимки в поисках нужных пород и потенциальных месторождений. Если искомых минералов нам нужно много, то ищем непосредственно по их спектральным характеристикам. Можно и самостоятельно спектральные отклики разных минералов составить, если есть данные геохимии. Есть исследования, что спектры отражения минералов за счет их аккумуляции растительностью в листве преобразуются в спектры поглощения и тоже могут быть обнаружены, равно как и повышенное содержание искомых минералов в воде, так что необходима предварительная классификация территории на наличие суши, воды и растительности. При этом нужно помнить, что размер пикселов отличается в разы даже для разных каналов одного снимка, не говоря уж про снимки разных миссий. А еще времена года следует учесть, чтобы не удивляться, почему классификатор растительности для экватора так плохо работает зимой в заснеженной Сибири. Кстати, в краях вечного лета хоть и нет снега, зато присутствует вечная облачность, так что не удаётся найти ни одного полностью безоблачного снимка и нужно делать композитную мозаику, совмещая множество снимков и для каждого пиксела выбирая наилучший по качеству (существует уйма алгоритмов, конечно, но идеального нет).


Вручную (хоть и на компьютере, оксюморон) все это делается, но делается медленно и разными несогласованными методами с несомненным преобладанием человеческого фактора. Хорошо нам знакомая и необходимая итеративная работа невозможна, так как нет автоматизированного способа повторять подготовку данных и их анализ. Для нас задача становится решаемой благодаря наличию доступа к единому многолетнему архиву всех необходимых космических снимков, рельефа и производных от него материалов, а также синхронизированных по времени масок облачности и классификаторов (вода, суша, растительность и других) на Google Earth Engine.


Подготовка данных


Обычно геологи работают с одним или несколькими (выбранными на свой вкус) снимками лишь одной спутниковой миссии, мы воспользуемся техническим преимуществом платформы Google Earth Engine (GEE) и из тысяч доступных космических снимков сделаем качественные композитные растры для разных миссий (Landsat 8, Sentinel 2, ...) и дополним их детальным цифровым рельефом местности и некоторыми его характеристиками.


Остановимся подробнее на том, зачем нужны снимки с разных миссий, хотя и разрешение и спектральные каналы у них более-менее одинаковые. На самом деле, нет разная оптика и ширина спектральных каналов и алгоритмы обработки обуславливают существенную разницу в результирующих изображениях. Ранее я уже публиковал свои результаты сравнения значений спектральных каналов разных миссий для классов поверхности (земля-вода-растительность) как раз для исследуемой территории: Compare Spectrograms of Hyperspectral and Multispectral Satellite Missions:



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


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


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



Построение классификатора и анализ территории


На гитхабе представлено два ноутбука, в первом из которых GEE_export.ipynb подготавливаются и скачиваются необходимые данные с Google Earth Engine, а во втором West Sumbawa AU 3-Class Prediction Synthetic.ipynb выполняется обучение классификатора на полученных растрах и их последующая классификация. В коде даны ссылки на все используемые датасеты GEE, так что, при желании, их несложно заменить на другие. Поскольку использованный линейный классификатор достаточно прост и требует подбора лишь одного параметра, этот подбор выполняется автоматически непосредственно в ноутбуке.


Отмечу, что желательно использовать физические характеристики поверхности функции от рельефа, отражательную способность для разных длин волн и так далее. Тем не менее, вместо отражающей способности земной поверхности (surface reflectance) для миссии Landsat-8 мы используем данные TOA (top of atmosphere), поскольку для этих спутников SR вычисляется по TOA недостаточно аккуратно и нужная нам корреляция теряется. Для Sentinel-2 такой проблемы нет.


Заключение


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


P.S. С днем Геолога!

Подробнее..

Перевод Пирамидальная сортировка, сортировка слиянием и выпуклая оболочка

07.04.2021 18:21:37 | Автор: admin

Базовые алгоритмы сортировки


Пирамидальная сортировка (или сортировка кучей, Heap Sort)

Куча (heap) это не что иное, как двоичное дерево с некоторыми дополнительными правилами, которым оно должно следовать: во-первых, оно всегда должно иметь структуру кучи, где все уровни двоичного дерева заполняются слева направо, и, во-вторых, оно должно быть упорядочено в виде max-кучи или min-кучи. В качестве примера я буду использовать min-кучу.

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

Ниже приведен псевдокод пирамидальной сортировки:

HeapSort(A[1n]):1 - H = buildHeap(A[1n])2 - for i = 1 to n do:3 -   A[i] = extract-min(H)

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

Ниже приведен псевдокод buildHeap:

buildHeap():1 - Изначально H пустая2 - for i = 1 to n do:3 -   Add(H, A[i])

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

Теперь самый маленький элемент в куче находится в последнем узле, что нам и нужно. Мы знаем, что он находится в отсортирован относительно остальных элементов, поэтому его можно полностью удалить из кучи (функция extract-min). Но нам нужно сделать еще кое-что: убедиться, что новый элемент корневого узла находится на своем месте! Маловероятно, что элемент, который мы сделали корневым узлом, находится на своем месте, поэтому мы переместим элемент корневого узла вниз в его корректное положение, используя функцию, которая обычно называется heapify (приведение к виду кучи).

Ниже приведен псевдокод extract-min и heapify:

extract-min(H):1 - min = H[1]2 - H[1] = H[H.size()]3 - уменьшаем H.size() на 14 - heapify(H, 1)5 - return minheapify():1 - n = H.size()2 - while (LeftChild(i) <= n and H[i] > H[LeftChild(i)]) or (RightChild(i) <= n and H[i] > H[RightChild(i)]) do:3 -   if (H[LeftChild(i)] < H[RightChild(i)]) then:4 -     j = LeftChild(i)5 -   else:6 -     j = RightChild(i)7 -   меняем местами H[i] и H[j]8 -   i = j

Вот и все! Алгоритм продолжает повторять эти шаги до тех пор, пока куча не сократится до одного единственного узла. На момент, когда это произойдет, мы будем уверенны, что все элементы в несортированном массиве находятся в своих отсортированных позициях и что последний оставшийся узел в конечном итоге станет первым элементом в отсортированном массиве. Общее время работы этого алгоритма составляет O(n log n).

Сортировка слиянием (Merge Sort)

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

Сортировка слиянием это алгоритм разделяй и властвуй, который можно свести к 3 шагам:

  • Разделите (разбейте) задачу на минимально возможные подзадачи одного типа.

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

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

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

Функция mergeSort в свою очередь состоит из двух функций:

  • функции слияния, которая фактически объединяет два списка вместе и сортирует их в правильном порядке.

  • функции mergeSort, которая будет продолжать разделять входной массив снова и снова (рекурсивно), а затем будет вызывать функцию слияния снова и снова (также рекурсивно).

Ниже приведен псевдокод сортировки слиянием:

Merge(A, B):1 - i = 1; j = 1; k = 1;2 - a_(m+1) = ; b_{n+1} = 3 - while (k <= m+n) do:4 -   if (a_i < b_j) then5 -     c_k = a_i; i++;6 -   else7 -     c_k = b_j; j++;8 -   k++;9 - return C = {c_1, c_2, , c_(m+n)}MergeSort(X, n)1 - if (n == 1) return X2 - middle = n/2 (round down)3 - A = {x_1, x_2, , x_middle}4 - B = {x_(middle+1), x_{middle+2), , x_n}5 - As = MergeSort(A, middle)6 - Bs = MergeSort(B, n - middle)7 - return Merge(As, Bs)

Именно потому, что сортировка слиянием реализована рекурсивно, это делает ее быстрее, чем другие алгоритмы, которые мы рассмотрели до сих пор. Сортировка слиянием имеет время выполнения O(n log n).

Выпуклая оболочка (или выпуклый контур, Convex Hull)

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

Подход 1 Упаковка подарков (Gift Wrapping) O(n)

Идея проста, мы начинаем с самой левой точки (или точки с минимальным значением координаты x) и продолжаем оборачивать точки против часовой стрелки. Если точка p является текущей точкой, следующая точка выбирается как точка, которая перекрывает все остальные точки по ориентации против часовой стрелки. Ниже приводится псевдокод:

1 - ConvexHull = пустой список2 - Ищем точку с наименьшим x и присваиваем ее u (:= u_original)3 - Пусть L будет вертикальной линией, проходящей через u3 - Do:4 -   Пусть v будет точкой с наименьшим углом между L и u * v5 -   Добавляем v в ConvexHull6 -   Пусть L = uv линии7 -   u := v8 - Until v = u_original9 - Выводим ConvexHull

Подход 2 Алгоритм Грэхема (Graham Scan) O(n log n)

Этот алгоритм можно разделить на 2 этапа:

  • Этап 1 (сортировка точек): сначала мы находим самую нижнюю точку. Идея состоит в том, чтобы предварительно обработать точки, сортируя их по самой нижней точке. После сортировки точек они образуют простой замкнутый путь. Какими должны быть критерии сортировки? Вычисление фактических углов было бы неэффективным, поскольку тригонометрические функции не являются простыми в вычислении. Идея состоит в том, чтобы использовать ориентацию для сравнения углов без их фактического вычисления.

  • Этап 2 (включении или отбрасывание точек): после того, как у нас есть замкнутый путь, следующим шагом будет прохождение по пути и удаление из него вогнутых точек. Первые две точки в отсортированном массиве всегда являются частью выпуклой оболочки. Для оставшихся точек мы смотрим на последние три точки и находим угол, образованный ими. Пусть это три точки: prev(p), curr(c) и next(n). Если ориентация этих точек (рассматривая их в том же порядке) не против часовой стрелки, мы отбрасываем c, в противном случае мы оставляем ее.

1 - ConvexHull = пустой список2 - Пусть u - точка с наименьшим значением x (если таких точек несколько, выбираем ту, у которой наименьший y)3 - Сортируем оставшиеся точки по угловой фазе в порядке против часовой стрелки вокруг u4 - Добавляем u и первую точку в ConvexHull5 - For i = 2 to n - 1:6 -   While угол между предпоследней, последней и точкой i > 180 градусов:7 -     Удаляем точку из ConvexHull8 -   Добавляем i в ConvexHull9 - Return ConvexHull

Если вам интересно следить за моей работой в области компьютерных наук и машинного обучения, вы можете посетить мои Medium и GitHub, а также другие проекты на https://jameskle.com/. Вы также можете написать мне мне в Твиттере, но электронной почте или найти меня в LinkedIn. Или подписывайтесь на мою рассылку, чтобы получать мои последние статьи прямо на ваш почтовый ящик!


Перевод статьи подготовлен в преддверии старта курса Алгоритмы и структуры данных.

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

Подробнее..

Аналитика возраста воздушного флота российских авиакомпаний

01.04.2021 16:06:37 | Автор: admin

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

Мотивация, планирование, выборка

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

Для начала хочется обозначить, что будем подразумевать под российскими авиакомпаниями те, которые есть в официальном списке эксплуатантов. В исследовании были отобраны топ российских авиакомпаний - Аэрофлот, Алроса, Аврора, Азимут(Azimuth), АзурЭйр(AzurAir), ИрАеро, НордСтар(NordStar), НордВинд(NordWind), Икар(PegasFly), Победа(входит в группу Аэрофлот), РэдВинг(RedWings), Россия(Rossiya), РоялФлайт (RoyalFlight), S7(АК Сибирь), СмартАвиа(SmartAvia), Уральские авиалинии(UralAirlines), Ютэйр(Utair), Якутия(Yakutia), Ямал(Yamal). Данная выборка охватывает 85% авиапарка российских авиакомпаний. В этот список не попала авиакомпания ГазпромАвиа у которой имеется большой авиапарк, но причина исключения - это отсутствие возраста в большинстве данных, что не представлялось возможным определить среднее значение, но модели авиапарка у компании очень разнообразны и интересны, но об этом позже.

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

Инструменты аналитики

В нашем исследовании будем применять стандартные инструменты для этого - язык программирования python с библиотеками numpy, pandas для анализа данных, библиотеки plotly для визуализации результата, и инструмент Тableau для дашборда, google sheets для первоначальной обработки и наш любимый brain.

Процесс обработки данных

Итак, наш исследуемый датафрейм содержит 7 переменных(колонок) и 834 строки. Посмотреть его можно тут.

Посмотрим гистограмму и посмотрим распределение данных.

Давайте сразу же посмотрим среднее значение и медиану возраста всей выборки. Получается среднее(mean) = 10.61 лет, медиана(median) = 9.0 лет.

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

Код
ages = data.groupby(by='airlines').age.describe()ages.sort_values(by='count', ascending=False)
Описательные статистики значений возраста, количество воздушных судов в разрезе каждой авикомпании.Описательные статистики значений возраста, количество воздушных судов в разрезе каждой авикомпании.

Из представленного результата мы видим, что топ-5 авиакомпаний с наибольшим количеством авиапарка это:

самый молодой флот у авиакомпаний:

Азимут (Azimuth) - среднее(mean) 2,9 лет, медиана(медиана) 3 года;

Победа - среднее(mean) 3,5 лет, медиана(медиана) 3 года;

Аэрофлот - среднее(mean) 5,1 лет, медиана(медиана) 5 лет;

S7 - среднее(mean) 9,5 лет, медиана(медиана) 9 лет,

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

АзурЭйр (AzurAir) - среднее(mean) 20,3 года, медиана(медиана) 20 лет, минимальное значение - 13 лет, максимальное значение 30 лет.

Теперь отсортируем наиболее часто повторяющийся тип авиалайнеров и выведем топ-10 из них.

Код
data.type.value_counts().to_frame('count').head(10)
Количество часто встречающихся авиалайнеровКоличество часто встречающихся авиалайнеров

Как можно видеть пятёрка наиболее часто встречающиеся судов это:

Airbus A320

Sukhoi Superjet 100

Boeing 737

Airbus A321

Топ-3 производителей авиалайнеров выглядит так:

Среди типов авиалайнеров был обнаружен Boeing 737 MAX, эксплуатация которых была приостановлена по решению международных воздушных организаций. Такие авиалайнеры были замечены у компаний S7, NordStar, UralAirlines, Utair,

Boeing 737 MAX

и один единственный новый авиалайнер Airbus A350-941 с регистрационным номером VQ-BFY в Аэрофлоте :)

Airbus A350-941

кстати, по сводке flightradar24 данный авиалайнер частенько летает маршрутом Москва - Майами(США) - Москва :)

А в завершении нашего исследования, как и говорил ранее, давайте поговорим о воздушном флоте авиакомпании ГазпромАвиа :) Итак, что мы имеем вернее они имеют, а имеют они 50 единиц флота в который входят такие разнообразные и интересном марки и модели как:

Airbus Helicopter H135 - 5 единиц;

Airbus Helicopter H155 - 1 единица;

Dassault Falcon 900 - 6 единиц;

Dassault Falcon 7X - 5 единиц;

Dassault Falcon 8X - 2 единицы;

и вот эта интересная модель Let L410UVP-E20 Turbolet

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

И конечно же на десерт красивый dashboard на Tableau, который можно посмотреть тут.

Всем всего хорошего, ваш konstatic :)

Подробнее..

Аналитический отчёт застройщика как выглядит и как поможет в работе

06.04.2021 14:13:41 | Автор: admin

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

Застройщики сталкиваются стакими проблемами:

  • разрозненные данные вотчётности;

  • беспорядок вCRMи, как следствие, потеря лидов;

  • при масштабировании бизнеса иотдельных проектов теряется контроль над тактическими задачами;

  • человеческий фактор впроцессе обработки информации приводит кпотере данных;

  • нет единой системы бизнес-аналитики.

Застройщикам важно видеть, что происходит накаждом уровне воронки продаж, как работает каждый офис икаждый менеджер.

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

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

Мыразработали динамический отчёт застройщика вPower BI.

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

Сводный отчёт

Сводный отчёт по всем объектам дашборд для топ-менеджеров. Он показывает ситуацию по продажам в целом.

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

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

Диаграмма воронки продаж позволяет оценить качество привлекаемых лидов:

Диаграмма снакоплением показывает объёмы продаж идостигнутый результат:

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

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

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

Отчёт потелефонным звонкам

Дашборд предназначен для руководителя колл-центра.

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

Диаграмма позвонкам показывает общую картину работы колл-центра иинтенсивность звонков заотчётный период:

Отдельно представлена информация понепринятым ипотерянным (когда менеджер неперезвонил клиенту) звонкам.

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

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

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

  • насколько оперативно отвечают;

  • как долго разговаривают склиентом;

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

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

Digital

Дашборд предназначен для менеджеров порекламе.

Надашборде представлена динамика стандартных метрик интернет-рекламы заотчётный период. Панель фильтров позволяет более детально проанализировать каждый канал.

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

Сделки

Дашборд для отдела продаж ибухгалтерии.

Панель карточек вверху показывает сводную информацию позаключенным сделкам:

Диаграмма посуммам сделок показывает реальные ипотенциально возможные суммы позаключенным договорам:

Диаграмма потипам оплат позволяет выявить предпочтения клиентов иоценить объёмы длинных денег (рассрочка/ипотека):

Внизу таблица сдетальной информацией попроданным объектам:

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

Как дашборд помогает застройщику

Отчёт застройщика вPower BIпредоставляет существенные преимущества для анализа продаж:

  1. Информация изразных источников собрана водном отчёте.

  2. Гибкая система фильтров позволяет индивидуально выбирать отчётный период, детализировать информацию понеобходимым параметрам.

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

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

  5. Вместо громоздких таблиц наглядные диаграммы играфики. Они позволяют проще воспринимать иинтерпретировать информацию.

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


Подробнее..

Перевод 10 постулатов по улучшению таблиц

06.04.2021 20:05:58 | Автор: admin

Короткое резюме 10 постулатов по улучшению таблиц, опубликованных в Journal of Benefit Cost Analysis экономистом Jon Schwabish.

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

Итак, перейдем к правилам.

1. Отделяйте заголовки от тела таблицы

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

Без заголовковБез заголовковС заголовкамиС заголовками

2. Используйте ненавязчивые разделители вместо толстой сетки

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

Без разделителейБез разделителейВыделение цветомВыделение цветом

3. Выравнивайте числа и заголовки по правому краю

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

Выравнивание чисел и заголовков по левому краюВыравнивание чисел и заголовков по левому краю

4. Выравнивайте текст и заголовки по левому краю

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

Различные варианты выравнивания текстаРазличные варианты выравнивания текста

5. Выбирайте адекватный уровень точности

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

Различные варианты округленийРазличные варианты округлений

6. Направляйте читателя с помощью расстояний между строками и столбцами

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

Расстояние между столбцамиРасстояние между столбцамиРасстояние между строкамиРасстояние между строками

7. Избегайте повтора единиц измерения

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

Излишек единиц измеренияИзлишек единиц измеренияПравильное оформление единиц измеренияПравильное оформление единиц измерения

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

8. Выделяйте выбросы

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

Выделение выбросов цветом текстаВыделение выбросов цветом текстаВыделение выбросов заливкойВыделение выбросов заливкой

9. Группируйте похожие данные и отделяйте их пробелами

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

Без группировки по регионамБез группировки по регионамС группировкой по регионамС группировкой по регионам

10. Добавляйте визуализацию при необходимости

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

Голая таблицаГолая таблицаОтформатированная таблицаОтформатированная таблица

Эпилог

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

Разница в наглядности очевидна. Проведите ревизию своих ежедневных и финансовых отчетов - а у Вас все правила соблюдаются? ;)

Подробнее..

Главная причина дискриминации в ML

12.04.2021 22:14:50 | Автор: admin

Из предыдущего поста вы узнали, что в ML существует дискриминация. Отлично! Таким образом вы уже разбираетесь в Этике машинного обучения лучше, чем многие инженеры МL. Благодаря примерам (из медицины, анализа твиттов, распознавания лиц) вы наверняка уже сделали вывод, что существуют разные виды предвзятости.

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

Три кита дискриминации

Есть три характеристики людей, на которых основываются большинство предвзятостей в real-world алгоритмах:

  • Гендер

  • Раса

  • Возраст

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

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

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

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

"Man is to Computer Programmer as a Woman is to Homemaker"Здесь вы можете увидеть распределение уже "справедливых" word-embeddings: сверху гендерно-нейтральные слова, снизу специальные для каждого гендера. "Man is to Computer Programmer as a Woman is to Homemaker"Здесь вы можете увидеть распределение уже "справедливых" word-embeddings: сверху гендерно-нейтральные слова, снизу специальные для каждого гендера.

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

Примеры дискриминации по половому признаку из алгоритмов машинного обучения:

  1. Word embeddings, полученные из статьей с Google News (где материал довольно строго курируется), отражают большое количество гендерных стереотипов (Man is to Computer Programmer as Woman is to Homemaker)

  2. Точность алгоритмов распознавания лица IBMs и Face++ значительно ниже для женщин по сравнению с мужчинами (Gender Shades)

  3. Некоторые алгоритмы допускают серьёзные погрешности во время перевода женского голоса в текст ( Where is Female Synthetic Speech).

Предвзятость, связанная с расой, очень удручает многих специалистов в области технологий. Пару лет назад некоторые американские клиники предоставляли темнокожим пациентам почти в два раза меньше средств для специальной медицинской помощи. Используемый алгоритм предсказывал, что темнокожие меньше нуждались в особом наблюдении (https://science.sciencemag.org/content/366/6464/447.abstract) Другой алгоритм, COMPAS, который использовали в американских судах, выдавал в два раза больше ложноположительных (false positive) прогнозов о рецидивизме по отношению к темнокожим, нежели к светлокожим. (https://www.propublica.org/article/how-we-analyzed-the-compas-recidivism-algorithm) Есть еще масса примеров biasа, который основывается на расе.

Так почему это происходит?

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

Большинство алгоритмов машинного обучения делают то, что им говорят данные и статистические методы. Проще говоря, учатся на прошлом опыте: на объективных данных.

Поэтому возникает вопрос: так разве можно утверждать, что результаты, полученные с помощью такого (объективного) подхода, несправедливы?

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

Подробнее..

Рекомендации с обоснованием (2020). Часть первая

04.04.2021 00:20:12 | Автор: admin

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

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

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

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

Оглавление

  1. Аннотация

  2. Введение

    1. Рекомендации с обоснованием

    2. Историческая справка

    3. Классификация методов

    4. Объяснимость и результативность

    5. Объяснимость и интерпретируемость

    6. Как читать данный обзор

  3. Список литературы

Рекомендации с обоснованием: обзор и новые перспективы

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

В данной статье мы приводим всесторонний обзор исследований в области рекомендаций с обоснованием. Сначала мы показываем место проблемы рекомендаций с обоснованием в общем направлении исследований по рекомендательным системам путем классификации актуальных проблем по пяти категориям под названием 5W: что, когда, кто, где и почему (what, when, who, where, why). Далее приводим полный обзор проблемы рекомендаций с обоснованием с трех точек зрения:

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

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

  3. Применение рекомендаций с обоснованием в различных задачах предоставления рекомендаций, таких как рекомендация продуктов, социальные рекомендации, рекомендации достопримечательностей (point-of-interest or POI recommendation).

Также один из разделов посвящен рассмотрению перспектив исследований проблемы рекомендаций с обоснованием в более широких областях исследований получения информации (information retrieval or IR), искуственного интеллекта (ИИ) и машинного обучения (МО). Статья завершается обсуждением потенциальных направлений исследований в будущем для дальнейшего развития данной области.

Раздел 1. Введение

1.1.Рекомендации с обоснованием

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

Для того, чтобы показать место проблемы рекомендаций с обоснованием в области исследований рекомендательных систем, мы приводим концептуальную таксономию. В частности, исследования в области рекомендаций с обоснованием могут быть классифицированы согласно 5W, т.е. на категории, отвечающие на вопросы когда, где, кто, что и почему (what, when, who, where, why), или, соотвественно, на рекомендации, зависящие от времени, от места, социальные рекомендации, рекоммендации в зависимости от предметной области и рекомендации с обоснованием.

Модели рекомендаций с обоснованиями могут разделяться на использующие внутренние модели (intristic models) и безмодельные (model-agnostic) (Lipton, 2018 [1]; Molnar, 2019 [2]). Подход с внутренними моделями предполагает создание интерпретируемой модели, где механизм принятия решений является прозрачным и, таким образом, становится возможным действительно обеспечить объяснение принятого решения (Zhang et al., 2014a [3]). В безмодельном подходе (Wang et al., 2018d [4]), который иногда так же называют подход с объяснениями постфактум (Peake and Wang, 2018 [5]), механизм принятия решения рассматривается как черный ящик, и модель объяснения генерируется уже после принятия решения. Основа философии обоих подходов лежит в области когнитивной психологии в одном случае человек принимает взвешенные, рациональные решения и может объяснить, почему данное решение было принято, а в другом случае сначала принимает решение и затем ищет объяснение, чтобы обосновать решение или оправдать себя. (Lipton, 2018 [1]; Miller, 2019 [6])

Область рекомендаций с обоснованием включает в себя не только разработку прозрачных моделей МО, получения информации (information retrieval) или глубинного анализа данных (data mining), но и также разработку эффективных методов представления рекомендаций или обоснований пользователям и разработчикам системы, т.к. человек [прямо или опосредованно] вовлечен в цикл решения задачи предоставления рекомендаций с обоснованием на протяжении всего времени. Значительные усилия в исследованиях поведения пользователей и взаимодействия человек-компьютер направлены на понимание того, как пользователи работают с обоснованиями.

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

1.2.Историческая справка

В данном разделе мы представим историю развития исследований в области рекомендаций с обоснованием. Несмотря на то, что сам термин рекомендации с обоснованием формально был введен недавно (Zhang et al., 2014a [3]), основная концепция, тем не менее, была введена в ранних работах по рекомендательным системам. Например, Schafer et al. (1999) [7] отмечает, что рекомендации могут быть объяснены с помощью других объектов, с которыми знаком пользователь, например обоснование продукт, который Вы ищете, похож на данные продукты, которые вам понравились ранее. Данное наблюдение приводит к фундаментальной идее коллаборативной фильтрации (КФ) (Collaborative filtering or CF), основанной на релевантных объектах (item-based collaborative filtering or item-based СF); Herlocker et al. (2000) [8] изучает проблему получения обоснований для рекомендаций, полученных с помощью КФ, в MovieLens, используя обзоры пользователей, а Sinha and Swearingen (2002) [9] подчеркивают роль прозрачности в рекомендательных системах. Кроме того, даже если рекомендации с обоснованием и ранее серьезно привлекали внимание исследователей, то на практике в основном использовались объяснения, полученные ручными или полуавтоматическими методами, например объяснение пользователи также просматривали в системах электронной торговли (Tintarev and Masthoff, 2007a [10]).

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

Ранние подходы к созданию персонализированных рекомендательных систем в основном фокусировались на использовании рекомендаций на основе контента (content-based) или на основе КФ (Ricci et al., 2011 [11]). Рекомендательные системы на основе контента моделируют пользовательские и объектные профайлы с помощью различной доступной контентной информации, такой, как цвет, цена, марка товаров в электронной торговле, или жанр, режиссер и длительность фильмов в системах обзоров (Balabanovic and Shoham, 1997 [12]; Pazzani and Billsus, 2007 [13]). Т.к. контент, относящийся к объекту, легко понимается пользователями, то объяснения для пользователей, почему объект был рекомендован, интуитивны. Например, одним из очевидных подходов является предоставление пользователю тех признаков контента, которые могут представлять для него интерес в рекомендованном объекте. Ferwerda et al. (2012) [14] проводит всестороннее исследование возможных способов предоставления обоснований для рекомендаций, основанных на контенте.

Тем не менее, сбор контентной информации для различных предметных областей может являться трудоемким процессом. С другой стороны, подходы, основанные на коллаборативной фильтрации, предпринимают попытку избежать данной проблемы, используя т. н. народную молву (Ekstrand et al., 2011 [15]). КФ, основанная на релевантных пользователях (user-based CF) - один из ранних алгоритмов КФ, применялась в GroupLens для рекомендательной системы новостей (Resnick et al., 1994 [16]). КФ, основанная релевантных пользователях, представляет каждого пользователя как вектор оценок, и предсказывает недостающие оценки сообщений, основываясь на взвешенном среднем оценок данного сообщения другими пользователями. Подобным образом Sarwar et al. (2001) [17] представляет метод КФ, основанной на релеватных объектах (item-based CF), и далее Linden et al. (2003) [18] описывает использование данного метода в рекомендательной системе товаров Амазон. КФ, основанная на релеватных объектах, представляет каждый объект как вектор оценок, и предсказывает недостающие значения, основываясь на взвешенном среднем оценок похожих элементов.

Несмотря на то, что механизм предсказаний, основанный на оценках, должен быть относительно сложным для понимания среднего пользователя, КФ, основанная на на релеватных пользователях или объектах, легко объясняется благодаря философии алгоритма. Например, объекты, рекомендованные КФ, основанной на релеватных пользователях, могут объясняться фразой пользователи со сходными интересами предпочитают данный продукт, в то время как КФ, основанная на релеватных объектах, объясняется фразой данный продукт похож на продукты, которые Вам понравились ранее. Тем не менее, несмотря на то, что идея КФ достигла значительного прогресса в улучшении точности рекомендаций, она менее интуитивна с точки зрения предоставления обоснований рекомендаций в сравнении с алгоритмами, основанными на контенте. Важность данной проблемы отмечается в ранних исследованиях в данной области (Herlocker and Konstan, 2000 [19]; Herlocker et al., 2000 [8]; Sinha and Swearingen, 2002 [9]).

Идея КФ достигла дальнейшего успеха в 2000х гг., когда в работе Koren (2008) [20] была представлена интеграция КФ и скрытой факторной модели (Latent Factor Models or LFM). Матричная факторизация (Matrix Factorization or MF) и ее разновидности оказались особенно успешны в задачах предсказания оценок (Koren et al., 2009 [21]). Исследования, посвященные скрытым факторным моделям, были ведущими в области рекомендательных систем в течении многих лет. Тем не менее, несмотря на хорошую производительность, показанную в задаче предоставления рекомендаций, скрытые факторы в скрытых факторных моделях не поддаются интуитивному объяснению, что делает трудным понимание, почему тот или иной объект получил высокий рейтинг рекомендации или почему был выбран именно он среди других объектов. Недостаточность объяснимости модели усложняет задачу предоставления обоснований пользователям, т.к. высокий рейтинг, полученный при решении задачи рекомендации не может служить удовлетворительным объяснением для конечного пользователя.

Для того, чтобы сделать рекомендательные модели более понятными, исследователи постепенно обратились к проблеме рекомендательных систем с обоснованием (Explainable Recommendation Systems), т.е. таких систем, в которых рекомендательный алгоритм не только выводит список рекомендаций, но также предоставляет обоснования для рекомендаций. Например, Zhang et al. (2014a) [3] определяет проблему рекомендаций с обоснованием и предлагает явную факторную модель (Explicit Factor Model or EFM) путем выравнивания скрытых измерений с явными признаками для получения рекомендаций с обоснованиями. Для решения проблемы обоснований были также предложены другие подходы, которые в дальнейшем будут рассмотрены в данной статье. Стоит отметить, что в последние годы появились примеры применения моделей глубокого обучения (deep learning or DL) для получения персонализированных рекомендаций. Мы полагаем, что использование моделей глубокого обучения для улучшения производительности в рекомендательных системах может иметь спорный результат (Dacrema et al., 2019 [22]) , но данная проблема выходит за рамки нашего исследования. В этом обзоре мы фокусируемся на том, что глубокие модели имеют природу черного ящика, и данная характеристика моделей вносит сложности в обеспечение обоснований. Далее мы рассмотрим исследования в области построения рекомендательных систем на основе моделей глубокого обучения.

В широком смысле, свойство объяснимости (explainability) систем ИИ уже было в центре обсуждения в 1980х в эпоху исследований старого, или логического ИИ, когда системы, основанные на знаниях (knowledge-based systems), выполняли задачи предсказания или диагностики с достаточным качеством, но не могли объяснить, почему был сделан тот или иной выбор. Работа (Clancey, 1982 [23]) показала, что предоставление обоснований требует гораздо больших знаний, чем простое предсказание. Недавний взрыв в области больших данных и быстрый рост вычислительных мощностей вывели производительность ИИ на новый уровень, но более широкое сообщество исследователей ИИ в последние годы вновь осознало важность ИИ с обоснованием (Explainable AI or XAI) (Gunning, 2017) [24]. Область ИИ с обоснованием включает исследование широкого круга задач обоснования ИИ в глубоком обучении, компьютерном зрении, системах беспилотного вождения и задачах обработки естественного языка. Тот факт, что данная задача является существенным направлением исследований в области ИИ, подчеркивает необходимость пристального внимания исследователей из области получения информации и рекомендательных систем (IR/RecSys) для решения задач обоснований в различных системах поиска и получения рекомендаций. Кроме того, проблема рекомендаций с обоснованием является подходящей задачей для основания нового направления исследований теорий и алгоритмов машинного обучения с обоснованием (Explainable Machine Learning).

1.3.Классификация методов

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

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

  1. Источник информации, или форма представления обоснований (напр., обоснование в виде предложений текста), что раскрывает аспект человекомашинного взаимодействия (HumanComputer Interaction or HCI) в исследованиях обоснования рекомендаций.

  2. Модели для генерации обоснований, что отражает аспект машинного обучения в данном направлении исследований. Потенциальные модели с обоснованием включают в себя метод ближайшего соседа (nearest-neighbor), матричную факторизацию, тематическое моделирование (topic modelling), графические модели (graph-models), глубокое обучение, механизмы вывода (knowledge reasoning), поиск по ассоциативным правилам (association rule mining) и др.

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

В таблице 1.1. показана классификация . Например, явная факторная модель для рекомендаций с обоснованием (Zhang et al., 2014a [3]) используется в сочетании с методом матричной факторизации, в результате обоснование представляется в виде предложения для рекомендованного объекта. Таким образом, данная модель попадает в категорию матричная факторизация с текстовым обоснованием. Интерпретируемая сверточная нейронная сеть (Seo et al., 2017 [25]), с другой стороны, предполагает использование модели глубокой сверточной нейронной сети и в качестве обоснований предлагает использование признаков объектов. Следовательно, она попадает в категорию глубокое обучение с обоснованием с помощью признаков объектов/пользователей. Другим примером является рекомендация с визуальным обоснованием (Chen et al., 2019b [26]), что предполагает использование модели глубокого обучения для генерации изображения-обоснования, что относится к категории глубокое обучение с визуальным обоснованием. Подобным образом мы классифицируем и другие исследования согласно данной таксономии, так что читатели могут проследить отношения между существующими методами рекомендаций с обоснованием.

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

Таблица 1.1 (начало)

Метод ближайшего соседа

Матричная факторизация

Тематическое моделирование

Графические методы

Релевантные пользователи или объекты

Herlocker et al., 2000 [8]

Abdollahi and Nasraoui, 2017 [32]

-

Heckel et al., 2017 [37]

Признаки пользователя или объекта

Vig et al., 2009 [30]

Zhang et al., 2014a [3]

McAuley and Leskovec, 2013 [34]

He et al., 2015 [38]

Текстовое обоснование, предложение

-

Zhang et al., 2014a [3]

-

-

Визульное обоснование

-

-

-

-

Социальное обоснование

Sharma and Cosley, 2013 [31]

-

Ren et al., 2017 [35]

Park et al., 2018 [39]

Кластер слов

-

Zhang, 2015 [33]

Wu and Ester 2015 [36]

-

Таблица 1.1 (продолжение)

Глубокое обучение

Системы, основанные на знаниях

Поиск правил

Объяснения постфактум

Релевантные пользователи или объекты

Chen et al., 2018c [40]

Catherine et al., 2017 [42]

Peake and Wang 2018 [5]

Cheng et al., 2019a [47]

Признаки пользователя или объекта

Seo et al., 2017 [25]

Huang et al., 2018 [43]

Davidson et al., 2010 [45]

McInerney et al., 2018 [48]

Текстовое обоснование,предложение

Li et al., 2017 [41]

Ai et al., 2018 [44]

Balog et al., 2019 [46]

Wang et al., 2018d [4]

Визульное обоснование

Chen et al., 2019b [26]

-

-

-

Социальное обоснование

-

-

-

-

Кластер слов

-

-

-

-

1.4.Объяснимость и результативность

Цели улучшить свойства объяснимости (explainability) и результативности (effectiveness) могут конфликтовать при разработке архитектуры модели, что приводит к необходимости компромисса (Ricci et al., 2011 [11]). Например, мы можем либо выбрать простую модель для улучшения качества объяснимости, либо выбрать сложную модель для улучшения точности в ущерб объяснимости. В то же время последние исследования показали, что обе цели необязательно являются конфликтующими в проектировании рекомендательных моделей (Bilgic et al., 2004 [27]; Zhang et al., 2014a [3]). Например, новейшие методы такие как глубокое обучение представлениям (deep representation learning) могут помочь проектировать рекомендательные модели, являющиеся одновременно и объяснимыми, и результативными. Разработка моделей глубокого обучения с обоснованием (explainable deep models) также является востребованным направлением в более широкой области ИИ, что приводит к дальнейшему прогрессу не только в области рекомендаций с обоснованиями, но и в фундаментальных проблемах машинного обучения с обоснованием (explainable machine learning).

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

1.5.Объяснимость и интерпретируемость

Объяснимость (explainability) и интерпретируемость (interpretability) являются тесно связанными концепциями в литературе. В целом, интерпретируемость один из подходов для достижения объяснимости. Более подробно, ИИ с обоснованием предназначен для разработки моделей, которые могут объяснить свои решения или решения других моделей пользователям или разработчикам. Для достижения данной цели, модели могут быть как интерпретируемыми, так и не интерпретируемыми. Например, в интерпретируемых моделях (такие как интерпретируемые модели машинного обучения) механизм вывода прозрачен в локальном или глобальном смыслах, и, таким образом, выходные данные модели обычно легко объяснимы. Выдающимися примерами интерпретируемых моделей может служить множество линейных моделей, таких как линейная регрессия и модели, основанные на деревьях, такие как деревья решений. Между тем, интерпретируемость является не единственным способом достигнуть объяснимости, например, некоторые модели могут раскрывать свой внутренний механизм принятия решений для предоставления обоснований с помощью сложных методов обоснования, таких как механизмы внимания (neural attention mechanisms), объяснения на естественном языке, а также существует множество моделей обоснования постфактум, широко использующихся при получении информации (IR), в задачах обработки естественного языка (NLP), компьютерном зрении (computer vision), анализе графов (graph analysis) и множестве других задач. Исследователи и практикующие специалисты могут разрабатывать и выбирать подходящие методы обоснований для достижения объяснимости в ИИ для различных задач.

1.6.Как читать данный обзор

Аудитория читателей данного обзора включает в себя как исследователей, так и практикующих специалистов, заинтересованных в области рекомендательных систем с обоснованиями. Читателям рекомендуется приобрести базовые представления о рекомендательных системах, например, о рекомендациях, основанных на контенте (Pazzani and Billsus, 2007 [13]), коллаборативной фильтрации (Ekstrand et al., 2011 [15]) и оценке рекомендательных систем (Shani and Gunawardana, 2011 [28]). Кроме того, читателям будет полезно ознакомиться с другими обзорами, посвященными теме обоснований в рекомендательных системах с точек зрения пользователя (Tintarev and Masthoff, 2007a [10]) или интерпретируемого машинного обучения (Lipton, 2018 [1]; Molnar, 2019 [2]), а также с ИИ с обоснованием в целом (Gunning, 2017 [24]; Samek et al., 2017 [29]).

Данный обзор структурирован следующим образом. В разделе 2 мы рассмотрим рекомендации с обоснованием с точки зрения взаимодействия с пользователем. В частности, мы обсудим различные источники информации, которые могут использоваться для получения обоснований, и тесно связанные с ними различные форматы представления информации. Раздел 3 фокусируется на аспекте машинного обучения в примении к решению задачи рекомендаций с обоснованиями и содержит классификацию моделей. В раздел 4 вводятся стандарты оценки рекомендаций с обоснованиями, а в разделе 5 обсуждается применение методов получения рекомендаций с обоснованием для решения практических задач в реальных рекомендательных системах. В разделе 6 мы завершаем обзор обсуждением нескольких открытых важных проблем и будущими направлениями исследований в данной области.

Список литературы

Список литературы

  1. Lipton, Z. C. (2018). The mythos of model interpretability. Communications of the ACM. 61(10): 3643.

  2. Molnar, C. (2019). Interpretable Machine Learning. Leanpub.

  3. Zhang, Y., G. Lai, M. Zhang, Y. Zhang, Y. Liu, and S. Ma (2014a). Explicit factor models for explainable recommendation based on phrase-level sentiment analysis. In: Proceedings of the 37th International ACM SIGIR Conference on Research & Development in Information Retrieval. ACM. 8392.

  4. Wang, X., Y. Chen, J. Yang, L. Wu, Z. Wu, and X. Xie (2018d). A reinforcement learning framework for explainable recommendation. In: 2018 IEEE International Conference on Data Mining (ICDM). IEEE. 587596.

  5. Peake, G. and J. Wang (2018). Explanation mining: Post hoc interpretability of latent factor models for recommendation systems. In: Proceedings of Beyond Personalization 2005: A Workshop on the Next Stage of Recommender Systems Research at the 2005 International Conference on Intelligent User Interfaces, San Diego, CA, USA. ACM. 20602069.

  6. Miller, T. (2019). Explanation in artificial intelligence: Insights from the social sciences. Artificial Intelligence. 267: 138.

  7. Schafer, J. B., J. Konstan, and J. Riedl (1999). Recommender systems in e-commerce. In: Proceedings of the 1st ACM Conference on Electronic Commerce. ACM. 158166.

  8. Herlocker, J. L., J. A. Konstan, and J. Riedl (2000). Explaining collaborative filtering recommendations. In: Proceedings of the 2000 ACM Conference on Computer Supported Cooperative Work. ACM. 241250.

  9. Sinha, R. and K. Swearingen (2002). The role of transparency in recommender systems. In: CHI02 Extended Abstracts on Human Factors in Computing Systems. ACM. 830831.

  10. Tintarev, N. and J. Masthoff (2007a). A survey of explanations in recommender systems. In: Data Engineering Workshop, 2007 IEEE 23rd International Conference. IEEE. 801810.

  11. Ricci, F., L. Rokach, and B. Shapira (2011). Introduction to recommender systems handbook. In: Recommender Systems Handbook. Springer. 135.

  12. Balabanovic, M. and Y. Shoham (1997). Fab: Content-based, collaborative recommendation. Communications of the ACM. 40(3): 6672.

  13. Pazzani, M. J. and D. Billsus (2007). Content-based recommendation systems. In: The Adaptive Web. Springer. 325341.

  14. Ferwerda, B., K. Swelsen, and E. Yang (2012). Explaining contentbased recommendations. New York. 124.

  15. Ekstrand, M. D. et al. (2011). Collaborative filtering recommender systems. Foundations and Trends in HumanComputer Interaction. 4(2): 81173.

  16. Resnick, P., N. Iacovou, M. Suchak, P. Bergstrom, and J. Riedl (1994). GroupLens: An open architecture for collaborative filtering of netnews. In: Proceedings of the 1994 ACM Conference on Computer Supported Cooperative Work. ACM. 175186.

  17. Sarwar, B., G. Karypis, J. Konstan, and J. Riedl (2001). Item-based collaborative filtering recommendation algorithms. In: Proceedings of the 10th International Conference on World Wide Web. ACM. 285295.

  18. Linden, G., B. Smith, and J. York (2003). Amazon.com recommendations: Item-to-item collaborative filtering. IEEE Internet Computing. 7(1): 7680.

  19. Herlocker, J. L. and J. A. Konstan (2000). Understanding and Improving Automated Collaborative Filtering Systems. University of Minnesota Minnesota.

  20. Koren, Y. (2008). Factorization meets the neighborhood: A multifaceted collaborative filtering model. In: Proceedings of the 14th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining. ACM. 426434.

  21. Koren, Y., R. Bell, and C. Volinsky (2009). Matrix factorization techniques for recommender systems. Computer. 42(8): 4249.

  22. Dacrema, M. F., P. Cremonesi, and D. Jannach (2019). Are we really making much progress? A worrying analysis of recent neural recommendation approaches. In: Proceedings of the 13th ACM Conference on Recommender Systems. ACM. 101109.

  23. Clancey, W. J. (1982). The epistemology of a rule-based expert system: A framework for explanation. Tech. Rep. Department of Computer Science, Stanford University, CA.

  24. Gunning, D. (2017). Explainable artificial intelligence (XAI). Defense Advanced Research Projects Agency (DARPA).

  25. Seo, S., J. Huang, H. Yang, and Y. Liu (2017). Interpretable convolutional neural networks with dual local and global attention for review rating prediction. In: Proceedings of the 11th ACM Conference on Recommender Systems. ACM. 297305.

  26. Chen, X., H. Chen, H. Xu, Y. Zhang, Y. Cao, Z. Qin, and H. Zha (2019b). Personalized fashion recommendation with visual explanations based on multimodal attention network: Towards visually explainable recommendation. In: Proceedings of the 42nd International ACM SIGIR Conference on Research and Development in Information Retrieval. ACM. 765774.

  27. Bilgic, M., R. Mooney, and E. Rich (2004). Explanation for recommender systems: Satisfaction vs. promotion. Computer Sciences Austin, University of Texas. Undergraduate Honors. 27.

  28. Shani, G. and A. Gunawardana (2011). Evaluating recommendation systems. In: Recommender Systems Handbook. Springer. 257297.

  29. Samek, W., T. Wiegand, and K.-R. Mller (2017). Explainable artificial intelligence: Understanding, visualizing and interpreting deep learning models. arXiv preprint arXiv:1708.08296.

  30. Vig, J., S. Sen, and J. Riedl (2009). Tagsplanations: Explaining recommendations using tags. In: Proceedings of the 14th International Conference on Intelligent User Interfaces. ACM. 4756.

  31. Sharma, A. and D. Cosley (2013). Do social explanations work?: Studying and modeling the effects of social explanations in recommender systems. In: Proceedings of the 22nd International Conference on World Wide Web. ACM. 11331144.

  32. Abdollahi, B. and O. Nasraoui (2017). Using explainability for constrained matrix factorization. In: Proceedings of the 11th ACM Conference on Recommender Systems. ACM. 7983.

  33. Zhang, Y. (2015). Incorporating phrase-level sentiment analysis on textual reviews for personalized recommendation. In: Proceedings of the 8th ACM International Conference on Web Search and Data Mining. ACM. 435440.

  34. McAuley, J. and J. Leskovec (2013). Hidden factors and hidden topics: understanding rating dimensions with review text. In: Proceedings of the 7th ACM Conference on Recommender Systems. ACM. 165172.

  35. Ren, Z., S. Liang, P. Li, S. Wang, and M. de Rijke (2017). Social collaborative viewpoint regression with explainable recommendations. In: Proceedings of the 10th ACM International Conference on Web Search and Data Mining. ACM. 485494.

  36. Wu, Y. and M. Ester (2015). Flame: A probabilistic model combining aspect based opinion mining and collaborative filtering. In: Proceedings of the 8th ACM International Conference on Web Search and Data Mining. ACM. 199208.

  37. Heckel, R., M. Vlachos, T. Parnell, and C. Duenner (2017). Scalable and interpretable product recommendations via overlapping coclustering. In: 2017 IEEE 33rd International Conference on Data Engineering (ICDE). IEEE. 10331044.

  38. He, X., T. Chen, M.-Y. Kan, and X. Chen (2015). Trirank: Review-aware explainable recommendation by modeling aspects. In: Proceedings of the 24th ACM International on Conference on Information and Knowledge Management. ACM. 16611670.

  39. Park, H., H. Jeon, J. Kim, B. Ahn, and U. Kang (2018). UniWalk: Explainable and accurate recommendation for rating and network data. arXiv preprint arXiv:1710.07134.

  40. Chen, X., H. Xu, Y. Zhang, Y. Cao, H. Zha, Z. Qin, and J. Tang (2018c). Sequential recommendation with user memory networks. In: Proceedings of the 11th ACM International Conference on Web Search and Data Mining. ACM.

  41. Li, P., Z. Wang, Z. Ren, L. Bing, and W. Lam (2017). Neural rating regression with abstractive tips generation for recommendation. In: Proceedings of the 40th International ACM SIGIR conference on Research and Development in Information Retrieval. ACM. 345354.

  42. Catherine, R., K. Mazaitis, M. Eskenazi, and W. Cohen (2017). Explainable entity-based recommendations with knowledge graphs. In: Proceedings of the Poster Track of the 11th ACM Conference on Recommender Systems. ACM.

  43. Huang, J., W. X. Zhao, H. Dou, J.-R. Wen, and E. Y. Chang (2018). Improving sequential recommendation with knowledge-enhanced memory networks. In: The 41st International ACM SIGIR Conference on Research & Development in Information Retrieval. ACM. 505514.

  44. Ai, Q., V. Azizi, X. Chen, and Y. Zhang (2018). Learning heterogeneous knowledge base embeddings for explainable recommendation. Algorithms. 11(9): 137.

  45. Davidson, J., B. Liebald, J. Liu, P. Nandy, T. Van Vleet, U. Gargi, S. Gupta, Y. He, M. Lambert, B. Livingston, et al. (2010). The YouTube video recommendation system. In: Proceedings of the 4th ACM conference on Recommender systems. ACM. 293296.

  46. Balog, K., F. Radlinski, and S. Arakelyan (2019). Transparent, scrutable and explainable user models for personalized recommendation. In: Proceedings of the 42nd International ACM SIGIR Conference on Research and Development in Information Retrieval. ACM.

  47. Cheng, W., Y. Shen, L. Huang, and Y. Zhu (2019a). Incorporating interpretability into latent factor models via fast influence analysis. In: Proceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. ACM. 885893.

  48. McInerney, J., B. Lacker, S. Hansen, K. Higley, H. Bouchard, A. Gruson, and R. Mehrotra (2018). Explore, exploit, and explain: Personalizing explainable recommendations with bandits. In: Proceedings of the 12th ACM Conference on Recommender Systems. ACM. 3139.

Подробнее..

Рекомендации Друзей ВКонтакте ML на эго-графах

13.04.2021 14:10:30 | Автор: admin

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

Меня зовут Женя Замятин, я работаю в команде Core ML ВКонтакте. Хочу рассказать, как устроены рекомендации, которые делают ближе пользователей самой крупной социальной сети рунета.

Обзор

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

Прежде всего сформулируем задачу, которую будем решать: для каждого пользователя необходимо найти k кандидатов, которых он с наибольшей вероятностью добавит в друзья. Метрика, на которую будем ориентироваться, recall@k. Она идеально описывает задачу: на первом уровне нам не интересен порядок кандидатов, но важна их релевантность.

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

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

Кроме методов на основе анализа общих друзей, довольно распространены рекомендации на базе эмбеддингов. В Лаборатории искусственного интеллекта ВКонтакте в МФТИ мы провели исследование: сравнили эффективность разных подходов к задаче предсказания дружб в VK. Результаты совпали с нашим опытом решения на базе графовых эмбеддингов у нас работают плохо. Учитывая это, мы стали развивать систему отбора кандидатов по пути анализа общих друзей.

EGOML

Общая схема нашего метода продолжает идеи числа общих друзей и Adamic/Adar. Финальная мера релевантности E(u, v), с помощью которой мы будем отбирать кандидатов, всё так же раскладывается в сумму по общим друзьям u и v. Ключевое отличие в форме слагаемого под суммой: в нашем случае это мера ez_c(u, v).

Сначала попробуем понять физический смысл меры ez_c(u, v). Представим, что мы взяли пользователя c и спросили у него: Насколько вероятно, что два твоих друга, u и v, подружатся? Чем больше информации для оценки он учтёт, тем точнее будет его предсказание. Например, если c сможет вспомнить только число своих друзей, его рассуждения могут выглядеть следующим образом: Чем больше у меня друзей, тем менее вероятно, что случайные двое из них знакомы. Тогда оценка вероятность дружбы u и v (с точки зрения c) может выглядеть как 1/log(n), где n число друзей. Именно так устроен Adamic/Adar. Но что если c возьмёт больше контекста?

Прежде чем отвечать на этот вопрос, разберёмся, почему ez_c(u, v) важно определять через пользователя c. Дело в том, что в таком виде очень удобно решать задачу распределённо. Представим, что теперь мы разослали всем пользователям платформы анкету с просьбой оценить вероятность дружбы в каждой паре их друзей. Получив все ответы, мы можем подставить значения в формулу E(u, v). Именно так выглядит вычисление E(u, v) с помощью MapReduce:

  • Подготовка. Для каждого c выделяется тот контекст, который он будет учитывать для вынесения оценок. Например, в Adamic/Adar это будет просто список друзей.

  • Map. Спрашиваем у каждого c, что он думает про возможность дружбы в каждой паре его друзей. По сути, вычисляем ez_c(u, v) и сохраняем в виде (u, v) ez_c(u, v) для всех u, v in N(c). В случае Adamic/Adar: (u, v) 1/log|N(c)|.

  • Reduce. Для каждой пары (u, v) суммируем все соответствующие ей значения. Их будет ровно столько, сколько общих друзей у u и v.

Таким образом мы получаем все ненулевые значения E(u, v). Заметим: необходимое условие того, что E(u, v) > 0, существование хотя бы одного общего друга у u и v.

Эго-граф ХоппераЭго-граф Хоппера

Контекстом пользователя c в случае меры ez_c будет тот же список друзей, но дополненный информацией о связях внутри этого списка. Такую структуру в науке называют эго-графом. Если более формально, эго-граф вершины x это такой подграф исходного графа, вершинами которого являются все соседи x и сама x, а рёбрами все рёбра исходного графа между этими вершинами. Коллеги из Одноклассников написали подробную статью об эго-графах и затронули в ней вопрос их эффективного построения.

Ключевая идея меры ez_c в том, что её можно сделать обучаемой. Для каждого пользователя c, его эго-графа и всех пар пользователей u, v внутри него мы можем посчитать много разных признаков, например:

  • число общих друзей u и v внутри эго-графа c;

  • число общих друзей u и c;

  • интенсивность взаимодействий между v и c;

  • время, прошедшее с последней дружбы между u и кем-либо из эго-графа c;

  • плотность эго-графа c;

  • и другие.

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

В конечном счёте мы получаем датасет следующего вида:

  • для каждой пары пользователей u и v, а также их общего друга c, посчитаны признаки по эго-графу c;

  • пара пользователей u и v встречается в датасете ровно столько раз, сколько у них общих друзей;

  • все пары пользователей в датасете не являются друзьями на момент времени T;

  • для каждой пары u и v проставлена метка подружились ли они в течение определённого промежутка времени начиная с T.

По такому датасету мы и будем обучать нашу меру ez_c. В качестве модели выбрали градиентный бустинг с pairwise функцией потерь, где идентификатором группы выступает пользователь u.
По сути, мера ez_c(u, v) определяется как предсказание описанной выше модели. Но есть один нюанс: при pairwise-обучении распределение предсказаний модели похоже на нормальное. Поэтому, если в качестве определения меры ez_c(u, v) взять сырое предсказание, может возникнуть ситуация, когда мы будем штрафовать финальную меру E(u, v) за общих друзей, так как значения предсказаний бывают отрицательными. Это выглядит не совсем логично хочется, чтобы с ростом числа общих друзей мера E(u, v) не убывала. Так что поверх предсказания модели мы решили взять экспоненту:

Такой подход хорошо себя показывает на небольших графах. Но чтобы применить его на реальных данных, необходимо выполнить ещё одно действие. Суть проблемы такая: мы не можем вычислять признаки и применять модель для каждой пары пользователей всех эго-графов это слишком долго. Для решения мы придумали специальный трюк. Представим, что наш градиентный бустинг обучился таким образом, что каждое дерево использует признаки только одного пользователя: либо u, либо v. Тогда мы могли бы разделить весь ансамбль на две группы: к группе A мы бы отнесли деревья, которые используют только признаки пользователя u, к B пользователя v. Предсказание такой модели можно представить в виде:

Имея такую модель, мы могли бы получить предсказания для всех пар пользователей одного эго-графа быстрее. Достаточно применить модели A и B для каждого пользователя, а затем сложить соответствующие парам предсказания. Таким образом, для эго-графа из n вершин мы могли бы сократить число применений модели с O(n^2) до O(n). Но как получить такую модель, каждое дерево которой зависит только от одного пользователя? Для этого сделаем следующее:

  1. Исключим из датасета все признаки, которые одновременно зависят и от u и от v. Например, от признака число общих друзей u и v внутри эго-графа c придётся отказаться.

  2. Обучим модель A, используя только признаки на базе u, c и эго-графа c.

  3. Для обучения модели B оставим только признаки на базе v, c и эго-графа c. Также в качестве базовых предсказаний передадим предсказания модели A.

Если объединим модели A и B, получим то что нужно: первая часть использует признаки u, вторая признаки v. Совокупность моделей осмысленна, поскольку B была обучена корректировать предсказания A. Эта оптимизация позволяет ускорить вычисления в сотни раз и делает подход применимым на практике. Финальный вид ez_c(u, v) и E(u, v) выглядит так:

Вычисление меры E в онлайне

Заметим, что E(u, v) можно представить в виде:

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

При построении рекомендаций мы уже вычислили предсказания моделей для всех существующих дружб. Поэтому для каждого пользователя мы можем собрать векторы и сложить их в доступное онлайн key-value хранилище. После этого сможем получать значение E(u, v) для любой пары пользователей в онлайне простой операцией перемножения векторов. Это даёт возможность использовать E(u, v) как лёгкую функцию релевантности в нагруженных местах либо как дополнительный признак финальной модели ранжирования.

Итог

В результате система EGOML позволяет:

  1. Распределённо отбирать кандидатов для каждого пользователя в офлайне. Асимптотическая сложность оптимизированного алгоритма составляет O(|E|) вычислений признаков и применений модели, где |E| число связей в графе. На кластере из 250 воркеров время работы алгоритма составляет около двух часов.

  2. Быстро вычислять меру релевантности E(u, v) для любой пары пользователей в онлайне. Асимптотическая сложность операции O(|N(u)| + |N(v)|).

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

В конечном счёте мы перешли со способа отбора кандидатов с использованием Adamic/Adar к системе EGOML и внедрили в модель второй уровень признаков на основе меры E(u, v). И это позволило увеличить количество подтверждённых дружб со всей платформы на несколько десятков процентов.

Благодарность

Хочу сказать спасибо руководителю команды Core ML Андрею Якушеву за помощь в разработке метода и подготовке статьи, а также всей команде Core ML за поддержку на разных этапах этой работы.

Подробнее..

Как использовать ClickHouse не по его прямому назначению

09.04.2021 12:18:12 | Автор: admin

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

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

ClickHouse для тестов железа

Самое простое, что можно сделать с ClickHouse, если есть свободные серверы это использовать его для тестов оборудования. Потому что его тестовый dataset содержит те же данные с production Яндекса, только анонимизированные и они доступны снаружи для тестирования. Про то, как подготовить хорошие анонимизированные данные, я рассказывал на Saint HighLoad++ 2019 в Санкт-Петербурге.

Ставим ClickHouse на любой Linux (x86_64, AArch64) или Mac OS. Как это сделать? мы собираем его на каждый коммит и pull request. ClickHouse Build Check покажет нам все детали всех возможных билдов:

Отсюда можно скачать любой бинарник с gcc и clang в релизе, в debug, со всякими санитайзерами или без, для x86, ARM или даже Mac OS. ClickHouse использует все ресурсы железа: все ядра CPU, шины памяти и грузит все диски. Какой сервер ему не дай проверит полностью, хорошо или плохо тот работает.

По этой инструкции можно скачать бинарник, тестовые данные и запустить запросы. Тест займёт около 30 минут и не требует установки ClickHouse. И даже если на сервере уже установлен другой ClickHouse, вы все равно сможете запустить тест.

В результате мы получаем публичный список протестированного железа:

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

Вы можете выбрать серверы для сравнения для каждого можно посмотреть разницу в производительности. Конечно, и других тестов железа существует немало, например, SPECint и вообще куча тестов из организации SPEC. Но ClickHouse позволяет не просто тестировать железо, а тестировать рабочую СУБД на настоящих данных на реальных серверах откуда угодно.

ClickHouse без сервера

Конечно, обычно ClickHouse это сервер + клиент. Но иногда нужно просто обработать какие-то текстовые данные. Для примера я взял все исходники ClickHouse, собрал их в файл и сконкатенировал в файл под названием code.txt:

И, например, я хочу проверить, какие строчки в коде на C++ самые популярные. С помощью типичной shell-команды удалим из каждой строчки кода начальные пробелы и пустые строки, отсортируем и посчитаем количество уникальных. После сортировки видим, что, конечно, самая популярная строчка это открывающая фигурная скобка, за ней закрывающая фигурная скобка, а еще очень популярно return false.

Этот результат я получил за 1,665 секунд. Потому что все это было сделано с учетом сложной локали. Если локаль заменить на простую, выставив переменную окружения LC_ALL=C, то будет всего лишь 0,376 с, то есть в 5 раз быстрее. Но это всего-лишь шел скрипт.

Можно ли быстрее? Да, если использовать clickhouse-local, будет еще лучше.

Это как-будто одновременно и сервер и клиент, но на самом деле ни то, и ни другое clickhouse-local может выполнять SQL запросы по локальным файлам. Вам достаточно указать запрос, структуру и формат данных (можно выбрать любой из форматов, по умолчанию TabSeparated), чтобы обработать запрос на входном файле. За 0.103 секунд то есть в 3,716 раз быстрее (в зависимости от того, как вы запускали предыдущую команду).

Для демонстрации чего-то более серьезного давайте посмотрим на те данные, которые собирает GitHub Archive это логи всех действий всех пользователей, которые происходили на GitHub, то есть коммиты, создание и закрытие issue, комментарии, код-ревью. Все это сохраняется и доступно для скачивания на сайте https://www.gharchive.org/ (всего около 890 Гб):

Чтобы их как-нибудь обработать, выполним запрос с помощью ClickHouse local:

Я выбрал все данные из табличной функции file, которая берет файлы вида *.json.gz то есть все файлы в формате TSV, интерпретируя их как одно поля типа string. С помощью функции для обработки JSON я вытащил из каждой JSONины сначала поле 'actor', а потом поле 'login' в случае, когда оно равно Алексей Миловидов и выбрал таких первых 10 действий на GitHub.

Может возникнуть впечатление, что 890 Гб данных смогли обработаться за 1,3 секунды. Но на самом деле запрос работает потоково. После того, как находятся первые 10 строк, процесс останавливается. Теперь попробуем выполнить более сложный запрос, например, я хочу посчитать, сколько всего действий я совершил на GitHub. Используем SELECT COUNT... и через полторы секунды кажется, что ничего не происходит. Но что происходит на самом деле, мы можем посмотреть в соседнем терминале с помощью программы dstat:

И мы видим, что данные читаются с дисков со скоростью примерно 530 Мб/с и все файлы обрабатываются параллельно почти с максимальной скоростью насколько позволяет железо (на сервере RAID из нескольких HDD).

Но можно использовать ClickHouse local даже без скачивания этих 980 Гб. В ClickHouse есть табличная функция url то есть можно вместо file написать адрес https://.../*.json.gz, и это тоже будет обрабатываться.

Чтобы можно было выполнять такие запросы в ClickHouse, мы реализовали несколько вещей:

  1. Табличная функция file.

  2. Поддержка glob patterns. В качестве имени файлов можно использовать шаблон с glob patterns (звёздочка, фигурные скобки и пр.)

  3. Поддержка сжатых файлов в формате gzip, xz и zstd из коробки. Указываем gz и всё работает.

  4. Функции для работы с JSON. Могу утверждать, что это самые эффективные функции для обработки JSON, которые мы смогли найти. Если вы найдёте что-нибудь лучше, скажите мне.

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

  6. Тот самый параллельный парсинг.

Применять можно, само собой, для обработки текстовых файлов. Еще для подготовки временной таблицы и партиций для MergeTree. Можно провести препроцессинг данных перед вставкой: читаете в одной структуре, преобразовываете с помощью SELECT и отдаете дальше в clickhouse-client. Для преобразования форматов тоже можно например, преобразовать данные в формате protobuf с разделителями в виде длины в JSON на каждой строке:

clickhouse-local --input-format Protobuf --format-schema такая-то --output format JSONEachRow ...

Serverless ClickHouse

ClickHouse может работать в serverless-окружении. Есть пример, когда ClickHouse засунули в Лямбда-функцию в Google Cloud Run: https://mybranch.dev/posts/clickhouse-on-cloud-run/ (Alex Reid). Там на каждый запрос запускается маленький ClickHouse на фиксированных данных и эти данные обрабатывает.

Текстовые форматы

Для обработки текстовых данных, естественно, есть поддержка форматов tab separated (TSV) и comma separated (CSV). Но еще есть формат CustomSeparated, с помощью которого можно изобразить и тот, и другой в качестве частных случаев.

CustomSeparated:

format_custom_escaping_rule

format_custom_field_delimiter

format_custom_row_before/between/after_delimiter

format_custom_result_before/after_delimiter

Есть куча настроек, которые его кастомизируют. Первая настройка это правило экранирования. Например, вы можете сделать формат CSV, но в котором строки экранированы как в JSON, а не как CSV. Разница тонкая, но довольно важная. Можно указать произвольный разделитель типа | и пр. между значениями, между строками и т.п.

Более мощный формат это формат Template:

format_template_resultset

format_template_row

format_template_rows_between_delimiter

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

Есть формат Regexp:

format_regexp

format_regexp_escaping_rule

format_regexp_skip_unmatched

И тут clickhouse-local превращается в настоящий awk. Указываете регулярные выражения, в Regexp есть subpatterns, и каждый subpattern теперь парсится как столбец. Его содержимое обрабатывается согласно некоторому правилу экранирования. И конечно можно написать пропускать строки, для которых регулярное выражение сработало, или нет.

ClickHouse для полуструктурированных данных

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

Допустим, у вас есть таблица с логами, в ней есть столбец с датой и временем, а вот всё остальное вообще непонятно что. Очень соблазнительно всю эту кучу данных записать в один столбец 'message' с типом String. Если эта куча в формате JSON, функции для работы с JSON будут работать. Но неэффективно каждый раз, когда нам будет нужно только одно поле, например 'actor.login', читать придется весь JSON не будет преимущества столбцовой базы данных. С помощью ClickHouse мы легко это исправим прямо на лету, добавив с помощью запроса ALTER материализованный столбец:

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

ALTER TABLE logs UPDATE actor_login = actor_login

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

Ускорение MySQL

В ClickHouse можно создать таблицу на основе табличной функции MySQL. Это просто: указываете хост: порт, БД, таблицу, имя пользователя и пароль (прямо так, как есть), делаем SELECT и всё выполняется за 15 секунд:

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

5 минут 41 секунда это позор! У ClickHouse тут как-будто нет преимуществ данные нужно переслать из MySQL в ClickHouse и потом уже обработать. А MySQL обрабатывает сам у себя локально почему же он так медленно работает?

Еще одна проблема результаты расходятся. У ClickHouse две строки счетчик (20577 и 13772), у MySQL один (44744), потому что он здесь учитывает collation (правила сравнения строк в разном регистре) при GROUP BY. Чтобы это исправить, можно перевести имя в нижний регистр, сгруппировать по нему и выбрать любой вариант:

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

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

Получилось уже 6 секунд, хотя основное предназначение словаря использование для джойнов, когда, например, нам нужно получить данные динамически через другие столбцы. Можно также создать словари MySQL на каждом сервере в кластере ClickHouse и быстро с ними работать. Но если MySQL не выдержит нагрузки при обновлении словаря на каждом сервере в кластере, то можно создать из MySQL словарь на двух ClickHouse-серверах, и они будут доступны в виде таблиц в ClickHouse. Если с помощью движка Distributed создать таблицу, которая смотрит на эти два сервера как на реплики, то можно на всех ClickHouse-серверах создать словари из ClickHouse, которые смотрят на таблицу, которая смотрит на словарь MySQL.

Словари еще можно использовать для шардирования, если схема расположена во внешней мета-базе (и не обязательно в ClickHouse). Это тоже будет работать:

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

Видим, что SELECT выполняется за 0,6 с. Вот это настоящая скорость, какая должна быть это скорость ClickHouse!

В ClickHouse можно даже создать базу данных типа MySQL. Движок БД MySQL создает в ClickHouse базу данных, которая содержит таблицы, каждая из которых представляет таблицу, расположенную в MySQL. И все таблицы будут видны прямо в ClickHouse:

А вообще в ClickHouse много табличных функций. Например, с помощью табличной функции odbc можно обратиться к PostgreSQL, а с помощью url к любым данным на REST-сервере. И все это можно поджойнить:

Примечение: в свежих релизах ClickHouse появилась табличная функция postgresql, движок баз данных PostgreSQL и даже поддержка бинарного протокола PostgreSQL. Кажется это даже слишком круто.

Машинное обучение в ClickHouse

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

Это можно использовать для заполнения пропусков в данных. Пример: компания, занимающаяся недвижимостью, публикует объявления о квартирах с разными параметрами: количество комнат, цена, метраж. Часто некоторые параметры не заполнены например, квадратные метры есть, а количества комнат нет. В этом случае мы можем использовать ClickHouse с моделью CatBoost, чтобы заполнить пропуски в данных.

Более простые модели можно обучать прямо в ClickHouse. Модель машинного обучения у нас будет представлена как агрегатная функция например, стохастическая логистическая регрессия. Задаются гиперпараметры, значение предсказываемой функции и значения фич, причем обучение будет независимым для каждого ключа агрегации, если в запросе указан GROUP BY:

А еще мы можем добавить к агрегатной функции суффикс State:

SELECT stochasticLogisticRegressionState(...

Так можно обучить логистическую регрессию для каждого k и получить состояние агрегатной функции. Состояние имеет полноценный тип данных AggregateFunction(stochasticLogisticRegression(01, 00, 10, 'Adam'), ...), который можно сохранить в таблицу. Достать его из таблицы и применить обученную модель можно функцией applyMLModel:

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

Более развернуто описано в этой презентации.

ClickHouse как графовая база данных

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

Это работает, и говорят, даже быстрее, чем некоторые другие графовые базы данных. Разработал его наш друг, один из ведущих контрибьюторов Amos Bird. Правда, эта разработка не доступна в open-source. Но мы не обижаемся.

UDF в ClickHouse

Казалось бы, в ClickHouse нет возможности написать пользовательские функции (user defined functions). Но на самом деле есть. Например, у вас есть cache-словарь с источником executable, который для загрузки выполняет произвольную программу или скрипт на сервере. И в эту программу в stdin передаются ключи, а из stdout в том же порядке мы будем считывать значения для словаря. Словарь может иметь кэширующий способ размещения в памяти, когда уже вычисленные значения будут кэшированы.

И если вы пишете произвольный скрипт на Python, который вычисляет, что угодно пусть те же модели машинного обучения, и подключаете его в ClickHouse, то получаете вы как раз аналог user defined function.

Примечание: полноценная реализация UDF находится в roadmap на 2021 год.

ClickHouse на GPU и как Application Server

Это ещё два необычных примера. В компании nVidia ClickHouse заставили работать на графических ускорителях, но рассказывать я про это не буду.

А наш друг Zhang2014 превратил ClickHouse почти в Application Server. У Zhang2014 есть pull request, где можно определить свои HTTP-хэндлеры и этим хэндлерам приписать подготовленный запрос (SELECT с подстановками или INSERT). Вы делаете POST на какой-то хэндлер для вставки данных, или делаете вызов какой-то GET ручки, передаете параметры, и готовый SELECT выполнится.

Вывод

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

Подробнее..

Новая схватка двух якодзун или Scylla vs Aerospike ( HBase для массовки)

08.04.2021 18:23:51 | Автор: admin
В прошлый раз обсуждение битвы тяжеловесов Cassandra VS HBase вызвало весьма бурную дискуссию, в ходе которой было много раз упомянута Scylla которая позиционируется как более быстрый аналог Cassandra (далее CS). Также меня заинтересовал весьма любопытный Aerospike (далее AS), который в своих тестах предсказуемо побеждает CS с разгромным счетом.
image

По удивительному совпадению Scylla (далее SC) также легко бьет CS, о чем гордо сообщает прямо на своей заглавной странице:



Таким образом естественным образом возникает вопрос, кто кого заборет, кит или слон?

В моем тесте оптимизированная версия HBase (далее HB) работает с CS на равных, так что он тут будет не в качестве претендента на победу, а лишь постольку, что весь наш процессинг построен на HB и хочется понимать его возможности в сравнении с лидерами.

Понятно, что бесплатность HB и CS это огромный плюс, однако с другой стороны если для достижения одинаковой производительности нужно в х раз больше железа, выгоднее бывает заплатить за софт, чем выделять этаж в ЦОД под дорогие грелки. Особенно учитывая, что если уж речь зашла про производительность, то так как HDD в принципе не способны дать хоть сколько-нибудь приемлемую скорость Random Access чтений (см. "Почему HDD и быстрые Random Access чтения несовместимы"). Что в свою очередь означает покупку SSD, который в объемах нужных для настоящей BigData весьма недешевое удовольствие.

Таким образом, было сделано следующее. Я арендовал 4 сервера в облаке AWS в конфигурации i3en.6xlarge где на борту каждого:
CPU 24 vcpu
MEM 192 GB
SSD 2 x 7500 GB


Если кто-то захочет повторить, то сразу отметим, что очень важно для воспроизводимости брать конфигурации, где полный объем дисков (7500 GB). Иначе диски придется делить с непредсказуемыми соседями, которые обязательно испортят ваши тесты, как им наверняка кажется весьма ценной нагрузкой.

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

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

Поэтому я модифицировал update следующим образом:

  @Override  public Status update(String table, String key,                       Map<String, ByteIterator> values) {    read(table, key, null, null); // << added read before write    return write(table, key, updatePolicy, values);  }


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

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

Насчет AS это весьма привлекательная БД, лидер в номинации удовлетворенности клиентов по версии ресурса g2.


Признаться, мне она тоже как-то приглянулась. Ставится легко, вот этим скриптом достаточно легко раскатывается в облако. Стабильная, конфигурировать одно удовольствие. Однако есть у ней один очень большой недостаток. На каждый ключ она выделяет 64 байта оперативной памяти. Кажется немного, но в промышленных объемах это становится проблемой. Типичная запись в наших таблицах весит 500 байт. Именно такой объем value я использовал почти* во всех тестах (*почему почти будет ниже).

Так как мы храним по 3 копии каждой записи, то получается что для хранения 1 PB чистых данных (3 PB грязных) мы должны будем выделить всего-то 400 TB оперативки. Идем дальше нет чтооо?! Секундочку, а нельзя ли с этим что-нибудь сделать? спросили мы у вендора.

Ха, конечно можно много чего, загибаем пальцы:
1. Упаковать несколько записей в одну (хопа).
2. Тоже самое что в п.1, только за счет расширения числа полей.
3. Включить режим all-flush. Суть хранить индекс не в памяти, а на диске. Правда есть нюанс, Ватсон, опция доступна только в entreprise версии (в моем случае в рамках trial-периода)

Хорошо, теперь разберемся с HB и можно уже будет рассмотреть результаты тестов. Для установки Hadoop у Амазона предусмотрена платформа EMR, которая позволяет легко раскатать необходимый вам кластер. Мне пришлось только поднять лимиты на число процессов и открытых файлов, иначе падало под нагрузкой и заменил hbase-server на свою оптимизированную сборку (подробности тут). Второй момент, HB безбожно тормозит при работе с одиночными запросами, это факт. Поэтому мы работаем только батчами. В данном тесте батч = 100. Регионов в таблице 100.

Ну и последний момент, все базы тестировались в режиме strong consistency. Для HB это из коробки. AS доступно только в enterprise версии. SC гонялась в режиме consistency=all.

Итак, поехали. Insert AS:

10 sec: 360554 operations; 36055,4 current ops/sec;
20 sec: 698872 operations; 33831,8 current ops/sec;

230 sec: 7412626 operations; 22938,8 current ops/sec;
240 sec: 7542091 operations; 12946,5 current ops/sec;
250 sec: 7589682 operations; 4759,1 current ops/sec;
260 sec: 7599525 operations; 984,3 current ops/sec;
270 sec: 7602150 operations; 262,5 current ops/sec;
280 sec: 7602752 operations; 60,2 current ops/sec;
290 sec: 7602918 operations; 16,6 current ops/sec;
300 sec: 7603269 operations; 35,1 current ops/sec;
310 sec: 7603674 operations; 40,5 current ops/sec;
Error while writing key user4809083164780879263: com.aerospike.client.AerospikeException$Timeout: Client timeout: timeout=10000 iterations=1 failedNodes=0 failedConns=0 lastNode=5600000A 127.0.0.1:3000
Error inserting, not retrying any more. number of attempts: 1Insertion Retry Limit: 0


Упс, а вы точно продюссер промышленная база? Можно подумать так на первый взгляд. Однако оказалось, что проблема в ядре амазонской версии линукса. На них завели тикет и в версии amzn2-ami-hvm-2.0.20210326.0-x86_64-gp2 проблему исправили. Но для этих тестов вендор предложил использовать скрипты ансибла под ubuntu, где эта проблема не возникала (для раскатки нужно выбрать соответствующую ветку в гите).

Ладно, продолжаем. Запускаем загрузку 200 млн. записей (INSERT), потом UPDATE, потом GET. Вот что получилось (ops операций в секунду):


ВАЖНО! Это скорость одной ноды! Всего их 4, т.е. чтобы получить суммарную скорость нужно умножать на 4.

Первая колонка 10 полей, это не совсем честный тест. Т.е. это когда индекс в памяти, чего в реальной ситуации BigData недостижимо.

Вторая колонка это упаковка 10 записей в 1. Т.е. тут уже реально идет экономия памяти, ровно в 10 раз. Как отлично видно из теста, такой фокус не проходит даром, производительность существенно падает.

Ну и наконец all-flush, тут примерно такая же картина. Чистые вставки хуже, но ключевая операция Update быстрее, так что дальше будем сравнивать только с all-flush.

Собственно не будем тянуть кота, сразу вот:


Все в общем-то понятно, но что тут стоит добавить.
1. Вендор AS подтвердил, что результаты выше по их БД релевантные.
2. У SC вставки были какие-то не очень правильные, вот более подробный график в разрезе по серверам:


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

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


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

Ну и наконец GET+WRITE (поверх залитых тестом выше пары миллиардов записей):


Что за просадка такая, в душе не догадываюсь. Никаких посторонних процессов не запускалось. Возможно как-то связано с кешом SSD, потому что утилизация во время всего хода тестирования AS в режиме all-flush была 100%.


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

Маркетинговая оптимизация в банке

14.04.2021 10:21:24 | Автор: admin
image
Привет, Хабр.

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

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

В статье поговорим о возможной постановке задачи оптимизации в банковской сфере и методах ее решения.


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

Существует много открытых фреймворков для решения оптимизационных задач таких как Gekko, Pyomo, Python-mip, а так же различное проприетарное ПО типа IBM ILOG CPLEX Optimization Studio.

План статьи




Задача оптимизации


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

$$display$$\begin{aligned} {\large f(\vec{x}) \rightarrow \underset{\vec{x} \in X}{\min} },\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\; \\ X = \left\{\vec{x} \; | \; g_{i}(\vec{x}) \leq 0, \; h_{k}(\vec{x}) = 0, \;\\ i = 1, \ldots, m, \;k=1\ldots,p \right\} \subset R^n.\end{aligned} \;\;\; (1)$$display$$


Т.е. среди всех векторов множества $X$, которое ограничено условиями $g_{i}(\vec{x}) \leq 0$ и $h_{k}(\vec{x}) = 0,$ необходимо найти такой вектор $\vec x^* $, при котором значение $f(\vec{x}^*)$ будет минимальным на всем множестве $X$.
При линейных ограничениях и линейной целевой функции задача (1) относится к классу задач линейного программирования и может быть решена симплекс-методом.

Маркетинговая оптимизация в банке


Представим себе современный банк, работающий с физическими лицами и продающий им свои основные продукты: кредитные карты, кредиты наличными и т.д. Каждому клиенту банк может предложить один из продуктов $P_i, \; i = 1, \ldots, n$ в одном из доступных для коммуникации каналов $C_{k}, \; k = 1, \ldots, m$ (звонок, смс и т.д.). При этом количество доступных для отправки в неделю/месяц коммуникаций в каждом канале (объем канала) ограничено

$\begin{aligned} &\sum Calls \leq N_1 \\ &\sum Sms \leq N_2 \\ &\sum Email \leq N_3 \\ &\sum Push \leq N_4 \\ \end{aligned} \;\;\;(2)$


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

image

Рис. 1

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

image


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

$\begin{cases} p_{11}x_{11} + p_{12}x_{12} + p_{13}x_{13} + p_{21}x_{21} + p_{22}x_{22} + p_{31}x_{31} + p_{32}x_{32} + p_{33}x_{33} \rightarrow \max \\\\ Одному \;клиенту\; не\; более \; одного\; продукта \\ x_{11} + x_{12} + x_{13} \leq 1 \\ x_{21} + x_{22} \leq 1 \\ x_{31} + x_{32} + x_{33} \leq 1 \\ \\ Ограничение \; количества \; звонков \\ x_{12} + x_{21} + x_{31} \leq N_1 \\ \\ Ограничение \; количества \; смс \\ x_{13} + x_{22} + x_{33} \leq N_2 \\\\ Ограничение \; количества \; имейлов\\ x_{11} + x_{32} \leq N_3 \\ \\ x_{ik} \in \left\{0, 1 \right\} \end{cases} \;\;\; (3)$


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

В случае, если целью коммуникаций будет максимизация будущей доходности, то целевую функцию в задаче (3) можно записать в виде

$\begin{aligned}D_{11}p_{11}x_{11} + D_{12}p_{12}x_{12} + D_{13}p_{13}x_{13} &+D_{23}p_{21}x_{21} + D_{22}p_{22}x_{22} +\\+ D_{34}p_{31}x_{31} + D_{32}p_{32}x_{32} + &D_{32}p_{33}x_{33} \rightarrow \max,\end{aligned}\;\;\; (4)$


где $D_{ik}$ доходность от k-го продукта на i-м клиенте. Значения $D_{ik}$ могут быть получены с помощью прогнозных моделей или оценены каким-то другим способом.

Замечания
  1. Описанные выше подходы предполагают, что мы имеем достаточно хорошие прогнозы/оценки для $p_{ik}$ и $D_{ik}.$
  2. Если скоры $p_{ik}$ для различных продуктов получены от разных моделей и при этом они (скоры) плохо согласуются с реальной вероятностью отклика (это можно увидеть, например, по графику как на Рис. 1), то перед оптимизацией их необходимо откалибровать. Про различные способы калибровки можно почитать по ссылке.
  3. Предполагается также, что количество коммуникаций, на которые банк готов потратить средства, меньше, чем количество клиентов, которым банк готов предложить свои продукты. В противном случае оптимизировать будет нечего.


Немного кода


Попробуем решить задачу маркетинговой оптимизации, поставленную в виде (3) с помощью библиотеки MIP, упомянутой выше. Возьмем случайным образом сгенерированный датасет объемом в 6000 строк, в котором содержится 1000 клиентов, каждому из которых можно предложить один из 3-х продуктов в двух каналах SMS и звонок.

Код
import pandas as pdfrom mip import Model, MAXIMIZE, CBC, BINARY, OptimizationStatusframe = pd.read_csv('table_for_optimization.csv')frame.head()


image

Предположим, что у нас есть ограничение на объем коммуникаций: 500 SMS и 200 звонков. Напишем функцию для решения задачи оптимизации.

Код
def optimize(frame: pd.DataFrame, channel_limits: dict) -> list:    """    Возвращает массив оптимальных предложений    """        df = frame.copy()        #создание модели    model = Model(sense=MAXIMIZE, solver_name=CBC)    #вектор бинарных переменных задачи    x = [model.add_var(var_type=BINARY) for i in range(df.shape[0])]    df['x'] = x    #целевая функция    model.objective = sum(df.score * df.x)    #ограничения на количество коммуникаций в каждом канале    for channel in df.channel.unique():        model += (sum(df[df.channel==channel]['x']) <= channel_limits[channel])    #ограничения на количество продуктов для каждого клиента    for client in df.client_id.unique():        model += (sum(df[df['client_id']==client]['x']) <= 1)            status = model.optimize(max_seconds=300)        del df        if status == OptimizationStatus.OPTIMAL or status == OptimizationStatus.FEASIBLE:        return [var.x for var in model.vars]    elif status == OptimizationStatus.NO_SOLUTION_FOUND:        print('No feasible solution found')


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

Код
#объем доступных коммуникаций в каналахCHANNELS_LIMITS = {    'call': 200,    'sms': 500}optimal_decisions = optimize(frame=frame, channel_limits=CHANNELS_LIMITS)frame['optimal_decision'] = optimal_decisions#распределение продуктов в каналахframe[frame['optimal_decision']==1].groupby(['channel', 'product']).\                                    agg({'client_id': 'count'}).\                                    rename(columns={'client_id': 'client_cnt'})


image

Весь код и данные доступны по ссылке.

P.S.


В зависимости от типа прогнозных моделей мы можем располагать не просто средней оценкой вероятности отклика $p_{ik},$ а также иметь распределение этого значения для каждого клиента и продукта. В таком случае задача оптимизации (3) может быть дополнена условием

$\sum (отклик \;с \;вероятностью \geq K ) \geq N. \;\;\; (5)$


Более того, если в нашем распоряжении есть распределение для каждой вероятности $p_{ik}$, то мы можем также решать и обратную задачу: минимизировать количество коммуникаций при условях типа (5) с учетом определенных ограничений, задаваемых бизнесом.

Благодарю коллег из команды GlowByte Advanced Analytics за помощь и консультации при подготовке этой статьи.
Подробнее..

Перевод Обзор статьи AdderNet Действительно ли нам нужно умножение в глубоком обучении? (Классификация изображений)

08.04.2021 14:12:31 | Автор: admin

Использование сложения вместо умножения для свертки результирует в меньшей задержке, чем у стандартной CNN

Свертка AdderNet с использованием сложения, без умноженияСвертка AdderNet с использованием сложения, без умножения

Вашему вниманию представлен обзор статьи AdderNet: действительно ли нам нужно умножение в глубоком обучении?, (AdderNet), Пекинского университета, Huawei Noah's Ark Lab и Сиднейского университета.

Действительно ли нам нужно умножение в глубоком обучении?

Структура статьи

  1. Свертка AdderNet

  2. Прочие моменты: BN, производные, скорость обучения

  3. Результаты экспериментов

1. Свертка AdderNet

1.1. Обобщенные фильтры

  • Как правило, выходной признак Y указывает на сходство между фильтром и входным элементом:

  • где S - мера сходства.

1.2. Стандартная свертка с использованием умножения

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

1.3. Свертка AdderNet с использованием сложения

Свертка AdderNet с использованием сложения, без умноженияСвертка AdderNet с использованием сложения, без умножения
  • Если используется сложение, то вычисляется l1-мера стандартного отклонения между фильтром и входным признаком:

  • с помощью l1-меры стандартного отклонения можно эффективно вычислить сходство между фильтрами и признаками.

Сложение требует гораздо меньших вычислительных ресурсов, чем умножение.

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

2. Прочие моменты: BN, производные, скорость обучения

2.1. Пакетная нормализация (Batch Normalization - BN)

  • После сложения, используется пакетная нормализация (BN) для нормализации Y к соответствующему диапазону, чтобы все функции активации, используемые в обычных CNN, после этого могли использоваться в предлагаемых AdderNets.

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

  • (Появятся ли в будущем какие-нибудь BN, использующие сложение?)

2.2. Производные

  • Производная l1-меры не подходит для градиентного спуска. Таким образом, мы рассматриваем производную l2-меры:

  • Использование точного градиента позволяет точно обновлять фильтры.

  • Чтобы избежать взрыва градиента, градиент X обрезается до [-1,1].

  • Затем вычисляется частная производная выходных признаков Y по отношению к входным характеристикам X как:

  • где HT - функция HardTanh:

2.3. Скорость адаптивного обучения

l2-меры градиентов в LeNet-5-BNl2-меры градиентов в LeNet-5-BN
  • Как показано в этой таблице, меры градиентов фильтров в AdderNets намного меньше, чем в CNN, что может замедлить обновление фильтров в AdderNets.

  • В AdderNets используется адаптивная скорость обучения для разных уровней:

  • где - глобальная скорость обучения всей нейронной сети (например, для сумматора и BN слоев), L(Fl) - градиент фильтра в слое l, а l - соответствующая локальная скорость обучения.

  • Таким образом, локальная скорость обучения может быть определена как

  • где k обозначает количество элементов в Fl, а - гиперпараметр для управления скоростью обучения фильтров сумматора.

3. Результаты экспериментов

3.1. MNIST

  • CNN достигает точности 99,4% при 435K умножений и 435K сложений.

  • Заменяя умножения в свертке на сложения, предлагаемая AdderNet достигает точности 99,4%, такой же показатель как у CNN, с 870K сложениями и почти без умножений.

  • Теоретическая задержка умножения в ЦП также больше, чем задержка сложения и вычитания.

  • Например, на модели VIA Nano 2000 задержка умножения и сложения с плавающей запятой составляет 4 и 2 соответственно. AdderNet с моделью LeNet-5 будет иметь задержку 1.7M, в то время как CNN будет иметь задержку 2.6M на том же CPU.

3.2. CIFAR

Результаты классификации на наборах данных CIFAR-10 и CIFAR-100Результаты классификации на наборах данных CIFAR-10 и CIFAR-100BNN: свертка XNORNet, использующая логической операции XNORBNN: свертка XNORNet, использующая логической операции XNOR
  • Двоичные нейронные сети (Binary neural networks - BNN): могут использовать операции XNOR для замены умножения, что мы также используем для сравнения.

  • Для модели VGG-small, AdderNets без умножения достигает почти таких же результатов (93,72% в CIFAR-10 и 72,64% в CIFAR-100) как и CNNs (93,80% в CIFAR-10 и 72,73% в CIFAR-100).

  • Хотя размер модели BNN намного меньше, чем у AdderNet и CNN, ее точность намного ниже (89,80% в CIFAR-10 и 65,41% в CIFAR-100).

  • Что касается ResNet-20, CNN достигают наивысшей точности (т.е. 92,25% в CIFAR-10 и 68,14% в CIFAR-100), но с большим числом умножений (41,17M).

  • Предлагаемые AdderNets достигают точности 91,84% в CIFAR-10 и 67,60% точности в CIFAR-100 без умножения, что сравнимо с CNN.

  • Напротив, BNN достигают точности только 84,87% и 54,14% в CIFAR-10 и CIFAR-100.

  • Результаты ResNet-32 также предполагают, что предлагаемые AdderNets могут достигать результатов аналогичных обычным CNN.

3.3. ImageNet

Классификация результатов на наборах данных ImageNetКлассификация результатов на наборах данных ImageNet
  • CNN достигает 69,8% точности top-1 и 89,1% точности top-5 в RESNET-18. Однако, при 1.8G умножениях.

  • AdderNet обеспечивает 66,8% точности top-1 и 87,4% точности top-5 в ResNet-18, что демонстрирует, что фильтры сумматора могут извлекать полезную информацию из изображений.

  • Несмотря на то, что BNN может достигать высокой степени ускорения и сжатия, он достигает только 51,2% точности top-1 и 73,2% точности top-5 в ResNet-18.

  • Аналогичные результаты для более глубокого ResNet-50.

3.4. Результаты визуализации

Визуализация признаков в AdderNets и CNN. Признаки CNN разных классов разделены по их углам.Визуализация признаков в AdderNets и CNN. Признаки CNN разных классов разделены по их углам.
  • LeNet++ обучался на наборе данных MNIST, который имеет шесть сверточных слоев и полносвязный слой для извлечения выраженных 3D признаков.

  • Количество нейронов в каждом сверточном слое составляет 32, 32, 64, 64, 128, 128 и 2 соответственно.

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

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

Визуализация фильтров в первом слое LeNet-5-BN на MNISTВизуализация фильтров в первом слое LeNet-5-BN на MNIST
  • Фильтры предлагаемых adderNets по-прежнему имеют некоторые схожие паттерны со сверточными фильтрами.

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

Гистограммы по весам с AdderNet (слева) и CNN (справа).Гистограммы по весам с AdderNet (слева) и CNN (справа).
  • Распределение весов с AdderNets близко к распределению Лапласа, тогда как распределение с CNN больше походит больше на распределение Гаусса. Фактически, априорным распределением l1-меры является распределение Лапласа.

3.5. Абляционное исследование

Кривая обучения AdderNets с использованием различных схем оптимизацииКривая обучения AdderNets с использованием различных схем оптимизации
  • AdderNets, использующие адаптивную скорость обучения (adaptive learning rate - ALR) и увеличенную скорость обучения (increased learning rate - ILR), достигают точности 97,99% и 97,72% со знаковым градиентом, что намного ниже, чем точность CNN (99,40%) .

  • Поэтому мы предлагаем использовать точный градиент для более точного обновления весов в AdderNets.

  • В результате AdderNet с ILR достигает точности 98,99% при использовании точного градиента. Используя адаптивную скорость обучения (ALR), AdderNet может достичь точности 99,40%, что демонстрирует эффективность предложенного метода.

Ссылка на статью

[2020 CVPR] [AdderNet]

AdderNet: Do We Really Need Multiplications in Deep Learning?

Классификация изображений

19891998: [LeNet]

20122014: [AlexNet & CaffeNet] [Dropout] [Maxout] [NIN] [ZFNet] [SPPNet] [Distillation]

2015: [VGGNet] [Highway] [PReLU-Net] [STN] [DeepImage] [GoogLeNet / Inception-v1] [BN-Inception / Inception-v2]

2016: [SqueezeNet] [Inception-v3] [ResNet] [Pre-Activation ResNet] [RiR] [Stochastic Depth] [WRN] [Trimps-Soushen]

2017: [Inception-v4] [Xception] [MobileNetV1] [Shake-Shake] [Cutout] [FractalNet] [PolyNet] [ResNeXt] [DenseNet] [PyramidNet] [DRN] [DPN] [Residual Attention Network] [IGCNet / IGCV1] [Deep Roots]

2018: [RoR] [DMRNet / DFN-MR] [MSDNet] [ShuffleNet V1] [SENet] [NASNet] [MobileNetV2] [CondenseNet] [IGCV2] [IGCV3] [FishNet] [SqueezeNext] [ENAS] [PNASNet] [ShuffleNet V2] [BAM] [CBAM] [MorphNet] [NetAdapt] [mixup] [DropBlock] [Group Norm (GN)]

2019: [ResNet-38] [AmoebaNet] [ESPNetv2] [MnasNet] [Single-Path NAS] [DARTS] [ProxylessNAS] [MobileNetV3] [FBNet] [ShakeDrop] [CutMix] [MixConv] [EfficientNet] [ABN] [SKNet] [CB Loss]

2020: [Random Erasing (RE)] [SAOL] [AdderNet]


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

Также приглашаем всех желающих посетить бесплатный демо-урок по теме: "Knowledge distillation: нейросети обучают нейросети".

- УЗНАТЬ ПОДРОБНЕЕ О КУРСЕ

- ЗАПИСАТЬСЯ НА БЕСПЛАТНЙ ДЕМО-УРОК

Подробнее..

Хватит уже называть всё подряд искусственным интеллектом!

18.04.2021 12:07:38 | Автор: admin
Бомбануло у одного из известнейших исследователей в области машинного обучения, Майкла И. Джордана из университета Беркли. Он один из самых влиятельных computer scientist в мире, участник и лидер самых важных сообществ в области ИИ. Джордан тот кто развил область обучения без учителя (unsupervised learning) и ввёл LDA в обиход. Это прям интересно, когда такая глыба неожиданно выступает с такой жесткой критикой.


image

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

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

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

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

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

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

Цель создания систем AI/ML не просто в обработке данных, но в создании новых цепочек, соединении новых покупателей и продавцов, в создании совершенно новых рынков

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

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

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

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

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

Книга Роман с Data Science. Как монетизировать большие данные

31.03.2021 12:04:48 | Автор: admin
image Привет, Хаброжители! Мы сдали в типографию новую книгу Романа Зыкова rzykov. Она предназначена для думающих читателей, которые хотят попробовать свои силы в области анализа данных и создавать сервисы на их основе. Она будет вам полезна, если вы менеджер, который хочет ставить задачи аналитике и управлять ею. Если вы инвестор, с ней вам будет легче понять потенциал стартапа. Те, кто пилит свой стартап, найдут здесь рекомендации, как выбрать подходящие технологии и набрать команду. А начинающим специалистам книга поможет расширить кругозор и начать применять практики, о которых они раньше не задумывались, и это выделит их среди профессионалов такой непростой и изменчивой области.


Отрывок из книги


ОТЧЕТ, ДАШБОРД И МЕТРИКИ


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

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

Первые два относительно просты и делаются через специальные системы, которые могут генерировать отчеты по запросу. Я стараюсь максимально оставить эту задачу на откуп пользователям. Почему? Потому, что тратить на это время высококвалифицированных сотрудников значит стрелять из пушки по воробьям. Кстати, этим могут заняться стажеры-аналитики отличный способ наработать опыт и понять бизнес-контекст. Как мотивировать пользователей стараться самостоятельно? Во-первых, они сэкономят время, которое обычно тратят на постановку задачи и ожидание результата. Во-вторых, получат возможность самим вносить правки и изменения а значит творить. По моему опыту, обычно этим занимаются очень перспективные сотрудники, которые не бояться освоить новый инструмент, чтобы делать свою работу лучше. Остальным придется пройти через стандартный цикл планирования задач: а это время (дни, а иногда недели) и очень четкая формулировка технического задания. И кстати, все генеральные директора (Ozon.ru, Wikimart.ru, Ostrovok), с которыми я работал, пользовались OLAP-кубами со своих компьютеров. С их помощью они всегда могли ответить на простые вопросы, а если не получалось обращались к аналитикам.

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

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

  • Ключевой показатель (key performance indicator, KPI) это индикатор, который показывает, насколько далеко мы находимся от цели, например отставание/опережение плана.
  • Метрика это цифра, которая характеризует процесс, обычно используется как справочная информация.

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

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

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

Часто велико искушение сделать огромную простыню цифр, закрывающую все аспекты бизнеса. И я понимаю владельцев/менеджеров компаний на старте проекта по построению внутренней аналитической системы всегда хочется большего. Я наблюдал это и в Ozon.ru, и в Ostrovok.ru. К слову, эти строки написаны по мотивам письма, которое я писал восемь лет назад операционному директору Ostrovok.ru, он хотел получить от аналитиков ту самую простыню. А я считаю такое цифровым микроменеджментом, в нем легко запутаться, самые важные показатели похоронены среди второстепенных. С первого взгляда будет сложно понять, где возникла проблема, а это основная функция дашбордов. Бороться с этим можно, например, через внедрение OKR цели и ключевые результаты (Objectives and Key Results) [13] или системы сбалансированных показателей (Balanced Scorecard). В этой книге я не буду подробно останавливаться на этих методиках, но рекомендую вам с ними ознакомиться. Также можно чаще пользоваться графическими элементами, например, добавив на график линию тренда (с помощью семиточечного скользящего среднего, чтобы убрать недельную сезонность), будет легче заметить восходящий или нисходящий тренд.

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

Никакой дашборд не заменит интерактивный анализ, для которого нужны соответствующая аналитическая система (SQL, OLAP, Google Data Studio, Tableau) и знание контекста. Мы никогда не сможем придумать ограниченный набор отчетов, которые будут отвечать на вопрос почему. Максимум, что мы можем сделать, наращивать (но не слишком) объем правильных метрик, исходя из инцидентов, за которыми будем следить.

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

Разработка дашбордов это одна из самых нелюбимых работ у тех, кто занимается анализом данных. Когда я обсуждал этот вопрос с Ди Джеем Патилом, отметив, что 50 % времени аналитического отдела занимает работа над отчетностью, он сказал, что у них в LinkedIn тоже периодически накапливался пул таких задач и приходилось их закрывать. И взгрустнул. Но дашборды очень нужны они помогают контролировать общее здоровье вашей системы вверенных вам серверов и сетей, если вы системный администратор, или всей компании, если вы генеральный директор.

КОНФЛИКТ ИССЛЕДОВАТЕЛЯ И БИЗНЕСА


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

Я много раз проводил собеседования и с новичками, и с опытными людьми, и знаю, что поиск интересной работы главный тренд на рынке труда. Действующие специалисты говорят: Надоело заниматься рутиной и всякой ерундой, хочу заниматься моделями машинного обучения. Новички: Хочу заниматься компьютерным зрением и NLP (машинное обучение в лингвистике). В целом людей объединяет любовь к машинному обучению, но для меня это звучит как любовь строителя к молотку, который пытается построить дом лишь с его помощью.

Эндрю н (Andrew Ng), которого я считаю одним из главных исследователей и популяризаторов машинного обучения, автор моего любимого курса на Coursera, в своей рассылке deeplearning.ai писал:
Существует огромная разница между построением модели в блокноте Python (Jupyter Notebook) на компьютере в лаборатории и созданием реально работающих систем, которые создают ценность. Кажется, что сфера AI переполнена людьми, но по факту она широко открыта для профессионалов, которые знают, что делают.

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

Ноа Лоранг, аналитик данных из компании Basecamp, в своем блоге пишет:
Маленькая грязная тайна продолжающегося бума data science в том, что то, что обычно подразумевается под этим на самом деле, не нужно бизнесу. Бизнесу нужна точная и полезная информация для принятия решений: как тратить время и ресурсы компании. Очень небольшое подмножество задач в бизнесе может быть лучшим образом решено машинным обучением; большинство же из них нуждается в хороших данных и понимании их смысла, что может быть достигнуто простыми методами.

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

ОБ АВТОРЕ

Роман Владимирович Зыков, 1981 года рождения, в 2004 году получил степень бакалавра, а затем магистра прикладной физики и математики в МФТИ (Московском физико-техническом институте).

В 2002 году начал свой карьерный путь в аналитике данных (Data Science) в качестве технического консультанта в компании StatSoft Russia, российского офиса одноименной американской компании-разработчика пакета статистического анализа данных STATISTICA.

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

В 2009 году консультировал ряд проектов инвестиционного фонда Fast Lane Ventures и гейм-индустрии.

В 2010 году возглавил отдел аналитики в интернет-ритейлере Wikimart.ru.

В конце 2012 года стал сооснователем и совладельцем маркетинговой платформы для интернет-магазинов RetailRocket.ru. Компания Retail Rocket занимает лидирующие позиции автоматизации маркетинга для интернет-магазинов. Среди клиентов: Сбер, Детский мир, Oysho, Decathlon. На текущий момент компания является безусловным лидером на рынке в России и успешно работает на рынках Чили, Голландии, Испании и других.

С 2007-го вел блог Аналитика на практике (KPIs.ru ныне не существует), где евангелизировал анализ данных в применении к бизнес-задачам в электронной коммерции. Выступал на отраслевых конференциях, таких как РИФ, iMetrics, Gec 2014 вместе с Аркадием Воложем (Yandex), бизнес-конференциях в Дублине и Лондоне, в посольстве США (AMC Center), университете Сбербанка. Печатался в технологическом прогнозе PwC, ToWave, Ведомостях, Секрете фирмы.

В 2016 году прочитал мини-лекцию в концертном зале MIT в Бостоне о процессах тестирования гипотез.

В 2020 году был номинирован на премию CDO Award.

Опыт работы аналитиком данных 18 лет.

Оформить предзаказ.
Подробнее..

Что такое Big data engineering, и как развиваться в этой сфере

14.04.2021 20:10:55 | Автор: admin

Как отдельная профессия 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 проекте. Пока рынок растёт настолько быстро, то возможность найти хорошую работу, есть даже у новичков.

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

Другие профессии и курсы
Подробнее..

Мультитул для управления Хранилищем Данных кейс Wheely dbt

30.03.2021 00:12:15 | Автор: admin

Уже более двух лет data build tool активно используется в компании Wheely для управления Хранилищем Данных. За это время накоплен немалый опыт, мы на тернистом пути проб и ошибок к совершенству в Analytics Engineering.

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

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

Структура превыше всего

Измерять сложность Хранилища Данных в количестве гигабайт сегодня - дурной тон

Налить кучу тяжело интерпретируемых данных без метаинформации (читай мусора) не составит большого труда. Гораздо сложнее из этих данных получить что-то осмысленное. То, на что с уверенностью могут опираться business stakeholders, принимая решения. То, что регулярно измеряется на предмет качества и актуальности. Наконец, то, что соответствует принципам Keep it simple (KISS) и Dont repeat yourself (DRY).

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

Схема слоев Хранилища ДанныхСхема слоев Хранилища Данных

Зеленым цветом слой источников данных sources. Это реплики структур и таблиц из исходных систем, которые поддерживаются ELT-сервисом. Данные синхронизируются 1:1 с источником, без каких-либо преобразований. Опциональный слой flatten позволяет вложенные иерархические структуры (JSON) превратить в плоские таблицы.

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

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

Кульминацией являются data marts или Витрины Данных, которые используются Data Scientists / Business Users / BI tools. Слой, в свою очередь, делится на:

  • dimensions: пользователи, компании, машины, водители, календарь

  • facts: поездки, транзакции, сеансы, продвижения, коммуникации

  • looker: материализованные представления и витрины, оптимизированные под чтение из BI-системы

Число 120 из заголовка публикации относится только к витринам данных:

Running with dbt=0.19.0Found 273 models, 493 tests, 6 snapshots, 4 analyses, 532 macros, 7 operations, 8 seed files, 81 sources, 0 exposures

На текущий момент в проекте:

  • 273 модели во всех перечисленных слоях

  • 493 теста на эти модели, включая not null, unique, foreign key, accepted values

  • 6 снапшотов для ведения истории SCD (slowly changing dimensions)

  • 532 макроса (большая часть из которых импортирована из сторонних модулей)

  • 7 operations включая vacuum + analyze

  • 81 источник данных

Помимо разбиения на логические слои, Хранилище можно нарезать по бизнес-областям. В случае необходимости есть возможность пересчитать или протестировать витрины, относящиеся к вертикалям Marketing / Supply / Growth / B2B. Например, в случае late arriving data или ручных корректировках маппингов/справочников.

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

dbt run -m +tag:marketing

Этот же принцип лежит в основе организации кодой базы. Все скрипты объединены в директории с общей логикой и понятными наименованиями. Сложно потеряться даже при огромном количестве моделей и витрин:

Иерархия проекта dbt
.|____staging| |____webhook| |____receipt_prod| |____core| |____wheely_prod| |____flights_prod| |____online_hours_prod| |____external| |____financial_service|____marts| |____looker| |____dim| |____snapshots| |____facts|____flatten| |____webhook| |____receipt_prod| |____wheely_prod| |____communication_prod|____audit|____sources|____aux| |____dq| | |____marts| | |____external|____intermediate

Оптимизация физической модели

Логическое разделение на слои и области - это замечательно. Но не менее важно и то, как эта логика ложится на конкретную СУБД. В случае Wheely это Amazon Redshift.

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

Цепочка зависимостей витрины поездок (journeys)Цепочка зависимостей витрины поездок (journeys)

На этапе обогащения данных важна скорость склейки таблиц (join performance), поэтому данные сегментированы и отсортированы в одинаковом ключе, начиная с sources. Это позволит использовать самый быстрый вид соединения - sort merge join:

Конфигурация для оптимального соединения sort merge join
{{config(materialized='table',unique_key='request_id',dist="request_id",sort="request_id")}}

Витрина же хранится отсортированной по самым популярным колонкам доступа: city, country, completed timestamp, service group. В случае правильного подбора колонок Interleaved key позволяет значительно оптимизировать I/O и ускорить отрисовку графиков в BI-системах.

Конфигурация для быстрого чтения витрины interleaved sortkey
{{config(materialized='table',unique_key='request_id',dist="request_id",sort_type='interleaved',sort=["completed_ts_loc", "city", "country", "service_group", "is_airport", "is_wheely_journey"])}}

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

staging:+materialized: view+schema: staging+tags: ["staging"]

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

В свою очередь большие таблицы фактов имеет смысл наполнять инкрементально. Особенно при условии того, что факт, случившийся однажды, больше не меняет своих характеристик. Таким образом мы процессим только изменения (delta) новые факты, произошедшие после последнего обновления витрины. Обратите внимание на условие where:

Пример инкрементального наполнения витрины
{{config(materialized='incremental',sort='metadata_timestamp',dist='fine_id',unique_key='id')}}with fines as (selectfine_id, city_id, amount, details, metadata_timestamp, created_ts_utc, updated_ts_utc, created_dt_utcfrom {{ ref('stg_fines') }}where true-- filter fines arrived since last processed time{% if is_incremental() -%}and metadata_timestamp > (select max(metadata_timestamp) from {{ this }}){%- endif %}),...

Кстати, о принципах MPP и о том, как выжать максимум из аналитических СУБД я рассказываю на курсах Data Engineer и Data Warehouse Analyst (скоро первый запуск!).

SQL + Jinja = Flexibility

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

Любой код, который вы используете с dbt проходит этапы compile & run. На этапе компиляции интерпретируются все шаблонизированные выражения и переменные. На этапе запуска код оборачивается в конструкцию CREATE в зависимости от выбранного типа материализации и фишек используемой СУБД: clustered by / distributed by / sorted by. Рассмотрим пример:

Model code:
{{config(materialized='table',dist="fine_id",sort="created_ts_utc")}}with details as (  select{{dbt_utils.star(from=ref('fine_details_flatten'),except=["fine_amount", "metadata_timestamp", "generated_number"])}}from {{ ref('fine_details_flatten') }}where fine_amount > 0)select * from details
Compiled code:
with details as (select  "id","fine_id","city_id","amount","description","created_ts_utc","updated_ts_utc","created_dt_utc"from "wheely"."dbt_test_akozyr"."fine_details_flatten"where fine_amount > 0)select * from details
Run code:
create table"wheely"."dbt_test_akozyr"."f_chauffeurs_fines"diststyle key distkey (fine_id)compound sortkey(created_ts_utc)as (with details as (select"id","fine_id","city_id","amount","description","created_ts_utc","updated_ts_utc","created_dt_utc"from "wheely"."dbt_test_akozyr"."fine_details_flatten"where fine_amount > 0)select * from details);

Ключевым моментом является тот факт, что пишете вы только лаконичный шаблонизированный код, а остальным занимается движок dbt. Написание boilerplate code сведено к минимуму. Фокус инженера или аналитика остается преимущественно на реализуемой логике.

Во-вторых, как происходит выстраивание цепочки связей и очередности создания витрин, продемонстрированные на картинках выше? Внимательный читатель уже заметил, что в рамках написания кода при ссылках на другие модели нет хардкода, но есть конструкция {{ ref('fine_details_flatten') }} ссылка на наименование другой модели. Она и позволяет распарсить весь проект и построить граф связей и зависимостей. Так что это тоже делается абсолютно прозрачным и органичным способом.

С помощью шаблонизации Jinja в проекте Wheely мы гибко управляем схемами данных и разделением сред dev / test / prod. В зависимости от метаданных подключения к СУБД будет выбрана схема и период исторических данных. Продакшн модели создаются в целевых схемах под технической учетной записью. Аналитики же ведут разработку каждый в своей личной песочнице, ограниченной объемом данных в 3-е последних суток. Это реализуется с помощью макроса:

Макрос управления схемами для подключений:
{% macro generate_schema_name_for_env(custom_schema_name, node) -%}{%- set default_schema = target.schema -%}{%- if target.name == 'prod' and custom_schema_name is not none -%}{{ custom_schema_name | trim }}{%- else -%}{{ default_schema }}{%- endif -%}{%- endmacro %}

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

Не повторяйся лучше подготовь макрос

Однотипный код, повторяющиеся обращения и действия, зачастую реализуемые по принципу copy-paste нередко являются причиной ошибок и багов. В Wheely мы придерживаемся принципа Do not repeat yourself и любой сколько-нибудь похожий код шаблонизируем в макрос с параметрами. Писать и поддерживать такой код становится сплошным удовольствием.

Простой пример с конвертацией валют:
-- currency conversion macro{% macro convert_currency(convert_column, currency_code_column) -%}( {{ convert_column }} * aed )::decimal(18,4) as {{ convert_column }}_aed, ( {{ convert_column }} * eur )::decimal(18,4) as {{ convert_column }}_eur, ( {{ convert_column }} * gbp )::decimal(18,4) as {{ convert_column }}_gbp, ( {{ convert_column }} * rub )::decimal(18,4) as {{ convert_column }}_rub, ( {{ convert_column }} * usd )::decimal(18,4) as {{ convert_column }}_usd{%- endmacro %}
Вызов макроса из модели:
select...-- price_details, r.currency, {{ convert_currency('price', 'currency') }}, {{ convert_currency('transfer_min_price', 'currency') }}, {{ convert_currency('discount', 'currency') }}, {{ convert_currency('insurance', 'currency') }}, {{ convert_currency('tips', 'currency') }}, {{ convert_currency('parking', 'currency') }}, {{ convert_currency('toll_road', 'currency') }}, {{ convert_currency('pickup_charge', 'currency') }}, {{ convert_currency('cancel_fee', 'currency') }}, {{ convert_currency('net_bookings', 'currency') }}, {{ convert_currency('gross_revenue', 'currency') }}, {{ convert_currency('service_charge', 'currency') }}...from {{ ref('requests_joined') }} r

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

Сравнить значения двух колонок
-- compare two columns{% macro dq_compare_columns(src_column, trg_column, is_numeric=false) -%}{%- if is_numeric == true -%}{%- set src_column = 'round(' + src_column + ', 2)' -%}{%- set trg_column = 'round(' + trg_column + ', 2)' -%}{%- endif -%}CASEWHEN {{ src_column }} = {{ trg_column }} THEN 'match'WHEN {{ src_column }} IS NULL AND {{ trg_column }} IS NULL THEN 'both null'WHEN {{ src_column }} IS NULL THEN 'missing in source'WHEN {{ trg_column }} IS NULL THEN 'missing in target'WHEN {{ src_column }} <> {{ trg_column }} THEN 'mismatch'ELSE 'unknown'END{%- endmacro %}

В макрос можно запросто записать даже создание UDF-функций:

Создать UDF
-- cast epoch as human-readable timestamp{% macro create_udf() -%}{% set sql %}CREATE OR REPLACE FUNCTION {{ target.schema }}.f_bitwise_to_delimited(bitwise_column BIGINT, bits_in_column INT)RETURNS VARCHAR(512)STABLEAS $$# Convert column to binary, strip "0b" prefix, pad out with zeroesif bitwise_column is not None:b = bin(bitwise_column)[2:].zfill(bits_in_column)[:bits_in_column+1]return belse:None$$ LANGUAGE plpythonu;CREATE OR REPLACE FUNCTION {{ target.schema }}.f_decode_access_flags(access_flags INT, deleted_at TIMESTAMP)RETURNS VARCHAR(128)STABLEAS $$SELECT nvl(DECODE($2, null, null, 'deleted'), DECODE(LEN(analytics.f_bitwise_to_delimited($1, 7))::INT, 7, null, 'unknown'), DECODE(analytics.f_bitwise_to_delimited($1, 7)::INT, 0, 'active', null), DECODE(SUBSTRING(analytics.f_bitwise_to_delimited($1, 7), 1, 1), 1, 'end_of_life', null), DECODE(SUBSTRING(analytics.f_bitwise_to_delimited($1, 7), 7, 1), 1, 'pending', null), DECODE(SUBSTRING(analytics.f_bitwise_to_delimited($1, 7), 6, 1), 1, 'rejected', null), DECODE(SUBSTRING(analytics.f_bitwise_to_delimited($1, 7), 5, 1), 1, 'blocked', null), DECODE(SUBSTRING(analytics.f_bitwise_to_delimited($1, 7), 4, 1), 1, 'expired_docs', null), DECODE(SUBSTRING(analytics.f_bitwise_to_delimited($1, 7), 3, 1), 1, 'partner_blocked', null), DECODE(SUBSTRING(analytics.f_bitwise_to_delimited($1, 7), 2, 1), 1, 'new_partner', null))$$ LANGUAGE SQL;{% endset %}{% set table = run_query(sql) %}{%- endmacro %}

Параметризовать можно и довольно сложные вещи, такие как работа с nested structures (иерархическими структурами) и выгрузка во внешние таблицы (external tables) в S3 в формате parquet. Эти примеры вполне достойны отдельных публикаций.

Не изобретай велосипед импортируй модули

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

С помощью модуля логирования и добавления 2 простых hooks на каждый запуск dbt у меня как на ладони появляется статистическая информация о времени, продолжительности, флагах и параметрах развертывания. Я наглядно вижу модели анти-лидеры по потребляемым ресурсам (первые кандидаты на рефакторинг):

models:+pre-hook: "{{ logging.log_model_start_event() }}"+post-hook: "{{ logging.log_model_end_event() }}"
Мониторинг развертывания dbt моделей на кластере RedshiftМониторинг развертывания dbt моделей на кластере Redshift

Измерение календаря собирается в одну строку, при этом набор колонок поражает:

{{ dbt_date.get_date_dimension('2012-01-01', '2025-12-31') }}
Измерение календарь, сгенерированное макросомИзмерение календарь, сгенерированное макросом

С помощью модуля dbt_external_tables я уже выстраиваю полноценный Lakehouse, обращаясь из Хранилища к данным, расположенным в файловом хранилище S3. К примеру, самые свежие курсы валют, получаемые через API Open Exchange Rates в формате JSON:

External data stored in S3 accessed vith Redshift Spectrum
- name: externalschema: spectrumtags: ["spectrum"]description: "External data stored in S3 accessed vith Redshift Spectrum"tables:- name: currencies_oxrdescription: "Currency Exchange Rates fetched from OXR API https://openexchangerates.org"freshness:error_after: {count: 15, period: hour}loaded_at_field: timestamp 'epoch' + "timestamp" * interval '1 second'external:location: "s3://data-analytics.wheely.com/dwh/currencies/"row_format: "serde 'org.openx.data.jsonserde.JsonSerDe'"columns:- name: timestampdata_type: bigint- name: basedata_type: varchar(3)- name: ratesdata_type: struct<aed:float8, eur:float8, gbp:float8, rub:float8, usd:float8>

Ну и, конечно, ночью по расписанию работает VACUUM + ANALYZE, ведь Redshift это форк PostgreSQL. Дефрагментация, сортировка данных в таблицах, сбор статистик. Иначе говоря поддержание кластера в тонусе, пока dba спит.

dbt run-operation redshift_maintenance --args '{include_schemas: ["staging", "flatten", "intermediate", "analytics", "meta", "snapshots", "ad_hoc"]}'
VACUUM + ANALYZEVACUUM + ANALYZE

Running in production: используем dbt Cloud в Wheely

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

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

Во-вторых, это гибкие настройки условий запуска джобов. Начиная от простых условий с выбором дня недели и времени, продолжая кастомными cron-выражениями, и заканчивая триггером запуска через webhook. Например, именно через вебхук мы связываем в цепочку завершение выгрузок для кросс-сверки и начало расчета соответствующих витрин в Хранилище (kicked off from Airflow):

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

Сам dbt является проектом с открытым исходным кодом, и использование продукта dbt Cloud представляется очень удобным, но не обязательным. В качестве альтернативных способов можно выбрать любой другой оркестратор: Airflow, Prefect, Dagster, и даже просто cron. В своем проекте Сквозная Аналитика я организую оркестрацию при помощи Github Actions. Выходит очень занятно.

Вместо заключения

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

Сегодня бизнес и команда активно растут. Доступен ряд интересных позиций:

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

Также время от времени я провожу вебинары и выступления, на которых подробнее рассказываю о своей работе и проектах. Следить за моими публикациями можно в телеграм-канале Technology Enthusiast https://t.me/enthusiastech

Пишите, задавайте вопросы и, конечно, пробуйте dbt в своих проектах!

Подробнее..

Not so big data как работать с небольшими, но очень ценными данными

06.04.2021 16:12:32 | Автор: admin

Что делать с данными в 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 лет.

Подробнее..

Как мы выбирали Data Catalog, но в итоге оставили все как есть

09.04.2021 12:18:12 | Автор: admin

Меня зовут Никита Василюк, я инженер по работе с данными в департаменте данных и аналитики Lamoda. Я и моя команда занимаемся всем, что связано с распределенной системой хранения и обработки данных.


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



В идеальном мире Data Catalog это инструмент, в котором можно найти краткую сводку по данным в хранилище, увидеть их структуру, проследить lineage (путь данных от системы-источника до целевой таблицы), посмотреть profiling (краткую статистику по полям таблицы) и историю проверок качества данных, увидеть владельцев данных и запросить доступ. Сейчас у нас есть подобие этого каталога: все таблицы нашего хранилища описываются вручную аналитиками в Confluence.


Мы решили поставить небольшой эксперимент и представить, что было бы, если роль Data Catalog исполнял не Confluence, а другая система.


Требования к системе


Мы определили несколько важных требований к потенциальной системе, в которой бы начали строить Data Catalog:


  • Автоматический сбор данных из разных СУБД. Это позволит нам избавить аналитиков от ручного обновления описаний таблиц.
  • Отображение структуры датасета с понятными описаниями и полнотекстовым поиском по этой информации.
  • Web UI с поиском. Это очень важное требование, поскольку в первую очередь Data Catalog задумывается как инструмент для поиска метаданных.
  • Визуализация data lineage от системы-источника до отчета в BI-системе.
  • Отображение data owner. С помощью этого можно понять, к какому человеку обратиться по всем вопросам, связанных с данными.

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


  • SSO SAML авторизация;
  • визуализация Data Profiling;
  • визуализация Data Quality;
  • добавление кастомной информации для отображения;
  • трекинг изменения датасетов.

Мы решили рассмотреть три популярных open source проекта: Amundsen, LinkedIn DataHub и Marquez.


Amundsen



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


  • neo4j хранилище метаданных (также может использоваться Apache Atlas);
  • elasticsearch поисковый движок;
  • amundsensearch сервис для поиска по данным в Elasticsearch;
  • amundsenfrontendlibrary Web UI (написан на Flask);
  • amundsenmetadatalibrary отвечает за работу с метаданными в Neo4j или Atlas;
  • amundsendatabuilder библиотека для извлечения данных из различных СУБД.


Принцип работы довольно простой. ETL-процесс сбора метаданных состоит из извлечения записей из источника при помощи выполнения SQL-запросов, преобразования записей и их загрузки в хранилище метаданных. Extractor выполняет запрос к хранилищу метаданных и преобразует их в набор вершин и связей между ними. Промежуточные результаты сохраняются в локальную директорию. Transformer преобразует загруженные данные в нужную структуру. Loader подхватывает промежуточные данные и складывает их либо во временный слой, либо сразу в финальное хранилище. Publisher подхватывает промежуточные данные и отправляет в хранилище.


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


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


Плюсы:


  • автоматический сбор данных из разных СУБД;
  • API для добавления или редактирования данных в автоматическом режиме за счет обращения напрямую к Metastore/information_schema;
  • Web UI с полнотекстовым поиском;
  • поиск по базам, таблицам, полям и тэгам;
  • добавление кастомной информации для отображения (programmatic description)
  • визуализация data profiling (например, количество записей, дата последнего обновления, исторические значения);
  • визуализация data quality (какие проверки навешаны на датасет, история результатов проверок);
  • отображение data owner.

Минусы:


  • нет трекинга изменения датасетов (хранит только актуальное состояние и работает как справочник);
  • нет data lineage (источник можно идентифицировать только в блоке с кастомной информацией);
  • не нашли SSO-аутентификацию, доступна только OIDC;
  • полнотекстовой поиск работает только для тегов, таблиц, баз и колонок (нет возможности искать по описаниям колонок).

LinkedIn DataHub



Как можно понять из названия, это платформа поиска и обнаружения метаданных от LinkedIn. Из коробки она состоит из целого зоопарка сервисов:


  • kafka-broker брокер Kafka;
  • zookeeper координатор для Kafka;
  • kafka-rest-proxy RESTful интерфейс для Kafka;
  • kafka-topics-ui Web UI для топиков Kafka;
  • schema-registry Kafka Schema Registry;
  • schema-registry-ui Kafka Schema Registry UI;
  • elasticsearch поисковый движок;
  • kibana дашборд для Elasticsearch;
  • neo4j графовая база данных;
  • datahub-gms Generalized Metadata Store;
  • datahub-frontend Web UI;
  • datahub-mae-consumer сервис для обработки сообщений Metadata Audit Events;
  • datahub-mce-consumer сервис для обработки сообщений Metadata Change Events;
  • mysql база данных для хранения метаданных.


Основная сущность DataHub dataset. Он может включать в себя таблицы (RDBMS и не только), топики в Kafka, директории на HDFS или другие сущности, имеющие схему.


Датасет имеет:


  • схему (включая типы и комментарии к полям),
  • статус (active или deprecated),
  • владельцев,
  • relationships (он же lineage),
  • docs с указанием ссылок на документацию.

Метаданные обновляются через отправку сообщений Metadata Change Event (MCE) в Kafka. MCE это сообщение в формате AVRO с указанием пунктов, которые необходимо обновить. Гибкость обновления данных в системе достигается за счет возможности в одном сообщении обновить владельцев датасета, в другом обновить схему, в третьем upstream datasets.


Отличительная особенность DataHub приятный веб-интерфейс. Он нам сразу понравился и запал в душу. У него все хорошо в плане поиска, обновлений типов таблиц и типов датасетов, информация о схеме датасета выглядит очень приятно. Можно добавлять владельцев датасетов, можно зайти в профиль пользователя и посмотреть, какими датасетами он владеет. У DataHub есть lineage, для каждого датасета можно наблюдать его взаимосвязи с другими объектами. Также есть возможность к каждому датасету прикладывать ссылки на документацию или исходный код.


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


Плюсы:


  • удобный UI с поиском;
  • автоматический сбор данных из разных СУБД (большая гибкость, поддерживает сбор данных не только из СУБД, работает для всего, у чего есть схема);
  • добавление или редактирование данных в автоматическом режиме через отправку AVRO-сообщений в Kafka;
  • добавление ссылок на документацию к датасету;
  • визуализация data lineage от источника до отчета в BI-системе (однако нет возможности отобразить всю цепочку сразу, отображается только upstream и downstream датасеты на один уровень вверх и вниз);
  • отображение data owner;
  • есть возможность сделать связку с интранетом компании.

Минусы:


  • огромное количество внутренних сервисов, за каждым из которых нужно следить;
  • отсутствует трекинг изменения датасетов;
  • data lineage показывает только upstream и downstream датасеты;
  • отсутствие визуализации data profiling;
  • отсутствие визуализации data quality (в roadmap на Q2 2021 есть пункт про отображение визуализаций и интеграцию с такими системами, как Great Expectations и deequ);
  • нет возможности добавить кастомную информацию для датасета;
  • нет возможности прослеживать изменения в датасетах;
  • поиск работает только для датасетов и пользователей.

Marquez



Третий инструмент Marquez. Он состоит из основного приложения, базы данных и веб-интерфейса для отображения датасетов, джобов и связей между ними.


Метаданные в Marquez отправляются с помощью REST API. Еще он поддерживает создание следующих типов объектов:


  • data source системы-источники;
  • dataset таблицы, из которых читаются и в которые пишутся данные, обрабатываемые джобами;
  • job абстракция над процессом трансформации данных, которая принимает таблицы на вход и записывают в них данные;
  • job run запуск конкретной джобы.


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


Его самый главный минус слишком минималистичный интерфейс, он плохо справляется с отображением lineage, в котором есть много таблиц и ветвлений. Нет возможности отображать владельца данных, нельзя в режиме справочника посмотреть, какие таблицы у нас есть. Нет возможности отображать информацию по качеству данных, по профилированию, невозможно добавить кастомную информацию. То есть Marquez максимально простой инструмент, который может подойти для каких-то простых use-caseов, но не подойдет для чего-то масштабного.


Плюсы:


  • быстрый и минималистичный UI;
  • поддержка airflow из коробки;
  • простая, но гибкая модель данных, позволяет с минимальным набором абстракций описывать данные;
  • понятный и простой API для добавления или редактирования данных;
  • Web UI с поиском;
  • есть lineage;
  • минимум компонентов.

Минусы:


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

Бонус: загоняем lineage из DWH в Neo4j


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



В первом подходе мы решили действовать в лоб: прошлись по всем таблицам в цепочке и соединили их промежуточными вершинами-джобами aka SQL-запросами, которые заполняют таблицу данными. Таким образом, получилось большое дерево связей, которое невозможно внятно читать (зато его забавно рассматривать и двигать).


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



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



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


Что мы выбрали в итоге и почему не стали внедрять


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


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


Мы отслеживаем развитие рассмотренных в статье сервисов, изучаем платные варианты Data Catalog и их возможности. Если у вас есть успешный (или не очень) опыт внедрения подобных систем, то поделитесь им в комментариях.

Подробнее..

Как New York Times подбирает самые кликбейтные заголовки

16.04.2021 22:16:20 | Автор: admin
Лавры Buzzfeed, специалистов по треш-заголовкам, не дают покоя и более крутым спокойным медиа. Один из техноблогеров заметил, что одно из самых авторитетных в США изданий New York Times экспериментирует с заголовками статей. Он вытащил все виды заголовков и данные по их тестированию через открытые API этого СМИ и пришёл к интересным выводам. А я постарался собрать их в короткий дайджест.

Автор этого пересказа куратор новой магистратуры ВШЭ по управлению продуктом и маркетингом на основе данных.

image

  • Всех посетителей сайта в момент визита на сайт разбивают на группы (иногда до 7) и дают им разные заголовки статей с одним и тем же содержимым. Затем смотрят, на что реагируют лучше и дальше уже на всю аудиторию выкатывают самый эффективный заголовок.
  • Оказалось, статьи попадают в самые читаемые после такого A/B тестирования с вероятностью на 80% больше, чем без тестирования заголовков.
  • Где-то это подбор правильного слова, но чаще сравнение разных по эмоциональной зарядке заголовков
  • 62% аудитории NYT это платные подписки и им нет смысла гнаться за кликбейтом. Однако всё равно чаще всего побеждают и выбираются редакцией существенно более драматические заголовки, преувеличивающие драматизм статьи.
  • В среднем проверка эффекта идёт за 6 часов жизни статьи на сайте.
  • Часто NYT начинает подтюнивать уже вышедшие в топ статьи, чтобы сделать их ещё убойнее. Самый яркий пример как заголовок про Меган Маркл из Её жизнь не была сказкой, она потеряла свободу и идентичность превратился в Жизнь в королевской семье почти довела меня до самоубийства.

image

Затем он делал ещё один рисёч, где изучал что выводится на главный экран. Главный вывод в нём: 90% статей живёт на главной странице 9 часов, 10% убивают меньше чем за час

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

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

Категории

Последние комментарии

© 2006-2021, personeltest.ru