Lean Big Data на 6 сервісах Google

    image
 
Здрастуй Хабр! Хочу розповісти як ми робили свою власну Big Data.
 
Кожен стартап хоче зібрати щось дешеве, якісне і гнучке. Зазвичай так не буває, але у нас, схоже, вийшло! Нижче йде опис нашого рішення і багато мого суто суб'єктивної думки з цього приводу.
 
І так, секрет в тому, що використовується 6 сервісів гугла і власного коду майже не писалося.
 
 

Що було потрібно?

Працюю у веселому сінгапурському стартапі — Bubbly, який робить голосову соціальну мережу. Фішка в тому, що можна користуватися без смартфона, досить старої доброї нокії. Користувач дзвонить на спеціальний номер і може прослуховувати повідомлення, записувати свої повідомлення і т.п. Всі голосом, навіть не потрібно вміти читати, щоб користуватися.
 
У Південно-Східній Азії у нас десятки мільйонів користувачів. Але так як працює це через операторів стільникового зв'язку, в інших країнах про нас ніхто нічого не знає. Ці користувачі генерують величезну кількість активності, яку хочеться реєструвати і всіляко аналізувати:
 
     
  • Зробити красивий Деш-борд з ключовими метриками, обновляющимися в он-лайн режимі
  •  
  • Моніторити роботу сервісу і помилки
  •  
  • Робити А \ Б тести і аналізувати поведінку користувачів
  •  
  • Робити звіти для наших партнерів
  •  
  •  
Загалом, завдання, які потрібні всім і завжди практично.
 
 

Навіщо винаходити велосипед?

Здавалося б — навіщо щось будувати, якщо є вже готові рішення? Керували мною такі мотиви:
 
 
1. Не хочу використовувати Mixpanel (сорі Гайс!)
 
     
  • Якщо немає повного контролю над даними, то завжди знайдеться питання, на який чужа готова система відповіді не дає. Так, я знаю, що є Mixpanel export APIs і вони дозволяють багато чого. Але за фактом стільки разів вже натикався на подібні ситуації. Хочеться повного контролю.
  •  
  • Купу усіляких «хотелок» доведеться прикручувати в чужому пропрієтарного продукту, що не дуже зручно. Наприклад, SMS-alert начальнику саппорта, якщо щось поламалося. Або спеціальні звіти стороннім партнерам. І такі фічі все заздалегідь не передбачиш.
  •  
  • Це реально дорого! Я знаю, що багато хто замість всіх даних завантажують туди тільки випадкову вибірку, щоб хоч якось знизити витрати. Але це дуже сумнівне щастя саме по собі.
  •  
 
2. Якщо так хочеться «свого» рішення, чому тоді не замутити Hadoop з усім фаршем?
 Тому що кишка тонка . Це реально складно!
 
 
     
  • Потрібно підняти сервера і все налаштувати. Є звичайно hosted Hadoop, де все вже «налаштоване», але розбиратися з цими настройками все одно доведеться.
  •  
  • Hadoop — це тільки зберігання і запити. Всі інші фічі доведеться робити самому.
  •  
MySQL під завдання зрозуміло не підходить, так як даних у нас для нього занадто багато.
 
 

Коротко як це працює у нас

 
     
  1. Ми заливаємо все «події» від користувачів з наших серверів в Google Big Query
  2.  
  3. Використовуємо Google Spreadsheets для запитів до Big Query і подальшої обробки даних. Вся логіка сидить у Spreadsheets і прив'язаних до нього скриптах.
  4.  
  5. Далі визуализируем отримані дані за допомогою Google Charts.
  6.  
  7. Хостам ці графіки на Google Drive
  8.  
  9. У єдиний «Деш боард» ці графіки збираються в Google Sites
  10.  
  11. І нарешті, поверх Google Sites варто Google Analytics, який дивиться за користувачами всієї цієї аналітики.
  12.  
 

Переваги цього підходу (немає я не піарю Google за гроші, a шкода )

 
Big Query — плюси
 
     
  • Ця база даних може зберігати величезну кількість даних. Питання масштабованості не варто.
  •  
  • Коштує це копійки в порівнянні з іншими рішеннями. Про витрати нижче пишу окремо.
  •  
  • Фактично будь-який запит займає менше 20 секунд. Це сильно відрізняється від Hadoop, де рахунок в кращому випадку на хвилини. Для стандартних, визначених раз і назавжди запитів різниця здається маленькою. Але якщо ти дивишся на дані «у вільному польоті» (ad hoc) або лагодиш щось методом проб і помилок, то навіть невеликі паузи рвуть весь робочий процес і знижують ефективність роботи аналітика в рази. А по житті виходить, що тільки такими завданнями і займаєшся цілий день. Дуже важлива перевага Big Query.
  •  
  • Дрібні плюшки, такі як web-інтерфейс, насправді, сильно допомагають.
  •  
 Покращення:
Дуже хотілося Big Query зробити schemaless, просто щоб додавати події у систему і ні про що не думати. Тому до завантажувача прикрутили шматочок коду, який перевіряє поточну схему таблиці в Big Query і порівнює з тим, що він хоче завантажити. Якщо є нові колонки, то вони додаються в таблицю через Big Query API.
 
 
Google Spreadsheets — плюси
Краще електронних таблиць для аналізу даних немає нічого. Це моя аксіома. Для даної задачі Spreadsheets підходить краще MS Excel (як би я його не любив). Причини такі:
 
     
  • Працює з Big Query з коробки (туториал від Goolge )
  •  
  • Все лежить в хмарі і скрипти можуть оновлювати дані за розкладом
  •  
  • Кросплатформеність! Однаково працює під PC і Mac.
  •  
  • Вже є купа корисних функцій — email і т.п.
  •  
 Покращення:
Cкриптов з туторіал був трохи допрацьований. Тепер він перевіряє кожен лист в електронних таблицях. Якщо в клітці A1 написано «SQL», то значить в А2 лежить запит до Big Query. Результати запиту скрипт покладе на цьому ж аркуші.
 
Це потрібно, щоб при використанні не торкатися коду взагалі. Створив новий лист, написав запит, отримав результат.
 
 image
 
 
Google Charts — плюси
 
     
  • Бібліотек по візуалізації багато, але є відчуття що у Гугла все більш надійно і функціонально (якщо звичайно вони Charts НЕ спишуть як Reader).
  •  
  • Працює з Spreadsheets з коробки (туториал від Google )
  •  
  • Підкупили їх інтерактивні контроли, які дозволяють досить глибоко грати з даними навіть бізнес-людям, які ні SQL, ні Excel не використовують.
  •  
 image
 
 
Google Sites / Google Drive — плюси
 
     
  • Можна користуватися гуглівською проробленою системою прав доступу. У Dropbox не можна дати read-olny доступ, а тут можна.
  •  
  • Google Sites мають wysiwyg-редактор, що мені особисто дуже подобається.
  •  
  • Після того як всю систему побудував на гуглових сервісах, вирішив ними користуватися до кінця з принципу.
  •  
 
Google Analytics
Рекурсія! У нашого Dash Board порядку 30 юзерів. Достатньо для того, щоб аналізувати статистику використання ресурсу. Google Sites, що не дивно, з Google Analytics інтегруються в пару кліків. Відвідуваність сторінок об'єктивно показує, які дані найбільш цікаві, щоб у цьому напрямку покращувати систему.
 
 

Про витрати на вирішення

Вважаю, що в будь-якій системі найдорожче цей час необхідний на розробку і людино-дні витрачені на розробку і підтримку. У цьому сенсі дане рішення ідеально, так як свого коду майже не писалося. Весь проект робила одна людина, в паралель з іншими завданнями, і перша версія була зроблена за місяць.
 
Є, звичайно, підозри, що інтеграція між сервісами Гугла може ламатися (за їх туторіали видно, що це вже траплялося) і потрібні зусилля на підтримку. Але не чекаю нічого страшного.
 
Що стосується прямих витрат, то у всій системі тільки Big Query коштує грошей. Оплачується зберігання даних і запити до даних. Але це просто копійки! Ми пишемо по 60 млн подій на день і жодного разу більше 200 USD на місяць не платили.
  
 

Важлива надбудова до Big Query

Big Query за замовчуванням сканує всю таблицю. Якщо події за весь час зберігати в одному місці, то запити стають повільніше і дорожче з часом.
 
Найбільш цікаві завжди дані за останній час, тому ми прийшли до місячного ротіванію цих таблиць. Кожного місяця таблиця events бекапе в events_201401Jan, events_201402Feb і так далі.
 
Щоб до такої структури зручно було робити запити, розширили трохи мову SQL. Благо все контролює власний скрипт з Spreadsheets, і він може наші запити парсити і обробляти як потрібно. Додав такі команди:
 
     
  • FROMDATASET dataset — запитує по черзі всі таблиці в дата-сеті. Це на випадок, якщо потрібно запросити дані за весь період часу
  •  
  • FROMLAST table — запитує поточну таблицю і таблицю за останній місяць. Це для запитів, яким потрібні дані за останні 7 днів, наприклад. Щоб на початку місяця запит повертав повні 7 днів, а не те що є на поточний місяць.
  •  
 

Плани на майбутнє:

 
     
  • Пиляти скрипт запускає SQL. Хочу щоб він крім FROMLAST вмів всякі корисні трансформації типу PIVOT і т.п.
  •  
  • Пиляти JavaScript для Google Charts. Хочу в ідеалі позбутися необхідності чіпати код взагалі. Щоб як в Excel pivot charts — перемикати одним кліком і тип графіка, і які серії по якій осі, і т.п. Але це глобальні плани.
  •  
  • Хочу поекспериментувати з nested data. Ми можемо на сервері отсортировивать всі події з окремої сесії користувача в одну запис. Тобто події всередині сесії (дзвінка в нашому випадку) будуть «дітьми» цієї сесії. У теорії це повинно спростити деякі заморочені запити.
  •  
 
Як це все працює можна подивитися на прикладі тут .
 
Дуже хочеться, щоб знаючі люди сказали свою думку. Для того ця стаття і писалася.
 
PS Прошу про помилки по тексту і моїх англіцизмів писати в личку, все поправлю.
 
PPS Я зовсім не програміст, тому мій код може бути страшний (але він працює!). Буду радий конструктивній критиці.
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.