Bi

Однажды мы размышляли о рейтинге знаков зодиака среди Великих людей. Задачу выполнили и представляю результаты на ваш суд.
Со скорбью замечу, что Весы (ЭТО Я!) на последнем месте Хотя что-то по данным мне кажется, что есть аномалии. Как-то подозрительно мало Весов!



ЧАСТЬ 1. Парсинг и получение исходных данных:
Wikipedia List of lists of lists
на выходе нужна база с ФИО + дата рождения + (если есть любые другие признаки например м/ж, страна и тд)
есть API

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

В других случаях парсили успешно вот так
Результат: файл BD wiki.zip

ЧАСТЬ 2. О препроцессинге (выполнил Станислав Костенков контакты ниже).
Многие сталкиваются со сложностью обработки входных данных. Так в данной задаче нужно было вытащить из более 42 тысяч статей данные о рождении и по возможности определить страну рождения. С одной стороны, это простая алгоритмическая задача, с другой стороны, средства Excel & BI систем не позволяют это выполнить в лоб.
В такой момент на помощь приходят языки программирования (Python, R), запуск которых предусмотрен в большинстве BI систем. Стоит отметить, что, например, в Power BI существует лимит в 30 минут на выполнение скрипта (программы) на языке Python. Поэтому многие тяжелые обработки делают до запуска BI систем, например, в озере данных.

Как решалась задача.
Первое, что сделал после загрузки и проверки на некорректные значения, было превратить каждую статью в список слов.
В этой задаче, мне повезло с языком, английским. Этот язык характеризует жесткая форма построения предложения, что значительно облегчило поиск даты рождения. Ключевое слово здесь born, затем смотрится и анализируется что находится после него.
С другой стороны, все статьи были взяты из одного источника, что тоже облегчило задачу. Все статьи имели примерно одинаковую структуру и обороты.
Далее, все года имели длину в 4 символа, все даты имели длину 1-2 символа, месяцы имели текстовое представление. Было всего 3-4 возможных вариации написания даты рождения, что решалось простой логикой. Также можно было бы анализировать через регулярные выражения.
Настоящий код неоптимизирован (такой задачи не ставилось, может быть есть огрехи в наименованиях переменных).
По предсказанию страны, мне повезло найти таблицу соответствия стран и национальностей. Обычно в статьях описывается не страна, а принадлежность к ней. Например, Russia russian. Поэтому производился поиск вхождений национальностей, но в виду, что в одной статье, могло быть более 5 разных национальностей, то я сделал гипотезучто нужное слово будет самым ближайшим из всех возможных к ключевому слову burn. Таким образом, критерий был минимальное индексное расстояние между нужными словами в статье. Потом одной строкой делалось переименование из национальности в страну.

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

Немного слов о полезности препроцессинга при очистке данных.
Есть банальные случаи, когда мы можем точно предположить, что должно быть на месте пропусков. Но есть случаи, например, есть пропуски по гендерному признаку покупателя магазина и есть данные о его покупках. Стандартных приемов по решению этой задачи не существует в системах BI, но в тоже время, на уровне препроцессинга можно создать легкую модель и посмотреть различные варианты заполнения пропусков. Существуют варианты заполнения, основанные на простых алгоритмах машинного обучения. И это стоит использовать. Это не трудно.
Исходный код (Python) доступен по ссылке
Результат: файл out_data_fin.xls
Станислав Костенков / Компания Си-Би-Эс Консалтинг (Ижевск, Россия) staskostenkov@gmail.com

ЧАСТЬ 2. Приложение Qlik Sense.
Дальше было сделано классическое приложение, где и выявились некие аномалии с датасетом:
имело смысл выбирать только декады с 1920-1980;
в разных странах были разные лидеры по знакам гороскопа;
топ знаков: Рак, Овен, Близнецы, Телец, Козерог;

Все данные (дата-сет, исходные данные, полученное приложение Qlik Sense для анализа данных) лежат по ссылке

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

Со скорбью замечу, что Весы (ЭТО Я!) на последнем месте Хотя что-то по данным мне кажется, что есть аномалии. Как-то подозрительно мало Весов!

Часть 1. Парсинг и получение исходных данных

Wikipedia List of lists of lists
на выходе нужна база с ФИО + дата рождения + (если есть любые другие признаки например м/ж, страна и т.д.) есть API.

Данный сайт получилось поскрапить (харвестинг / получение / экстракт (извлечение) / сбор данных полученных с web-ресурсов) сайт при помощи Python библиотеки Scrapy.

Подробная инструкция
сначала получаются ссылки (листы с людьми с Википедии, а потом уже данные).

В других случаях парсили успешно вот так.

Результат: файл BD wiki.zip

Часть 2. О препроцессинге (выполнил Станислав Костенков контакты ниже)

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

В такой момент на помощь приходят языки программирования (Python, R), запуск которых предусмотрен в большинстве BI систем. Стоит отметить, что, например, в Power BI существует лимит в 30 минут на выполнение скрипта (программы) на языке Python. Поэтому многие тяжелые обработки делают до запуска BI систем, например, в озере данных.

Как решалась задача

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

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

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

Далее, все года имели длину в 4 символа, все даты имели длину 1-2 символа, месяцы имели текстовое представление. Было всего 3-4 возможных вариации написания даты рождения, что решалось простой логикой. Также можно было бы анализировать через регулярные выражения.
Настоящий код неоптимизирован (такой задачи не ставилось, может быть есть огрехи в наименованиях переменных).

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

Что не делалось

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

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

Немного слов о полезности препроцессинга при очистке данных

Есть банальные случаи, когда мы можем точно предположить, что должно быть на месте пропусков. Но есть случаи, например, есть пропуски по гендерному признаку покупателя магазина и есть данные о его покупках. Стандартных приемов по решению этой задачи не существует в системах BI, но в тоже время, на уровне препроцессинга можно создать легкую модель и посмотреть различные варианты заполнения пропусков. Существуют варианты заполнения, основанные на простых алгоритмах машинного обучения. И это стоит использовать. Это не трудно.
Исходный код (Python) доступен по ссылке
Результат: файл out_data_fin.xls

Станислав Костенков / Компания Си-Би-Эс Консалтинг (Ижевск, Россия) staskostenkov@gmail.com

Часть 3. Приложение Qlik Sense

Дальше было сделано классическое приложение, где и выявились некие аномалии с датасетом:

• имело смысл выбирать только декады с 1920-1980;
• в разных странах были разные лидеры по знакам гороскопа;
• топ знаков: Рак, Овен, Близнецы, Телец, Козерог.

Все данные (дата-сет, исходные данные, полученное приложение Qlik Sense для анализа данных) лежат по ссылке.

Привет, Хабр! Меня зовут Иван Вахмянин, и сегодня я хочу рассказать о том, что находится под капотом у современной BI-системы, от чего зависит ее производительность (и как можно её ненароком убить), и какие технические оптимизации позволяют технологии In-Memory OLAP выигрывать по скорости у других подходов.




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

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

