Google-ийн BigQuery нь өгөгдлийн шинжилгээг хэрхэн ардчилсан. 2-р хэсэг

Сайн уу, Хабр! Яг одоо OTUS дээр шинэ сургалтын элсэлт явагдаж байна "Өгөгдлийн инженер". Хичээл эхлэхийг угтан бид танд хэрэгтэй материалаа үргэлжлүүлэн хуваалцсаар байна.

Нэгдүгээр хэсгийг уншина уу

Google-ийн BigQuery нь өгөгдлийн шинжилгээг хэрхэн ардчилсан. 2-р хэсэг

Өгөгдлийн менежмент

Хүчтэй мэдээллийн засаглал нь Twitter инженерчлэлийн үндсэн зарчим юм. Бид BigQuery-г платформдоо нэвтрүүлэхдээ өгөгдөл илрүүлэх, хандалтын хяналт, аюулгүй байдал, нууцлал зэрэгт анхаарлаа хандуулдаг.

Өгөгдлийг олж, удирдахын тулд бид өгөгдөлд нэвтрэх давхаргыг өргөтгөсөн DAL) хэрэглэгчдэдээ нэг интерфэйс болон API-ээр ханган, газар дээрх болон Google Cloud датад зориулсан хэрэгслээр хангах. Google шиг Өгөгдлийн каталог ерөнхий хүртээмж рүү шилжиж байгаа тул хэрэглэгчдэд баганын хайлт зэрэг функцуудыг өгөхийн тулд бид үүнийг төсөлдөө оруулах болно.

BigQuery нь өгөгдөл хуваалцах, хандахад хялбар болгодог, гэхдээ бид өгөгдлийг гадагшлуулахаас сэргийлэхийн тулд үүнийг хянах шаардлагатай байсан. Бусад хэрэгслүүдийн дотроос бид хоёр функцийг сонгосон:

  • Домэйн хязгаарлагдмал хуваалцах: Хэрэглэгчид BigQuery өгөгдлийн багцыг Twitter-ээс бусад хэрэглэгчидтэй хуваалцахаас урьдчилан сэргийлэх бета функц.
  • VPC үйлчилгээний хяналт: Өгөгдөл гадагшлуулахаас сэргийлдэг хяналт бөгөөд хэрэглэгчид мэдэгдэж буй IP хаягийн мужаас BigQuery-д хандахыг шаарддаг.

Бид дараах байдлаар аюулгүй байдлын баталгаажуулалт, зөвшөөрөл, аудитын (AAA) шаардлагуудыг хэрэгжүүлсэн.

  • Баталгаажуулалт: Бид түр хүсэлтэд GCP хэрэглэгчийн бүртгэл, үйлдвэрлэлийн хүсэлтэд үйлчилгээний данс ашигласан.
  • Зөвшөөрөл: Бид өгөгдлийн багц бүрийг эзэмшигчийн үйлчилгээний бүртгэл болон уншигчийн бүлэгтэй байхыг шаарддаг.
  • Аудит: Бид асуулгын гүйцэтгэлийн нарийвчилсан мэдээллийг агуулсан BigQuery стек драйверын бүртгэлийг хялбархан дүн шинжилгээ хийхийн тулд BigQuery өгөгдлийн багц руу экспортолсон.

Твиттер хэрэглэгчдийн хувийн мэдээллийг зөв зохицуулахын тулд бид BigQuery-ийн бүх өгөгдлийн багцыг бүртгэх, хувийн мэдээлэлд тайлбар оруулах, зохих хадгалалтыг хадгалах, хэрэглэгчдийн устгасан өгөгдлийг устгах (хусах) ёстой.

Бид Google-ийг харлаа Cloud Data Loss Prevention API, энэ нь эмзэг өгөгдлийг ангилах, засварлахад машин сургалтыг ашигладаг боловч нарийвчлалын улмаас өгөгдлийн багцад гараар тайлбар оруулахаар шийдсэн. Бид захиалгат тэмдэглэгээг нэмэгдүүлэхийн тулд Data Loss Prevention API ашиглахаар төлөвлөж байна.

