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

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

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

Самой последней наиболее дорогой по баблу, но самой милой сердцу любого начальника идет предписывающая аналитика. И если преддиктивная аналитика отвечает на вопрос "что будет если нихера не менять?", то предписывающая аналитика отвечает на вопрос "что будет если что-то все таки поменять?" и "что делать?". И подобные вопросы типа "Как, когда, в каком количестве нужно делать, чтобы не проебать все полимеры". Само собой она основывается на предыдущих трёх уровнях аналитики, типа в субботу нужно купить 12 творожков на сумму 768 рублей, потому что в запасе ещё 3 творожка, прогнозируемое потребление - 2.5 творожка в день, зарплата в пятницу, по субботам скидки, а в магазин в следующий раз мы пойдем в лучшем случае в четверг. Здесь аналитику придется смотреть на бизнес уже глазами руководителя.

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

Продолжение следует...

Ну а Василий Петрович периодически захаживает домой к ненасытной Елене Афиногеновне, пока ее муж снова "задерживается на совещании".

Все данные выше можно свести в табличку с данными о том, кто кого ебет.

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

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

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

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

Поэтому для ебырей и блядей создаем отдельные таблички.

Это называется вторая нормальная форма.

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

Есть еще Бойс-Кодд нормальная форма (та же третья форма, только более жесткая), где все зависимости должны быть от ключа.

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

Есть еще пятая нормальная форма, где если  Елена Афиногеновна ебется только дома, а Алевтина Сергеевна и дома и в офисе, то это тоже должно быть вынесено в отдельную таблицу кто где ебется.

Но это уже не так важно как первые три формы.

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

А вообще сильно связанные данные типа “Вася ебется с Леной - Лена ебется с Колей и все вместе они учатся в одном ПТУ” - лучше всего хранить в графовой базе. Но об этом как-нибудь в другой раз.

Продолжение следует…

P.S. Все персонажи вымышленные, все совпадения случайны, Кострома - охуенный город.

Есть один секрет, как быстро сделать календарь для любой аналитической системы. Сейчас я вам его открою. Заходите в гугл и забиваете в строку поиска “Мастер календарь для /название вашей аналитической системы/”. После этого тыкаете во вторую, третью или максимум четвертую ссылку, пиздите оттуда код, вставляете его к себе, запускаете и Вуаля! Наш календарь готов! Осталось только соединить его с моделькой прислюнявив даты из календаря к датам покупочек.

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

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

Выглядит конечно уебищно, но зато все видно.

Продолжение следует…

Скопировав эти данные я получил сырой датасет.  Дата, че купил, сколько и за сколько.

Питончиком причесываем данные и приводим в съедобный вид:

И первое что делает аналитик с сырыми данными - изучает их. И поэтому первое что мы разберём - это QA (качество) данных.

Данные проверяются по принципу “КОролевской СОбаке ТОчно ПОхуй на СВОю УНикальность”.

КО - корректность. Проверяем, что в колонке количество у нас числа, а не слово “хуй” например.

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

ТО - точность. Если творожок стоит 63.99 это значит за два творожка я отвалю 127.98, а не 128 рублей. Ясно вам, Округлятели херовы?

ПО - полнота. Забегая вперед скажу, что на творожки за этот год я потратил 26 тысяч рубасов. Сам охуел если честно. Больше всего творожков пришлось на октябрь. Я бы не смог посчитать этого если в данных нет даты или названия продукта.

СВО - своевременность. Данные собрал с 1 декабря прошлого года до 1 декабря нынешнего. На следующий год пересчитаю за полный год. Будет своевременно. И красиво. 

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

В любом случае в больших организациях за качество данных отвечает владелец бизнес-функции (начальник продаж, начальник закупок, начальник логистики и прочие шишки), а в очень больших - Data Quality Engineer. Поэтому если закупщики при создании карточки товара въебут килограммы туда где должны быть граммы и “хз” туда где должны быть сантиметры - то вместо кучи интересной информации бизнес-пользователи получат кучу говна. И это должна быть проблема бизнес-функции, а не аналитика, который по мнению бизнес-пользователей должен всю эту херню вылавливать и причесывать.

Продолжение следует…

P.S. Где тег "Творожок"?

Школа аналитиков данных МТС снова открывает двери. Подать заявку можно до 20 октября, а начать обучение длиной 10 месяцев после успешного отбора — уже 7 ноября. Сегодня — о программе, ее плюшках и тех, кому точно зайдет.

В Школе преподают эксперты из разных продуктов Центра Big Data МТС, которые уже подготовили интенсивную программу. Студентов ждут SQL и Python, ML и Big Data, нейросети и рекомендательные системы, математика и несколько дополнительных тем. Вот такая концентрация пользы!

У Школы аналитиков данных много плюсов, но мы расскажем про 3 основных:

1. Онлайн-обучение. Занятия проходят 2 раза в неделю, теория чередуется с практикой, все записи и полезные материалы доступны в любое время.

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

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

Уже готов подать заявку

Обучение точно зайдет:

• Junior и middle аналитикам данных.

• Айтишникам из смежных областей.

• Студентам последних курсов и выпускникам технических специальностей.

Если ML, Big Data и Data Science вам интересны и у вас есть 6+ свободных часов в неделю — успейте подать заявку до 20 октября!

Хочу подать ее прямо сейчас