Когда мы только начинали работать в сфере BI 5 лет назад, в основу продукта Visiology легла open-source библиотека Pentaho Mondrian. Но достаточно быстро мы столкнулись с проблемами по части производительности и начали самостоятельно разрабатывать In-Memory OLAP движок под названием ViQube (об этом можно почитать в другой нашей статье Как разработать BI-платформу наш трудный, но интересный опыт). Собственно, в процессе этой разработки мы и накопили опыт, которым сейчас хотим поделиться.

Как работает OLAP

На первый взгляд, все BI-платформы выглядят одинаково: у вас есть источники информации, у вас есть инструменты загрузки, анализа и визуализации данных, а на выходе пользователь получает разнообразные отчеты от печатных форм до дашбордов, в том числе на мобильных, на видеостенах, на любых устройствах. В своей основе все BI-инструменты используют модель данных на основе OLAP (On-Line Analytical Processing, многомерное представление данных), но техническая реализация OLAP движка (который непосредственно занимается вычислениями) может быть реализован по-разному, и от этого очень сильно зависит производительность и масштабируемость системы.



MOLAP

Технология OLAP возникла ещё в 80-х годах. В то время процессоры были намного медленнее, да и память была в дефиците, поэтому чтобы аналитик мог реально работать с данными в онлайн-режиме, придумали такую вещь как MOLAP (Multidimensional OLAP). Идея подхода в том, что для всего многомерного куба после загрузки данных производится предрасчет: на узлах иерархий предварительно рассчитываются агрегации, чтобы под любой более или менее типовой запрос пользователя можно было получить результат запроса без необходимости пересчитывать все строки. Да, при любом изменении данных нужно долго пересчитывать куб, а объем рассчитанного куба может быть в разы больше исходного датасета, но в то время других вариантов не было. MOLAP до сих пор существует и используется, например, в SQL Server Analysis Services, но на практике его используют все реже и реже.

ROLAP

Позже появилась реляционный OLAP, или ROLAP. Отличие от MOLAP заключается в том, что не происходит никакого предварительного расчёта агрегаций, а вычисления происходят на СУБД из бэкэнда BI-платформы. В этом случае пользователь работает с удобными инструментами, например, с конструктором дашбордов, а под капотом ROLAP-движок преобразует его запросы на лету в SQL, и они просто выполняются на какой-то СУБД.



Подобный подход характерен, например, для таких open-source систем, как Pentaho или Metabase или проприетарного SAP Business Objects, Oracle OBIEE.

У ROLAP есть целый ряд недостатков. Во-первых, если, не использовать на бэкенде специальные аналитические СУБД, такие как ClickHouse или Vertica, все будет работать ооочень медленно (дальше будет понятно, почему). Во-вторых, даже при использовании аналитической СУБД, при работе с ROLAP очень неэффективно используется кэш, потому что СУБД и BI-платформа работают отдельно друг от друга. В-третьих, поскольку не все аналитические задачи можно завернуть в SQL-запрос, ограничивается аналитическая функциональность. Но зато, на сегодняшний день ROLAP это единственный способ работы с реально большими объемами данных, которые не помещаются в память.

In-Memory OLAP

Если речь идет о работе с данными объемом до терабайта, как правило, используется схема In-Memory. Данные постоянно находятся в памяти, и за расчеты отвечает специальный движок. В системах Qlik это QIX, Power BI использует SQL Server Tabular Engine, который раньше был продуктом xVelocity, но Microsoft купил эту компанию, и теперь движок является частью MS SQL Server. У нас в Visiology движок In-Memory OLAP называется ViQube.

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



При этом у подхода In-Memory есть и свои недостатки. И главный из них это предел емкости памяти. Если объем данных измеряется в терабайтах, вам нужно либо строить дорогой кластер, либо склоняться к ROLAP. Кроме этого, при таком подходе не всегда удается минимизировать задержку отображения обновлений, потому что для этого данные приходится перегружать из источника в память.

Гибридный OLAP

Основной схемой работы для большинства промышленных BI становится гибридная схема с одновременным использованием и In-Memory OLAP, и реляционного OLAP-движка. Горячие данные хранятся в In-Memory, холодные данные, которые не влезли в заданный объем, в СУБД. Такое решение в QlikView, например, называется Direct Discovery, в Power BI Direct Query. В Visiology тоже поддерживаются интеграции с несколькими СУБД, в том числе с ClickHouse.



Кстати, выбор СУБД для гибридного режима также критически важен. Если мы будем работать с PostgreSQL, в котором лежит 5 терабайт данных, аналитические запросы будут исполняться крайне медленно. И если у вас не SAP HANA, придется вручную распределять данные на холодные и горячие. Как следствие, не все аналитические функции будут доступны на полном объёме данных. Но если памяти не хватает, увы, с таким положением дел приходится мириться.

Откуда растут плюсы In-memory OLAP?

Для скорости работы In-Memory OLAP есть как очевидные, так и скрытые причины. Тот факт, что работа движка происходит в памяти, а она намного быстрее, чем жесткий диск (спасибо, кэп) это только 1/10 правды. Но давайте подумаем, как работают реляционные СУБД, например, тот же PostgreSQL. Ведь он в какой-то мере тоже является In-Memory. И вообще, любая современная СУБД активно использует как блочный кэш в памяти, так и внутренний.



Когда обычной дисковой СУБД, такой как PostgreSQL, нужно считать данные с жёсткого диска, она обращается к накопителю и считывает какую-то страницу. Эта страница помещается в блочный кэш (в Linux он располагается в свободном пространстве памяти). Допустим, у нас есть 128 гигабайт памяти, и 20 из них мы занимаем софтом. Всё остальное может использоваться под блочный кэш. И если СУБД нужно будет считать с этой страницы ещё что-нибудь, она возьмет эту информацию из памяти. И от того, насколько эффективно используется кэш, зависит производительность. Если для анализа используется, скажем, 30-40 гигабайт данных, мы можем расширить емкость оперативной памяти на сервере и уже после первого чтения СУБД все данные окажутся In-Memory, а обращения к диску на чтения будут происходить лишь эпизодически.



Кроме этого, у умных СУБД, в том числе у Postgres, имеется механизм cache-aware управления. Они могут выбирать, что складывать в кэш, а что нет, какие данные надо заново прочитать с диска.


Источник: www.enterprisedb.com/blog/autoprewarm-new-functionality-pgprewarm

На графике выше влияние прогрева кэша на производительность PostgreSQL. Жёлтым показана производительность в зависимости от времени, и наглядно видно, что по мере работы пользователей СУБД считывает данные, постепенно раскладывает всё в In-Memory и достигает предела своей производительности. Если же использовать prewarm и дать Postgres команду поднять все данные в память сразу, максимальная производительность достигается сразу.

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


Источник: www.tpc.org/information

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

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

In-Memory OLAP: конкретные примеры оптимизации для BI

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

1. Колоночное хранение данных

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



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


Источник: arstechnica.com/gadgets/2002/07/caching/2

2. Сжатие

