В этой статье хотелось бы погрузить вас в мир данных и вспомнить:  

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

• какие задачи приходилось решать; 

• какие навыки пригодились. 

Но вначале придется разобрать извечные вопросы: кто же такие аналитики, что такое данные и понять – должны ли они быть вместе?

Вопрос 1: Кто такие аналитики?

Аналитик – это специалист по изменениям. 

Любое изменение должно быть осмыслено. 

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

1. не содержит описание деятельности или привязки к определенной области применения аналитика;

2. указывает на то, что аналитик –  “информационное окно”, способен осмыслить, зафиксировать, транслировать процесс изменения на заказчика и команду; 

3. определение емкое, но понятное, объяснить его можно даже дошкольнику (удачно проверено несколько раз: ни один ребенок не пострадал).

В моем случае все сошлось: люблю осмысливать свои данные (и чужие тоже, если предоставляется такая возможность) и считаю, что анализ данных (АД) – это равноценная область, наравне с бизнес-анализом (БА) и системным анализом (СА). 

Бизнес анализ – исследование изменений системы, чаще всего результатом является процесс. Отвечает на вопрос “Что делать?”.

Системный анализ – проектирование изменений системы – то есть результат, некий конечный продукт. Отвечает на вопрос “Как делать?”.

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

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

Вопрос 2: Что такое данные?

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

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

• Осмысленность: не понимая смысл данных, мы упускаем выгоду;

• Доступность: если нет гарантий того, что нужные данные будут получены, мы теряем пользователей;

• Масштабируемость: нужно предусмотреть, что объем данных будет только расти. Готовы ли ваши процессы и системы к этому?

• Качественность: пользователь должен быть уверен в данных, доверять им;

• Безопасность: общедоступные данные обесцениваются.

Вопрос 3: Какие встречались проекты, связанные с хранилищами и данными?

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

1. Перетекающие данные

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

• RAW  –  собираем данные из систем-источников в исходном качестве и сохранением полной истории изменений;

• ODS (Operational Data Store) – стандартизируем сырые данные;

• DDS (Detail Data Store) – сохраняем данные в удобном для нас виде, обеспечиваем целостность и качество;

• DM (Data Mart) – подготавливаем данные согласно требованиям конкретного потребителя.

На разных проектах мне встречались от одно до восьми слоев с разными подходами к данным, типами архитектур и трансформациями. По названиям этих слоев можно написать книгу – называют их кто как хочет. Видимо для того, чтобы  проще было понять и запомнить действия, которые там происходят. Аналитику придется собирать требования и участвовать в проектировании хранилища, процессе обработки и “перетекания” данных со слоя на слой. Неплохо было бы знать различные архитектуры хранилищ, ETL\ELT процессы, типы и способы хранения данных.

2. Неубиваемые данные

Мне нравится такое сравнение: “Данные – почти как люди. Они рождаются, взрослеют, женятся. Только не умирают – их убивают.” Не всё так печально: на самом деле никто на моей практике никогда не убивал данные, потому что люди уже вложили ресурсы в их сохранение и преобразование и удалять их – невыгодно. Чаще всего их архивируют. Иногда из них выделяют более эффективные легковесные данные, которые при этом также информативны. На некоторых ресурсах такие данные называют Smart Data. Старые сырые родители, извините, в дом архивирования, пожалуйста. Вы уже не так ценны. 

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

3. Температура данных

Иногда сложно понять, кто в данных старый и редко используемый, а кто – молодой и полезный. Тут по паспорту не посмотришь и по времени создания тоже. Например, есть название компании, которое мы давно сохранили, но используем каждый день. А есть вчерашний прогноз погоды, который никто не захочет еще раз перечитывать.  Для таких случаев существует показатель: температура данных. Горячие данные хранятся в оперативном хранилище – они должны максимально быстро изыматься, затраты на их хранение большие. Холодные данные можно хранить дешево, но время доступа к ним будет увеличиваться. 

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

4. Расселение данных

В распределенных системах есть такие процессы как:

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

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

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

5. Нереальные данные

Следующая тема – виртуализация данных, и при первом слове DevOps-ы начинают активно шевелиться :). Успокоим их, так как у нас несколько другая история. Виртуализация данных – представление данных в абстрактном виде, независимо от систем управления и хранения данных, а также их структуры.

То есть обычный проект – 30-50 источников, которые физически хранятся в разных местах и в разном виде. Обычно всем предлагают мигрировать или реплицировать данные в единое хранилище. Долго, дорого, требуется столько же узконаправленных специалистов, сколько у вас разных систем. В какой-то момент, видимо, кому-то это надоело и предложили просто создать виртуальную модель данных и подтягивать к ней все необходимые данные из источников. Аналитик заходит в таблицу "Клиент” и работает с множеством  записей и ему совершенно необязательно знать, что часть этих записей система подтянула из Oracle, а часть пришла из озера данных на Hadoop или (никогда так не делайте) из файла на рабочем столе бухгалтера. Просто нарисуйте удобную модель  для аналитиков (при этом  каждому можно предоставить доступ только к нужной ему информации) и найдите в команде администратора системы виртуализации, который настроит для вас поступление данных. 

Начальные навыки аналитиков для работы в подобных системах – это понимание логической модели данных и SQL. 

6. Экспертиза данных

Тема профилирования, качества данных – актуальна на всех проектах, потому что иногда  приходят подозрительные или усеченные данные  в виде “скелета”. Тут кроме стандартных характеристик, таких как полнота, согласованность, актуальность, доступность и прочее, важно определить еще и бизнес-метрики от заказчика. К ним могут относится, например, лимит на определенную финансовую операцию или ограничения на диапазон значений. Такая экспертиза поддерживается постоянно, есть целые системы мониторинга, на которых отображаются критичные для заказчика метрики. При стандартных подходах помогут знания специальных инструментов DQ и\или языки для анализа данных (Python, R, SQL), и\или BI инструменты для визуализации.

7. Поддельные данные

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

• Генерация – процесс создания искусственных данных. На подобном проекте приходится самим создавать специальную утилиту, способную заполнять таблицы и связи между ними на источниках, например, чтобы  проверить техническую работоспособность витрины. Часто генерация встречается при нагрузочном тестировании. Учитываем, что нет никакого бизнес-смысла в этих данных: они помогут, когда необходима техническая проверка функционала. Аналитику здесь пригодятся навыки понимания типов и способов хранения данных, инструментов для манипуляции с данными, а также языки Python, SQL;

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

8. Обогащение  данных

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

Изменения могут быть такими:

• дополнение: например, заполнение пустых полей некими вычисленными значениями, полученными после манипуляций с имеющимися данными; 

• удаление: например, есть данные, источнику которых мы не доверяем и видим, что они существенно портят картину;

• маскирование: потому что оно увеличивается ценность с точки зрения доступности команде. 

Тут аналитику помогут базовые знания статистики и знание инструментов для профилирования\анализа данных (Python, R, SQL).

Вопрос 4:  Нужны ли друг другу данные и аналитики?

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

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

Автор статьи: Татьяна Половинкина, аналитик в компании Neoflex.