Sveiks, Habr! Šobrīd OTUS ir atvērta pieteikšanās jaunai kursu straumei . Gaidot kursu sākumu, turpinām dalīties ar jums noderīgā materiālā.
Datu vadība
Spēcīga datu pārvaldība ir Twitter inženierijas pamatprincips. Ieviešot BigQuery savā platformā, mēs koncentrējamies uz datu atklāšanu, piekļuves kontroli, drošību un privātumu.
Lai atklātu un pārvaldītu datus, esam paplašinājuši savu datu piekļuves slāni līdz ), lai nodrošinātu rīkus gan lokālajiem, gan Google mākoņa datiem, nodrošinot mūsu lietotājiem vienotu saskarni un API. Kā Google virzās uz vispārēju pieejamību, mēs to iekļausim savos projektos, lai nodrošinātu lietotājiem tādas funkcijas kā kolonnu meklēšana.
BigQuery atvieglo datu kopīgošanu un piekļuvi tiem, taču mums bija nepieciešams to kontrolēt, lai novērstu datu izfiltrēšanu. Starp citiem rīkiem mēs izvēlējāmies divas funkcijas:
- : Beta funkcija, lai neļautu lietotājiem koplietot BigQuery datu kopas ar lietotājiem ārpus Twitter.
- : vadīkla, kas novērš datu izfiltrēšanu un pieprasa lietotājiem piekļūt BigQuery no zināmiem IP adrešu diapazoniem.
Mēs esam ieviesuši autentifikācijas, autorizācijas un auditēšanas (AAA) prasības drošībai, kā norādīts tālāk.
- Autentifikācija: mēs izmantojām GSP lietotāju kontus ad hoc pieprasījumiem un pakalpojumu kontus ražošanas pieprasījumiem.
- Autorizācija: katrai datu kopai bija jābūt īpašnieka pakalpojuma kontam un lasītāju grupai.
- Auditēšana: mēs eksportējām BigQuery steka draivera žurnālus, kuros bija detalizēta informācija par vaicājumu izpildi, BigQuery datu kopā, lai to varētu viegli analizēt.
Lai nodrošinātu, ka Twitter lietotāju personas dati tiek pareizi apstrādāti, mums ir jāreģistrē visas BigQuery datu kopas, jāanotē personas dati, jāuztur pareiza uzglabāšana un jādzēš (jāiztīra) dati, ko lietotāji ir dzēsuši.
Mēs apskatījām Google , kas izmanto mašīnmācīšanos, lai klasificētu un rediģētu sensitīvus datus, taču precizitātes dēļ nolēma manuāli anotēt datu kopu. Mēs plānojam izmantot Data Loss Prevention API, lai papildinātu pielāgoto anotāciju.
Vietnē Twitter esam izveidojuši četras BigQuery datu kopu konfidencialitātes kategorijas, kas norādītas šeit dilstošā jutības secībā.
- Ļoti sensitīvas datu kopas tiek darītas pieejamas pēc vajadzības, pamatojoties uz mazāko privilēģiju principu. Katrai datu kopai ir atsevišķa lasītāju grupa, un mēs izsekosim lietojumu pa atsevišķiem kontiem.
- Vidēja jutīguma datu kopas (vienvirziena pseidonīmi, kas izmanto sālītu jaukšanu) nesatur personu identificējošu informāciju (PII) un ir pieejamas lielākai darbinieku grupai. Tas ir labs līdzsvars starp privātuma problēmām un datu lietderību. Tas ļauj darbiniekiem veikt analīzes uzdevumus, piemēram, aprēķināt to lietotāju skaitu, kuri izmantojuši funkciju, nezinot, kas ir īstie lietotāji.
- Zemas jutības datu kopas ar visu lietotāju identifikācijas informāciju. Šī ir laba pieeja no privātuma viedokļa, taču to nevar izmantot lietotāja līmeņa analīzei.
- Publiskās datu kopas (izlaistas ārpus Twitter) ir pieejamas visiem Twitter darbiniekiem.
Kas attiecas uz reģistrēšanu, mēs izmantojām ieplānotus uzdevumus, lai uzskaitītu BigQuery datu kopas un reģistrētu tās datu piekļuves slānī (), Twitter metadatu krātuve. Lietotāji anotēs datu kopas ar privātuma informāciju un norādīs arī saglabāšanas periodu. Runājot par tīrīšanu, mēs novērtējam divu iespēju veiktspēju un izmaksas: 1. Datu kopu tīrīšana GCS, izmantojot tādus rīkus kā applaucēšana, un to ielāde BigQuery; 2. BigQuery DML priekšrakstu izmantošana. Mēs, iespējams, izmantosim abu metožu kombināciju, lai apmierinātu dažādu grupu un datu prasības.
Sistēmas funkcionalitāte
Tā kā BigQuery ir pārvaldīts pakalpojums, Twitter SRE komanda nebija jāiesaista sistēmu pārvaldībā vai darba pienākumos. Bija viegli nodrošināt lielāku ietilpību gan uzglabāšanai, gan skaitļošanai. Mēs varētu mainīt vietu rezervāciju, izveidojot biļeti ar Google atbalstu. Mēs identificējām jomas, kuras varētu uzlabot, piemēram, pašapkalpošanās laika nišu piešķiršanu un informācijas paneļa uzlabojumus pārraudzībai, un iesniedzām šos pieprasījumus uzņēmumam Google.
Izmaksāt
Mūsu sākotnējā analīze parādīja, ka BigQuery un Presto vaicājumu izmaksas bija vienā līmenī. Mēs iegādājāmies slotus par cena, lai maksājuma vietā būtu stabilas ikmēneša izmaksas uz TB apstrādāto datu. Šis lēmums tika balstīts arī uz atsauksmēm no lietotājiem, kuri nevēlējās domāt par izmaksām pirms katra pieprasījuma iesniegšanas.
Datu glabāšana pakalpojumā BigQuery radīja papildu izmaksas GCS izmaksām. Tādiem rīkiem kā Scalding ir nepieciešamas datu kopas GCS, un, lai piekļūtu BigQuery, mums bija jāielādē tās pašas datu kopas BigQuery formātā. . Mēs strādājam pie Scalding savienojuma ar BigQuery datu kopām, kas novērsīs nepieciešamību uzglabāt datu kopas gan GCS, gan BigQuery.
Retos gadījumos, kad bija nepieciešami reti vaicājumi desmitiem petabaitu garumā, mēs nolēmām, ka datu kopu glabāšana pakalpojumā BigQuery nebija rentabla, un izmantojām Presto, lai tieši piekļūtu datu kopām GCS. Lai to izdarītu, mēs aplūkojam BigQuery ārējos datu avotus.
Nākamās darbības
Kopš alfa versijas izlaišanas esam redzējuši lielu interesi par BigQuery. Mēs pievienojam vairāk datu kopu un vairāk komandu BigQuery. Mēs izstrādājam savienotājus datu analīzes rīkiem, piemēram, Scalding, lai lasītu un rakstītu BigQuery krātuvē. Mēs meklējam tādus rīkus kā Looker un Apache Zeppelin, lai izveidotu uzņēmuma kvalitātes pārskatus un piezīmes, izmantojot BigQuery datu kopas.
Mūsu sadarbība ar Google ir bijusi ļoti produktīva, un mēs esam priecīgi turpināt un attīstīt šo partnerību. Mēs sadarbojāmies ar Google, lai ieviestu savu lai nosūtītu vaicājumus tieši uzņēmumam Google. Dažus no tiem, piemēram, BigQuery Parketa iekrāvēju, Google jau ir ieviesis.
Šeit ir daži no mūsu augstas prioritātes funkciju pieprasījumiem uzņēmumam Google.
- Rīki ērtai datu saņemšanai un atbalstam LZO-Thrift formātā.
- Stundu segmentācija
- Piekļuves kontroles uzlabojumi, piemēram, tabulas, rindu un kolonnu līmeņa atļaujas.
- BigQuery ar Hive Metastore integrāciju un LZO-Thrift formāta atbalstu.
- Uzlabota datu kataloga integrācija BigQuery lietotāja saskarnē
- Pašapkalpošanās laika nišu piešķiršanai un uzraudzībai.
Secinājums
Datu analītikas, vizualizācijas un mašīnmācīšanās demokratizācija drošā veidā ir datu platformas komandas galvenā prioritāte. Mēs identificējām Google BigQuery un Data Studio kā rīkus, kas varētu palīdzēt sasniegt šo mērķi, un pagājušajā gadā izlaidām BigQuery Alpha visā uzņēmumā.
Mēs atklājām, ka BigQuery vaicājumi ir vienkārši un efektīvi. Mēs izmantojām Google rīkus, lai pārņemtu un pārveidotu datus par vienkāršiem cauruļvadiem, bet sarežģītiem cauruļvadiem mums bija jāizveido savs Airflow ietvars. Datu pārvaldības telpā BigQuery autentifikācijas, autorizācijas un auditēšanas pakalpojumi atbilst mūsu vajadzībām. Lai pārvaldītu metadatus un saglabātu privātumu, mums bija nepieciešama lielāka elastība, un mums bija jāizveido savas sistēmas. BigQuery, kas ir pārvaldīts pakalpojums, bija viegli lietojams. Vaicājumu izmaksas bija līdzīgas esošajiem rīkiem. Par datu glabāšanu BigQuery papildus GCS izmaksām ir jāmaksā.
Kopumā BigQuery labi darbojas vispārīgai SQL analīzei. Mēs novērojam lielu interesi par BigQuery, un mēs strādājam, lai migrētu vairāk datu kopu, piesaistītu vairāk komandu un izveidotu vairāk konveijeru, izmantojot BigQuery. Twitter izmanto dažādus datus, kuriem būs nepieciešama dažādu rīku kombinācija, piemēram, Scalding, Spark, Presto un Druid. Mēs plānojam turpināt uzlabot savus datu analīzes rīkus un sniegt lietotājiem skaidrus norādījumus par to, kā vislabāk izmantot mūsu piedāvājumu.
Pateicības vārdi
Es vēlos pateikties saviem līdzautoriem un komandas biedriem Anju Jha un Will Pascucci par lielisko sadarbību un smago darbu pie šī projekta. Vēlos pateikties arī inženieriem un vadītājiem no vairākām Twitter un Google komandām, kas palīdzēja mums un BigQuery lietotājiem pakalpojumā Twitter un sniedza vērtīgas atsauksmes.
Ja jūs interesē darbs pie šīm problēmām, skatiet mūsu Datu platformas komandā.
Avots: www.habr.com