Твиттерт бид BigQuery дахь өгөгдлийн багцын нууцлалын дөрвөн категорийг үүсгэсэн бөгөөд эдгээрийг мэдрэмжийн бууралтын дарааллаар жагсаав.

  • Өндөр мэдрэмжтэй өгөгдлийн багцыг хамгийн бага давуу эрхийн зарчимд тулгуурлан шаардлагатай бол ашиглах боломжтой болгодог. Өгөгдлийн багц бүр нь тусдаа уншигчдын бүлэгтэй бөгөөд бид хувь хүний ​​бүртгэлээр ашиглалтыг хянах болно.
  • Дунд зэргийн мэдрэмжийн өгөгдлийн багц (давсалсан хэш ашиглан нэг талын зохиомол нэр) нь Хувь хүний ​​​​мэдээлэл (PII) агуулаагүй бөгөөд илүү том бүлэг ажилтнуудад хандах боломжтой. Энэ нь нууцлалын асуудал болон өгөгдлийн хэрэгслийн хоорондох сайн тэнцвэр юм. Энэ нь ажилтнуудад тухайн функцийг ашигласан хэрэглэгчдийн тоог тооцоолох гэх мэт дүн шинжилгээ хийх ажлыг бодит хэрэглэгчид хэн болохыг мэдэхгүйгээр гүйцэтгэх боломжийг олгодог.
  • Хэрэглэгчийн таних бүх мэдээлэл бүхий мэдрэмж багатай өгөгдлийн багц. Энэ нь нууцлалын үүднээс сайн арга боловч хэрэглэгчийн түвшний шинжилгээнд ашиглах боломжгүй.
  • Нийтийн мэдээллийн багц (Твиттерээс гадуур гарсан) Твиттерийн бүх ажилчдад нээлттэй.

Бүртгэлийн хувьд бид BigQuery өгөгдлийн багцыг тоолж, Дата хандалтын давхаргад бүртгүүлэхийн тулд хуваарьт ажлуудыг ашигласан (DAL), Twitter мета өгөгдлийн агуулах. Хэрэглэгчид нууцлалын мэдээлэл бүхий өгөгдлийн багцыг тэмдэглэж, хадгалах хугацааг зааж өгнө. Цэвэрлэгээний хувьд бид хоёр сонголтын гүйцэтгэл, зардлыг үнэлдэг. 1. Scalding гэх мэт хэрэгслүүдийг ашиглан GCS дахь өгөгдлийн багцыг цэвэрлэж, BigQuery руу ачаалах; 2. BigQuery DML мэдэгдлийг ашиглах. Бид янз бүрийн бүлэг, өгөгдлийн шаардлагыг хангахын тулд хоёр аргыг хослуулан ашиглах болно.

Системийн функциональ байдал

BigQuery бол удирдлагатай үйлчилгээ учраас Twitter-ийн SRE багийг системийн удирдлага эсвэл ширээний ажилд татан оролцуулах шаардлагагүй байсан. Хадгалах болон тооцоолох аль алинд нь илүү их багтаамж өгөхөд хялбар байсан. Бид Google-н тусламжтай тасалбар үүсгэснээр слотын захиалгыг өөрчилж болно. Бид өөрөө өөртөө үйлчлэх зайны хуваарилалт, хяналтын самбарыг сайжруулах зэрэг сайжруулах боломжтой хэсгүүдийг тодорхойлж, эдгээр хүсэлтийг Google-д илгээсэн.

зардал

Бидний урьдчилсан дүн шинжилгээгээр BigQuery болон Presto-н асуулгын зардал ижил түвшинд байгааг харуулсан. Бид слот худалдаж авсан тогтмол төлбөрийн оронд сар бүр тогтвортой зардалтай байх үнэ хүсэлтээр боловсруулсан мэдээллийн TB тутамд. Энэхүү шийдвэр нь хүсэлт бүрийг гаргахын өмнө зардлын талаар бодохыг хүсээгүй хэрэглэгчдийн санал хүсэлт дээр үндэслэсэн болно.

BigQuery-д өгөгдөл хадгалах нь GCS зардлаас гадна зардлыг авчирсан. Scalding гэх мэт хэрэгслүүд нь GCS-д өгөгдлийн багц шаарддаг бөгөөд BigQuery-д хандахын тулд бид ижил өгөгдлийн багцыг BigQuery формат руу ачаалах шаардлагатай болсон. Кондуктор. Бид BigQuery өгөгдлийн багцтай Scalding холболт дээр ажиллаж байгаа бөгөөд энэ нь GCS болон BigQuery-д өгөгдлийн багцыг хадгалах шаардлагагүй болно.

Хэдэн арван петабайтын давтамжгүй асуулга шаарддаг ховор тохиолдлын хувьд бид BigQuery-д өгөгдлийн багц хадгалах нь зардал багатай гэж үзээд Presto-г ашиглан GCS-ийн өгөгдлийн багцад шууд хандсан. Үүнийг хийхийн тулд бид BigQuery-ийн гадаад мэдээллийн эх сурвалжийг судалж байна.

Дараагийн алхамууд

Альфа хувилбар гарснаас хойш бид BigQuery-г маш их сонирхож байгааг харсан. Бид BigQuery-д илүү олон дата багц болон бусад тушаалуудыг нэмж байна. Бид BigQuery сан руу унших, бичихийн тулд Scalding зэрэг өгөгдлийн аналитик хэрэгсэлд зориулсан холбогчийг боловсруулдаг. Бид BigQuery датасет ашиглан байгууллагын чанарын тайлан, тэмдэглэл үүсгэх Looker болон Apache Zeppelin зэрэг хэрэгслүүдийг судалж байна.