В этой оптимизации есть свои особенности. Для дисковых СУБД это обязательная оптимизация. Здесь мы выигрываем за счет того, что реже ходим в медленное хранилище, но также проигрываем, потому что данные надо распаковать, а это вычислительно ёмкая операция. Для дисковых СУБД получается очень выгодно, для In-Memory все не так очевидно, потому что читать из памяти обычно быстрее, чем заниматься распаковкой.


Источник: www.percona.com/blog/2016/03/09/evaluating-database-compression-methods

Самый быстрый из алгоритмов сжатия по скорости распаковки LZ4. Он в среднем уменьшает размер всего в 2 раза, но зато очень быстро распаковывает, со скоростью порядка 500 мегабайт в секунду на ядро процессора. В бенчмарке на графике LZ4 вообще показал результат 3 гигабайта данных в секунду. Такая скорость дает очень хороший выигрыш для дисковых СУБД, скорость чтения для которых те же 500 мегабайт в секунду. Но для памяти скорость передачи данных составляет десятки гигабайт в секунду, получить преимущество за счёт LZ4 оказывается сложно.

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


Источник: Guassian and speckle noise removal from ultrasound images using bivariate shrinkage by dual tree complex wavelet transform (Professor G R Sinha, 2015)

Для подобных данных есть ещё один алгоритм, который называется Run-length encoding. Он работает очень просто: строки типа ААААВВВВВСС он сжимает в виде 4A5B2C. Это прекрасный подход для данных с низкой кардинальностью, он помогает экономить память и оптимальнее использовать кэш процессора.

3. Векторные инструкции

Чтобы сложить 2 числа, мы кладём в один регистр процессора одно число, а в другой регистр другое. Для ускорения этого процесса существуют векторные регистры и векторные операции (SIMD Single Instruction Multiple Data). Они позволяют за одну операцию сложить сразу N чисел. Это уже очень зрелая технология, которая появилась в процессорах еще в 1993 году. Она поддерживалась еще в Pentium MMX (166 МГц у меня такой был, до сих пор помню, как на него термопасту намазывал).


Источник: www.codetd.com/en/article/9633503

В Pentium MMX векторных регистров было 8, и они были рассчитаны только на целочисленную арифметику. На текущий момент практически во всех процессорах есть 128-битные регистры SSE и наборы инструкций. Регистры AVX уже 256-битные, а в серверах есть даже AVX 512. Они работают с числами с плавающей запятой, и их можно использовать для оптимизации аналитической нагрузки.


Источник: technews.tw/2020/07/16/linus-torvalds-avx-512-critique

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

Вот пример, как для расчёта скалярного произведения используется AVX-инструкции 256-битных регистров.



На нашей практике использование именно AVX даёт от 1 до 10% прирост производительности, в зависимости от задач. Когда вы используете современную BI-систему, в зависимости от конкретного процессора, система будет применять разный код. Производительность от этого увеличивается, но не драматически, а в лишь в небольших пределах.

4. Поздняя материализация

Материализация это процесс формирования результата, ответа на запрос. Например, простой SQL-запрос SELECT C1, С2, D1, D2 из 2 таблиц, получит 2 поля из одной и 2 поля из другой таблицы. Далее мы соединяем их по ключу С1=D1.



В случае ранней материализации мы получаем 4 колонки и работаем с колоночной базой. То есть мы сначала берём С1 и С2, соединяем их в таблицу. Потом делаем то же самое с D1, D2 и после этого выполняем Join, то есть формируем строки из этих 2 таблиц, для которых истинно условие С1=D1.

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

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

Конечно, такая оптимизация не сработает на любой нагрузке. Исследования Vertica, например, показывают, как многопрофильная СУБД позволяет выбирать различные стратегии материализации, в зависимости от задач. Но именно для BI характерна нагрузка, связанная с поздней материализацией, поэтому ее использование предпочтительно.

5. Эвристические оптимизации

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

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

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

6. Сортировка по календарю

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

7. Разделяемый кэш

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

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

8. Обратный индекс

Многие BI-системы выстраивают обратный индекс для строковых полей. Он позволяет ускорить поиск с операторами по строкам. И хотя BI-системы и OLAP движок In-Memory это не замена полнотекстовому поиску, подобные оптимизации встречаются достаточно часто.

Каков эффект?

Все перечисленные меры помогают сделать BI-систему, основанную на In-Memory OLAP, более устойчивой и производительной, не прибегая к гибридным схемам работы с подключением реляционных БД. Рост производительности сильно зависит от используемых задач, но в процессе работы над ViQube мы убедились в том, что оптимизации лучше всего закладывать на этапе исходного кода и изначально проектировать систему с учетом особенностей аналитических запросов.

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

5 способов убить производительность In-Memory OLAP

BI-система, работающая на базе In-Memory OLAP, уже по определению имеет высокую производительность однако она не будет неубиваемой! Ниже список из 5 вредных советов по In-Memory, выстраданных на своей шкуре в процессе разработки движка ViQube и его использования в реальных проектах.

1. Сложные вложенные выражения

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

Очень часто в своей практике я сталкивался с тем, что аналитик пишет какое-то выражение на Qlik Expressions или на DAX в Power BI, которое хорошо работает, когда в базе 10 тысяч строк. Но по мере роста масштабов производительность начинает деградировать невероятными темпами.

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

2. Вложенные запросы

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

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

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

3. Частое обновление данных

Частое обновление данных не так страшно, если вы используете специальные инструменты для работы в режиме Real-time. Для чего? Почему BI-платформа In-Memory OLAP не очень любят Real-time и для Real-time предлагают, по сути, отдельные инструменты. В Power BI, например, Streaming Dataset. Зачем это сделано? Почему просто не дописывать и не считать заново?

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

Частая инвалидация ведёт к деградации производительности BI-системы, и это особенно заметно, если одновременно BI-система обрабатывает тысячи запросов. Как правило, большинство пользователей работают с готовыми дашбордами, для которых кэш основной источник оптимизации. Когда мы проводили нагрузочное тестирование для профиля пользователя, который просто работает с дашбордом, 90-95% запросов в принципе не доходили до движка и обслуживались из кэша. Именно поэтому частая инвалидация ведет к падению производительности в 10 и более раз.

4. Маленький запас свободной памяти

Иногда кажется, что для работы системы неважно, сколько имеется свободной оперативной памяти, лишь бы хватало общей емкости. Но на самом деле свободная память используется для буферного кэша. Можно сказать, что для In-Memory движков это не так критично, потому что они не так часто работают с жёстким диском. Но в те моменты, когда он поднимает данные, использует snapshot, сохраняет или загружает что-то, наличие буферного кэша оказывается очень даже важным фактором. К тому же, помимо In-Memory движка в любой BI есть и другие части системы, например, компоненты ОС. И если память кончится, они начнут резко тормозить, потому что не смогут использовать буферный кэш.

Но и это еще не все. Нехватка свободной памяти ведет к рискам просадки производительности в сложных запросах. Когда происходит создание больших объемов промежуточных данных, они тоже могут вытеснить буферный кэш, не позволяя использовать его. Что ещё хуже, такие запросы могут достичь предела доступной памяти, и вся система упадёт в swap. Это будет полный коллапс с точки зрения производительности.

