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

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

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

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

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

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

BigQuery: склад за корпоративни данни с SQL двигател на база Dremel, който е известен със своята бързина, простота и справяне с машинното обучение.
Data Studio: инструмент за визуализация на големи данни с функции за съвместна работа, подобно на 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 г. пуснахме alpha версия на BigQuery и Data Studio за цялата компания. Предоставихме на служителите на Twitter част от най-използваните ни таблици с обработени лични данни. BigQuery е използван от над 250 потребители от различни екипи, включително инженерни, финансови и маркетингови. Съвсем наскоро те извършваха около 8000 заявки, обработвайки около 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 с едно щракване. Разглеждахме Cloud Composer (управляем Airflow), но не успяхме да го използваме заради нашия модел за сигурност „Domain Restricted Sharing“ (повече информация в секцията „Управление на данни“ по-долу). Експериментирахме с използването на Google Data Transfer Service (DTS) за организиране на натоварващи задачи в BigQuery. Докато DTS бързо се настройваше, той не беше достатъчно гъвкав за изграждане на конвейери с зависимости. За нашата алфа версия създадохме собствена среда Apache Airflow в GCE и я подготвяме за работа в продукция и възможностите да поддържа повече източници на данни, като Vertica.

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

Производителност

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

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

За управлението на данни, функционалността и цената на системите ще говорим в най-близките дни втора част на превода, а сега каним всички желаещи на безплатен жив уебинар, в рамките на който могат да научат подробности за курса и да зададат въпроси на нашия експерт — Егор Матешук (Старши инженер по данни, MaximaTelecom).