Как BigQuery на Google демократизира анализа на данни. Част 1

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

Всеки ден повече от сто милиона души посещават Twitter, за да разберат какво се случва по света и да го обсъдят. Всеки туит и всяко друго потребителско действие генерира събитие, което е достъпно за вътрешния анализ на данните на Twitter. Стотици служители анализират и визуализират тези данни и подобряването на техния опит е основен приоритет за екипа на Twitter Data Platform.

Вярваме, че потребителите с широк набор от технически умения трябва да могат да откриват данни и да имат достъп до добре работещи инструменти за анализ и визуализация, базирани на SQL. Това би позволило на цяла нова група от по-малко технически потребители, включително анализатори на данни и продуктови мениджъри, да извличат прозрения от данните, позволявайки им да разберат и използват по-добре възможностите на Twitter. Ето как демократизираме анализа на данни в Twitter.

Тъй като нашите инструменти и възможности за вътрешен анализ на данни се подобриха, ние видяхме подобрение на Twitter. Все още обаче има място за подобрение. Настоящите инструменти като Scalding изискват опит в програмирането. Базираните на SQL инструменти за анализ като Presto и Vertica имат проблеми с производителността в мащаб. Също така имаме проблем с разпространението на данни в множество системи без постоянен достъп до тях.

Миналата година обявихме ново сътрудничество с Google, в рамките на който прехвърляме части от нашите инфраструктура за данни на Google Cloud Platform (GCP). Стигнахме до заключението, че инструментите на Google Cloud Голямо количество от данни може да ни помогне с нашите инициативи за демократизиране на анализа, визуализацията и машинното обучение в Twitter:

• BigQuery: корпоративно хранилище за данни с базиран на SQL двигател Dremel, който се слави със своята бързина, простота и се справя с машинно обучение.
• Студио за данни: инструмент за визуализация на големи данни с подобни на Google Документи функции за сътрудничество.

В тази статия ще научите за нашия опит с тези инструменти: какво направихме, какво научихме и какво ще направим след това. Сега ще се съсредоточим върху пакетния и интерактивен анализ. Ще обсъдим анализите в реално време в следващата статия.

История на хранилищата за данни в Twitter

Преди да се потопите в BigQuery, си струва да разкажем накратко историята на складирането на данни в Twitter. През 2011 г. анализът на данните от Twitter беше извършен във Vertica и Hadoop. Използвахме Pig, за да създадем MapReduce Hadoop задания. През 2012 г. заменихме Pig с Scalding, който имаше Scala API с предимства като възможността за създаване на сложни конвейери и лекота на тестване. Въпреки това, за много анализатори на данни и продуктови мениджъри, които се чувстваха по-удобно да работят със SQL, това беше доста стръмна крива на обучение. Около 2016 г. започнахме да използваме Presto като SQL интерфейс към данни на Hadoop. Spark предложи интерфейс на Python, което го прави добър избор за ad hoc наука за данни и машинно обучение.

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

• Попарване за производствени конвейери
• Scalding и Spark за ad hoc анализ на данни и машинно обучение
• Vertica и Presto за ad hoc и интерактивен SQL анализ
• Druid за ниско интерактивен, проучвателен и ниско забавяне достъп до показатели за времеви серии
• Tableau, Zeppelin и Pivot за визуализация на данни

Установихме, че докато тези инструменти предлагат много мощни възможности, имахме трудности да направим тези възможности достъпни за по-широка аудитория в Twitter. Като разширяваме нашата платформа с Google Cloud, ние се фокусираме върху опростяването на нашите инструменти за анализ за целия Twitter.

BigQuery Data Warehouse на Google

Няколко екипа в Twitter вече са включили BigQuery в някои от своите производствени линии. Използвайки техния опит, ние започнахме да оценяваме възможностите на BigQuery за всички случаи на използване на Twitter. Нашата цел беше да предложим BigQuery на цялата компания и да го стандартизираме и поддържаме в рамките на набора от инструменти на Data Platform. Това беше трудно по много причини. Трябваше да разработим инфраструктура за надеждно поглъщане на големи обеми данни, да поддържаме управлението на данни в цялата компания, да осигурим подходящ контрол на достъпа и да гарантираме поверителността на клиентите. Също така трябваше да създадем системи за разпределение на ресурси, мониторинг и връщане на плащания, така че екипите да могат да използват BigQuery ефективно.

