Энэ бол аналитик системийн тухай цуврал нийтлэлийн хоёр дахь хэсэг юм ().
Өгөгдлийг сайтар боловсруулж, үр дүнг тайлбарлах нь бараг бүх төрлийн бизнест тустай гэдэгт өнөөдөр эргэлзэх зүйл алга. Үүнтэй холбогдуулан аналитик системүүд параметрүүдээр улам бүр ачаалалтай болж, програмууд дахь триггер болон хэрэглэгчийн үйл явдлын тоо нэмэгдэж байна.
Ийм учраас компаниуд дүн шинжилгээ хийж, оновчтой шийдвэр гаргахын тулд шинжээчдэд улам бүр түүхий мэдээллийг өгч байна. Компанийн хувьд аналитик системийн ач холбогдлыг дутуу үнэлж болохгүй бөгөөд систем өөрөө найдвартай, тогтвортой байх ёстой.
Үйлчлүүлэгчийн шинжээчид
Хэрэглэгчийн аналитик нь компани албан ёсны SDK-ээр дамжуулан вэбсайт эсвэл програм руугаа холбогдож, өөрийн кодын санд нэгтгэж, үйл явдлын триггерүүдийг сонгодог үйлчилгээ юм. Энэ аргын илэрхий сул тал бий: таны сонгосон үйлчилгээний хязгаарлалтаас болж цуглуулсан бүх өгөгдлийг таны хүссэнээр боловсруулахгүй байж болно. Жишээлбэл, нэг систем дээр MapReduce даалгавруудыг ажиллуулахад амаргүй байх болно, нөгөө систем дээр та загвараа ажиллуулах боломжгүй болно. Өөр нэг сул тал бол үйлчилгээний тогтмол (сүртэй) төлбөр байх болно.
Зах зээл дээр хэрэглэгчийн аналитикийн олон шийдлүүд байдаг боловч эрт орой хэзээ нэгэн цагт шинжээчид ажил бүрт тохирох бүх нийтийн үйлчилгээ байдаггүй (эдгээр бүх үйлчилгээний үнэ байнга өсч байдаг) тулгардаг. Ийм нөхцөлд компаниуд шаардлагатай бүх тохиргоо, чадавхи бүхий өөрсдийн аналитик системийг бий болгохоор шийддэг.
Серверийн шинжээчид
Сервер талын аналитик нь компани дотор өөрийн серверүүд болон (ихэвчлэн) өөрийн хүчин чармайлтаар байршуулж болох үйлчилгээ юм. Энэ загварт хэрэглэгчийн бүх үйл явдал дотоод сервер дээр хадгалагдаж, хөгжүүлэгчид өөр өөр хадгалалтын мэдээллийн санг туршиж үзэх, хамгийн тохиромжтой архитектурыг сонгох боломжийг олгодог. Хэдийгээр та гуравдагч талын үйлчлүүлэгчийн аналитикийг зарим ажилд ашиглахыг хүсч байгаа ч гэсэн боломжтой хэвээр байх болно.
Сервер талын аналитикийг хоёр аргаар байрлуулж болно. Нэгдүгээрт: нээлттэй эхийн зарим хэрэгслийг сонгоод, тэдгээрийг машин дээрээ байрлуулж, бизнесийн логикийг хөгжүүл.
Плюсы
Минусы
Та хүссэн зүйлээ өөрчлөх боломжтой
Энэ нь ихэвчлэн маш хэцүү бөгөөд тусдаа хөгжүүлэгчид шаарддаг
Хоёрдугаарт: SaaS үйлчилгээг (Amazon, Google, Azure) өөрөө ашиглахын оронд аваарай. Гурав дахь хэсэгт бид SaaS-ийн талаар илүү дэлгэрэнгүй ярих болно.
Плюсы
Минусы
Энэ нь дунд хэмжээний хувьд хямд байж болох ч том өсөлттэй үед энэ нь хэтэрхий үнэтэй хэвээр байх болно
Бүх параметрүүдийг хянах боломжгүй болно
Захиргааг бүхэлд нь үйлчилгээ үзүүлэгчийн мөрөн дээр шилжүүлдэг
Үйлчилгээнд юу байгаа нь үргэлж мэдэгддэггүй (энэ нь шаардлагагүй байж болно)
Серверийн аналитикийг хэрхэн цуглуулах вэ
Хэрэв бид үйлчлүүлэгчийн аналитик ашиглахаас татгалзаж, өөрийн гэсэн системийг бий болгохыг хүсч байвал юуны түрүүнд шинэ системийн архитектурыг сайтар бодох хэрэгтэй. Доор би та юуг анхаарч үзэх хэрэгтэй, яагаад алхам бүр хэрэгтэй вэ, ямар хэрэгслийг ашиглаж болох талаар алхам алхмаар хэлэх болно.
1. Мэдээлэл хүлээн авах
Үйлчлүүлэгчийн аналитикийн нэгэн адил юуны өмнө компанийн шинжээчид ирээдүйд судлахыг хүсч буй үйл явдлын төрлийг сонгон жагсаалтад цуглуулдаг. Ерөнхийдөө эдгээр үйл явдлууд нь "үйл явдлын загвар" гэж нэрлэгддэг тодорхой дарааллаар явагддаг.
Дараа нь гар утасны програм (вэб сайт) нь байнгын хэрэглэгчид (төхөөрөмжүүд) болон олон серверүүдтэй гэж төсөөлөөд үз дээ. Үйл явдлыг төхөөрөмжөөс сервер рүү найдвартай дамжуулахын тулд завсрын давхарга хэрэгтэй. Архитектураас хамааран хэд хэдэн өөр үйл явдлын дараалал байж болно.
Байна уу , энэ нь үйл явдлыг цуглуулах дараалал болгон ашигладаг.
Дагуу 2014 онд Apache Kafka-г бүтээгч программ хангамжийг Франц Кафкагийн нэрээр нэрлэхээр шийдсэн тул "энэ нь бичихэд оновчтой систем" бөгөөд Кафкагийн бүтээлүүдэд дуртай байсан. -
Бидний жишээнд олон тооны өгөгдөл үйлдвэрлэгч, өгөгдөл хэрэглэгчид (төхөөрөмж ба серверүүд) байдаг бөгөөд Кафка тэдгээрийг хооронд нь холбоход тусалдаг. Хэрэглэгчид үндсэн субьект болох дараагийн үе шатуудад илүү дэлгэрэнгүй тайлбарлах болно. Одоо бид зөвхөн өгөгдөл үйлдвэрлэгчдийг (үйл явдлыг) авч үзэх болно.
Кафка дараалал, хуваалт гэсэн ойлголтуудыг багтаасан бөгөөд энэ тухай өөр газраас илүү дэлгэрэнгүй уншсан нь дээр (жишээ нь: ). Дэлгэрэнгүй ярихгүйгээр гар утасны програмыг хоёр өөр үйлдлийн системд зориулж гаргасан гэж төсөөлөөд үз дээ. Дараа нь хувилбар бүр өөрийн тусдаа үйл явдлын урсгалыг үүсгэдэг. Продюсерууд Кафка руу үйл явдлуудыг илгээдэг бөгөөд тэдгээр нь тохиромжтой дараалалд бүртгэгддэг.
(зураг )
Үүний зэрэгцээ Кафка танд хэсэг хэсгээрээ уншиж, үйл явдлын урсгалыг мини багцаар боловсруулах боломжийг олгодог. Кафка бол өсөн нэмэгдэж буй хэрэгцээ шаардлагад нийцдэг маш тохиромжтой хэрэгсэл юм (жишээлбэл, үйл явдлын газарзүйн байршлаар).
Ихэвчлэн нэг хэлтэрхий хангалттай байдаг, гэхдээ масштаблах үед бүх зүйл илүү төвөгтэй болдог (үргэлж хийдэг шиг). Архитектур нь эвдрэлд тэсвэртэй байх ёстой тул үйлдвэрлэлд зөвхөн нэг физик хэлтэрхий ашиглахыг хэн ч хүсэхгүй байх. Кафкагаас гадна өөр нэг алдартай шийдэл байдаг - RabbitMQ. Бид үүнийг үйлдвэрлэлд үйл явдлын дүн шинжилгээ хийх дараалал болгон ашиглаагүй (хэрэв танд ийм туршлагатай бол энэ талаар тайлбар дээр хэлээрэй!). Гэсэн хэдий ч бид AWS Kinesis ашигласан.
Дараагийн алхам руу шилжихийн өмнө бид системийн өөр нэг давхаргыг дурдах хэрэгтэй - raw log storage. Энэ нь шаардлагатай давхарга биш боловч ямар нэг зүйл буруу болж, Кафка дахь үйл явдлын дарааллыг дахин тохируулсан тохиолдолд хэрэг болно. Түүхий лог хадгалах нь нарийн төвөгтэй, үнэтэй шийдэл шаарддаггүй бөгөөд та тэдгээрийг хаа нэгтээ зөв дарааллаар (хатуу диск дээр ч гэсэн) бичиж болно.
2. Үйл явдлын урсгалыг боловсруулж байна
Бид бүх үйл явдлыг бэлтгэж, зохих дараалалд оруулсны дараа бид боловсруулах алхам руу шилждэг. Энд би хамгийн түгээмэл хоёр боловсруулах хувилбарын талаар танд хэлэх болно.
Эхний сонголт бол Apache системд Spark Streaming-г идэвхжүүлэх явдал юм. Бүх Apache бүтээгдэхүүнүүд нь файлын хуулбар бүхий аюулгүй файлын систем болох HDFS дээр амьдардаг. Spark Streaming нь дамжуулах өгөгдөл, масштабыг сайн зохицуулдаг ашиглахад хялбар хэрэгсэл юм. Гэсэн хэдий ч үүнийг хадгалахад хэцүү байж магадгүй юм.
Өөр нэг сонголт бол өөрийн үйл явдал зохицуулагчийг бүтээх явдал юм. Үүнийг хийхийн тулд та жишээ нь Python програм бичиж, Docker дээр бүтээж, Кафкагийн дараалалд бүртгүүлэх хэрэгтэй. Докер зохицуулагчдад триггерүүд ирэхэд боловсруулалт эхэлнэ. Энэ аргын тусламжтайгаар та програмуудыг байнга ажиллуулж байх хэрэгтэй.
Бид дээр дурдсан сонголтуудын аль нэгийг сонгоод өөрөө боловсруулалт руу шилжсэн гэж бодъё. Процессорууд өгөгдлийн үнэн зөвийг шалгаж, хог хаягдал, "эвдэрсэн" үйл явдлуудыг шүүж эхлэх хэрэгтэй. Баталгаажуулахын тулд бид ихэвчлэн ашигладаг . Үүний дараа та өгөгдлийн зураглалыг хийж болно: янз бүрийн эх сурвалжаас авсан өгөгдлийг нийтлэг хүснэгтэд нэмэхийн тулд хэвийн болгож, стандартчилдаг.
3. Өгөгдлийн сан
Гурав дахь алхам бол хэвийн үйл явдлыг хадгалах явдал юм. Бэлэн аналитик системтэй ажиллахдаа бид тэдгээрт байнга хандах шаардлагатай болдог тул тохиромжтой мэдээллийн санг сонгох нь чухал юм.
Хэрэв өгөгдөл нь тогтмол схемд сайн тохирч байвал та сонгож болно эсвэл бусад багана мэдээллийн сан. Ингэснээр нэгтгэлүүд маш хурдан ажиллах болно. Сул тал нь схем нь хатуу бэхлэгдсэн тул дурын объектуудыг өөрчлөхгүйгээр (жишээлбэл, стандарт бус үйл явдал тохиолдох үед) нэмэх боломжгүй болно. Гэхдээ та маш хурдан тоолж чадна.
Бүтэцгүй өгөгдлийн хувьд та NoSQL ашиглаж болно, жишээлбэл, . Энэ нь HDFS дээр ажилладаг, сайн хуулбарладаг, та олон тохиолдлуудыг өсгөж чаддаг, алдааг тэсвэрлэдэг.
Та мөн илүү энгийн зүйлийг өсгөж болно, жишээлбэл, . Энэ нь нэлээд удаан бөгөөд бага хэмжээний хувьд. Гэхдээ давуу тал нь энэ нь маш энгийн, тиймээс эхлэхэд тохиромжтой.
4. Агрегатууд
Бүх үйл явдлыг анхааралтай хадгалсны дараа бид ирсэн багцаас бүх чухал мэдээллийг цуглуулж, мэдээллийн санг шинэчлэхийг хүсч байна. Дэлхий даяар бид холбогдох хяналтын самбар, хэмжүүрүүдийг авахыг хүсч байна. Жишээлбэл, үйл явдлуудаас хэрэглэгчийн профайлыг цуглуулж, ямар нэгэн байдлаар зан төлөвийг хэмжинэ. Үйл явдлуудыг нэгтгэж, цуглуулж, дахин хадгалдаг (хэрэглэгчийн хүснэгтэд). Үүний зэрэгцээ та шүүлтүүрийг нэгтгэгч-зохицуулагчтай холбох боломжтой системийг бий болгож чадна: зөвхөн тодорхой төрлийн үйл явдлаас хэрэглэгчдийг цуглуул.
Үүний дараа, хэрэв багийн хэн нэгэнд зөвхөн өндөр түвшний аналитик хэрэгтэй бол гадны аналитик системийг холбож болно. Та дахин Mixpanel авч болно. гэхдээ энэ нь нэлээд үнэтэй тул бүх хэрэглэгчийн үйл явдлыг тийш нь илгээдэггүй, зөвхөн шаардлагатай зүйлийг л илгээдэг. Үүнийг хийхийн тулд бид зарим түүхий үйл явдлууд эсвэл бидний өмнө нь нэгтгэсэн зүйлийг гадны систем, API эсвэл зар сурталчилгааны платформ руу шилжүүлэх зохицуулагчийг бий болгох хэрэгтэй.
5. Frontend
Та үүсгэсэн системд урд талын хэсгийг холбох хэрэгтэй. Сайн жишээ бол үйлчилгээ юм , нь хяналтын самбар бүтээхэд тусалдаг мэдээллийн сангийн GUI юм. Харилцаа хэрхэн ажилладаг вэ:
- Хэрэглэгч SQL асуулга хийдэг.
- Хариуд нь тэр тэмдэг хүлээн авдаг.
- Үүний тулд "шинэ дүрслэл" үүсгэж, өөртөө хадгалах боломжтой сайхан графикийг олж авна.
Үйлчилгээний дүрслэлүүд автоматаар шинэчлэгдэж байгаа тул та хяналтаа өөрчилж, хянах боломжтой. Редаш нь өөрөө зохион байгуулдаг бол үнэ төлбөргүй боловч SaaS-ийн хувьд сард 50 долларын үнэтэй болно.
дүгнэлт
Дээрх бүх алхмуудыг хийсний дараа та өөрийн серверийн аналитикийг үүсгэх болно. Энэ нь зөвхөн хэрэглэгчийн аналитикийг холбох шиг энгийн зүйл биш гэдгийг анхаарна уу, учир нь бүх зүйлийг өөрөө тохируулах шаардлагатай. Тиймээс, өөрийн системийг бий болгохын өмнө ноцтой аналитик системийн хэрэгцээг түүнд хуваарилахад бэлэн байгаа нөөцтэй харьцуулах нь зүйтэй.
Хэрэв та тооцооллыг хийсэн бөгөөд зардал нь хэтэрхий өндөр байгааг олж мэдсэн бол дараагийн хэсэгт би сервер талын аналитикийн хямд хувилбарыг хэрхэн хийх талаар ярих болно.
Уншсанд баярлалаа! Би сэтгэгдэл дээр асуулт асуухдаа баяртай байх болно.
Эх сурвалж: www.habr.com