5. Строковые поля с высокой кардинальностью

Последний вредный совет загружать строковые поля с высокой кардинальностью. Добавляя к датасету комментарии к заказам, сообщения из чата или что-то подобное, можно сильно просадить производительность. То, что хорошо подходит для полнотекстового поиска, плохо работает для движков In-Memory OLAP. Такие данные не дают использовать RLE, векторные инструкции. Здесь мы снова падаем в выполнение строковых операций, производительность для которых намного меньше, чем для арифметических. BI-система в принципе не всегда может создать индекс на такие строковые поля со всеми вытекающими последствиями.

Да пребудет с вами производительность

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

Всех с наступающим, и отличной производительности всем вашим сервисам в Новом Году! :)

Всем привет! Меня зовут Михаил Волошин, и я, как руководитель отдела инструментов бизнес-анализа, хочу верхнеуровнево рассказать о плюсах и особенностях BI-решения Yota.

200 Tb Vertica, 400 Tb Hadoop, кластер Tableau, специфичная организация процесса разработки и многое другое ждут вас под катом.

Внимательный читатель спросит: А причем тут Vertica и слоник Hadoop, технологии же разные? Да ни при чем это лишь КДПВ.

1. DWH: ода Вертике

Vertica. На ее базе построено корпоративное хранилище данных (data warehouse, DWH), являющееся ядром решения. Наша Vertica первая инсталляция в СНГ была развернута в 2012 году (я пришел лишь в 2016). 8 лет назад не было и половины зоопарка продуктов Apache, а выбор происходил между Netezza, Greenplum и, собственно, Vertica. Время показало, что выбор оказался верным: IBM прекратила техническую поддержку Netezza в 2019, Greenplum еще в 2015 стал opensource продуктом (т.к. никто не покупал шардированный Postgress). И к началу 2021 года в мире осталось 2 серьезных аналитических on-premise БД: Vertica и Teradata. Не хочу разводить холивар, но буду рад услышать об иных решениях, позволяющих обычным аналитикам в adhoc запросах оперировать >1 трлн строк за разумное время в минутах и без поддержки команды data engineer + dataops.

Итак, Vertica это колоночная MPP БД. Т.е. данные хранятся в колонках, что ускоряет доступ к ним и позволяет оптимизировать хранение. Запросы выполняются одновременно всеми нодами кластера, что также позитивно сказывается на скорости обработки данных (однако происходит высокая утилизация сети и дисков). При этом входной порог для доступа к терабайтам и петабайтам данных низок за счет ANSI SQL 99 с небольшими расширениями. 1-й Tb этого великолепия бесплатно. Важный момент все колоночные решения не соответствуют ACID, т.е. не могут заменить классических OLTP БД для условного биллинга, но отлично подходят для целей анализа данных. Более подробно об архитектуре Vertica здесь.

У нас 161 Tb на 34 rack нодах HP, каждая из которых имеет:

• 2*CPU по 20 ядер
• 256Gb RAM
• 2*10G сеть
• быстрые 10k SAS HDD RAID 10 (в 2017/18, когда мы планировали обновление и обновляли RAID массивы, SSD стоили как чугунный мост и были не такими надежными как сейчас)

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

В целом продукт достаточно надежный: за все время, что я работаю в Yota (5-й год пошел), кластер ни разу не падал целиком. Были кейсы, когда 9 нод вываливались в течение 10 минут (диски, контроллеры рейдов, иные технические проблемы), и это приводило к просадкам производительности, но кластер не рассыпался, и после вывода сбоивших нод из кластера на горячую производительность восстанавливалась. Вывод необходим, т.к. кластер всегда работает со скоростью самой медленной ноды (вспоминаем рекомендацию вендора о гомогенности). Теоретически из строя может выйти до половины всех узлов кластера, но может хватить и 2 нод (при k-safety=1, параметр репликации данных со стандартным значением для большинства инсталляций в мире).

Еще одним фактом, касающимся надежности DWH, хотя и не красящим нас, является появление бэкапа: он у нас появился лишь в 2019 перед мажорным обновлением версии Vertica. И это при том, что до 2018 года наша Vertica была самой большой в СНГ (сейчас по объему вторая-третья, но по сложности самого хранилища, по-прежнему, первая).

Обновлялись мы, кстати, сразу на 2 версии (7 -> 8, 8 -> 9). Ну, как обновлялись: в 13:00 остановили кластер и запустили .py скрипт от вендора, а в 21:10 мы уже открывали пиво, после того как кластер начал подниматься. Никаких эксцессов не было. И тут вспомнилась статья на Хабре от коллег из телекома про обновление кластера Greenplum c 4-ой до 5-ой версии. Так они, насколько помню, потратили сотни дней разработчиков на costylmaking из-за несовместимости типов данных между мажорными версиями одного продукта.

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

Anchor modeling, Datavault 2.0 всего этого у нас нет. Мы не фокусировались на жестком соблюдении какой-то одной изначально выбранной методологии, иначе сами себе устроили бы приключения. Почему? Хотя бы потому, что при разворачивании DWH, Yota была независимой компанией и крупнейшим оператором 4G, но предоставлявшим доступ в сеть только для модемных устройств. После покупки МегаФоном в Yota появились голосовые абоненты, а голос принципиально иной продукт, и мы бы просто не запустились в крайне сжатые сроки, если бы не определенная архитектурная свобода. У нас 37 схем, и архитектура внутри каждой не то, что схемы, но даже витрины, может отличаться от мейнстрима и выбирается в соответствии с решаемой задачей с учетом особенностей хранения в источниках.

И еще момент во внутренней команде нет ни архитектора, ни девопс-гуру. Они просто не нужны fulltime, т.к. Vertica не требует постоянного обслуживания. Эти роли у нас выполняются подрядчиком, а внутренняя команда сфокусирована на создании инструментов анализа бизнес-данных для всей компании и совместном с бизнесом улучшении продуктов. Как бы высокопарно это ни звучало, но Yota изначально data driven business. У нас под сотню персональных учеток для adhoc-запросов и широкого доступа к данным всем, кому он нужен.

В завершение разговора о Vertica хочется обсудить регулярно поднимающийся вопрос: Дорого же! Зачем оно надо?. По моему скромному мнению, в бизнесе нет понятий дорого/дешево, но есть понятие эффективно/не эффективно. Давным-давно я работал в складской логистике, так вот, строительство склада начинается с изучения характеристик будущих единиц хранения (SKU) и потоков движения этих SKU. При проектировании хранилища ситуация должна быть аналогичной: изучение данных, подразумеваемых для обработки внутри DWH, выбор наиболее оптимальной архитектуры с параллельными расчетами финансовой модели. Звучит просто, но это позволит избежать догматов: Делаем только на opensource или Наш потрясающий стартап может себе позволить Teradata в топ-комплектации. Пару месяцев назад создал модель Vertica total cost of ownership, и эффективность текущего решения Yota вышла оптимальной. Поделиться, к сожалению, по понятным причинам не смогу.

