Сайт дээр халдагчидтай тэмцэх автомат системийг бий болгох (луйвар)

Сүүлийн зургаан сар орчмын хугацаанд би ямар ч анхан шатны дэд бүтэцгүйгээр залилан (луйврын ажиллагаа, залилан гэх мэт)-тэй тэмцэх тогтолцоог бий болгож байна. Өнөөдрийн бидний олж, системдээ хэрэгжүүлсэн санаанууд нь олон залилангийн үйлдлийг илрүүлэх, дүн шинжилгээ хийхэд тусалдаг. Энэ нийтлэлд би техникийн хэсэг рүү орохгүйгээр бидний баримталж байсан зарчмууд, системийн өнөөгийн байдалд хүрэхийн тулд юу хийсэн тухай ярихыг хүсч байна.

Манай системийн зарчим

"Автомат" болон "хууран мэхлэх" гэх мэт нэр томъёог сонсохдоо та Apache сангийн экосистем болон мэдээллийн шинжлэх ухааны талбарт машин сурах, Apache Spark, Hadoop, Python, Airflow болон бусад технологийн талаар бодож эхлэх байх. Эдгээр хэрэгслүүдийг ашиглахад ихэвчлэн дурдагддаггүй нэг тал бий гэж би бодож байна: тэдгээрийг ашиглахын өмнө тэд танай байгууллагын систем дээр тодорхой урьдчилсан нөхцөлүүдийг бий болгохыг шаарддаг. Товчхондоо, танд дата нуур, хадгалах сан бүхий байгууллагын мэдээллийн платформ хэрэгтэй. Гэхдээ танд ийм платформ байхгүй ч энэ туршлагыг хөгжүүлэх шаардлагатай бол яах вэ? Миний доор тайлбарласан дараах зарчмууд нь бидэнд ашигтай санаа олохын оронд санаагаа сайжруулахад анхаарлаа төвлөрүүлэх хэмжээнд хүрэхэд тусалсан. Гэсэн хэдий ч энэ нь төслийн "давхар" биш юм. Төлөвлөгөөнд технологи, бүтээгдэхүүн талаасаа өөр олон зүйл бий.

1-р зарчим: Бизнесийн үнэ цэнэ юун түрүүнд

Бид "бизнесийн үнэ цэнийг" бүх хүчин чармайлтынхаа тэргүүн эгнээнд тавьдаг. Ерөнхийдөө аливаа автомат шинжилгээний систем нь өндөр түвшний автоматжуулалт, техникийн нарийн төвөгтэй системүүдийн бүлэгт багтдаг. Хэрэв та үүнийг эхнээс нь бий болговол бүрэн шийдлийг бий болгоход маш их цаг хугацаа шаардагдана. Бид бизнесийн үнэ цэнийг нэгдүгээрт, технологийн төлөвшлийг хоёрдугаарт тавихаар шийдсэн. Энэ нь бодит амьдрал дээр бид дэвшилтэт технологийг догма гэж хүлээн зөвшөөрдөггүй гэсэн үг юм. Бид яг одоо өөрт тохирох технологийг сонгодог. Цаг хугацаа өнгөрөхөд бид зарим модулийг дахин хэрэгжүүлэх шаардлагатай болж магадгүй юм. Энэ бол бидний хүлээн зөвшөөрсөн буулт юм.

2-р зарчим: Өргөтгөсөн оюун ухаан

Машин сургалтын шийдлүүдийг боловсруулахад гүнзгий оролцдоггүй ихэнх хүмүүс хүнийг орлуулах нь зорилго гэж бодож магадгүй гэж би бодож байна. Үнэн хэрэгтээ, машин сургалтын шийдлүүд нь төгс биш бөгөөд зөвхөн тодорхой хэсэгт солих боломжтой. Бид энэ санаагаа хэд хэдэн шалтгааны улмаас орхисон: залилан мэхлэх үйл ажиллагааны талаархи тэнцвэргүй өгөгдөл, машин сургалтын загварт зориулсан функцүүдийн бүрэн жагсаалтыг гаргаж чадахгүй байна. Үүний эсрэгээр бид сайжруулсан тагнуулын хувилбарыг сонгосон. Энэ бол танин мэдэхүйн технологи нь хүний ​​оюун ухааныг орлох бус харин сайжруулахад зориулагдсан гэдгийг онцолсон хиймэл оюун ухааныг дэмжих өөр нэг ойлголт юм. [1]