Google-тэй хийсэн бидний хамтын ажиллагаа маш үр дүнтэй байсан бөгөөд бид энэхүү түншлэлийг үргэлжлүүлэн хөгжүүлж байгаадаа баяртай байна. Бид Google-тэй хамтран ажиллаж, өөрсдийнхөө төслийг хэрэгжүүлсэн Түншийн асуудал хянагчGoogle рүү шууд асуулга илгээх. Тэдгээрийн заримыг нь, тухайлбал BigQuery Паркет ачигчийг Google аль хэдийн хэрэгжүүлсэн.

Эндээс Google-д зориулсан манай хамгийн чухал онцлог шинж чанаруудын зарим нь:

  • Тохиромжтой өгөгдөл хүлээн авах, LZO-Thrift форматыг дэмжих хэрэгслүүд.
  • Цагийн сегментчилэл
  • Хүснэгт, мөр, баганын түвшний зөвшөөрөл зэрэг хандалтын хяналтын сайжруулалт.
  • BigQuery Гадаад мэдээллийн эх сурвалж Hive Metastore-ийн интеграци болон LZO-Thrift форматыг дэмждэг.
  • BigQuery хэрэглэгчийн интерфэйс дэх өгөгдлийн каталогийг сайжруулсан
  • Слот хуваарилах, хянах өөрөө өөртөө үйлчлэх үйлчилгээ.

дүгнэлт

Өгөгдлийн аналитик, дүрслэл, машин сургалтыг найдвартай аргаар ардчилах нь Дата платформын багийн нэн тэргүүний зорилт юм. Бид Google BigQuery болон Data Studio-г энэ зорилгод хүрэхэд туслах хэрэгсэл гэж тодорхойлсон бөгөөд өнгөрсөн жил BigQuery Alpha-г компани даяар гаргасан.

Бид BigQuery дээрх асуулга нь энгийн бөгөөд үр дүнтэй болохыг олж мэдсэн. Бид Google-ийн хэрэгслүүдийг энгийн дамжуулах хоолойн өгөгдлийг шингээж, хувиргахад ашигладаг байсан бол нарийн төвөгтэй дамжуулах хоолойн хувьд бид өөрсдийн Airflow тогтолцоог бий болгох шаардлагатай болсон. Өгөгдлийн удирдлагын талбарт BigQuery-н баталгаажуулалт, зөвшөөрөл, аудитын үйлчилгээ нь бидний хэрэгцээг хангадаг. Мета өгөгдлийг удирдах, нууцлалыг хадгалахын тулд бидэнд илүү уян хатан байдал хэрэгтэй байсан бөгөөд өөрсдийн системийг бий болгох шаардлагатай болсон. BigQuery нь удирдлагатай үйлчилгээ учраас ашиглахад хялбар байсан. Асуулгын зардал одоо байгаа хэрэгслүүдтэй төстэй байсан. BigQuery-д өгөгдөл хадгалахад GCS зардлаас гадна зардал гардаг.

Ерөнхийдөө BigQuery ерөнхий SQL шинжилгээнд сайн ажилладаг. Бид BigQuery-г маш их сонирхож байгааг харж байгаа бөгөөд бид BigQuery-ийн тусламжтайгаар илүү олон дата багцыг шилжүүлж, илүү олон багийг авчирч, илүү олон дамжуулах шугам барихаар ажиллаж байна. Твиттер нь Scalding, Spark, Presto, Druid гэх мэт хэрэгслүүдийг хослуулах шаардлагатай олон төрлийн өгөгдлийг ашигладаг. Бид өгөгдлийн аналитик хэрэгслүүдээ үргэлжлүүлэн бэхжүүлж, хэрэглэгчдэдээ санал болгож буй саналаа хэрхэн хамгийн сайн ашиглах талаар тодорхой зааварчилгаа өгөхийг зорьж байна.

Талархлын үгс

Энэхүү төсөл дээр маш сайн хамтран ажиллаж, шаргуу ажилласан миний хамтран зохиогчид болон багийн найзууд болох Анжу Жа, Вилл Паскуччи нартаа талархал илэрхийлье. Мөн бидэнд тусалсан Твиттер болон Google-ийн хэд хэдэн багийн инженер, менежерүүд болон үнэ цэнэтэй санал хүсэлтийг өгсөн Twitter-ийн BigQuery хэрэглэгчдэд талархал илэрхийлье.

Хэрэв та эдгээр асуудлууд дээр ажиллах сонирхолтой байгаа бол манай сул орон тоо Data Platform багт.

DWH дахь өгөгдлийн чанар - Өгөгдлийн агуулахын тууштай байдал

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх