Та хэд хэдэн бэлэн нээлттэй эхийн хэрэгслүүдийг хурдан бөгөөд хялбар холбож, stackoverflow-ийн зөвлөмжийн дагуу "олон үсэг"-ийн талаар дэлгэрэнгүй мэдээлэл авалгүйгээр "ухамсараа унтраасан" байдлаар тохируулж, ажиллуулж болох гайхалтай цаг үед амьдарч байна. тэдгээрийг арилжааны зориулалтаар ашиглах. Та шинэчлэх/өргөжүүлэх шаардлагатай үед эсвэл хэн нэгэн санамсаргүйгээр хэд хэдэн машиныг дахин ачаалах үед - ямар нэгэн хий хоосон мөрөөдөл эхэлсэн, бүх зүйл танигдахын аргагүй ээдрээтэй болсон, эргэж буцах зүйлгүй, ирээдүй бүрхэг, аюулгүй гэдгийг та ойлгох болно. програмчлалын оронд зөгий үржүүлж, бяслаг хий.
Толгойгоо алдаатай, саарал өнгөтэй болсон туршлагатай хамт олон олон арван серверүүд дээр "загварлаг хэлээр" олон арван сервер дээр "шоо" хэлбэрээр "контейнер" -ийг гайхалтай хурдан байрлуулах талаар бодож байгаа нь дэмий хоосон зүйл биш юм. асинхрон блоклохгүй I/O, даруухан инээмсэглэ. Мөн тэд чимээгүйхэн "man ps"-ийг дахин уншиж, нүд нь цус болтлоо "nginx" эх кодыг судалж, нэгжийн тест бичиж, бичиж, бичдэг. Шинэ жилийн өмнөх шөнө "энэ бүх зүйл" нэг өдөр гацах үед хамгийн сонирхолтой зүйл ирнэ гэдгийг хамт олон мэддэг. Тэдэнд зөвхөн unix-ийн мөн чанар, цээжилсэн TCP/IP төлөвийн хүснэгт, эрэмбэлэх-хайлтын үндсэн алгоритмуудын талаар гүнзгий ойлголттой байх нь л туслах болно. Хонх дуугарах үед системийг сэргээхийн тулд.
Өө тийм ээ, би жаахан сатаарсан, гэхдээ би хүлээлтийн байдлыг дамжуулж чадсан гэж найдаж байна.
Өнөөдөр би DataLake-д тохиромжтой, хямд стекийг ашиглах туршлагаасаа хуваалцахыг хүсч байна, энэ нь компанийн аналитик даалгаврын ихэнхийг огт өөр бүтцийн хэлтэсүүдэд шийддэг.
Хэсэг хугацааны өмнө бид компаниудад бүтээгдэхүүний болон техникийн аналитикийн үр жимс (машины сургалтын хэлбэрээр бялуу дээрх мөстөлтийг дурдахгүй) улам бүр хэрэгцээтэй болж, чиг хандлага, эрсдлийг ойлгохын тулд бид цуглуулж, дүн шинжилгээ хийх хэрэгтэй гэдгийг ойлгосон. улам олон хэмжүүр.
Bitrix24 дээрх үндсэн техникийн аналитик
Хэдэн жилийн өмнө Bitrix24 үйлчилгээг нэвтрүүлэхтэй зэрэгцэн бид дэд бүтцэд тулгарч буй асуудлуудыг хурдан харж, дараагийн алхмыг төлөвлөхөд туслах энгийн бөгөөд найдвартай аналитик платформыг бий болгоход цаг хугацаа, нөөцийг идэвхтэй зарцуулсан. Мэдээжийн хэрэг, аль болох энгийн, ойлгомжтой бэлэн багаж хэрэгслийг авахыг зөвлөж байна. Үүний үр дүнд мониторинг хийх зорилгоор нагиос, аналитик болон дүрслэлд зориулж мунин сонгосон. Одоо бид нагио дахь мянга мянган чек, мунин дахь олон зуун графиктай бөгөөд манай хамт олон өдөр бүр амжилттай ашиглаж байна. Хэмжигдэхүүнүүд нь тодорхой, графикууд нь тодорхой, систем нь хэдэн жилийн турш найдвартай ажиллаж байгаа бөгөөд түүнд шинэ туршилтууд, графикууд байнга нэмэгддэг: шинэ үйлчилгээг ашиглалтад оруулахад бид хэд хэдэн тест, графикуудыг нэмдэг. Амжилт хүсье.
Судасны хуруу - Техникийн дэвшилтэт аналитик
Асуудлын талаархи мэдээллийг "аль болох хурдан" авах хүсэл нь биднийг энгийн бөгөөд ойлгомжтой хэрэгслүүд болох pinba болон xhprof ашиглан идэвхтэй туршилт хийхэд хүргэсэн.
Пинба бидэнд PHP дэх вэб хуудсын хэсгүүдийн ажиллах хурдны талаарх статистикийг UDP багцаар илгээсэн бөгөөд бид онлайнаар MySQL хадгалах сангаас (Pinba нь үйл явдлын хурдан аналитик хийхэд зориулагдсан MySQL хөдөлгүүртэй ирдэг) асуудлын товч жагсаалтыг харж, хариу өгөх боломжтой болсон. тэд. Мөн xhprof нь үйлчлүүлэгчдээс хамгийн удаан PHP хуудасны гүйцэтгэлийн графикийг цуглуулж, үүнд юу хүргэж болохыг шинжлэх боломжийг автоматаар олгосон - тайван, цай эсвэл илүү хүчтэй зүйл асгах.
Хэсэг хугацааны өмнө уг хэрэгслийг домогт Лусений номын сан болох Elastic/Kibana-д төгс хэрэгжүүлсэн урвуу индексжүүлэх алгоритм дээр суурилсан өөр нэг энгийн бөгөөд ойлгомжтой хөдөлгүүрээр дүүргэсэн. Бүртгэлд байгаа үйл явдлууд дээр үндэслэн бичиг баримтыг урвуу люсен индекс болгон олон урсгалтай бүртгэх энгийн санаа, фасет хуваах замаар тэдгээрийг хурдан хайх нь үнэхээр ашигтай болсон.
Кибана дахь "хувин" "дээшээ урсах" зэрэг бага түвшний ойлголттой, хараахан бүрэн мартагдахгүй байгаа харилцааны алгебрийн хэлийг дахин зохион бүтээсэн дүрслэл нь техникийн хувьд нэлээд техникийн дүр төрхтэй байсан ч уг хэрэгсэл нь дараах ажлуудыг хийхэд бидэнд тусалж эхэлсэн.
- Bitrix24 клиент сүүлийн нэг цагийн дотор p1 портал дээр хэдэн PHP алдаа гаргасан бэ, аль нь вэ? Ойлгож, уучилж, хурдан засаарай.
- Өнгөрсөн 24 цагийн дотор Герман дахь порталууд дээр хичнээн видео дуудлага хийсэн, ямар чанартай, суваг/сүлжээнд ямар нэгэн хүндрэл гарсан уу?
- Үйлчилгээний хамгийн сүүлийн үеийн шинэчлэлтээр эх сурвалжаас эмхэтгэж, үйлчлүүлэгчдэд түгээсэн системийн ажиллагаа (PHP-д зориулсан манай C өргөтгөл) хэр сайн ажиллаж байна вэ? Алдаа дутагдал байна уу?
- Хэрэглэгчийн мэдээлэл PHP санах ойд багтах уу? Процессуудад хуваарилагдсан санах ойг хэтрүүлэхэд алдаа гарсан уу: "санах ойгүй"? Олж, саармагжуулах.
Энд тодорхой жишээ байна. Нарийвчилсан, олон түвшний туршилтыг үл харгалзан маш стандарт бус тохиолдол, гэмтсэн оролтын өгөгдөлтэй үйлчлүүлэгч ядаргаатай, гэнэтийн алдаа хүлээн авч, дохиолол дуугарч, үүнийг хурдан засах үйл явц эхлэв.
Нэмж дурдахад кибана нь тодорхой үйл явдлын талаархи мэдэгдлийг зохион байгуулах боломжийг олгодог бөгөөд богино хугацаанд компаний хэрэгслийг техникийн дэмжлэг, хөгжүүлэлтээс эхлээд QA хүртэл янз бүрийн хэлтсийн олон арван ажилтнууд ашиглаж эхэлсэн.
Компанийн аль ч хэлтсийн үйл ажиллагааг хянах, хэмжихэд хялбар болсон - сервер дээрх бүртгэлийг гараар шинжлэхийн оронд та зүгээр л нэг удаа задлан шинжлэлийн бүртгэлийг тохируулаад уян кластер руу илгээх хэрэгтэй, жишээлбэл, кибана дээр эргэцүүлэн үзэх. Хяналтын самбарт сүүлийн сарны 3 хэмжээст принтерээр хэвлэсэн хоёр толгойтой зулзага зарагдсан.
Бизнесийн үндсэн аналитик
Компаниудын бизнесийн аналитик нь ихэвчлэн Excel програмыг маш идэвхтэй ашиглахаас эхэлдэг гэдгийг бүгд мэддэг. Гэхдээ гол зүйл нь үүгээр дуусахгүй. Үүлэнд суурилсан Google Analytics нь гал дээр түлш нэмдэг - та сайн зүйлд хурдан дасаж эхэлдэг.
Эв найрамдалтай хөгжиж буй манай компанид илүү их мэдээлэлтэй илүү эрчимтэй ажилладаг "эш үзүүлэгчид" энд тэнд гарч ирэв. Илүү гүнзгий, олон талт тайлан гаргах хэрэгцээ байнга гарч эхэлсэн бөгөөд янз бүрийн хэлтсийн залуусын хүчин чармайлтаар хэсэг хугацааны өмнө энгийн бөгөөд практик шийдэл болох ClickHouse болон PowerBI-ийн хослолыг зохион байгуулжээ.
Удаан хугацааны туршид энэхүү уян хатан шийдэл нь маш их тусалсан боловч аажмаар ClickHouse бол резин биш бөгөөд үүнийг шоолж болохгүй гэсэн ойлголттой болсон.
ClickHouse, Druid, Vertica, Amazon RedShift (postgres дээр суурилсан) зэрэг нь нэлээд тохиромжтой аналитик (нийлбэр, нэгтгэл, баганаар хамгийн бага-дээд тал болон хэд хэдэн боломжит нэгдлүүд)-д зориулагдсан аналитик хөдөлгүүр гэдгийг сайн ойлгох нь чухал. ), учир нь MySQL болон бидний мэддэг бусад (мөр рүү чиглэсэн) өгөгдлийн сангаас ялгаатай нь харилцааны хүснэгтийн багануудыг үр ашигтай хадгалах зорилгоор зохион байгуулагдсан.
Үндсэндээ ClickHouse бол зүгээр л илүү багтаамжтай "мэдээллийн сан" бөгөөд цэг тус бүрээр оруулах нь тийм ч тохиромжтой биш (энэ нь ийм зорилготой, бүх зүйл зүгээр), гэхдээ тааламжтай аналитик, өгөгдөлтэй ажиллах сонирхолтой хүчирхэг функцүүдийн багц юм. Тийм ээ, та кластер үүсгэж болно, гэхдээ та хадаасыг микроскопоор цохих нь тийм ч зөв биш гэдгийг ойлгож байгаа тул бид өөр шийдлүүдийг хайж эхэлсэн.
Питон болон шинжээчдийн эрэлт хэрэгцээ
Манай компанид PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash хэл дээр 10-20 жил шахам өдөр бүр код бичдэг олон хөгжүүлэгч бий. Статистикийн хууль тогтоомжид үл нийцэх нэгээс олон гайхалтай гамшигт өртсөн олон туршлагатай системийн администраторууд байдаг (жишээлбэл, RAID-10-ийн ихэнх дискүүд хүчтэй аянга цохиход сүйрсэн). Ийм нөхцөлд "питон шинжээч" гэж юу болох нь удаан хугацааны туршид тодорхойгүй байсан. Python нь PHP шиг, зөвхөн нэр нь арай урт бөгөөд орчуулагчийн эх кодонд оюун санааг өөрчлөх бодисын ул мөр бага байдаг. Гэсэн хэдий ч илүү олон аналитик тайлангууд бий болохын хэрээр туршлагатай хөгжүүлэгчид numpy, pandas, matplotlib, seaborn зэрэг хэрэгслүүдийн нарийн мэргэшлийн ач холбогдлыг улам бүр ойлгож эхлэв.
Шийдвэрлэх үүрэг нь "логистик регресс" гэсэн үгсийн хослолоос болж ажилтнууд гэнэт ухаан алдаж, pyspark ашиглан их хэмжээний мэдээллийн талаар үр дүнтэй тайлагнаж байгааг харуулсан явдал байв.
Apache Spark, түүний харилцааны алгебр төгс тохирох функциональ парадигм, түүний чадварууд нь MySQL-д дассан хөгжүүлэгчдэд маш их сэтгэгдэл төрүүлсэн тул туршлагатай шинжээчдээр зэрэглэлээ бэхжүүлэх хэрэгцээ өдөр ирэх тусам тодорхой болсон.
Apache Spark/Hadoop-ийн цааш хөөрөх оролдлого ба юу нь скриптийн дагуу бүтсэнгүй
Гэсэн хэдий ч удалгүй Spark-тай холбоотой ямар нэг зүйл системчилсэн байдлаар буруу байгаа эсвэл гараа илүү сайн угаах шаардлагатай болсон нь тодорхой болсон. Хэрэв Hadoop/MapReduce/Lucene стекийг нэлээн туршлагатай програмистууд хийсэн бол Java хэл дээрх эх код эсвэл Дуг Куттингийн Луцен хэл дээрх санааг сайтар ажиглавал Spark гэнэт Scala хэмээх чамин хэлээр бичигдсэн байх нь ойлгомжтой. практик байдлын үүднээс маш маргаантай бөгөөд одоогоор хөгжөөгүй байна. Мөн санах ойн хуваарилалт бүхий логикгүй, тунгалаг бус ажлын улмаас Spark кластер дээрх тооцоо тогтмол буурч байгаа нь (олон товчлуурууд нэг дор ирдэг) эргэн тойронд ургах зайтай байгаа гэрэлт цагираг үүсгэдэг. Нэмж дурдахад, олон тооны хачирхалтай нээлттэй портууд, хамгийн ойлгомжгүй газруудад өсөн нэмэгдэж буй түр зуурын файлууд, ваарны тамын хамаарал зэрэг нь нөхцөл байдлыг улам хүндрүүлсэн бөгөөд энэ нь системийн администраторуудад бага наснаасаа мэдэгдэж байсан нэг мэдрэмжийг төрүүлэв: догшин үзэн ядалт (эсвэл магадгүй). тэд гараа савангаар угаах хэрэгтэй байсан).
Үүний үр дүнд бид Apache Spark (Spark Streaming, Spark SQL гэх мэт) болон Hadoop экосистемийг (гэх мэт) идэвхтэй ашигладаг хэд хэдэн дотоод аналитик төслүүдийг "амьд гарсан". Цаг хугацаа өнгөрөхөд бид "үүнийг" маш сайн бэлтгэж, хянаж сурсан ч өгөгдлийн шинж чанар өөрчлөгдсөн, RDD-ийн жигд хэшний тэнцвэргүй байдлаас болж "энэ нь" гэнэт уналтад орохоо больсон ч аль хэдийн бэлэн болсон зүйлийг авах хүсэл төрж байв. , шинэчлэгдэж, үүлэн дотор хаа нэгтээ удирдаж байсан нь улам бүр хүчирхэгжсэн. Яг энэ үед бид Amazon Web Services-ийн бэлэн үүл угсралтыг ашиглахыг оролдсон. улмаар үүнийг ашиглан асуудлыг шийдэхийг оролдсон. EMR нь Cloudera/Hortonworks-ийн бүтээцтэй адил экосистемийн нэмэлт программ хангамжаар Amazon-оос бэлтгэсэн Apache Spark юм.
Шинжилгээнд зориулсан резинэн файл хадгалах нь яаралтай хэрэгцээ юм
Биеийн янз бүрийн хэсэгт түлэгдэх Hadoop/Spark-ийг "хоол хийх" туршлага дэмий хоосон байсангүй. Техник хангамжийн эвдрэлд тэсвэртэй, өөр өөр системээс файлуудыг өөр өөр форматаар хадгалах, эдгээр өгөгдөл дээр үндэслэн тайлангуудыг үр ашигтай, цаг хэмнэлттэй түүвэрлэх боломжтой нэг, хямд, найдвартай файлын санг бий болгох хэрэгцээ гарч ирэв. улам тодорхой болж байна.
Мөн би энэ платформын программ хангамжийг шинэчлэх нь 20 хуудас Java мөрүүдийг уншиж, Spark History Server болон арын гэрэлтүүлэгтэй томруулдаг шил ашиглан кластерын километрийн нарийвчилсан бүртгэлд дүн шинжилгээ хийх шинэ жилийн хар дарсан зүүд биш байгаасай гэж хүссэн. Сайн сонгогдоогүй эх сурвалжийн өгөгдлийг хуваах алгоритмаас болж өгөгдлийг багасгах ажилтан санах ойгүй болсон үед хөгжүүлэгчийн стандарт MapReduce хүсэлт ажиллахаа больсон тохиолдолд энгийн бөгөөд ил тод хэрэгсэлтэй болохыг хүссэн.
Amazon S3 нь DataLake-д нэр дэвшигч мөн үү?
Hadoop/MapReduce-ийн туршлагаас харахад бидэнд өргөтгөх боломжтой, найдвартай файлын систем, түүн дээр нь өгөгдөлд ойртож, сүлжээгээр дамжуулан өгөгдөл дамжуулахгүйн тулд өргөтгөх боломжтой ажилчид хэрэгтэй гэдгийг харуулсан. Ажилчид өөр өөр форматтай өгөгдлийг унших чадвартай байх ёстой, гэхдээ шаардлагагүй мэдээллийг уншихгүй байх, ажилчдад тохиромжтой форматаар өгөгдлийг урьдчилан хадгалах боломжтой байх ёстой.
Дахин нэг удаа, үндсэн санаа. Том өгөгдлийг нэг кластер аналитик хөдөлгүүрт "цутгах" хүсэл байхгүй бөгөөд энэ нь эрт орой хэзээ нэгэн цагт амьсгал боогдуулж, та үүнийг муухай болгох хэрэгтэй болно. Би зүгээр л файлуудыг ойлгомжтой форматаар хадгалж, өөр өөр боловч ойлгомжтой хэрэгслээр үр дүнтэй аналитик асуулга хийхийг хүсч байна. Мөн өөр өөр форматтай олон файлууд байх болно. Хөдөлгүүрийг биш, харин эх сурвалжийг задлах нь дээр. Бидэнд өргөтгөх боломжтой, бүх нийтийн DataLake хэрэгтэй, бид шийдсэн ...
Хэрэв та Hadoop-оос өөрийн гараар жигнэмэг бэлтгэх шаардлагагүйгээр танил, сайн мэдэх Amazon S3 үүл хадгалах санд файл хадгалвал яах вэ?
Хувийн мэдээлэл нь "бага" гэдэг нь ойлгомжтой, гэхдээ бид үүнийг тэндээс гаргаж аваад "үр дүнтэй жолоодох" бол бусад өгөгдлийн талаар яах вэ?
Амазоны вэб үйлчилгээний кластер-биг өгөгдөл-аналитик экосистем - маш энгийн үгээр
AWS-тэй хийсэн бидний туршлагаас харахад Apache Hadoop/MapReduce нь тэнд удаан хугацааны турш янз бүрийн соусын дор идэвхтэй ашиглагдаж байсан, жишээлбэл DataPipeline үйлчилгээнд (би хамт олондоо атаархаж байна, тэд үүнийг хэрхэн зөв бэлтгэхийг сурсан). Энд бид DynamoDB хүснэгтүүдээс өөр өөр үйлчилгээнүүдийн нөөцлөлтийг тохируулсан:
Мөн тэд хэдэн жилийн турш цаг шиг суулгагдсан Hadoop/MapReduce кластерууд дээр тогтмол ажиллаж байна. "Үүнийг тохируулаад март":
Та мөн Бархасбадийн зөөврийн компьютеруудыг үүлэн дээр шинжээчдэд зориулан тохируулж, AWS SageMaker үйлчилгээг ашиглан хиймэл оюун ухааны загваруудыг сургаж, тулалдаанд оруулснаар дата сатанизмд үр дүнтэй оролцох боломжтой. Энэ нь бидний хувьд иймэрхүү харагдаж байна:
Тийм ээ, та өөртөө эсвэл үүлэн дэх шинжээчдээ зориулж зөөврийн компьютер аваад Hadoop/Spark кластерт хавсаргаж, тооцоо хийж, дараа нь бүх зүйлийг хийж болно:
Бие даасан аналитик төслүүдэд үнэхээр тохиромжтой бөгөөд зарим хүмүүсийн хувьд бид EMR үйлчилгээг том хэмжээний тооцоолол, аналитик хийхэд амжилттай ашигласан. DataLake-ийн системийн шийдлийн талаар юу хэлэх вэ, энэ нь ажиллах уу? Энэ мөчид бид итгэл найдвар, цөхрөлийн ирмэг дээр байсан бөгөөд эрэл хайгуулаа үргэлжлүүлэв.
AWS цавуу - стероидууд дээр маш сайн савласан Apache Spark
AWS нь "Hive/Pig/Spark" стекийн өөрийн гэсэн хувилбартай болох нь тогтоогдсон. Hive-ийн үүрэг, i.e. DataLake дахь файл, тэдгээрийн төрлүүдийн каталогийг "Өгөгдлийн каталог" үйлчилгээ гүйцэтгэдэг бөгөөд энэ нь Apache Hive форматтай нийцэж байгааг нуудаггүй. Та энэ үйлчилгээнд өөрийн файлууд хаана байрлаж байгаа, ямар форматтай байгаа талаарх мэдээллийг нэмэх хэрэгтэй. Өгөгдөл нь зөвхөн s3-д төдийгүй мэдээллийн санд байж болно, гэхдээ энэ нь энэ нийтлэлийн сэдэв биш юм. Манай DataLake мэдээллийн санг хэрхэн зохион байгуулсныг эндээс үзнэ үү.
Файлууд бүртгэгдсэн, гайхалтай. Хэрэв файлууд шинэчлэгдсэн бол бид мөлхөгчдийг гараар эсвэл хуваарийн дагуу ажиллуулдаг бөгөөд энэ нь нуураас тэдгээрийн талаарх мэдээллийг шинэчилж, хадгалах болно. Дараа нь нуурын мэдээллийг боловсруулж, үр дүнг хаа нэгтээ байршуулах боломжтой. Хамгийн энгийн тохиолдолд бид мөн s3 руу байршуулдаг. Мэдээллийн боловсруулалтыг хаана ч хийх боломжтой боловч AWS Glue API-ээр дамжуулан дэвшилтэт боломжуудыг ашиглан Apache Spark кластер дээр боловсруулалтыг тохируулахыг зөвлөж байна. Үнэн хэрэгтээ та pyspark номын санг ашиглан хуучин сайн мэддэг python кодыг авч, Hadoop-ийн гүн рүү ухаж, docker-moker контейнеруудыг чирэхгүйгээр, хараат байдлын зөрчилдөөнийг арилгахгүйгээр тодорхой хүчин чадалтай кластерын N зангилаа дээр гүйцэтгэлийг нь хянах боломжтой. .
Дахин нэг энгийн санаа. Apache Spark-ийг тохируулах шаардлагагүй, та зүгээр л pyspark-д зориулж python код бичиж, үүнийг өөрийн ширээний компьютер дээр туршиж үзээд, үүлэн доторх том кластер дээр ажиллуулж, эх өгөгдөл хаана байгаа, үр дүнг хаана байрлуулахаа зааж өгөх хэрэгтэй. Заримдаа энэ нь шаардлагатай бөгөөд ашигтай байдаг бөгөөд бид үүнийг хэрхэн тохируулахыг эндээс үзнэ үү:
Тиймээс, хэрэв та Spark кластер дээр s3 дахь өгөгдлийг ашиглан ямар нэгэн зүйлийг тооцоолох шаардлагатай бол бид python/pyspark дээр код бичиж, туршиж үзээд үүлэнд амжилт хүсье.
Оркестрийн талаар юу хэлэх вэ? Хэрэв даалгавар унасан, алга болвол яах вэ? Тийм ээ, Apache Pig хэв маягаар гоёмсог хоолой хийхийг санал болгож байгаа бөгөөд бид үүнийг туршиж үзсэн боловч одоогоор бид PHP болон JavaScript дээр гүнзгий тохируулсан зохион байгуулалтаа ашиглахаар шийдсэн (би ойлгож байна, танин мэдэхүйн диссонанс байдаг, гэхдээ энэ нь ажилладаг. жил, алдаагүй).
Нууранд хадгалагдсан файлуудын формат нь гүйцэтгэлийн түлхүүр юм
Өөр хоёр гол зүйлийг ойлгох нь маш чухал юм. Нуур дахь файлын өгөгдлийн асуулгыг аль болох хурдан гүйцэтгэж, шинэ мэдээлэл нэмэгдэхэд гүйцэтгэл буурахгүй байхын тулд дараахь зүйлийг хийх шаардлагатай.
- Файлын баганыг тусад нь хадгалаарай (багананд юу байгааг ойлгохын тулд бүх мөрийг унших шаардлагагүй болно). Үүний тулд бид шахалт бүхий паркетан форматыг авсан
- Файлуудыг хэл, жил, сар, өдөр, долоо хоног гэх мэт хавтсанд хуваах нь маш чухал юм. Энэ төрлийн хэлтэрхийг ойлгодог хөдөлгүүрүүд бүх өгөгдлийг дараалан шигшихгүйгээр зөвхөн шаардлагатай хавтаснуудыг л харна.
Үндсэндээ ийм байдлаар та эх өгөгдлийг дээд талд нь өлгөгдсөн аналитик хөдөлгүүрт хамгийн үр ашигтай хэлбэрээр байрлуулдаг бөгөөд тэдгээр нь жижиглэсэн фолдеруудад ч гэсэн файлуудаас зөвхөн шаардлагатай баганыг сонгон оруулж уншиж чаддаг. Та өгөгдлийг хаана ч "бөглөх" шаардлагагүй (хадгалах нь зүгээр л тэсрэх болно) - зүгээр л зөв форматаар файлын системд ухаалгаар оруулаарай. Мэдээжийн хэрэг, багануудыг задлахын тулд эхлээд кластераар мөр мөрөөр унших ёстой асар том csv файлыг DataLake-д хадгалах нь тийм ч зохимжгүй гэдгийг эндээс ойлгох хэрэгтэй. Энэ бүхэн яагаад болоод байгаа нь тодорхойгүй байгаа бол дээрх хоёр зүйлийн талаар дахин бодоорой.
AWS Athena - хайрцагт үүр
Тэгээд нуур үүсгэж байхдаа бид санамсаргүй байдлаар Амазон Афинатай таарав. Гэнэт бидний асар том бүртгэлийн файлуудыг зөв (паркетан) баганын форматаар хавтасны хэлтэрхий болгон байрлуулснаар та тэдгээрээс маш хурдан мэдээлэл сайтай сонголтуудыг хийж, Apache Spark/Glue кластергүйгээр тайлан гаргах боломжтой болох нь гэнэт гарч ирэв.
s3 дахь өгөгдлөөр ажилладаг Athena хөдөлгүүр нь домогт суурилсан - s3 болон Hadoop-аас Кассандра болон энгийн текст файлууд хүртэл өгөгдөл боловсруулах, хаана байгаа өгөгдлийг нь авах МАНП (массив параллель боловсруулалт) гэр бүлийн төлөөлөл. Та зүгээр л Athena-аас SQL хайлтыг гүйцэтгэхийг хүсэх хэрэгтэй бөгөөд дараа нь бүх зүйл "хурдан бөгөөд автоматаар ажилладаг". Афина бол "ухаалаг" гэдгийг анхаарах нь чухал бөгөөд энэ нь зөвхөн шаардлагатай хавтаснууд руу ордог бөгөөд зөвхөн хүсэлтэд шаардлагатай багануудыг уншдаг.
Афина руу хийх хүсэлтийн үнэ нь бас сонирхолтой юм. Бид төлдөг . Тэдгээр. минутанд кластерт байгаа машинуудын тоогоор биш, харин... 100-500 машин дээр бодитоор сканнердсан өгөгдлийн хувьд зөвхөн хүсэлтийг биелүүлэхэд шаардлагатай өгөгдөл.
Зөв хуваасан хавтаснуудаас зөвхөн шаардлагатай баганыг хүссэнээр Афина үйлчилгээ сард хэдэн арван долларын өртөгтэй болох нь тогтоогдсон. Кластер дээрх аналитиктай харьцуулахад гайхалтай, бараг үнэгүй!
Дашрамд хэлэхэд, бид s3-д өгөгдөлөө хэрхэн хуваах вэ:
Үүний үр дүнд богино хугацаанд компанийн мэдээллийн аюулгүй байдлаас эхлээд аналитик хүртэлх огт өөр хэлтэсүүд Афина руу идэвхтэй хүсэлт гаргаж эхэлсэн бөгөөд хэдхэн секундын дотор нэлээд урт хугацаанд "том" өгөгдлөөс хэрэгтэй хариултуудыг хурдан хүлээн авч эхлэв: сар, хагас жил гэх мэт П.
Гэхдээ бид цаашаа явж, хариулт авахын тулд үүлэнд очиж эхлэв : Шинжээч нь танил консол дээр SQL асуулга бичдэг бөгөөд энэ нь 100-500 машин дээр "пенни төлөө" s3 руу өгөгдөл илгээж, ихэвчлэн хэдхэн секундын дотор хариултыг буцаадаг. Тав тухтай. Бас хурдан. Би одоо хүртэл итгэж чадахгүй байна.
Үүний үр дүнд бид өгөгдлийг s3 дээр, үр ашигтай багана хэлбэрээр хадгалахаар шийдсэн бөгөөд өгөгдлийг хавтас болгон хуваах замаар... DataLake болон хурдан бөгөөд хямд аналитик системийг үнэгүй хүлээн авлаа. Тэгээд тэр компанид маш их алдартай болсон, учир нь... нь SQL-г ойлгодог бөгөөд кластеруудыг эхлүүлэх/зогсоох/тохируулснаас илүү хурдтай ажилладаг. "Хэрэв үр дүн нь адилхан бол яагаад илүү их мөнгө төлөх ёстой вэ?"
Афины хүсэлт иймэрхүү харагдаж байна. Хэрэв хүсвэл мэдээжийн хэрэг та хангалттай хэмжээгээр үүсгэж болно , гэхдээ бид өөрсдийгөө энгийн бүлэглэлээр хязгаарлах болно. Хэдэн долоо хоногийн өмнө үйлчлүүлэгч вэб серверийн бүртгэлд ямар хариу кодтой байсныг харцгаая, мөн алдаа байхгүй эсэхийг шалгацгаая:
үр дүн нь
Урт, гэхдээ хэцүү замыг туулж, эрсдэл, хүндрэлийн түвшин, дэмжлэгийн өртгийг тогтмол үнэлж, бид хурд болон өмчлөлийн өртгөөр бидэнд таалагдах DataLake болон аналитик шийдлийг олсон.
Компанийн огт өөр хэлтэсүүдийн хэрэгцээнд зориулж үр дүнтэй, хурдан бөгөөд хямдхан ашиглах DataLake-ийг бий болгох нь архитектороор ажиллаж байгаагүй, дөрвөлжин дээр дөрвөлжин зурахыг мэддэггүй туршлагатай хөгжүүлэгчдийн чадавхид бүрэн багтах нь тодорхой болсон. сумнууд болон Hadoop экосистемийн 50 нэр томъёог мэддэг.
Аяллын эхэнд нээлттэй, хаалттай программ хангамж, хойч үеийнхээ өмнө хүлээсэн үүрэг хариуцлагын ачааг ойлгох олон зэрлэг амьтны хүрээлэнгээс толгой минь салж байлаа. Зүгээр л өөрийн DataLake-г энгийн хэрэгслээс бүтээж эхлээрэй: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., санал хүсэлтийг цуглуулж, болж буй үйл явцын физикийг гүнзгий ойлгох. Бүх зүйл төвөгтэй, бүдэг бадаг - үүнийг дайснууд болон өрсөлдөгчдөд өг.
Хэрэв та клоуд руу орохыг хүсэхгүй байгаа бөгөөд нээлттэй эхийн төслүүдийг дэмжих, шинэчлэх, засварлахыг хүсэхгүй байгаа бол Hadoop болон Presto-той хямд оффисын машинууд дээр манайхтай төстэй схемийг бүтээж болно. Хамгийн гол нь зогсохгүй, урагшлахгүй, тоолж, энгийн бөгөөд тодорхой шийдлүүдийг эрэлхийл, тэгвэл бүх зүйл бүтнэ! Бүгдэд нь амжилт хүсье, дахин уулзъя!
Эх сурвалж: www.habr.com