Мене звуть Джеймс Роуен, я молодший студент, який вивчає математику в MIT. Мені довелося провести літо, працюючи стажером у команді аналітики в edX, зосереджуючись на конвеєр даних. Команда аналітики надає дані та показники для використання групами курсів, дослідниками та внутрішніми командами edX. Моя робота цього літа була зосереджена на вдосконаленні нашого сховища даних, бази даних HP Vertica, яка використовується для створення внутрішніх звітів для маркетингових і виконавчих команд.
Розширення сховища даних
Мій перший проект було додати інформацію про предметні області курсу до сховища даних. Хоча початкова схема сховища дозволяла аналітикам запитувати показники реєстрації та активності для кожного курсу, не було можливості агрегувати та порівнювати курси за предметною областю. Наявність у сховищі інформації про предметну галузь курсу дасть змогу маркетинговій команді побачити, які предметні галузі мають найвищий рівень перевірених сертифікатів, наприклад, тоді як інші аналітики зможуть запитати про моделі залучення за предметною галуззю (чи курси математики мають тенденцію бачити багато учнів намагаються вирішити проблеми, тоді як гуманітарні курси частіше використовують дискусійні форуми?).
Щоб виконати це завдання, мені спочатку потрібно було дізнатися про Луїджі, інфраструктура обробки даних, яку використовує конвеєр open edX. Luigi — це платформа обробки даних Python з відкритим кодом, розроблена Spotify, яка розбиває робочі процеси обробки даних на серії завдань, кожне з яких має власний результат, щоб спростити обробку залежностей і робочі процеси можна було перезапустити після невдачі проміжних кроків. Ця властивість Луїджі змушує нас прагнути до максимально модульних робочих процесів.
Робочий процес предметних областей курсу складається з трьох частин:
- Телефонуйте API каталогу курсів, який містить перелік усіх курсів, які продаються на сайті, а також інформацію про їх предмет(и), інструкторів і тривалість.
- Проаналізуйте вихід API у файл із значеннями, розділеними табуляцією, де кожен рядок містить ідентифікатор курсу, предметну область курсу та деяку додаткову інформацію.
- Завантажте дані цієї предметної області в базу даних Vertica.
Три окремі фази цього процесу, які я визначив вище, природно трансформувалися в завдання Луїджі, і перші дві були досить простими для написання. Третє було цікавіше. Хоча Луїджі має попередньо створені завдання для завантаження в бази даних MySQL, попередньо створеного завдання завантаження Vertica не було, тому мені спочатку довелося створити загальне завдання Luigi для масового завантаження Vertica. Цей загальний масовий завантажувач використовувався іншими членами команди протягом літа, і мені було приємно мати цю частину конвеєра, яка забезпечить інфраструктуру для майбутніх робочих процесів для подальшого розширення нашого внутрішнього сховища аналітики.
На наступному графіку показано приклад запитання, на яке аналітики тепер можуть відповісти завдяки цьому проекту. Він показує, який відсоток учнів, активних на курсах на edx.org, були активними на курсах певних предметних областей. Восени 2014 року близько десяти відсотків активних учнів відвідували курси з інформатики, бізнесу, аналізу даних і гуманітарних наук. Однак у 2015 році набагато більша частка активних учнів на курсах на edx.org брала участь у курсах інформатики. У червні 2015 року майже половина всіх активних учнів на edx.org були активними в курсі інформатики! Інші три предметні області також відзначили зростання популярності серед активних користувачів, підвищившись до двадцяти відсотків кожна.
Після проекту предметних областей я працював над експериментальною функцією для аналітики продуктів. Уся взаємодія користувача з платформою, від відтворення відео до спроб проблем до редагування профілів користувачів, реєструється для аналізу. Якщо нова функція додається та починає видавати події, команда продукту може захотіти знати, як часто вона використовується, або чи спостерігає непропорційно велике використання в настільних браузерах (що свідчить про проблему з мобільною сумісністю). Замість того, щоб чекати, доки аналітична команда побудує конвеєрний робочий процес для агрегування інформації журналу відстеження про нову функцію, продукт та інші команди повинні мати можливість проводити попередній аналіз журналів подій самостійно.
Складність прямого запиту журналів подій полягає в тому, що журнали подій напівструктуровані та зберігаються у форматі JSON. Оскільки різні типи подій мають різні атрибути, було б незручно намагатися створити єдину схему таблиці для подій; замість цього я скористався Гнучкі столи Vertica і вибрав схему таблиці, яка має матеріалізовані стовпці (стовпці таблиці SQL першого класу) для полів, спільних для всіх або майже всіх подій (таких як ім’я користувача, позначка часу та тип пристрою користувача), але все ще дозволяє користувачам запитувати поля, пов’язані з подіями (наприклад, до якої позначки часу у відео хтось переходить). Хоча ми не впевнені, чи буде це наша основа для аналітики продуктів у майбутньому, це допомогло нам вивчити можливості нашого складу.
Інтеграція обробки даних BI в конвеєр
Коли я почав працювати в edX цього літа, у нас було фактично два окремих конвеєри: один для даних для викладачів, які використовуються в Insights (Відкрийте панель аналітики edX) і інший для нашої внутрішньої бізнес-аналітики (BI). Конвеєр для зовнішніх даних написаний мовою Luigi та містить пакетні завдання Hadoop для заповнення сховища результатів для API даних, тоді як конвеєр для внутрішньої звітності використовує Pentaho Data Integration для отримання даних із LMS і сховища результатів, їх трансформації та завантаження в сховище. Конвеєр BI залежав від деяких результатів основного конвеєра, але не міг повідомити йому ці залежності, що змушувало команду ретельно визначати час виконання завдань на нашому сервері збірки Дженкінса та не використовувало Луїджі для обробки залежностей. .
Стара архітектура конвеєра аналітики з двома непересічними шляхами потоку даних.
Мені було доручено зменшити технічний борг, пов’язаний із обслуговуванням двох систем початок переходу задач Пентахо в задачі Луїджі. На додаток до очевидних переваг переходу на єдину структуру обробки даних, ця ініціатива також відкриває шлях для подальшого вдосконалення сховища даних. Оскільки в цій новій архітектурі всі записи в сховище виконуються через конвеєр, нові завдання обробки даних (наприклад, завдання з предметних областей мого курсу вище) зможуть записувати в сховище без необхідності вручну планувати завантаження даних Pentaho кроки. Уніфікований процес обробки даних також спростить перевірку даних; завдання перевірки даних можна вбудувати в етапи обробки, просто додавши завдання Луїджі в уніфікований конвеєр.
Архітектура внутрішньої аналітики (BI) після відставки Pentaho завершена.
Цей проект дозволив мені працювати з усім технологічним набором трубопроводу. Я отримав можливість писати завдання, взаємодіючи з базами даних MySQL LMS, журналами відстеження подій, сховищем проміжних результатів Apache Hive і готовим сховищем продуктів даних Vertica, і це було гарним завершенням використання навичок, які я набув протягом курс літа.
Висновок
Мені було приємно отримати можливість працювати в edX цього літа. Це стажування навчило мене низці технічних навичок (фреймворк Луїджі, парадигма MapReduce, SQL, git), а участь у команді аналітика також дало мені змогу отримати безпосередній досвід розробки архітектур обробки даних, обслуговування великих кодових баз, і цикл розробки програмного забезпечення та продуктів даних. Навчитися працювати в контексті гнучкої команди також є широко застосовною навичкою, і це спонукало мене більш усвідомлено думати про групову динаміку та управління проектами у неробочому середовищі.
Я хотів би подякувати Джону Бейкеру, Гейбу Маллі та Браяну Вілсону за допомогу у вирішенні технічних запитань, решті аналітичної команди за створення чудового робочого середовища та всім іншим в edX за те, що зробили це літо веселим.