Hadoop. Их у нас целых 2 кластера (Cloudera 6.3), которые мы используем как дешевое хранилище некритичных для бизнеса данных. К данным, хранящимся в наших Hadoop, не требуется скорость доcтупа, предъявляемая к Вертике. Здесь стоит отметить подставу со стороны Cloudera: когда мы наши Хадупы планировали и разворачивали в 2018-2019, то существовавшая Comminity Edition нас вполне устраивала; однако в феврале 2020 пришла полярная лисичка в виде изменения политики лицензирования и, по сути, отмены т.н. free версий. Из-за этого вынуждены думать сейчас о редеплое кластера из 23 нод на CH 5.16 с потерей данных (ими можно пожертвовать). А на маленький кластер Hadoop вынуждены оформлять ненужную нам лицензию.

Oracle. Легаси-вишенкой на торте DWH выступает хранилище Oracle объемом всего 1.4 Tb. Его мы иногда используем для собственной обработки в ODS слое высокочастотных потоков малонасыщенных данных. Например, 100 000 файлов в сутки по несколько строк в каждом, конечно, можно писать в Вертику напрямую, но разумнее сначала в транзакционную БД, а уже затем часовыми батчами в DWH. Движемся дальше.

2. ETL

В нашем случае зачастую ELT, так как наше DWH позволяет перемалывать терабайты внутри себя без реализации стадии Transform на относительно слабых ETL-серверах.

Высоконагруженные потоки данных. У нас 9 пайплайнов по 2-8 ETL-джобов в каждом. Они редко меняются, и поскольку границы не выходят за staging слой, то мы отдали их нашим подрядчикам. Тем же, которые поддерживают Vertica. Коллеги написали свой Loader на Groovy 3, который сами и поддерживают. Loader вполне неплохо перемалывает свой 1 Tb в сутки, поступающий в Vertica, и до 10 Tb в большой Hadoop.

Из интересного стоит упомянуть используемый нами механизм CDC от Oracle Oracle Golden Gate. Kafka пока не используем, но, возможно, начнем, т.к. переезд на Oracle 19 имеет специфичную реализацию Oracle for BigData вместо старого доброго OGG. На текущий момент мы еще в процессе исследований, но как бы не пришлось свои костыли писать

Остальные потоки данных. Здесь кроется соль нашего решения формирование промежуточных и конечных витрин как на основе данных из п. 2.1, так и на собственных интеграциях примерно с 150 системами-источниками. Этим занимается исключительно внутренняя команда. Здесь примерно 1150 ETL-джобов. В основе стэка разработки: Talend Data Integration 7.1. Инструмент условно бесплатный. Условно, т.к. требует лицензии для использования среды выполнения и оркестрации. Я уже не застал того благостного времени, когда использовалась Talend Administration Console, но старшие товарищи рассказывали, что это был тот еще садомазочуланчик папаши Мюллера образцовый UI, привносящий незабываемый UX. Можно, конечно, деплоить джобы Talend в виде .zip пакетов сразу в .sh и оркестрировать в cron, а потом грепать логи. Но было решено еще в 2016 году, что деплоить джобы Talend будем сразу в Scheduler (рантайм с web UI для доступа к нему). Который, как уже понятно, написал под нас тот же самый подрядчик. Разумеется, и лицензия стоит дешевле чем TAC, UI оставляет более позитивный UX, и доработки под наши пожелания не затягиваются во времени.

Пара слов про Talend Data Integration. Это среда визуального программирования потоков интеграции. Сам инструмент не уступает Informatica PowerCenter по производительности. JVM под капотом у обоих. Максимум, что придется писать руками SQL для стадии Transform внутри некоторых компонентов, но его и нет смысла пытаться чем-то заменить. Чтобы не было сомнений в возможностях Talend и иных интеграционных комбайнов, 2 факта:

• до появления Loader сотни Гб бинарников CDR парсились джобами Talend. Loader и появился из доработки джобов Talend, которые перестали справляться с нагрузкой;
• внутренняя команда иногда переписывает за подрядчиком пайплайны, созданные в их Loader, и время на обработку данных уменьшается. Понятно, что ситуация разовая, и 1 Tb в сутки из бинарников вряд ли Talend распарсит, но факт есть факт.

3. Визуализация данных

Используем следующие инструменты: MS Analysis Services, Tableau, есть у нас и любимое легаси в виде SAP BO.

MS Analysis Services. Исторически аналитические кубы были значимым инструментом. В проде у нас всего 16 кубов весом от 6 Mb до 144 Gb, а через пару месяцев после доработок и до 200 Gb. В 2020 году возникла идея о возможном переносе кубов в Tableau, но там уже при экстракте в 5 Gb дэшборд стал люто тормозить. В нашем случае платформа оказалась безальтернативной. Кстати, используем последний free version MS AS 11. Не PowerBI, конечно, но нулевые траты на лицензии нас вполне устраивают.

Tableau. На конец 2020 у нас было 277 дэшбордов, и бизнесу они адски заходят. Одна из целей 2021 максимальная автоматизация ручной отчетности аналитиков. И тут мы споткнулись, т.к. наши аналитики, как и любые нормальные аналитики, для прототипирования используют Excel. Без шуток.


Очень круто выглядит и нравится топ-менеджменту. Как бывший аналитик данных, сам кайфую, когда вижу такую красоту. Но чтобы реализовать такой водопад в Tableau, нужно сделать 5 графиков, обеспечить синхронизацию фильтров между ними Ок, пару накликать можно. А если в дэшборде их 171? Ну, вы поняли. На одной стороне весов 12 человеко-часов аналитиков на ежемесячный сбор презентации. На другой полгода разработки сеньором + 100% гарантия превращения дэшборда в недвижимость. Недавно был тяжелый разговор с аналитиками, где мы зафиксировали, что такой красоты может быть не больше 2-3 графиков на весь дэшборд. Но продолжаем искать пути автоматизации именно этого типа визуализации в юзкейсах наших аналитиков адская идея скриптами powershell повторить ручные действия в Excel (там их пилят при помощи платной надстройки ThinkCell) пока не отпала. Офтопом стоит отметить сам факт повторения многостраничных презентаций в Tableau, где на самом деле однотипные данные намертво распечатаны в .pdf во всех возможных измерениях имеющихся в дэшборде. Конечно же, подход спорный, но мы очень клиентоориентированы по отношению к внутренним заказчикам, и мысли об изменении в сторону сторителлинга аккуратно и потихоньку продвигаем в жизнь.

Sap BO. Очевидная legacy система визуализации устаревшая чуть более, чем полностью. Аккуратно уходим от нее в сторону более современных и гибких решений, т.к. она прекрасна для point-to-point повторения отчетов (именно тут необходимо собирать большие и однотипные презентации аналитиков, но трудозатраты будут еще выше, да и такие водопады вообще не факт, что реализуемы в SAP BO), но не позволяет создавать интерактивные дэшборды. Следует отметить, что сам подход реализации point-to-point больших презентаций актуален для большого российского бизнеса, например, из сферы добычи сырья. В 2к21 это, на мой взгляд, выглядит морально устаревшим, особенно для Yota, средних размеров data driven business. Поэтому нам не имеет смысла заниматься реализацией намертво прибитых по брендбуку отчетов на миллион вкладок/страниц.

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

