Прывітанне, Хабр! Прама цяпер у OTUS адкрыты набор на новы паток курса . Напярэдадні старту курса працягваем дзяліцца з вамі карысным матэрыялам.
Кіраванне дадзенымі
Моцнае кіраванне дадзенымі (Strong Data Governance) – асноўны прынцып Twitter Engineering. Паколькі мы ўкараняем BigQuery у нашу платформу, мы канцэнтруемся на выяўленні дадзеных, кантролі доступу, бяспекі і канфідэнцыяльнасці.
Для выяўлення дадзеных і кіравання імі мы пашырылі наш узровень доступу да дадзеных (Data Access Layer) ), каб прадастаўляць інструменты як для лакальных дадзеных, так і для дадзеных Google Cloud, падаючы адзіны інтэрфейс і API для нашых карыстальнікаў. Па меры таго як Google рухаецца ў бок агульнадаступнасці, мы ўключым яго ў нашы праекты, каб даць карыстальнікам такія функцыі, як пошук па калонках.
BigQuery дазваляе лёгка абменьвацца дадзенымі і атрымліваць да іх доступ, але нам трэба было да некаторай ступені кантраляваць гэта, каб прадухіліць эксфільтрацыю дадзеных. Сярод іншых інструментаў мы выбралі дзве функцыі:
- : бэта-функцыя, якая забараняе карыстальнікам абменьвацца наборамі дадзеных BigQuery з карыстальнікамі за межамі Twitter.
- : элемент кіравання, які прадухіляе эксфільтрацыю дадзеных і патрабуе ад карыстальнікаў доступ да BigQuery з вядомых дыяпазонаў IP-адрасоў.
Мы рэалізавалі патрабаванні аўтэнтыфікацыі, аўтарызацыі і аўдыту (AAA) для забеспячэння бяспекі наступным чынам:
- Аўтэнтыфікацыя: мы выкарыстоўвалі ўліковыя запісы карыстальнікаў GCP для ad hoc запытаў і ўліковыя запісы службаў для працоўных запытаў.
- Аўтарызацыя: мы патрабавалі, каб кожны набор дадзеных меў уліковы запіс службы ўладальніка і групу чытачоў.
- Аўдыт: мы экспартавалі часопісы стэкдрайвераў BigQuery, у якіх змяшчалася падрабязная інфармацыя аб выкананні запытаў, у набор дадзеных BigQuery для зручнасці аналізу.
Каб забяспечыць належную апрацоўку асабістых дадзеных карыстальнікаў Twitter, мы павінны зарэгістраваць усе наборы дадзеных BigQuery, анатаваць асабістыя дадзеныя, падтрымліваць належнае захоўванне і выдаляць (вычышчаць) дадзеныя, якія былі выдалены карыстальнікамі.
Мы разглядалі Google , Які выкарыстоўвае машыннае навучанне для класіфікацыі і рэдагавання канфідэнцыйных дадзеных, але прынялі рашэнне ў карысць ручной анатацыі набору дадзеных з-за дакладнасці. Мы плануем выкарыстоўваць Data Loss Prevention API, каб дапоўніць карыстацкую анатацыю.
У Twitter мы стварылі чатыры катэгорыі канфідэнцыйнасці для набораў дадзеных у BigQuery, пералічаныя тут у парадку змяншэння адчувальнасці:
- Высокачуллівыя наборы дадзеных даступныя па меры неабходнасці на аснове прынцыпу найменшых прывілеяў. Кожны набор дадзеных мае асобную групу чытачоў, і мы будзем адсочваць выкарыстанне асобных уліковых запісаў.
- Наборы дадзеных сярэдняй адчувальнасці (аднабаковыя псеўданімы з выкарыстаннем салёнага хэшавання) не ўтрымоўваюць асабістай інфармацыі (Personally Identifiable Information – PII) і даступныя для большай групы супрацоўнікаў. Гэта добры баланс паміж меркаваннямі канфідэнцыйнасці і карыснасці дадзеных. Гэта дазваляе супрацоўнікам выконваць задачы аналізу, такія як вылічэнне колькасці карыстальнікаў, якія выкарыстоўвалі функцыю, не ведаючы, хто з'яўляецца рэальнымі карыстальнікамі.
- Наборы дадзеных з нізкай адчувальнасцю з усёй інфармацыяй, якая ідэнтыфікуе карыстальніка. Гэта добры падыход з пункту гледжання канфідэнцыйнасці, але яго нельга выкарыстоўваць для аналізу на ўзроўні карыстальніка.
- Публічныя наборы дадзеных (выпушчаныя па-за Twitter) даступныя ўсім супрацоўнікам Twitter.
Што да рэгістрацыі, мы выкарыстоўвалі запланаваныя задачы для пералічэння набораў дадзеных BigQuery і рэгістрацыі іх у Data Access Layer (), сховішча метададзеных Twitter. Карыстальнікі будуць анатаваць наборы дадзеных інфармацыяй аб канфiдэнцыяльнасцi, а таксама ўказваць тэрмін захоўвання. Што да ачысткі, мы ацэньваем прадукцыйнасць і кошт двух варыянтаў: 1. Ачыстка набораў дадзеных у GCS з дапамогай такіх прылад, як Scalding, і загрузка іх у BigQuery; 2. Выкарыстанне аператараў BigQuery DML. Мы, верагодна, будзем выкарыстоўваць камбінацыю абодвух метадаў для задавальнення патрабаванняў розных груп і даных.
Функцыянальнасць сістэмы
Паколькі BigQuery з'яўляецца кіраванай службай, не было неабходнасці падлучаць SRE каманду Twitter да кіравання сістэмамі або выкананню дзяжурных абавязкаў. Было лёгка забяспечыць большую ёмістасць як для захоўвання, так і для вылічэнняў. Мы маглі б змяніць рэзерваванне слотаў, ствараючы цікеты ў падтрымцы Google. Мы вызначылі, што можна было б палепшыць, напрыклад, самаабслугоўванне для размеркавання слотаў і паляпшэнне дашборда для маніторынгу, і перадалі гэтыя запыты ў Google.
Кошт
Наш папярэдні аналіз паказаў, што кошт запытаў для BigQuery і Presto быў на адным узроўні. Мы набылі слоты па кошце, каб мець стабільную штомесячную кошт замест аплаты за ТБ апрацаваных дадзеных. Гэтае рашэнне таксама было заснавана на водгуках карыстальнікаў, якія не хацелі думаць аб выдатках перад выкананнем кожнага запыту.
Захоўванне дадзеных у BigQuery прынесла выдаткі ў дадатак да выдаткаў на GCS. Такія прылады, як Scalding, патрабуюць наяўнасці набораў дадзеных у GCS, а для доступу да BigQuery нам прыйшлося загрузіць тыя ж наборы дадзеных у фармат BigQuery. . Мы працуем над злучэннем Scalding з наборамі дадзеных BigQuery, якое ўхіліць неабходнасць захоўвання набораў дадзеных як у GCS, так і ў BigQuery.
Для рэдкіх выпадкаў, якія патрабавалі нячастых запытаў на дзясяткі петабайт, мы вырашылі, што захоўванне набораў дадзеных у BigQuery не з'яўляецца эканамічна эфектыўным, і выкарыстоўвалі Presto для прамога доступу да набораў дадзеных у GCS. Для гэтага мы прыглядаемся да BigQuery External Data Sources.
наступныя крокі
Мы адзначылі вялікую цікавасць да BigQuery з моманту выпуску альфы. Мы дадаем больш набораў дадзеных і больш каманд у BigQuery. Мы распрацоўваем канектары для інструментаў аналізу дадзеных, такіх як Scalding, для чытання і запісы ў сховішча BigQuery. Мы разглядаем такія прылады, як Looker і Apache Zeppelin, для стварэння карпаратыўных справаздач аб якасці і нататак з выкарыстаннем набораў дадзеных BigQuery.
Супрацоўніцтва з Google было вельмі прадуктыўным, і мы рады працягнуць і развіваць гэтае партнёрства. Мы працавалі з Google, каб укараніць наш уласны , Каб напрамую адпраўляць запыты ў Google. Некаторыя з іх, такія як загрузнік BigQuery Parquet, ужо рэалізаваны Google.
Вось некаторыя з нашых высокапрыярытэтных запытаў фіч для Google:
- Інструменты для зручнага прыёму даных і падтрымка фармату LZO-Thrift.
- Пагадзіннае сегментаванне
- Паляпшэнні ў галіне кантролю доступу, такія як дазволы на ўзроўні табліц, радкоў і слупкоў.
- BigQuery з інтэграцыяй і падтрымкай Hive Metastore для фармату LZO-Thrift.
- Палепшаная інтэграцыя каталога дадзеных у карыстацкім інтэрфейсе BigQuery
- Самаабслугоўвання для размеркавання і маніторынгу слотаў.
Заключэнне
Дэмакратызацыя аналізу дадзеных, візуалізацыі і машыннага навучання бяспечным спосабам з'яўляецца найвышэйшым прыярытэтам для каманды Data Platform. Мы вызначылі Google BigQuery і Data Studio як прылады, якія могуць дапамагчы ў дасягненні гэтай мэты, і зарэлізавалі ў мінулым годзе BigQuery Alpha для ўсёй кампаніі.
Мы выявілі, што запыты ў BigQuery былі простыя і эфектыўныя. Для прыёму і пераўтварэнні дадзеных мы выкарыстоўвалі прылады Google для простых канвеераў, але для складаных канвеераў нам прыйшлося стварыць уласную інфраструктуру Airflow. У вобласці кіравання дадзенымі службы BigQuery для аўтэнтыфікацыі, аўтарызацыі і аўдыту задавальняюць нашы запатрабаванні. Для кіравання метададзенымі і захавання прыватнасці нам патрабавалася вялікая гнуткасць і нам даводзілася ствараць уласныя сістэмы. BigQuery, быўшы кіраваным сэрвісам, быў просты ў эксплуатацыі. Выдаткі на запыты былі аналагічныя існуючым інструментам. Захоўванне дадзеных у BigQuery панесла выдаткі ў дадатак да выдаткаў на GCS.
У цэлым, BigQuery добра працуе для агульнага аналізу SQL. Мы адзначаем вялікую цікавасць да BigQuery, і мы працуем над пераносам большай колькасці набораў дадзеных, прыцягненнем большай колькасці каманд і стварэннем большай колькасці канвеераў з BigQuery. У Twitter выкарыстоўваюцца розныя дадзеныя, для якіх запатрабуецца спалучэнне такіх прылад, як Scalding, Spark, Presto і Druid. Мы маем намер працягваць нарошчваць нашы інструменты аналізу дадзеных і прадастаўляць дакладныя рэкамендацыі нашым карыстальнікам аб тым, як найлепшым чынам выкарыстаць нашы прапановы.
Словы падзякі
Я хацеў бы падзякаваць маім суаўтарам і таварышам па камандзе, Анжу Джа і Уіла Паскучы, за іх цудоўнае супрацоўніцтва і цяжкую працу на гэтым праекце. Я таксама хацеў бы падзякаваць інжынерам і менеджэрам з некалькіх каманд у Twitter і Google, якія дапамаглі нам і карыстальнікам BigQuery у Twitter, якія далі каштоўную зваротную сувязь.
Калі вы зацікаўлены ў працы над гэтымі задачамі, азнаёмцеся з нашымі у камандзе Data Platform.
Крыніца: habr.com