През ноември 2018 г. пуснахме алфа версия за цялата компания на BigQuery и Data Studio. Предложихме на служителите на Twitter някои от нашите най-често използвани електронни таблици с изчистени лични данни. BigQuery е използван от над 250 потребители от различни екипи, включително инженеринг, финанси и маркетинг. Съвсем наскоро те изпълняваха около 8k заявки, обработвайки около 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 е вътрешен инструмент за изгаряне за зареждане на набори от данни HDFS Vertica и Thrift-LZO в BigQuery.

В следващите раздели обсъждаме нашия подход и опит в областите на лесна употреба, производителност, управление на данни, изправност на системата и цена.

Лесна употреба

Установихме, че е лесно за потребителите да започнат работа с BigQuery, защото не изисква инсталиране на софтуер и потребителите могат да имат достъп до него чрез интуитивен уеб интерфейс. Потребителите обаче трябваше да се запознаят с някои от функциите и концепциите на GCP, включително ресурси като проекти, набори от данни и таблици. Разработихме образователни материали и ръководства, за да помогнем на потребителите да започнат. С придобито основно разбиране, потребителите откриха, че е лесно да навигират в набори от данни, да преглеждат данни от схеми и таблици, да изпълняват прости заявки и да визуализират резултатите в Data Studio.

Нашата цел за въвеждане на данни в BigQuery беше да позволим безпроблемно зареждане на HDFS или GCS набори от данни с едно щракване. Обмислихме Облачен композитор (управляван от Airflow), но не успяхме да го използваме поради нашия модел за сигурност с ограничено споделяне на домейн (повече за това в раздела за управление на данни по-долу). Експериментирахме с използването на Google Data Transfer Service (DTS), за да организираме натоварванията на BigQuery. Докато DTS се настройваше бързо, той не беше гъвкав за изграждане на тръбопроводи със зависимости. За нашата алфа версия изградихме собствена рамка Apache Airflow в GCE и я подготвяме да работи в производствена среда и да може да поддържа повече източници на данни като Vertica.

За да трансформират данните в BigQuery, потребителите създават прости SQL конвейери за данни, като използват планирани заявки. За сложни многоетапни конвейери със зависимости планираме да използваме или нашата собствена рамка на Airflow, или Cloud Composer заедно с Поток от данни в облак.

продуктивност

BigQuery е предназначен за SQL заявки с общо предназначение, които обработват големи количества данни. Не е предназначен за заявки с ниска латентност и висока пропускателна способност, изисквани от транзакционна база данни, или за приложен анализ на времеви серии с ниска латентност Друид от апачи. За заявки за интерактивен анализ нашите потребители очакват време за отговор по-малко от една минута. Трябваше да проектираме нашата употреба на BigQuery, за да отговорим на тези очаквания. За да осигурим предвидима производителност за нашите потребители, ние използвахме функционалността на BigQuery, достъпна за клиентите на база фиксирана такса, която позволява на собствениците на проекти да резервират минимални слотове за своите заявки. прорез BigQuery е единица изчислителна мощност, необходима за изпълнение на SQL заявки.

Анализирахме над 800 заявки, обработващи приблизително 1 TB данни всяка и установихме, че средното време за изпълнение е 30 секунди. Научихме също, че производителността е силно зависима от използването на нашия слот в различни проекти и задачи. Трябваше ясно да очертаем нашите производствени и ad hoc слот резерви, за да поддържаме производителността за производствени случаи на употреба и онлайн анализ. Това силно повлия на нашия дизайн за резервации на слотове и йерархията на проекта.

Ще говорим за управление на данни, функционалност и цена на системите през следващите дни във втората част на превода, но сега каним всички да безплатен уебинар на живо, по време на който ще можете да се запознаете подробно с курса, както и да зададете въпроси на нашия експерт – Егор Матешук (Senior Data Engineer, MaximaTelecom).

Прочетете още:

• Data Build Tool или какво е общото между Data Warehouse и Smoothie
• Гмуркане в Delta Lake: Еволюция на прилагането и схемата
• Високоскоростен Apache Parquet в Python с Apache Arrow

Източник: www.habr.com