Сайн уу, Хабр! Яг одоо OTUS дээр шинэ сургалтын элсэлт явагдаж байна . Хичээл эхлэхийг угтан бид уламжлал ёсоор та бүхэнд сонирхолтой материалын орчуулгыг бэлдлээ.
Твиттерт өдөр бүр зуун сая гаруй хүн зочилж, дэлхий дээр болж буй үйл явдлын талаар мэдээлэл авч, ярилцдаг. Жиргээ бүр болон хэрэглэгчийн бусад үйлдэл бүр Twitter-ийн дотоод өгөгдөлд дүн шинжилгээ хийх боломжтой үйл явдлыг үүсгэдэг. Олон зуун ажилчид эдгээр өгөгдөлд дүн шинжилгээ хийж, дүрслэн харуулдаг бөгөөд тэдний туршлагыг сайжруулах нь Twitter Data Platform багийн хувьд нэн тэргүүний зорилт юм.
Техникийн өргөн хүрээний ур чадвартай хэрэглэгчид өгөгдлийг олж мэдэх, SQL-д суурилсан дүн шинжилгээ хийх, дүрслэх хэрэгслүүдийг ашиглах боломжтой байх ёстой гэж бид үзэж байна. Энэ нь өгөгдлийн шинжээчид болон бүтээгдэхүүний менежерүүд зэрэг техник технологи багатай хэрэглэгчдийн цоо шинэ бүлэгт өгөгдлөөс ойлголт авч, Twitter-ийн чадавхийг илүү сайн ойлгож, ашиглах боломжийг олгоно. Бид Твиттер дэх дата аналитикийг ингэж ардчилдаг.
Манай хэрэгслүүд болон мэдээллийн дотоод аналитик чадвар сайжирснаар Twitter сайжирсан. Гэсэн хэдий ч сайжруулах боломж байсаар байна. Scalding гэх мэт одоогийн хэрэгслүүд нь програмчлалын туршлага шаарддаг. Presto, Vertica зэрэг SQL-д суурилсан шинжилгээний хэрэгслүүд нь гүйцэтгэлийн асуудалтай байдаг. Бидэнд мөн өгөгдөлд байнга хандахгүйгээр олон системд мэдээлэл түгээх асуудал тулгардаг.
Өнгөрсөн жил бид зарласан , дотор нь бид өөрсдийнхөө хэсгийг шилжүүлэх Google Cloud Platform (GCP) дээр. Бид Google Cloud хэрэгслүүд гэж дүгнэсэн Твиттер дэх аналитик, дүрслэл, машин сургалтыг ардчилах санаачилгад бидэнд тусалж чадна:
- : SQL хөдөлгүүрт суурилсан байгууллагын мэдээллийн агуулах , энэ нь хурд, энгийн байдал, даван туулах чадвараараа алдартай .
- Google Docs-тэй төстэй хамтын ажиллагааны онцлог бүхий том өгөгдлийг дүрслэх хэрэгсэл.
Энэ өгүүллээс та эдгээр хэрэгслүүдийн талаар бидний туршлагаас суралцах болно: бид юу хийсэн, юу сурсан, цаашид юу хийх вэ. Бид одоо багц болон интерактив аналитик дээр анхаарлаа хандуулах болно. Бид дараагийн өгүүллээр бодит цагийн аналитикийн талаар ярилцах болно.
Twitter мэдээллийн дэлгүүрүүдийн түүх
BigQuery-д орохын өмнө Twitter-ийн мэдээллийн агуулахын түүхийг товч дурдах нь зүйтэй. 2011 онд Twitter мэдээллийн шинжилгээг Vertica болон Hadoop дээр хийсэн. MapReduce Hadoop ажлуудыг үүсгэхийн тулд бид Pig-г ашигласан. 2012 онд бид Pig-ийг Scalding-ээр сольсон бөгөөд энэ нь нарийн төвөгтэй дамжуулах хоолой үүсгэх чадвар, туршилт хийхэд хялбар гэх мэт давуу талтай Scala API-тай байсан. Гэсэн хэдий ч SQL-тэй ажиллахад илүү таатай байсан олон тооны өгөгдлийн шинжээчид болон бүтээгдэхүүний менежерүүдийн хувьд энэ нь сурахад нэлээд эгц муруй байсан юм. 2016 онд бид Presto-г Hadoop өгөгдөлд SQL интерфейс болгон ашиглаж эхэлсэн. Spark нь Python интерфэйсийг санал болгосон бөгөөд энэ нь тусгай өгөгдөл шинжлэх ухаан болон машин суралцахад тохиромжтой сонголт болгодог.
2018 оноос хойш бид өгөгдөлд дүн шинжилгээ хийх, дүрслэхийн тулд дараах хэрэгслийг ашигласан.
- Үйлдвэрлэлийн туузан дамжуулагчийг түлэх
- Түр зуурын өгөгдөлд дүн шинжилгээ хийх, машин сурахад зориулсан Scalding болон Spark
- Түр зуурын болон интерактив SQL шинжилгээнд зориулсан Vertica болон Presto
- Цагийн цувралын хэмжигдэхүүнүүдэд интерактив, хайгуулын болон хоцролт багатай хандалт хийх Druid
- Өгөгдлийн дүрслэлд зориулсан Tableau, Zeppelin болон Pivot
Эдгээр хэрэгслүүд нь маш хүчирхэг боломжуудыг санал болгодог хэдий ч бид Twitter дээр илүү өргөн хүрээний үзэгчдэд эдгээр чадварыг ашиглахад бэрхшээлтэй байсныг олж мэдсэн. Google Cloud-ийн тусламжтайгаар платформоо өргөжүүлснээр бид бүх Twitter-ийн аналитик хэрэгслүүдээ хялбарчлахад анхаарч байна.
Google-ийн BigQuery мэдээллийн агуулах
Твиттерийн хэд хэдэн багууд BigQuery-г үйлдвэрлэлийнхээ зарим шугамд аль хэдийн оруулсан байна. Тэдний мэдлэгийг ашиглан бид Twitter-ийг ашиглах бүх тохиолдлуудад BigQuery-ийн чадавхийг үнэлж эхэлсэн. Бидний зорилго бол BigQuery-г бүх компанид санал болгож, Дата платформын хэрэглүүрийн хүрээнд стандартчилах, дэмжих явдал байв. Энэ нь олон шалтгааны улмаас хэцүү байсан. Бид их хэмжээний өгөгдлийг найдвартай шингээж авах, компанийн хэмжээнд өгөгдлийн менежментийг дэмжих, зөв хандалтын хяналтыг хангах, хэрэглэгчийн нууцлалыг хангах дэд бүтцийг хөгжүүлэх шаардлагатай байсан. Мөн бид багууд BigQuery-г үр дүнтэй ашиглахын тулд нөөцийг хуваарилах, хянах, буцаан олгох системийг бий болгох шаардлагатай болсон.
2018 оны 250-р сард бид BigQuery болон Data Studio-н альфа хувилбарыг компанийн хэмжээнд гаргасан. Бид Twitter-ийн ажилтнуудад цэвэршүүлсэн хувийн мэдээлэл бүхий хамгийн түгээмэл хэрэглэгддэг хүснэгтүүдийг санал болгосон. BigQuery-г инженерчлэл, санхүү, маркетинг гэх мэт янз бүрийн багийн 8 гаруй хэрэглэгчид ашигласан. Хамгийн сүүлд тэд хуваарьт хүсэлтийг тооцохгүйгээр сар бүр 100 орчим PB боловсруулж, XNUMXк орчим хүсэлт явуулж байсан. Маш эерэг санал хүсэлтийг хүлээн авсны дараа бид урагшилж, BigQuery-г Twitter дээрх өгөгдөлтэй харилцах үндсэн эх сурвалж болгон санал болгохоор шийдсэн.
Манай Google BigQuery мэдээллийн агуулахын архитектурын өндөр түвшний диаграмм энд байна.
Бид дотоод Cloud Replicator хэрэгслийг ашиглан дотоод Hadoop кластеруудаас өгөгдлийг Google Cloud Storage (GCS) руу хуулдаг. Дараа нь бид "Apache Airflow"-ийг ашигладаг дамжуулах хоолойг бий болгоход ашигладаг.» GCS-ээс BigQuery руу өгөгдөл ачаалах. Бид Presto-г ашиглан GCS дэх Паркет эсвэл Thrift-LZO дата багцыг асуудаг. BQ Blaster нь HDFS Vertica болон Thrift-LZO өгөгдлийн багцуудыг BigQuery руу ачаалахад зориулагдсан дотоод шатаах хэрэгсэл юм.
Дараах хэсгүүдэд бид ашиглахад хялбар, гүйцэтгэл, өгөгдлийн удирдлага, системийн эрүүл мэнд, өртөг зэрэг чиглэлээр өөрсдийн арга барил, туршлагаа ярилцах болно.
Хэрэглэхэд хялбар байдал
Програм хангамж суулгах шаардлагагүй, хэрэглэгчид ойлгомжтой вэб интерфэйсээр дамжуулан хандах боломжтой тул BigQuery-г ашиглаж эхлэх нь хэрэглэгчдэд хялбар байсныг бид олж мэдсэн. Гэсэн хэдий ч хэрэглэгчид төсөл, өгөгдлийн багц, хүснэгт зэрэг эх сурвалж зэрэг GCP-ийн зарим онцлог, ойлголттой танилцах шаардлагатай байв. Бид хэрэглэгчдэд эхлэхэд нь туслах боловсролын материал, зааварчилгааг боловсруулсан. Үндсэн ойлголттой болсноор хэрэглэгчид Data Studio дээр өгөгдлийн багцыг удирдах, схем болон хүснэгтийн өгөгдлийг үзэх, энгийн асуулга явуулах, үр дүнг дүрслэн харуулах зэрэгт хялбар болсон.
BigQuery-д өгөгдөл оруулах бидний зорилго бол HDFS эсвэл GCS өгөгдлийн багцыг нэг товшилтоор тасралтгүй ачаалах боломжийг олгох явдал байв. Бид авч үзсэн (Airflow-аас удирддаг) боловч манай Домэйн Хязгаарлагдмал Хуваалцах аюулгүй байдлын загвараас шалтгаалан үүнийг ашиглах боломжгүй болсон (энэ талаар доор Мэдээллийн Удирдлагын хэсгээс дэлгэрэнгүй үзнэ үү). Бид BigQuery-ийн ажлын ачааллыг зохицуулахын тулд Google Data Transfer Service (DTS) ашиглах туршилт хийсэн. DTS-ийг хурдан суулгаж байсан ч хамаарал бүхий дамжуулах хоолой барихад уян хатан биш байсан. Альфа хувилбараа гаргахын тулд бид GCE-д өөрийн Apache Airflow тогтолцоог бий болгосон бөгөөд үүнийг үйлдвэрлэлд ажиллуулах, Vertica зэрэг илүү олон мэдээллийн эх сурвалжийг дэмжих боломжтой болгохоор бэлтгэж байна.
Өгөгдлийг BigQuery болгон хувиргахын тулд хэрэглэгчид хуваарьт асуулга ашиглан энгийн SQL өгөгдлийн шугам үүсгэдэг. Хамааралтай олон үе шаттай нарийн төвөгтэй дамжуулах хоолойн хувьд бид өөрийн Airflow framework эсвэл Cloud Composer-ийг ашиглахаар төлөвлөж байна. .
Бүтээмж
BigQuery нь их хэмжээний өгөгдөл боловсруулах ерөнхий зориулалттай SQL асуулгад зориулагдсан. Энэ нь гүйлгээний өгөгдлийн санд шаардагдах хоцролт багатай, дамжуулах чадвар өндөртэй асуулгад зориулагдаагүй эсвэл хэрэгжсэн бага хоцролттой хугацааны цувралын шинжилгээнд зориулагдаагүй болно. . Интерактив аналитик асуулгын хувьд манай хэрэглэгчид хариу өгөх хугацаа нэг минутаас бага байх болно. Бид эдгээр хүлээлтийг хангахын тулд BigQuery-ийн хэрэглээгээ төлөвлөх хэрэгтэй болсон. Хэрэглэгчиддээ урьдчилан таамаглаж болохуйц гүйцэтгэлийг хангахын тулд бид BigQuery функцийг ашигласан бөгөөд энэ нь төслийн эзэмшигчдэд асуулгадаа хамгийн бага зайг нөөцлөх боломжийг олгодог. BigQuery нь SQL асуулгыг гүйцэтгэхэд шаардагдах тооцоолох хүчин чадлын нэгж юм.
Бид тус бүр нь ойролцоогоор 800 TB өгөгдөл боловсруулдаг 1 гаруй асуулгад дүн шинжилгээ хийж, гүйцэтгэлийн дундаж хугацаа 30 секунд байсныг олж мэдсэн. Мөн бид гүйцэтгэл нь янз бүрийн төсөл, даалгаварт бидний үүрийг ашиглахаас ихээхэн хамаардаг гэдгийг олж мэдсэн. Бид үйлдвэрлэлийн ашиглалтын тохиолдол болон онлайн шинжилгээнд зориулж гүйцэтгэлийг хадгалахын тулд үйлдвэрлэлийн болон түр зуурын нөөцөө тодорхой тодорхойлох шаардлагатай болсон. Энэ нь бидний слотын захиалга болон төслийн шатлалын загварт ихээхэн нөлөөлсөн.
Бид ойрын өдрүүдэд орчуулгын хоёрдугаар хэсэгт өгөгдлийн удирдлага, функциональ байдал, системийн өртгийн талаар ярих болно, гэхдээ одоо бид хүн бүрийг урьж байна. , энэ үеэр та сургалтын талаар дэлгэрэнгүй мэдээлэл авахаас гадна манай мэргэжилтэн Егор Матешукаас (МаксимаТелекомын мэдээллийн ахлах инженер) асуулт асуух боломжтой.
Цааш унших:
Эх сурвалж: www.habr.com