4. Data science (machine learning)

Кроме классического BI в отделе есть команда DS и, надеюсь, в этом году здесь появится ссылка на статью о Data Science в Yota, написанную профессионалом. Я таковым не являюсь, т.к. вырос из разработчиков классического BI. Извините, если кто-то зашел сюда только ради этого :-)

5. Agile? Нет У нас своё

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

В направлении классического BI 6 инженеров и тимлид. При этом нет ни выделенных архитекторов, ни аналитиков, ни тестировщиков, ни релиз-менеджеров. Каждый инженер = BI-фулстэк, реализует задачу под ключ, напрямую общаясь с бизнес-заказчиком и лично ответственен за конечный результат. Кодеров по ТЗ/токсичных рок-звезд нет и не будет от слова совсем. Но у всей команды изначально хорошие софт-скилы вдобавок к хард. В теории взаимозаменяемы, но жизнь вносит свои коррективы, и кто-то оказывается более сильным в ETL, а кому-то интереснее визуализация в Tableau пожелания в развитии каждого учитываются и мной, и тимлидом.

Работа по заявке идет с упором на 2 показателя: time-to-market (TTM) и customer satisfaction index (CSI). Причем сразу на проде, если речь об ETL-задачах в DWH. Тестовая зона, конечно же, есть, но подготовка данных на наших объемах занимает сильно больше времени, чем сама разработка. Важный момент: сообщения в чате наподобие ой, я оттранкейтил справочник... встречаются не чаще 1-2 раз в год и исправляются за 5-10 минут. Потерь невосстановимых, критичных для компании данных я не помню. В этом плане интереснее обращения от коллег из систем-источников на 100% реплицируемых в DWH с просьбой выслать из нашего бэкапа какую-нибудь таблицу фактов, которую массово проапдейтили, но что-то пошло не так За последний год такое было 2 раза.

Вы спросите, почему все так необычно устроено?


Есть очевидные минусы, с которыми мы умеем жить:

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

и плюсы:

• Высокий TTM и высокая пропускная способность команды в целом. Весь проектный портфель компании (почти во всех проектах есть фичи на отдел) составляет 15-20% общего объема разработки отдела. Остальное прямые пожелания конечных бизнес-заказчиков, реализуемые с минимумом бюрократии.
• Стабильно высокий CSI, демонстрирующий правильность выбранного подхода в организации разработки. Один раз в квартал мы проводим опрос среди бизнес-заказчиков. В 4Q20 из 43 респондентов ответили 21. По итогу получили 4,89 из 5. Это упавший CSI, хотя я предполагал падение до 4,5. Стандартно у нас ближе к 5. Объясняется это гибкостью в подходе к реализациям задумок бизнес-заказчиков и скоростью появления конечного результата с максимально эффективным использованием имеющихся инструментов/технологий.

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

Пользуясь случаем хочу поблагодарить #BI_TEAM за стабильно высокие результаты: ребята вы крутые, мне повезло работать со всеми вами! Спасибо.

6. Заключение

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

По идее здесь должны быть вакансии отдела, но извините full house) И даже есть небольшой лист ожидания Однако в соседних, не менее интересных, командах еще требуются люди. Буду рад комментариям нам есть куда расти.

Как мало пройдено дорог как много сделано отчетов

Введение

Василий, мы установили новый BI продукт, наш САМЙ ГЛАВНЙ от него просто в восторге!
Да, но я не знаю, как выгрузить данные для анализа из этой системы?! Он, похоже, только в html может что-то показывать.
Ничего, я думаю ты справишься, сам понимаешь, чем шире улыбка шефа, тем выше премия.
Но, Иван Васильевич, этот продукт в качестве источника данных использует только PDF файлы.
Зато он показывает шикарные разноцветные графики, у него анимация как в Звездных войнах, а руководство просто в восторге от его интерактивных возможностей. Там ещё и пасхалочка есть. Если три раза кликнуть в правом нижнем углу, появится Дарт Вейдер и споёт Марсельезу. Да и в целом, Вася, будь оптимистом! Хочешь анекдот в тему?

Что у вас запланировано на 1 января?
Катание на санках
А если снег не выпадет?
Это нас огорчит, но не остановит.

Не грусти Вася, принимайся за работу, а мне пора спешить утренняя планерка, эээ Daily Standup Meeting точнее, всё никак не могу запомнить.

Вася садится за свой рабочий стол и с грустью смотрит в монитор. Да уж, красивые графики, только толку от них? В Excel не выгрузить, с формулами не сверить, хоть бери тетрадку с ручкой и делай всё на бумаге. Плюс ещё как-то KPI на основе этого надо посчитать. Зато в ИТ отдел, говорят, художника взяли, чтобы он красивые отчеты для руководства оформлял. Глядя на новый продукт, Вася загрустил. В голове у него крутились пару строк из стихотворения C.А. Есенина Мне грустно на тебя смотреть:

Так мало пройдено дорог,
Так много сделано ошибок.

Ну что ж, оставим Васю на едине со своей болью и посмотрим на проблему шире. Видя переделку строк C.А. Есенина, которая вынесена в цитату к этой статье, мне кажется, что он не одинок в своих мыслях. Сложно понять, как работают современные BI системы и для кого их пишут то ли для аналитиков, то ли для руководителей. Очень много теории и информации, причём, в зависимости от источника, эта информация может противоречить самой себе. К этому стоит добавить обилие научных терминов и трудный для понимания язык описания. Сложно угадать с выбором, а цена ошибки велика, так как системы дорогие и работа с ними часто требует определенной квалификации. Понимая всё это, я решил поделиться своим опытом в BI сфере. Попытаюсь написать об этом простым языком и не вдаваться глубоко в теорию. Речь пойдет о Microsoft Analysis Services и о том, как он может решить часть проблем связанных с аналитической отчетностью. Другую часть этих проблем, я решил, написав специальную программу, которая позволяла формировать отчеты непосредственно в Excel, минуя HTML формы и минимизируя нагрузку на Web сервер, но о ней я уже писал тут http://personeltest.ru/aways/habr.com/ru/post/281703/, а тут даже видео снял: https://youtu.be/_csGSw-xyzQ. Приятного вам чтения.

Отчетность и её проблемы

Все началось с задачи, поставленной финансовым отделом крупного банка. Надо было создать систему отчетности, которая бы позволяла быстро и оперативно оценивать текущую ситуацию в организации. Для решения этой задачи мы взяли базу данных. Организовали в ней Хранилище (Data Warehouse), настроили процессы загрузки данных и установили систему отчетности. В качестве которой мы взяли SQL Server Reporting Services, так как этот продукт входил в MS Sharepoint, использовавшийся в тот момент в банке. В принципе всё работало, но у заказчика были претензии:

