Како BigQuery на Google ја демократизираше анализата на податоците. Дел 1

Здраво, Хабр! Уписот за нов тек на курсеви е отворен во моментов на OTUS Инженер за податоци. Во пресрет на почетокот на курсот, традиционално ви подготвивме превод на интересен материјал.

Секој ден, повеќе од сто милиони луѓе го посетуваат Твитер за да дознаат што се случува во светот и да разговараат за тоа. Секој твит и секое друго корисничко дејство генерира настан кој е достапен за внатрешна анализа на податоците на Twitter. Стотици вработени ги анализираат и визуелизираат овие податоци, а подобрувањето на нивното искуство е главен приоритет за тимот на Twitter Data Platform.

Сметаме дека корисниците со широк опсег на технички вештини треба да бидат способни да откриваат податоци и да имаат пристап до алатките за анализа и визуелизација засновани на SQL кои работат добро. Ова ќе и овозможи на цела нова група на помалку технички корисници, вклучувајќи аналитичари на податоци и менаџери на производи, да извлечат увид од податоците, овозможувајќи им подобро да ги разберат и користат можностите на Twitter. Вака ја демократизираме анализата на податоци на Твитер.

Како што се подобрија нашите алатки и способности за внатрешна анализа на податоци, видовме подобрување на Twitter. Сепак, се уште има простор за подобрување. Тековните алатки како Scalding бараат програмско искуство. Алатките за анализа базирани на SQL, како што се Presto и Vertica, имаат проблеми со перформансите на ниво. Имаме и проблем со дистрибуција на податоци низ повеќе системи без постојан пристап до нив.

Минатата година објавивме нова соработка со Google, во чии рамки пренесуваме делови од нашите инфраструктура на податоци на Google Cloud Platform (GCP). Заклучивме дека алатките на Google Cloud Биг податоци може да ни помогне со нашите иницијативи за демократизирање на аналитиката, визуелизацијата и машинското учење на Твитер:

• големо прашање: складиште на податоци за претпријатие со SQL мотор базиран Dremel, кој е познат по својата брзина, едноставност и се справува со машинско учење.
• Data Studio: алатка за визуелизација на големи податоци со функции за соработка слични на Google Docs.

Во оваа статија, ќе научите за нашето искуство со овие алатки: што направивме, што научивме и што ќе правиме понатаму. Сега ќе се фокусираме на серија и интерактивна аналитика. Ќе разговараме за аналитика во реално време во следната статија.

Историја на Твитер продавници за податоци

Пред да се нурне во BigQuery, вреди накратко да се раскаже историјата на складирањето податоци на Twitter. Во 2011 година беше извршена анализа на податоците на Твитер во Вертика и Хадуп. Го користевме Pig за да креираме работни места за MapReduce Hadoop. Во 2012 година, го заменивме Pig со Scalding, кој имаше Scala API со предности како што се способноста за создавање сложени цевководи и леснотија на тестирање. Сепак, за многу аналитичари на податоци и менаџери на производи на кои им беше поудобно да работат со SQL, тоа беше прилично стрмна крива на учење. Околу 2016 година, почнавме да користиме Presto како SQL интерфејс за податоците на Hadoop. Spark понуди интерфејс Python, што го прави добар избор за ад хок наука за податоци и машинско учење.

Од 2018 година, ги користиме следниве алатки за анализа и визуелизација на податоците:

• Варење за производствени транспортери
• Scalding и Spark за ад хок анализа на податоци и машинско учење
• Вертика и Престо за ад хок и интерактивна SQL анализа
• Друид за низок интерактивен, истражувачки и ниско латентен пристап до метрика на временски серии
• Tableau, Zeppelin и Pivot за визуелизација на податоци

Откривме дека иако овие алатки нудат многу моќни способности, имавме потешкотии да ги направиме овие способности достапни за пошироката публика на Твитер. Со проширување на нашата платформа со Google Cloud, ние се фокусираме на поедноставување на нашите аналитички алатки за целиот Твитер.

Магацин на податоци BigQuery на Google

Неколку тимови на Twitter веќе го вградија BigQuery во некои од нивните производствени цевководи. Користејќи ја нивната експертиза, почнавме да ги оценуваме можностите на BigQuery за сите случаи на употреба на Twitter. Нашата цел беше да го понудиме BigQuery на целата компанија и да го стандардизираме и поддржиме во рамките на сетот алатки на платформата за податоци. Ова беше тешко од многу причини. Требаше да развиеме инфраструктура за доверливо внесување на големи количини на податоци, да го поддржиме управувањето со податоци во целата компанија, да обезбедиме правилна контрола на пристапот и да обезбедиме приватност на клиентите. Исто така, моравме да создадеме системи за распределба на ресурси, следење и враќање на трошоците за тимовите да можат ефективно да го користат BigQuery.

Во ноември 2018 година, објавивме алфа издание на BigQuery и Data Studio за целата компанија. На вработените во Twitter им понудивме некои од нашите најчесто користени табели со исчистени лични податоци. BigQuery е користен од над 250 корисници од различни тимови, вклучувајќи инженерство, финансии и маркетинг. Неодамна, тие извршуваа околу 8 илјади барања, обработувајќи околу 100 PB месечно, не сметајќи ги закажаните барања. Откако добивме многу позитивни повратни информации, решивме да продолжиме напред и да го понудиме BigQuery како примарен ресурс за интеракција со податоци на Twitter.

Еве дијаграм на високо ниво на нашата архитектура на складиште за податоци на Google BigQuery.

Ние ги копираме податоците од кластерите на Hadoop во просториите во Google Cloud Storage (GCS) користејќи ја внатрешната алатка Cloud Replicator. Потоа користиме Apache Airflow за да создадеме цевководи кои користат "bq_load» за да се вчитаат податоци од GCS во BigQuery. Ние користиме Presto за да побараме сетови на податоци за Parquet или Thrift-LZO во GCS. BQ Blaster е внатрешна алатка Scalding за вчитување на сетови на податоци HDFS Vertica и Thrift-LZO во BigQuery.

Во следните делови, ќе разговараме за нашиот пристап и експертиза во областа на леснотијата на користење, перформансите, управувањето со податоци, здравјето на системот и трошоците.

Леснотија на користење

Откривме дека на корисниците им беше лесно да започнат со BigQuery бидејќи не бараше инсталација на софтвер и корисниците можеа да пристапат до него преку интуитивен веб-интерфејс. Сепак, корисниците требаше да се запознаат со некои од карактеристиките и концептите на GCP, вклучувајќи ресурси како што се проекти, сетови на податоци и табели. Развивме едукативни материјали и упатства за да им помогнеме на корисниците да започнат. Со стекнатото основно разбирање, на корисниците им беше лесно да се движат низ збирките на податоци, да гледаат податоци од шема и табели, да извршуваат едноставни прашања и да ги визуелизираат резултатите во Data Studio.

Нашата цел за внесување податоци во BigQuery беше да овозможиме непречено вчитување на сетови на податоци HDFS или GCS со еден клик. Размислувавме Облак композитор (управуван од Airflow), но не можевме да го користиме поради нашиот безбедносен модел за споделување со ограничен домен (повеќе за ова во делот за управување со податоци подолу). Експериментиравме со користење на услугата за пренос на податоци на Google (DTS) за оркестрирање на оптоварувањата на BigQuery. Додека DTS брзо се поставуваше, тој не беше флексибилен за изградба на цевководи со зависности. За нашето издание на алфа, изградивме сопствена рамка Apache Airflow во GCE и ја подготвуваме да работи во производство и да може да поддржува повеќе извори на податоци како што е Vertica.

За да ги трансформираат податоците во BigQuery, корисниците создаваат едноставни SQL податочни цевки користејќи закажани барања. За сложени повеќестепени цевководи со зависности, планираме да користиме или сопствена рамка за проток на воздух или Cloud Composer заедно со Облак на проток на податоци.

Перформанси

BigQuery е дизајниран за SQL барања за општа намена кои обработуваат големи количини на податоци. Не е наменет за прашања со ниска латентност, висока пропусност што ги бара трансакциската база на податоци или за имплементирана анализа на временски серии со ниска латентност Апачи друид. За интерактивни аналитички прашања, нашите корисници очекуваат време на одговор помалку од една минута. Моравме да ја дизајнираме нашата употреба на BigQuery за да ги исполниме овие очекувања. За да обезбедиме предвидливи перформанси за нашите корисници, ја искористивме функционалноста на BigQuery, достапна за клиентите со рамна такса што им овозможува на сопствениците на проектите да резервираат минимални слотови за нивните прашања. Процеп BigQuery е единица на компјутерска моќ потребна за извршување на SQL барања.

Анализиравме над 800 барања кои обработуваат приближно 1 ТБ податоци и откривме дека просечното време на извршување е 30 секунди. Научивме и дека перформансите многу зависат од употребата на нашиот слот во различни проекти и задачи. Моравме јасно да ги разграничиме нашите резерви на производство и ад хок слот за да ги одржиме перформансите за случаи на употреба во производството и анализа на интернет. Ова во голема мера влијаеше на нашиот дизајн за резервации на слот и хиерархија на проекти.

Ќе зборуваме за управување со податоци, функционалност и цена на системите во наредните денови во вториот дел од преводот, но сега ги покануваме сите да бесплатен вебинар во живо, при што ќе можете детално да научите за курсот, како и да поставувате прашања до нашиот експерт - Егор Матешук (виш инженер за податоци, MaximaTelecom).

Прочитај повеќе:

• Алатка за градење податоци или она што е заедничко помеѓу Data Warehouse и Smoothie
• Нурнете во езерото Делта: Спроведување на шема и еволуција
• Апачи паркет со голема брзина во Пајтон со Apache Arrow

Извор: www.habr.com