Qlik Sense в FutureToday — опыт работы с API SurveyMonkey

by Андрей Белобородов
Qlik Sense в FutureToday — опыт работы с API SurveyMonkey

Всем привет! Сегодня я поделюсь с вами своим опытом разработки аналитического приложения на базе Qlik Sense Cloud для компании FutureToday.

Одним из её направлений, является сбор и анализ данных о карьерных предпочтениях студентов из разных городов и ВУЗов по всей России. Компания проводит опросы тысяч студентов, а затем анализирует их ответы.

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

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

Далее (в отдельной статье) мы рассмотрим способ настройки REST-подключения к API SurveyMonkey и произведем тестовую выгрузку в Qlik Sense.

Предыстория

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

Грабли номер 1 — выгрузка в Excel

С самого начала мы хотели выгружать данные встроенными в SurveyMonkey средствами экспорта в Excel.

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

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


Грабли номер 2 — SurveyMonkey Connector

После первой неудачной попытки, мы начали делать тоже самое, что делает любой человек на стадии «само собой как-то не получилось» — гуглить.

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

— Должен же быть способ попроще, — подумали мы.

И такой (черт его побери) способ действительно нашелся! Мы внезапно вспомнили, что работаем через Qlik Sense Cloud, а там, оказывается, есть специальный SurveyMonkey коннектор, который всю настройку REST-подключения делает за вас.

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

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

На то, чтобы это понять, у нас ушел почти месяц! Расстройству не было предела...

— Видимо, все-таки придется заморочиться, — подытожил я.


Грабли номер 3 — Лимит API запросов (это когда-нибудь закончится вообще?)

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

А нас при этом отбросило в самое начало проекта. Да еще и с самой сложной задачей напоследок — разбираться с этим API, с их структурой хранения данных, ключевыми полями и особенностью работы с запросами. Короче, вот это вот все, на что обычно выделяют до 30% проектного времени...

Чтобы не впасть в депрессию и не выбросить свой ноутбук в окно, я решил думать как Фридрих Ницше: «То, что нас не убивает, делает нас сильнее».

Вот вам его назидательный фото-портрет:


Спустя пару дней, мы разобрались со всеми прелестями настройки REST-соединения, получили наш «Authorization Token», выучили такие понятия как «End-point», «URL-header», «Pagination», и начали выгружать данные.

Все бы хорошо, но...

— Рано радуетесь, товарищи, — сказало ограничение по количеству запросов в день через API.

Да, добро пожаловать обратно на землю, оказывается тут нас поджидала третья грабля: вы не можете бесплатно делать больше чем 500 запросов в день через API, а нам надо было выгрузить 5 миллионов строк, не более тысячи строк в одном запросе.

На решение этого вопроса ушла ещё неделя. Мы написали в поддержку SurveyMonkey письмо с просьбой расширить лимит запросов на небольшой срок.

И случилось чудо! Они согласились расширить лимит до 4000 тысяч запросов в день на 2 недели! Супер!


Грабли номер 4 — Чистота данных...

Есть некий предел, после которого выдержка, самообладание перестают быть добродетелью. (Эдмунд Бёрк)

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

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

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

После того, как мы выслали заказчику все возможные варианты комбинаций ВУЗ - Факультет, оказалось, что каким-то чудом в МГТУ им. Баумана появился Химический факультет. И это явно не единственный случай.

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

Перелопатив все скрипты, мы не обнаружили ошибок ни на этапе трансформации, ни на этапе сборки модели данных.

— Не может же быть, что ошибка в исходных данных? — яростно негодовали мы.

— Может! — опять развеяли наши светлые надежды разработчики из SurveyMonkey.

Изучив тщательно случаи с неправильным сопоставлением ВУЗ - Факультет, мы нашли конкретного респондента с такой ошибкой.

В исходных данных у него на один вопрос «В каком ВУЗе вы обучаетесь?», выбрано два варианта ответа. Причем в последующих вопросах задвоений нет.

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

К счастью, таких случаев оказалось не более 1% на весь массив данных. М�� написали специальный обработчик, который полностью исключал из выборки ошибочные анкеты.




На сегодня это все!

Спасибо за внимание, надеюсь статья окажется кому-то полезной :)

Не отходя от кассы, читайте продолжение: Настройка REST-подключения к API SurveyMonkey

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

Если у вас есть вопросы или предложения, не стесняйтесь и пишите мне на почту: me@andbel.it

January 29, 2019
by Андрей Белобородов
Qlik
Разработка
Лучшие практики