• Претензия 1. HTML -> MS Excel: отчеты изначально формируются в HTML, а аналитики работают с MS Excel. Надо постоянно делать экспорт из одного формата в другой. При этом часто сбивается разметка и в Excel часто подгружается множество дополнительной информации, большой объём которой, в некоторых случаях, существенно влияет на производительность.
• Претензия 2. Параметры для отчета: данные в отчетах зависят от параметров, причём при их изменении формируется новый отчет, который надо опять выгружать в Excel, что не всегда удобно.
• Претензия 3. Добавление изменений в отчет: для того, чтобы что-то изменить в отчете, добавить новую колонку или создать группировку, надо обращаться к специалисту, который может поправить этот отчет на сервере.
• Претензия 4. Анализ данных: отчеты получаются статическими и когда нужно посмотреть различные разрезы, поменять строки с колонками, отфильтровать или добавить, либо удалить какие-то значения, надо делать все эти манипуляции в Excel, что не всегда удобно, а порой и сложно, из-за проблем с производительностью компьютеров, на которых работают аналитики.

Стоит отметить, что сотрудники банка не рассматривали для себя никакого другого инструмента в качестве замены MS Excel. И на то были веские основания. Весь его функционал сложно чем-то заменить. К примеру, аналитики очень часто:

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

В общем использовали его на все 100%. Хотя были те, кто предлагал им что-то другое, точнее не столько предлагал, сколько заставлял. Как итог таких предложений, у нас в системе появились SAP BO, Oracle Reports Services и ряд других BI инструментов. Возможно, они в чем-то превосходили SQL Server Reporting Services, но суть работы с ними кардинально не изменилась:

1. формируем отчет в HTML,
2. экспортируем его в Excel,
3. начинаем заниматься бесконечными танцами вокруг данных.

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

Выход из ситуации

К найденному решению подтолкнули PivotTable в Excel



