Мы на своем кластере используем кодеки: gzip, bzip2 и lzma. Lzma имеет самую высокую компрессию и используется для архивируемых данных. Gzip используется для всех остальных данных, поступающих в кластер. От конкретного кодека сжатия зависит возможность «разрезания» (split) файла для операции Map без его распаковки. Как уже писалось ранее, для операции Map данные «нарезаются» на блоки размером не больше заданного в настройках Hadoop (block size). Если сжатый файл больше этого размера, то в случае разделимого кодека (splittable codec) его можно разрезать и распаковать по частям на разных нодах кластера параллельно. В противном случае придется распаковывать этот огромный файл целиком а это уже будет гораздо медленнее.
Таблица 6.2. Сравнение кодеков сжатия
Мониторинг хранилищ данных
Пользователи вашей аналитической системы могут принимать очень важные решения на основе данных, поэтому важно обеспечить их надежными данными.
Однажды у меня произошел нехороший случай: в пятницу вечером я произвел изменения в системе пополнения данных в хранилище в Ozon.ru. И ушел в отпуск. Конечно, на выходных все упало. Ребята-аналитики получили в понедельник письмо от генерального директора на английском, которое начиналось словами: «Im fed up» (Я сыт по горло). Они, конечно, нашли причину проблемы и исправили. Как следовало мне поступить? Во-первых, не делать никаких изменений в пятницу, тем более перед отпуском. Если бы я это сделал хотя бы в четверг, то в пятницу утром изменения «сломали» бы систему и у меня было бы время все исправить. Во-вторых, если бы была полноценная система мониторинга, то разработчики первыми получили бы сообщения о проблеме. У них была бы возможность предупредить пользователей до того, как те ее сами заметят.
Когда я проверял задачи по анализу данных или делал их сам, то периодически мучился вопросом: «А все ли в порядке с данными?» Иногда эти сомнения оправданны, и проблема действительно существует. Это заставляет нас первым шагом делать проверку. Но она не всегда бывает простой и может занять приличное время. Есть второй путь автоматизация проверок данных и мониторинг. Вот об этом и поговорим.
Есть два параметра, которые нужно проверить:
доступность всех данных, которые есть в источнике;
целостность.
Доступность данных проверяется легче всего. Во-первых, проверяется дата последнего обновления, например файла или таблицы. А еще лучше воспользоваться полем с датой/временем например датой и временем заказа. Во-вторых, можно посчитать и сравнить количество записей в хранилище данных и в источнике. Если есть поле с датой и временем, можно сделать такое сравнение по дням. Конечно, в момент проверки данные источника и хранилища будут расходиться, потому что всегда есть дельта времени изменения данных в источнике и отражения этих изменений в хранилище. Если вы уверены, что с данными все в порядке, можно опытным путем найти допустимые пороговые значения относительной разницы в процентах. Для одних данных это может быть полпроцента, для других все пять. Этот тип проверки закроет 80 % проблем с данными в хранилище. Это как раз те 20 % усилий по Парето, которые дают 80 % результата. Методика недорогая, доступна всем и нравится мне своей простотой.
Второй параметр целостность данных проверить сложнее. Под целостностью я подразумеваю наличие в одной таблице тех данных, которые есть во второй. Простейший пример есть две таблицы, одна с клиентами, вторая с заказами. В таблице с заказами есть поле «клиент». Целостность таблицы с заказами будет означать, что все клиенты из этой таблицы должны быть также и в таблице справочнике клиентов. Если это соответствие не соблюдается, то при соединении (join) двух таблиц либо возникнут «битые» данные (если соединение было сделано с учетом этой особенности left join, right join, full outer join), либо эти данные просто исчезнут и эти продажи выпадут из отчетов (если соединение сделано через inner join). Оба этих результата потенциально могут привести к неверным решениям. Хорошо бы это контролировать через независимые тесты, например проверять относительный объем продаж клиентов, которых нет в таблице с клиентами.
Личный опыт
Не надо бояться. Свое первое хранилище я стал собирать в 2004 году в Ozon.ru. Мне в работе очень помогло обучение «MS SQL Server» в «Софтлайне», когда я еще работал в StatSoft. Этот сертификат хранится у меня до сих пор. Я ничего практически не знал об этом, но знакомство с SQL Server и опора на здравый смысл сделали свое дело я создал своего первого «паука», который закачивал данные в наспех собранное хранилище. Мне никто не помогал в этом, но никто и не мешал, что очень важно. Схема хранилища модифицировалась, но ее концепт, заложенный в самом начале, остался прежним. В Wikimart.ru я, работая два дня в неделю, собрал первую версию аналитической системы с полной внутренней веб-аналитикой всего за два месяца. Если вы хотите лучше узнать принципы построения хранилищ, рекомендую обратиться к трудам Ральфа Кимбалла я в них почерпнул много полезного.
А теперь о сложностях. К моменту моего ухода из Ozon.ru расхождение данных о продажах в хранилище с бухгалтерией составляло 45 %. При этом бухгалтерия закрывала период в течение месяца, а данные в кубах аналитической системы были уже в первый день следующего месяца. После ухода из Ozon.ru я встречался с операционным директором «Связного» целая небольшая команда пришла пообщаться со мной по поводу «строительства кубов». Они очень удивились тому, что я сделал весь основной движок в одиночку. Это не я такой крутой, это вопрос допустимой погрешности системы. Чем меньшего процента расхождения с бухгалтерией мы хотим достичь, тем сложнее его получить. Допустим, нужно уменьшить расхождение с 4 до 3 %. Это потребует большего вовлечения меня, найма одного-двух человек, усложнения системы, а следовательно, увеличения управленческой «энтропии». Если мы хотим продолжать дальше спуститься до двух процентов, это потребует уже на порядок больше усилий. Каждое уменьшение будет требовать усложнения и удорожания по экспоненте. Но что мы теряем? Мы теряем гибкость, мы теряем маневренность. Не нужно молиться на нулевую погрешность, ее никогда не будет. Помните про правило Парето 20 % усилий дают 80 % результата, и не факт, что остальные 80 % усилий стоит затрачивать. Возможно, стоит потратить их на что-то другое, что сделает нас ближе к цели, а не стремиться к идеально вылизанным цифрам.
Глава 7
Инструменты анализа данных
Как вы помните из предыдущих глав, классическая аналитика данных делится на два этапа поиск гипотез и их статистическая проверка. Для формирования гипотез нам понадобятся описательная статистика, визуализация данных и доменные знания, например, какие события в компании произошли.
Для первых двух пунктов существует много видов программного обеспечения, которое облегчает и ускоряет труд аналитика. Здесь я рассмотрю диаметрально разные подходы. Можно быть приверженцем только одного из них, но расширить кругозор полезно вдруг альтернативный подход будет удобнее.
Я делю эти инструменты по способу взаимодействия с пользователем. Это деление весьма условно, так как некоторые категории могут пересекаться друг с другом.
Электронные таблицы Microsoft Excel, Open Office Calc, Google Docs Sheets.
Программные сервисы блокнотов, например Jupyter Notebook, Netflix Polynote, Google Colab, R studio.
Визуальные инструменты Tableau, Google Data Studio, Yandex Data Lens, Microsoft Power BI, Amazon QuickSight.
Специализированные статистические пакеты SAS, SPSS, Statistica, Knime, Orange data mining.
Электронные таблицы
Электронные таблицы одни из самых распространенных инструментов анализа данных. Впервые я познакомился с ними еще в 1997 году, когда делал таблицы для школьного реферата по географии в Quattro Pro, чем произвел впечатление на учительницу географии. Я много дней ходил на работу к отцу, который в то время занимался IT-технологиями, набирал текст на клавиатуре и масштабировал карты стран на ксероксе. В итоге получился полностью напечатанный реферат, что было очень примечательно в те времена, особенно в Твери. Затем я работал c Microsoft Excel, потом в Google Sheets, которые сделали очень легкой совместную работу в облаке. В чем плюс электронных таблиц:
низкий порог входа;
все делается интуитивно и наглядно: добавление нового столбца или формулы;
есть возможность анализа сводных таблиц (pivot) самый мощный инструмент генерации гипотез;
очень легко делать графики.
Основной минус электронные таблицы не предназначены для автоматизации задач с использованием программирования. Когда такой проект усложняется, его поддержка превращается в ад для разработчиков. Внутри электронных таблиц появляется много программного кода, который находится вне системы контроля версий, поэтому отслеживать его изменения невозможно. У меня был опыт «изготовления» сложных отчетов для еженедельных собраний директоров в Ozon.ru и Wikimart.ru на основе электронных таблиц. В Ozon.ru к таблице подключались источники ручного ввода данных менеджерами компании, OLAP-кубы, SQL-скрипты. В определенный момент отчет обновлялся программным способом и сохранялся в папку с нужной датой. В Wikimart.ru плюс к тому аналитики вручную корректировали отчет и конвертировали его в PDF-файл для презентаций. Сейчас я бы по максимуму отказался от этого в пользу более управляемых решений, пусть и менее гибких, чем электронные таблицы. И договорился бы с менеджментом об изменении шаблона отчетов так, чтобы сделать его более инженерным способом.