Привіт, Хабре! Прямо зараз у OTUS відкрито набір на новий потік курсу . Напередодні старту курсу ми традиційно підготували для вас переклад цікавого матеріалу.
Щодня понад сто мільйонів людей відвідують Twitter, щоб дізнатися, що відбувається у світі, та обговорити це. Кожен твіт та будь-яка інша дія користувача генерують подію, доступну для внутрішнього аналізу даних у Twitter. Сотні співробітників аналізують та візуалізують ці дані, і покращення їхнього досвіду є головним пріоритетом для команди Twitter Data Platform.
Ми вважаємо, що користувачі з широким спектром технічних навичок повинні мати можливість знаходити дані та мати доступ до добре працюючих інструментів аналізу та візуалізації на основі SQL. Це дозволило б цілій новій групі користувачів з меншим технічним ухилом, включаючи дату аналітиків та продакт менеджерів, витягувати інформацію з даних, дозволяючи їм краще розуміти та використовувати можливості Twitter. Так ми демократизуємо аналіз даних у Twitter.
У міру вдосконалення наших інструментів та можливостей для внутрішнього аналізу даних ми стали свідками покращення сервісу Twitter. Тим не менш, є ще куди рости. Поточні інструменти, такі як Scalding, потребують досвіду програмування. Інструменти аналізу на основі SQL, такі як Presto та Vertica, мають проблеми з продуктивністю у великому масштабі. У нас також є проблема з поширенням даних щодо кількох систем без постійного доступу до них.
Минулого року ми оголосили про , у межах якого переносимо частини нашої Google Cloud Platform (GCP). Ми дійшли висновку, що інструменти Google Cloud можуть допомогти нам у наших ініціативах з демократизації аналізу, візуалізації та машинного навчання у Twitter:
- : сховище корпоративних даних із SQL движком на основі , який славиться швидкістю, простотою і справляється з .
- інструмент для візуалізації великих даних із функціями спільної роботи, як у Google Docs.
З цієї статті ви дізнаєтеся про наш досвід роботи з цими інструментами: що ми зробили, чого навчилися і що робитимемо далі. Зараз ми зосередимося на пакетній та інтерактивній аналітиці. Аналітику у реальному часі ми обговоримо у наступній статті.
Історія сховищ даних у Twitter
Перед тим, як заглиблюватися в BigQuery, варто коротко переказати історію сховищ даних у Twitter. У 2011 році аналіз даних у Twitter проводився у Vertica та Hadoop. Для створення MapReduce робіт Hadoop ми використали Pig. У 2012 році ми замінили Pig на Scalding, який мав Scala API з такими перевагами, як можливість створювати складні конвеєри та простота тестування. Тим не менш, для багатьох дата аналітиків і продакт менеджерів, яким було комфортніше працювати з SQL, це була досить крута крива навчання. Приблизно в 2016 році ми почали використовувати Presto як SQL інтерфейс для даних Hadoop. Spark пропонував Python інтерфейс, який робить його гарним вибором для ad hoc досліджень даних та машинного навчання.
Починаючи з 2018 року, ми використовували наступні інструменти для аналізу та візуалізації даних:
- Scalding для виробничих конвеєрів
- Scalding та Spark для ad hoc аналізу даних та машинного навчання
- Vertica та Presto для ad hoc та інтерактивного SQL аналізу
- Druid для малої інтерактивного, дослідницького та доступу з малою затримкою до метриків часових рядів
- Tableau, Zeppelin та Pivot для візуалізації даних
Ми виявили, що, хоча ці інструменти пропонують дуже потужні можливості, ми мали труднощі в реалізації доступності цих можливостей для більш широкої аудиторії в Twitter. Розширюючи нашу платформу за допомогою Google Cloud, ми зосереджуємося на спрощенні наших аналітичних інструментів для всього Twitter.
Сховище даних BigQuery від Google
Декілька команд у Twitter вже включили BigQuery до деяких зі своїх виробничих конвеєрів. Використовуючи їхній досвід, ми почали оцінювати можливості BigQuery для всіх сценаріїв використання Twitter. Нашою метою було запропонувати BigQuery всій компанії, а також стандартизувати та підтримувати її в рамках набору інструментів Data Platform. Це було важко з багатьох причин. Нам необхідно було розробити інфраструктуру для надійного прийому великих обсягів даних, підтримки управління даними в масштабах усієї компанії, забезпечення належного контролю доступу та забезпечення конфіденційності клієнтів. Нам також довелося створювати системи для розподілу ресурсів, моніторингу та повернення платежів, щоб команди могли ефективно використовувати BigQuery.
У листопаді 2018 року ми випустили альфа-реліз BigQuery та Data Studio для всієї компанії. Ми запропонували співробітникам Twitter деякі з наших таблиць, що найбільш часто використовуються, з очищеними персональними даними. BigQuery використовували понад 250 користувачів з різних команд, включаючи інженерні, фінансові та маркетингові. Зовсім недавно вони виконували близько 8 тис. запитів, обробляючи близько 100 ПБ на місяць, не рахуючи запланованих запитів. Отримавши позитивні відгуки, ми вирішили рухатися вперед і запропонувати BigQuery як основний ресурс для взаємодії з даними в Twitter.
Ось схема високорівневої архітектури нашого сховища даних Google BigQuery.
Ми копіюємо дані з локальних кластерів Hadoop у Google Cloud Storage (GCS), використовуючи внутрішній інструмент Cloud Replicator. Потім ми використовуємо Apache Airflow для створення конвеєрів, які використовують» для завантаження даних із GCS у BigQuery. Ми використовуємо Presto для запиту наборів даних Parquet або Thrift-LZO у GCS. BQ Blaster – це внутрішній інструмент Scalding для завантаження наборів даних HDFS Vertica та Thrift-LZO у BigQuery.
У наступних розділах ми обговоримо наш підхід та знання в галузі простоти використання, продуктивності, управління даними, працездатності системи та вартості.
Простота використання
Ми виявили, що користувачам було легко починати з BigQuery, оскільки він не вимагав встановлення програмного забезпечення і користувачі могли отримувати доступ через інтуїтивно зрозумілий веб-інтерфейс. Проте користувачам необхідно було ознайомитися з деякими функціями GCP та його концепціями, включаючи такі ресурси, як проекти, набори даних та таблиці. Ми розробили навчальні матеріали та туторіали, щоб допомогти користувачам розпочати роботу. З придбанням базового розуміння користувачам стало легко переміщатися наборами даних, переглядати схему та дані таблиць, виконувати прості запити та візуалізувати результати в Data Studio.
Наша мета щодо введення даних у BigQuery полягала в тому, щоб забезпечити плавне завантаження наборів даних HDFS або GCS одним клацанням миші. Ми розглядали (Керований Airflow), але не змогли його використовувати через нашу модель безпеки «Domain Restricted Sharing» (докладніше про це в розділі «Управління даними» нижче). Ми експериментували з використанням Google Data Transfer Service (DTS) для організації навантажувальних завдань BigQuery. В той час, як DTS швидко налаштовувався, він не був гнучким для побудови конвеєрів із залежностями. Для нашої альфа версії ми створили власне середовище Apache Airflow у GCE і готуємо його до роботи в продакшені та можливості підтримувати більше джерел даних, таких як Vertica.
Для перетворення даних на BigQuery користувачі створюють прості конвеєри даних SQL, використовуючи заплановані запити. Для складних багатоступеневих конвеєрів із залежностями ми плануємо використовувати або нашу власну інфраструктуру Airflow, або Cloud Composer разом із .
Продуктивність
BigQuery створений для SQL запитів загального призначення, які обробляють великі обсяги даних. Він не призначений для запитів з низькою затримкою, високою пропускною здатністю, необхідних для транзакційної бази даних, або для аналізу тимчасових рядів з низькою затримкою, реалізованого . Для інтерактивних аналітичних запитів наші користувачі чекають на час відгуку менше однієї хвилини. Ми повинні були спроектувати використання BigQuery таким чином, щоб відповідати цим очікуванням. Щоб забезпечити передбачувану продуктивність наших користувачів, ми використовували функціонал BigQuery, доступний для клієнтів на фіксованій оплаті, яка дозволяє власникам проектів резервувати мінімальні слоти для своїх запитів. BigQuery — це одиниця обчислювальної потужності, яка потрібна на виконання SQL запитів.
Ми проаналізували понад 800 запитів, що обробляють близько 1 ТБ даних кожен, і виявили, що середній час виконання становив 30 секунд. Ми також дізналися, що продуктивність залежить від використання нашого слота в різних проектах і завданнях. Ми повинні були чітко розмежувати наші виробничі та ad hoc резерви слотів, щоб підтримувати продуктивність для виробничих сценаріїв використання та інтерактивного аналізу. Це дуже вплинуло на наш дизайн для резервування слотів та ієрархії проектів.
Про управління даними, функціональність та вартість систем, поговоримо вже найближчими днями у другій частині перекладу, а зараз запрошуємо всіх бажаючих на , в рамках якого можна буде детально дізнатися про курс, а також поставити запитання нашому експерту - Єгор Матешук (Senior Data Engineer, MaximaTelecom).
Читати ще:
Джерело: habr.com