и PivotGrid от фирмы DevExpress ( https://demos.devexpress.com/blazor/PivotGrid).

Детально изучив эти решения вышли на MS Analysis Services и решили попробовать. Его можно использовать в Excel, и он может работать с Oracle, как с источником данных, что нас на тот момент устраивало. С точки зрения архитектуры, источником данных для него может служить что угодно, был бы нужный провайдер. Суть его в том, что он способен хранить в себе большие объемы данных со всеми их агрегациями и выдавать их клиенту максимально быстро. К Excel его можно легко подключить и манипулировать данными в Pivot Table.



В MS Analysis Services есть возможность партиционирования данных (хранение их в виде множества отдельных частей) и так же инкрементальное обновление данных. Это даёт ему возможность загружать данные из внешних систем небольшими кусочками и хранить их во множестве партиций. С точки зрения максимальных объемов, у него есть ограничения, но они довольно большие https://docs.microsoft.com/en-us/analysis-services/multidimensional-models/olap-physical/maximum-capacity-specifications-analysis-services?view=asallproducts-allversions.

MS Analysis Services является OLAP системой, которая использует отдельный сервер для хранения данных, либо части данных. Его плюсом является то, что он способен довольно быстро работать с миллионами записей, будучи установленным на обычный, современный компьютер. Так же он позволяет анализировать данные непосредственно в Excel и может заменить собой десятки отчетов на MS Reporting Services или ему подобных. Причем при работе с ним не надо писать и править различные запросы типа SQL, хотя при желании можно, только вместо SQL он использует MDX.

Правда есть тут и ложка дегтя. В Excel можно запросить разом очень большой объём данных и OLAP их вернет, но отобразить такой объем Excel не сможет, либо сможет, но работать при этом будет очень медленно. На первых порах это раздражало аналитиков, но поняв причину и настроив фильтры в Pivot Table эту проблему решили.

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

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

Чаще всего, когда анализируют данные их объединяют в группы, а сами группы так же объединяют в иерархии. Для примера возьмём торговую точку. С точки зрения бизнеса, интерес представляют продажи. То есть сколько товара было продано за день (1-группа), за месяц (2-ая) и за год (3-я). Где день месяц и год это разные уровни одной иерархии. Получается, что продажи за месяц это сумма всех продаж за все дни в месяце, а продажи за год это сумма продаж за все месяцы в этом году. Отсюда получается, что для получения максимального быстродействия, можно заранее собрать данные в группы и рассчитать агрегаты (в нашем примере суммы продаж) для каждого уровня иерархи. Вот на этом принципе и работают MS Analysis Services. Им достаточно сказать что надо считать, по какой формуле и на какие группы это можно разбить. Остальную работу они сделают сами. Тут немного о том как они это делают: http://citforum.ru/consulting/BI/molap_overview/node7.shtml. Стоит отметить, что в современных OLAP системах все агрегаты, чаще всего, не рассчитываются заранее. Это всё делается на лету, в момент запроса.

Теперь о терминах:

MS Analysis Services это одна из OLAP систем, где OLAP это аббревиатура online analytical processing. Дословно это означает интерактивная (online) аналитическая обработка данных. Со временем данная формулировка утратила свой первоначальный смысл, так как появились системы, способные обрабатывать данные с большой скоростью и передавать их пользователю без использования подходов, декларируемых в OLAP. Поэтому, сейчас есть более полное описание требований к системам, которые могут называться OLAP, это:

• Тест FASMI Fast Analysis of Shared Multidimensional Information. Более детально об этом можно прочитать здесь: http://www.olap.ru/basic/fasmi.asp.
• И описание правильного куба, которое дал в 1993 году Е.Ф. Кодд: http://www.calligraph.ru/kodda.htm .

По своему опыту, могу сказать, что чем больше ваш OLAP куб удовлетворяет описанию Е.Ф. Кодда, тем лучше, как с точки зрения работы с ним, так и с точки зрения его создания.

Вкратце, OLAP это система хранения, организованная таким образом, чтобы данные в ней:

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

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

При построении OLAP выделяют Факты и Измерения. Факты это цифровые значения измеряемых величин. Измерения это сами измеряемые величины. Совокупность всех связанных между собой измерений, фактов и функций для их агрегации называют OLAP-кубом. Факты и Измерения связанны между собой. По типу связи выделяют 2 схемы организации хранения данных Звезда и Снежинка. Звезда это когда все измерения напрямую связаны с фактом, снежинка это когда есть измерения, которые связанны с фактом через другие измерения. Эти схемы можно создавать и просматривать в разделе Data Source Views в SSAS.

Создание OLAP-куба в Microsoft Analysis Services

Построение OLAP кубов делается через проект в Visual Studio. По большей части там реализована технология визуального программирования перетащить, кликнуть мышкой, настроить. Отсюда это проще показать, чем описать. Что я и сделал в моем видео: https://youtu.be/f5DgG51KMf8. Так же стоит отметить то, что Microsoft, в ознакомительных целях, предоставляет свои продукты бесплатно. Отсюда, посмотреть, как он работает можно на любом компьютере с ОС Windows 10, удовлетворяющем следующим требованиям: https://docs.microsoft.com/en-us/sql/sql-server/install/hardware-and-software-requirements-for-installing-sql-server-ver15?view=sql-server-ver15. Требования по ссылке к MS SQL Server, так как MS Analysis Services являются его частью.

Заключение

OLAP это относительно простой способ повысить скорость и удобство работы с данными. В данный момент существует множество решений, основанных на этой технологии. Я работал с MS Analysis Services (SSAS) и вот что мне в нём понравилось:

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

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

Какой у Вас выбор?

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

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

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

Приведенные особенности BI-систем заставляют задуматься о подборе альтернативы. Далее я предлагаю сравнить решение стандартного набора задач при подготовке отчетности с помощью Power BI и Excel.

Power BI или Excel?

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

А как решается эта задача с помощью Power BI?

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

Какие преимущества применения Power BI по сравнению с традиционным подходом можно заметить в приведенном примере?

1 Автоматизация процедуры получения данных и подготовка их к анализу.
2 Построение бизнес-модели.
3 Невероятная визуализация.
4 Разграниченный доступ к отчетам.

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

1 Для подготовки данных к построению отчета, нужно единожды определить процедуру, выполняющую подключение к данным и их обработку и каждый раз, когда понадобится получить отчет за другой период, Power BI будет пропускать данные через созданную процедуру. Таким образом автоматизируется большая часть работы по подготовки данных к анализу. Но дело в том, что Power BI осуществляет процедуру подготовки данных с помощью инструмента, который доступен в классической версии Excel, и называется он Power Query. Он позволяет выполнить поставленную задачу в Excel абсолютно тем же способом.

2 Здесь та же ситуация. Инструмент Power BI для построения бизнес-модели имеется и в Excel это Power Pivot.

3 Как Вы, наверное, уже догадались, с визуализацией дело обстоит подобным образом: расширение Excel Power View справляется с этой задачей на ура.

4 Остается разобраться с доступом к отчетам. Тут не так все радужно. Дело в том, что Power BI это облачный сервис, доступ к которому осуществляется через персональную учетную запись. Администратор сервиса распределяет пользователей по группам и задает для этих групп различный уровень доступа к отчетам. Этим достигается разграничение прав доступа между сотрудниками компании. Таким образом, аналитики, менеджеры и директора заходя на одну и туже страницу видят отчет в доступном для них представлении. Может быть ограничен доступ к определенному набору данных, либо к отчету целиком. Однако, если отчет находится в файле формата Excel, то усилиями системного администратора можно попытаться решить задачу с доступом, но это будет уже не то. Я еще вернусь к рассмотрению этой задачи, когда буду описывать особенности корпоративного портала.

Стоит отметить, что, как правило, потребность компании в сложных и красивых дашбордах не велика и часто, для анализа данных в Excel, после построения бизнес-модели не прибегают к возможностям Power View, а пользуются сводными таблицами. Они предоставляют OLAP-функциональность, которой вполне достаточно чтобы решить большинство бизнес-аналитических задач.

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

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

ETL и DWH

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

С их помощью осуществляется выгрузка данных из источников (Extract), их преобразование (Transform), что подразумевает очистку и сопоставление, и загрузка в хранилище данных (Load). Хранилище данных (DWH Data Warehouse) это, как правило, реляционная база данных, расположенная на сервере. Эта база содержит данные, пригодные для анализа. По расписанию запускается ETL-процесс, который обновляет данные хранилища до актуальных. Кстати говоря, всю эту кухню прекрасно обслуживает Integration Services, входящие в состав MS SQL Server.

Далее, как и раньше для построения бизнес-модели данных и визуализации можно воспользоваться Excel, Power BI, либо другими аналитическими инструментами, такими как Tableau или Qlik Sense. Но прежде, мне бы хотелось обратить Ваше внимание еще на одну возможность, о которой Вы могли не знать, несмотря на то, что она Вам давно доступна. Речь идет о построении бизнес-моделей с помощью аналитических служб MS SQL Server, а именно Analysis Services.

Модели данных в MS Analysis Services

Этот раздел статьи будет более интересен тем, кто уже использует MS SQL Server в своей компании.

На данный момент службы Analysis Services предоставляют два вида моделей данных это многомерная и табличная модели. Кроме того, что данные в этих моделях связаны, значения показателей модели предварительно агрегируются и хранятся в ячейках OLAP кубов, доступ к которым осуществляется MDX, либо DAX запросами. За счет такой архитектуры хранения данных, запрос, который охватывает миллионы записей, возвращается за секунды. Такой способ доступа к данным необходим компаниям, таблицы транзакций которых содержат от миллиона записей (верхний придел не ограничен).

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

Если Вы пошли продвинутым путем: автоматизировали процесс ETL и построили бизнес-модели при помощи служб MS SQL Server, то Вы достойны иметь свой собственный корпоративный портал.

Корпоративный портал

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

Однако, пока не понятно, как будет организовано отображение отчетов на странице портала. Чтобы ответить на этот вопрос, сначала нужно определиться с технологией, на основе которой будет строиться портал. Я предлагаю взять за основу один из фреймворков: ASP.NET MVC/Web Forms/Core, либо Microsoft SharePoint. Если в Вашей компании имеется хотя бы один .NET разработчик, то выбор не составит труда. Теперь можно подбирать встраиваемый в приложение OLAP-клиент, способный подключаться к многомерным или табличным моделям служб Analysis Services.

Выбор OLAP-клиента для визуализации

Сравним несколько инструментов по уровню сложности встраивания, функциональности и цене: Power BI, компоненты Telerik UI for ASP.NET MVC и компоненты RadarCube ASP.NET MVC.

Power BI

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

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

Сначала отчет, сформированный в Power BI Desktop, публикуется на портале Power BI и потом, с помощью не простой настройки, встраивается в страницу web-приложения.

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

Компоненты Telerik и RadarCube

Для встраивания компонентов Telerik и RadarCube достаточно владеть программными технологиями на базовом уровне. Поэтому профессиональных навыков одного программиста из IT-отдела будет вполне достаточно. Все что нужно, это разместить компонент на web-странице и настроить их под свои нужды.

Компонент PivotGrid из набора Telerik UI for ASP.NET MVC встраивается на страницу в изящной манере Razor и предоставляет самые необходимые OLAP-функции. Однако, если требуется более гибкие настройки интерфейса и развитый функционал, то лучше использовать компоненты RadarCube ASP.NET MVC. Большое количество настроек, богатый функционал с возможностями его переопределения и расширения, позволят создать OLAP-отчет любой сложности.

Ниже приведу таблицу сравнения характеристик рассматриваемых инструментов по шкале Низкий-Средний-Высокий.


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

Условия выбора Power BI

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

Условия выбора компонентов Telerik

• Нужен простой OLAP-клиент для Ad hock анализа.
• В штате компании имеется .NET разработчик начального уровня.
• Небольшой бюджет на разовую покупку лицензии и дальнейшее ее продление со скидкой менее 20%.

Условия выбора компонентов RadarCube

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

Заключение

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