Үүнийг анхаарч үзвэл, машин сургалтын иж бүрэн шийдлийг эхнээс нь боловсруулахад асар их хүчин чармайлт шаардагдах бөгөөд энэ нь манай бизнест үнэ цэнийг бий болгохыг хойшлуулах болно. Бид домайны мэргэжилтнүүдийнхээ удирдлаган дор машин сургалтын давтагдах өсөн нэмэгдэж буй талтай системийг бүтээхээр шийдсэн. Ийм системийг хөгжүүлэх хамгийн төвөгтэй хэсэг нь зөвхөн энэ нь залилан мэхлэх үйл ажиллагаа мөн эсэх талаар манай шинжээчдэд жишээ судалгаа өгөх явдал юм. Ерөнхийдөө үйлчлүүлэгчдийн зан үйлийн аливаа гажигийг мэргэжилтнүүд шалгаж, ямар нэгэн байдлаар хариу өгөх шаардлагатай сэжигтэй тохиолдол байдаг. Эдгээр бүртгэгдсэн тохиолдлын цөөхөн хэдийг луйвар гэж ангилж болно.

3-р зарчим: Баян аналитик платформ

Манай системийн хамгийн хэцүү хэсэг бол системийн ажлын явцыг төгсгөлөөс нь шалгах явдал юм. Шинжээчид болон хөгжүүлэгчид дүн шинжилгээ хийхэд ашигласан бүх хэмжүүр бүхий түүхэн мэдээллийн багцыг хялбархан олж авах ёстой. Нэмж дурдахад мэдээллийн платформ нь одоо байгаа шалгуур үзүүлэлтүүдийг шинэ үзүүлэлтээр нөхөх хялбар арга замыг өгөх ёстой. Бидний үүсгэсэн процессууд нь зөвхөн програм хангамжийн процесс биш бөгөөд өмнөх үеүүдийг дахин тооцоолох, шинэ хэмжүүр нэмэх, өгөгдлийн урьдчилсан мэдээг өөрчлөхөд хялбар болгох ёстой. Манай үйлдвэрлэлийн систем бий болгож буй бүх өгөгдлийг хуримтлуулах замаар бид үүнд хүрч чадна. Ийм тохиолдолд өгөгдөл нь аажмаар саад болох болно. Бид ашигладаггүй өсөн нэмэгдэж буй өгөгдлийг хадгалах, хамгаалах шаардлагатай болно. Ийм нөхцөлд өгөгдөл нь цаг хугацаа өнгөрөх тусам хамааралгүй болох боловч үүнийг удирдахын тулд бидний хүчин чармайлт шаардлагатай хэвээр байна. Бидний хувьд өгөгдөл хуримтлуулах нь утгагүй байсан тул бид өөр арга хэрэглэхээр шийдсэн. Бид ангилахыг хүсч буй зорилтот байгууллагуудынхаа эргэн тойронд бодит цагийн мэдээллийн агуулахуудыг зохион байгуулж, зөвхөн хамгийн сүүлийн үеийн, шинэчлэгдсэн үеийг шалгах боломжийг олгодог өгөгдлийг хадгалахаар шийдсэн. Энэхүү хүчин чармайлтын сорилт нь манай систем нь олон төрлийн мэдээллийн сан, програм хангамжийн модулиудаас бүрддэг тул тууштай ажиллахын тулд сайтар төлөвлөх шаардлагатай байдаг.

Манай системийн дизайны үзэл баримтлал

Бид системдээ дөрвөн үндсэн бүрэлдэхүүн хэсэгтэй: залгих систем, тооцооллын систем, BI шинжилгээ, хянах систем. Эдгээр нь тодорхой тусгаарлагдсан зорилгод үйлчилдэг бөгөөд бид тодорхой хөгжлийн хандлагыг дагаж тэднийг тусгаарладаг.

Сайт дээр халдагчидтай тэмцэх автомат системийг бий болгох (луйвар)

Гэрээнд суурилсан загвар

Юуны өмнө, бүрэлдэхүүн хэсгүүд нь зөвхөн тэдгээрийн хооронд дамждаг тодорхой өгөгдлийн бүтцэд (гэрээ) найдах ёстой гэж бид тохиролцсон. Энэ нь тэдгээрийг хооронд нь нэгтгэхэд хялбар болгодог бөгөөд бүрэлдэхүүн хэсгүүдийн тодорхой найрлага (болон дараалал) ногдуулахгүй. Жишээлбэл, зарим тохиолдолд энэ нь хүлээн авах системийг дохиоллын хяналтын системтэй шууд нэгтгэх боломжийг олгодог. Ийм тохиолдолд энэ нь тохиролцсон мэдэгдлийн гэрээний дагуу хийгдэнэ. Энэ нь бусад бүрэлдэхүүн хэсгүүдийг ашиглаж болох гэрээг ашиглан хоёр бүрэлдэхүүн хэсгийг нэгтгэнэ гэсэн үг юм. Оролтын системээс хяналтын системд анхааруулга нэмэх нэмэлт гэрээг бид нэмэхгүй. Энэ арга нь урьдчилан тогтоосон хамгийн бага тооны гэрээг ашиглахыг шаарддаг бөгөөд систем, харилцаа холбоог хялбаршуулдаг. Үндсэндээ бид "Гэрээний анхны загвар" гэсэн арга барилыг авч, стриминг гэрээнд хэрэглэж байна. [2]

Хаа сайгүй цацаж байна

Тогтолцоонд төрөө хэмнэж, удирдах нь түүнийг хэрэгжүүлэхэд хүндрэл гарах нь дамжиггүй. Ерөнхийдөө төлөв нь аль ч бүрэлдэхүүн хэсгээс хандах боломжтой байх ёстой, энэ нь тууштай байх ёстой бөгөөд бүх бүрэлдэхүүн хэсгүүдэд хамгийн сүүлийн үеийн утгыг өгөх ёстой бөгөөд энэ нь зөв утгуудтай найдвартай байх ёстой. Нэмж дурдахад, хамгийн сүүлийн үеийн төлөвийг авахын тулд байнгын санах ой руу залгах нь бидний бодит цагийн дамжуулах хоолойд хэрэглэгддэг I/O-ийн хэмжээ болон алгоритмуудын нарийн төвөгтэй байдлыг нэмэгдүүлэх болно. Ийм учраас бид боломжтой бол улсын хадгалалтыг системээсээ бүрэн устгахаар шийдсэн. Энэ арга нь дамжуулагдсан мэдээллийн нэгжид (мессеж) шаардлагатай бүх өгөгдлийг оруулахыг шаарддаг. Жишээлбэл, хэрэв бид зарим ажиглалтын нийт тоог (тодорхой шинж чанартай үйлдлүүд эсвэл тохиолдлуудын тоо) тооцоолох шаардлагатай бол бид үүнийг санах ойд тооцоолж, ийм утгын урсгалыг үүсгэдэг. Хамааралтай модулиуд нь урсгалыг аж ахуйн нэгжүүдэд хувааж, хамгийн сүүлийн үеийн утгууд дээр ажиллахын тулд хуваах, багцлах аргыг ашиглана. Энэ арга нь ийм өгөгдөлд зориулсан байнгын диск хадгалах хэрэгцээг арилгасан. Манай систем Кафкаг мессеж брокер болгон ашигладаг бөгөөд KSQL-тэй мэдээллийн сан болгон ашиглах боломжтой. [3] Гэхдээ үүнийг ашиглах нь бидний шийдлийг Кафкатай хүчтэй холбож өгөх тул бид үүнийг ашиглахгүй гэж шийдсэн. Бидний сонгосон арга нь системд томоохон дотоод өөрчлөлт оруулахгүйгээр Кафкаг өөр мессеж брокероор солих боломжийг олгодог.

