Прывітанне, Хабр! Прама цяпер у 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 разам з .
Proizvoditelnost
BigQuery створаны для запытаў SQL агульнага прызначэння, якія апрацоўваюць вялікія аб'ёмы дадзеных. Ён не прызначаны для запытаў з нізкай затрымкай, высокай прапускной здольнасцю, неабходных для транзакцыйнай базы дадзеных, або для аналізу часовых шэрагаў з нізкай затрымкай, рэалізаванага . Для інтэрактыўных аналітычных запытаў нашы карыстальнікі чакаюць часу водгуку менш за адну хвіліну. Мы павінны былі спраектаваць выкарыстанне BigQuery такім чынам, каб адпавядаць гэтым чаканням. Каб забяспечыць прадказальную прадукцыйнасць для нашых карыстальнікаў, мы выкарыстоўвалі функцыянал BigQuery, даступны для кліентаў на фіксаванай аплаце, якая дазваляе ўладальнікам праектаў рэзерваваць мінімальныя слоты для сваіх запытаў. BigQuery - гэта адзінка вылічальнай магутнасці, неабходнай для выканання SQL запытаў.
Мы прааналізавалі больш за 800 запытаў, якія апрацоўваюць каля 1 ТБ дадзеных кожны, і выявілі, што сярэдні час выканання склаў 30 секунд. Мы таксама даведаліся, што прадукцыйнасць моцна залежыць ад выкарыстання нашага слота ў розных праектах і задачах. Мы павінны былі дакладна размежаваць нашы вытворчыя і ad hoc рэзервы слотаў, каб падтрымліваць прадукцыйнасць для вытворчых сцэнарыяў выкарыстання і інтэрактыўнага аналізу. Гэта вельмі моцна паўплывала на наш дызайн для рэзервавання слотаў і іерархіі праектаў.
Пра кіраванне дадзенымі, функцыянальнасць і кошт сістэм, пагаворым ужо ў бліжэйшыя дні ў другой частцы перакладу, а зараз запрашаем усіх жадаючых на , у рамках якога можна будзе падрабязна даведацца пра курс, а таксама задаць пытанні нашаму эксперту – Ягору Мацешуку (Senior Data Engineer, MaximaTelecom).
Чытаць яшчэ:
Крыніца: habr.com