Энэ ойлголт нь бид дискний хадгалалт, мэдээллийн санг ашиглахгүй гэсэн үг биш юм. Системийн гүйцэтгэлийг шалгаж, дүн шинжилгээ хийхийн тулд бид янз бүрийн үзүүлэлт, төлөвийг илэрхийлдэг их хэмжээний өгөгдлийг дискэн дээр хадгалах хэрэгтэй. Энд хамгийн чухал зүйл бол бодит цагийн алгоритмууд ийм өгөгдлөөс хамаардаггүй явдал юм. Ихэнх тохиолдолд бид хадгалсан өгөгдлийг офлайн дүн шинжилгээ хийх, дибаг хийх, системээс гаргаж буй тодорхой тохиолдол, үр дүнг хянахад ашигладаг.

Манай системийн асуудлууд

Бид тодорхой түвшинд шийдвэрлэсэн тодорхой асуудлууд байгаа ч илүү нухацтай шийдлийг шаарддаг. Одоохондоо би тэдгээрийг энд дурдахыг хүсч байна, учир нь зүйл бүр өөрийн гэсэн нийтлэлийн үнэ цэнэтэй юм.

  • Бид өгөгдлийг автоматжуулсан дүн шинжилгээ хийх, илрүүлэх, судлахад чухал ач холбогдолтой, хамааралтай өгөгдлийг бий болгоход туслах үйл явц, бодлогыг тодорхойлох шаардлагатай хэвээр байна.
  • Шинжилгээний үр дүнг хамгийн сүүлийн үеийн өгөгдлөөр шинэчлэхийн тулд системийг автоматаар тохируулах явцад хүн оруулсан. Энэ нь зөвхөн манай загварын шинэчлэлт төдийгүй бидний үйл явцын шинэчлэл, бидний өгөгдлийг илүү сайн ойлгох явдал юм.
  • IF-ELSE ба ML-ийн детерминист хандлага хоорондын тэнцвэрийг олох. Хэн нэгэн: "ML бол цөхрөнгөө барсан хүмүүст зориулсан хэрэгсэл юм." Энэ нь та алгоритмуудаа хэрхэн оновчтой болгох, сайжруулах талаар ойлгохоо больсон үедээ ML ашиглахыг хүсэх болно гэсэн үг юм. Нөгөөтэйгүүр, детерминист арга нь урьдчилан тооцоолоогүй гажиг илрүүлэх боломжийг олгодоггүй.
  • Бидэнд таамаглал эсвэл өгөгдөл дэх хэмжигдэхүүн хоорондын хамаарлыг шалгах хялбар арга хэрэгтэй байна.
  • Систем нь олон түвшний жинхэнэ эерэг үр дүнтэй байх ёстой. Залилангийн хэргүүд нь системийн хувьд эерэг гэж үзэж болох бүх хэргүүдийн зөвхөн нэг хэсэг юм. Жишээлбэл, шинжээчид бүх сэжигтэй хэргүүдийг хянуулахаар хүлээж авахыг хүсдэг бөгөөд тэдний зөвхөн багахан хэсэг нь луйвартай байдаг. Систем нь бодит залилан эсвэл зүгээр л сэжигтэй үйлдэл эсэхээс үл хамааран шинжээчдэд бүх тохиолдлыг үр дүнтэйгээр хангах ёстой.
  • Өгөгдлийн платформ нь нэн даруй үүсгэж, тооцоолсон тооцоолол бүхий түүхэн мэдээллийн багцыг авах боломжтой байх ёстой.
  • Системийн бүрэлдэхүүн хэсгүүдийн аль нэгийг үйлдвэрлэлийн, туршилтын (бета) болон хөгжүүлэгчдэд зориулсан дор хаяж гурван өөр орчинд энгийн бөгөөд автоматаар байрлуулах.
  • Эцэст нь хэлэхэд хамгийн багадаа. Бид загваруудаа дүн шинжилгээ хийх өргөн хүрээтэй жишиг платформыг бий болгох хэрэгтэй. [4]

лавлагаа

  1. Өргөтгөсөн оюун ухаан гэж юу вэ?
  2. API-First дизайны аргачлалыг хэрэгжүүлэх
  3. Кафка “Event Streaming Database” болж хувирч байна
  4. AUC-ROC муруйг ойлгох

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

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