Өнгөрсөн жилээс манай компани хакатон зохион байгуулж эхэлсэн. Анхны ийм тэмцээн маш амжилттай болсон, бид энэ тухай бичсэн . Хоёр дахь хакатон 2019 оны XNUMX-р сард болсон бөгөөд үүнээс дутахааргүй амжилттай болсон. Сүүлийнхийг саяхан зохион байгуулах зорилгын талаар зохион байгуулагч.
Оролцогчдод үүнийг хэрэгжүүлэх технологийн стекийг сонгох бүрэн эрх чөлөөтэй нэлээд сонирхолтой даалгавар өгсөн. Хэрэглээний хурдан урсгалтай ажиллах, хүнд ачааллыг тэсвэрлэх чадвартай, систем өөрөө хялбархан өргөтгөх боломжтой хэрэглэгчийн онооны функцийг ашиглахад тохиромжтой шийдвэр гаргах платформыг хэрэгжүүлэх шаардлагатай байв.
Оролцогчдын төслүүдийн эцсийн илтгэлийг үзүүлэх үеэр бид итгэлтэй байсан тул даалгавар нь өчүүхэн зүйл биш бөгөөд олон янзаар шийдэж болно. Хакатонд 6 хүний бүрэлдэхүүнтэй 5 баг оролцсон, бүх оролцогчид сайн төслүүдтэй байсан ч манай платформ хамгийн өрсөлдөөнтэй нь болсон. Бидэнд маш сонирхолтой төсөл байгаа бөгөөд би энэ нийтлэлд ярихыг хүсч байна.
Манай шийдэл нь Kubernetes доторх сервергүй архитектурт суурилсан платформ бөгөөд үйлдвэрлэлд шинэ боломжуудыг нэвтрүүлэхэд зарцуулагдах хугацааг багасгадаг. Энэ нь шинжээчдэд өөрт тохирсон орчинд код бичиж, инженер, хөгжүүлэгчдийн оролцоогүйгээр үйлдвэрлэлд нэвтрүүлэх боломжийг олгодог.
Оноо гэж юу вэ
Tinkoff.ru нь орчин үеийн олон компаниудын нэгэн адил хэрэглэгчийн оноотой байдаг. Үнэлгээ нь өгөгдөлд дүн шинжилгээ хийх статистик аргууд дээр суурилсан хэрэглэгчийн үнэлгээний систем юм.
Жишээлбэл, үйлчлүүлэгч түүнд зээл олгох эсвэл бидэнтэй хувиараа бизнес эрхлэгчийн данс нээлгэх хүсэлт гаргаж бидэнд ханддаг. Хэрэв бид түүнд зээл олгохоор төлөвлөж байгаа бол түүний төлбөрийн чадварыг үнэлэх хэрэгтэй бөгөөд хэрэв данс нь хувиараа бизнес эрхлэгч бол үйлчлүүлэгч нь хуурамч гүйлгээ хийхгүй гэдэгт итгэлтэй байх ёстой.
Ийм шийдвэр гаргах үндэс нь програмын өөрөө болон бидний хадгалалтын өгөгдөлд дүн шинжилгээ хийдэг математик загварууд юм. Үнэлгээнээс гадна ижил төстэй статистик аргуудыг манай үйлчлүүлэгчдэд зориулсан шинэ бүтээгдэхүүний талаархи зөвлөмжийг бий болгох үйлчилгээнд ашиглаж болно.
Ийм үнэлгээний арга нь янз бүрийн оролтын өгөгдлийг хүлээн авах боломжтой. Хэзээ нэгэн цагт бид оролтод шинэ параметр нэмж болох бөгөөд энэ нь түүхэн өгөгдөлд хийсэн шинжилгээний үр дүнд үндэслэн уг үйлчилгээг ашиглах хөрвүүлэх хурдыг нэмэгдүүлэх болно.
Бид харилцагчийн харилцааны талаар асар их мэдээлэлтэй бөгөөд энэ мэдээллийн хэмжээ байнга нэмэгдэж байна. Оноо авахын тулд өгөгдөл боловсруулахад хэн өргөдөл гаргахыг зөвшөөрөх, хэн татгалзах, хэнд илүү олон бүтээгдэхүүн санал болгох, тэдний боломжит сонирхлыг үнэлж хурдан шийдэх боломжийг олгодог дүрэм (эсвэл математик загвар) шаардлагатай.
Даалгаврын хувьд бид шийдвэр гаргах тусгай системийг аль хэдийн ашиглаж байна , энэ нь шинжээч, технологич, хөгжүүлэгчдийн тогтоосон дүрэмд үндэслэн тухайн банкны бүтээгдэхүүнийг үйлчлүүлэгчид зөвшөөрөх эсвэл татгалзах эсэхийг шийддэг.
Зах зээл дээр онооны загварууд болон шийдвэр гаргах системүүд аль аль нь олон бэлэн шийдлүүд байдаг. Бид эдгээр системүүдийн аль нэгийг компанидаа ашигладаг. Гэвч бизнес хөгжиж, төрөлжиж, үйлчлүүлэгчдийн тоо, санал болгож буй бүтээгдэхүүний тоо нэмэгдэж байгаа бөгөөд үүнтэй зэрэгцэн одоо байгаа шийдвэр гаргах үйл явцыг хэрхэн сайжруулах талаар санаанууд гарч ирж байна. Одоо байгаа системтэй ажиллаж байгаа хүмүүст үүнийг хэрхэн хялбар, илүү сайн, илүү тохиромжтой болгох талаар олон санаа байгаа нь гарцаагүй, гэхдээ заримдаа гаднаас ирсэн санаанууд хэрэг болдог. Шинэ Хакатон нь зөв санаа цуглуулах зорилготойгоор зохион байгуулагдсан.
Даалгавар
Хакатон 23-р сарын XNUMX-нд болсон. Оролцогчдод хэд хэдэн нөхцөлийг хангасан шийдвэр гаргах тогтолцоог хөгжүүлэх байлдааны даалгавар санал болгов.
Одоо байгаа систем хэрхэн ажилладаг, түүнийг ажиллуулах явцад ямар бэрхшээл тулгардаг, түүнчлэн боловсруулсан платформ нь бизнесийн ямар зорилтуудыг хэрэгжүүлэх ёстойг бидэнд хэлсэн. Шинжээчдийн ажлын кодыг аль болох хурдан үйлдвэрлэлд нэвтрүүлэхийн тулд систем нь дүрмийг боловсруулах зах зээлд хурдан гарах цагтай байх ёстой. Ирж буй өргөдлийн урсгалын хувьд шийдвэр гаргах хугацаа хамгийн бага байх ёстой. Түүнчлэн, боловсруулж буй систем нь үйлчлүүлэгчид манайхаас зөвшөөрөгдсөн бусад компанийн бүтээгдэхүүнийг худалдан авах боломжийг олгохын тулд хөндлөн борлуулалт хийх чадвартай байх ёстой.
Үйлдвэрлэлд орох нь гарцаагүй, бэлэн төслийг нэг шөнийн дотор бичих боломжгүй нь ойлгомжтой бөгөөд системийг бүхэлд нь хамрах нь нэлээд хэцүү тул ядаж нэг хэсгийг нь хэрэгжүүлэхийг биднээс хүссэн. Прототип нь хангасан байх ёстой хэд хэдэн шаардлагыг тогтоосон. Бүх шаардлагыг бүхэлд нь хамарч, боловсруулж буй платформын бие даасан хэсгүүд дээр нарийвчлан ажиллахын тулд хоёуланг нь туршиж үзэх боломжтой байв.
Технологийн хувьд бүх оролцогчдод сонголт хийх бүрэн эрх чөлөө олгосон. Ямар ч ойлголт, технологийг ашиглах боломжтой байсан: Өгөгдлийн урсгал, машин сургалт, үйл явдлын эх сурвалж, том өгөгдөл болон бусад.
Бидний шийдэл
Бага зэрэг оюуны довтолгооны дараа бид FaaS шийдэл нь даалгаврыг гүйцэтгэхэд тохиромжтой гэж шийдсэн.
Энэхүү шийдлийн хувьд боловсруулж буй шийдвэр гаргах системийн дүрмийг хэрэгжүүлэхэд тохиромжтой Сервергүй тогтолцоог олох шаардлагатай байв. Тинкофф Кубернетесийг дэд бүтцийн менежментэд идэвхтэй ашигладаг тул бид үүн дээр суурилсан хэд хэдэн бэлэн шийдлүүдийг авч үзсэн; Би дараа нь энэ талаар дэлгэрэнгүй ярих болно.
Хамгийн үр дүнтэй шийдлийг олохын тулд бид бүтээгдэж буй бүтээгдэхүүнийг хэрэглэгчдийн нүдээр харлаа. Манай системийн гол хэрэглэгчид нь дүрэм боловсруулахад оролцдог шинжээчид юм. Дүрмүүд нь серверт тавигдах ёстой, эсвэл дараагийн шийдвэр гаргахын тулд манай тохиолдолд үүлэн дээр байрлуулсан байх ёстой. Шинжээчдийн үүднээс авч үзвэл ажлын явц дараах байдалтай байна.
- Шинжээч нь агуулахын өгөгдөл дээр үндэслэн скрипт, дүрэм эсвэл ML загварыг бичдэг. Хакатоны хүрээнд бид Mongodb-г ашиглахаар шийдсэн боловч өгөгдөл хадгалах системийн сонголт энд чухал биш юм.
- Боловсруулсан дүрмийг түүхэн өгөгдөл дээр туршиж үзсэний дараа шинжээч өөрийн кодыг админ самбарт байршуулдаг.
- Хувилбарыг баталгаажуулахын тулд бүх код Git репозиторууд руу очно.
- Админ самбараар дамжуулан үүлэн дотор кодыг тусдаа функциональ сервергүй модуль болгон байрлуулах боломжтой болно.
Үйлчлүүлэгчдийн анхны өгөгдөл нь анхны хүсэлтийг агуулахын мэдээллээр баяжуулах зориулалттай тусгай баяжуулах үйлчилгээгээр дамжих ёстой. Өгөгдлийн нэгдсэн бүтцийг хадгалахын тулд энэ үйлчилгээг нэг репозитортой ажиллах (шинжээч дүрэм боловсруулахдаа өгөгдлийг авдаг) байдлаар хэрэгжүүлэх нь чухал байсан.
Хакатон болохоос өмнө ч бид Сервергүй фреймворкийг ашиглахаар шийдсэн. Өнөөдөр зах зээл дээр энэ аргыг хэрэгжүүлдэг маш олон технологиуд байдаг. Kubernetes архитектурын хамгийн алдартай шийдэл бол Fission, Open FaaS болон Kubeless юм. Бүр байдаг .
Бүх давуу болон сул талуудыг жинлэсний дараа бид сонгосон . Энэхүү Сервергүй хүрээ нь удирдахад маш хялбар бөгөөд даалгаврын шаардлагыг хангадаг.
Fission-тэй ажиллахын тулд функц ба орчин гэсэн хоёр үндсэн ойлголтыг ойлгох хэрэгтэй. Функц нь Fission орчинтой аль нэг хэлээр бичигдсэн кодын хэсэг юм. Python, JS, Go, JVM болон бусад олон алдартай хэл, технологиуд багтана.
Fission нь архивт урьдчилан савласан хэд хэдэн файлд хуваагдсан функцуудыг гүйцэтгэх чадвартай. Kubernetes кластер дахь Fission-ийн ажиллагааг хүрээ өөрөө удирддаг тусгай pods-уудаар хангадаг. Кластер подкуудтай харилцахын тулд функц бүрд өөрийн гэсэн маршрутыг хуваарилах ёстой бөгөөд POST хүсэлтийн тохиолдолд GET параметр эсвэл хүсэлтийн биетийг дамжуулж болно.
Үүний үр дүнд бид шинжээчид боловсруулсан дүрмийн скриптийг инженер, хөгжүүлэгчдийн оролцоогүйгээр ашиглах боломжийг олгох шийдлийг олж авахаар төлөвлөж байсан. Тайлбарласан арга нь хөгжүүлэгчид аналитик кодыг өөр хэл рүү дахин бичих хэрэгцээг арилгадаг. Жишээлбэл, бидний хэрэглэж буй шийдвэр гаргах тогтолцооны хувьд бид маш нарийн мэргэжлийн технологи, хэлээр дүрмийг бичих ёстой бөгөөд тэдгээрийн хамрах хүрээ нь маш хязгаарлагдмал, мөн банкны бүх дүрмийн төсөл нь програмын серверээс ихээхэн хамааралтай байдаг. нэг орчинд байрлуулсан. Үүний үр дүнд шинэ дүрмийг хэрэгжүүлэхийн тулд системийг бүхэлд нь гаргах шаардлагатай болно.
Бидний санал болгож буй шийдэлд дүрэм гаргах шаардлагагүй бөгөөд кодыг товчлуур дээр дарахад хялбархан байрлуулж болно. Түүнчлэн, Кубернетес дэх дэд бүтцийн менежмент нь ачаалал, масштабын талаар бодохгүй байх боломжийг олгодог бөгөөд ийм асуудлыг хайрцагнаас нь шийддэг. Мөн нэг мэдээллийн агуулах ашиглах нь бодит цагийн өгөгдлийг түүхэн өгөгдөлтэй харьцуулах шаардлагагүй бөгөөд энэ нь шинжээчийн ажлыг хялбаршуулдаг.
Бид юу авсан
Бид хакатонд бэлэн шийдэлтэй ирсэн тул (бидний уран зөгнөлөөр) бүх бодлоо кодын мөр болгон хувиргах л үлдлээ.
Аливаа хакатон тэмцээнд амжилтанд хүрэх түлхүүр бол бэлтгэл, сайн бичсэн төлөвлөгөө юм. Тиймээс бидний хийсэн хамгийн эхний зүйл бол манай системийн архитектур ямар модулиудаас бүрдэх, ямар технологи ашиглахаа шийдэх явдал байв.
Манай төслийн архитектур нь дараах байдалтай байв.
Энэ диаграмм нь шинжээч (манай системийн үндсэн хэрэглэгч) болон үйлчлүүлэгч гэсэн хоёр нэвтрэх цэгийг харуулж байна.
Ажлын процесс нь ийм бүтэцтэй байдаг. Шинжээч өөрийн загварт зориулж дүрмийн функц болон өгөгдөл баяжуулах функцийг боловсруулж, Git репозиторид өөрийн кодыг хадгалж, администраторын хэрэглүүрээр дамжуулан загвараа клоуд руу байрлуулдаг. Оруулсан функцийг хэрхэн дуудаж, үйлчлүүлэгчдээс ирж буй хүсэлтийн талаар шийдвэр гаргахыг авч үзье.
- Үйлчлүүлэгч вэбсайт дээрх маягтыг бөглөж, хүсэлтээ хянагч руу илгээдэг. Шийдвэр гаргах шаардлагатай өргөдөл нь системийн оролтонд орж, мэдээллийн санд анхны хэлбэрээр нь бүртгэгддэг.
- Дараа нь шаардлагатай бол түүхий хүсэлтийг баяжуулахаар илгээнэ. Та анхны хүсэлтийг гадаад үйлчилгээ болон хадгалах сангийн мэдээллээр нөхөж болно. Үр дүнд нь баяжуулсан хайлт нь мэдээллийн санд хадгалагдана.
- Шинжээч функцийг эхлүүлсэн бөгөөд энэ нь баяжуулсан асуулгыг оролт болгон авч, шийдэл гаргах бөгөөд үүнийг мөн хадгалах санд бичдэг.
Анхны хүсэлтийг оролцуулан баяжуулах үйлчилгээ нь REST хянагчаар дамжуулан бүх өгөгдлийг нэгтгэсэн тул бид MongoDB-ийг JSON баримт хэлбэрээр баримт бичигт суурилсан өгөгдлийг хадгалах системд ашиглахаар шийдсэн.
Тиймээс бид мөрийн хөтөлбөрөө хэрэгжүүлэхэд XNUMX цагийн хугацаа үлдсэн. Бид дүрүүдийг нэлээд амжилттай хуваарилсан; багийн гишүүн бүр манай төсөлд өөрийн хариуцах чиглэлтэй байсан:
- Шинжээчийн ажилд зориулсан урд талын админ самбарууд нь бичмэл скриптүүдийн хувилбарын хяналтын системээс дүрмийг татаж авах, оролтын өгөгдлийг баяжуулах сонголтыг сонгох, дүрмийн скриптийг онлайнаар засварлах боломжтой.
- Урд талын REST API болон VCS-тэй нэгтгэсэн арын админ.
- Google Cloud-д дэд бүтцийг бий болгож, эх сурвалжийн өгөгдлийг баяжуулах үйлчилгээг хөгжүүлж байна.
- Дараа нь дүрмүүдийг байршуулах зорилгоор админ програмыг Сервергүй хүрээтэй нэгтгэх модуль.
- Бүхэл бүтэн системийн гүйцэтгэлийг шалгах дүрмийн скриптүүд, эцсийн үзүүлэнгийн хувьд ирж буй програмууд дээр дүн шинжилгээ хийх (шийдвэрүүд) нэгтгэх.
Эхлээд эхлээрэй.
Манай урд тал нь банкны UI Kit ашиглан Angular 7 дээр бичигдсэн. Админ самбарын эцсийн хувилбар дараах байдалтай байв.
Цаг хугацаа бага байсан тул бид зөвхөн үндсэн функцийг хэрэгжүүлэхийг хичээсэн. Kubernetes кластерт функцийг байрлуулахын тулд үйл явдал (дүрмийг үүлэнд байрлуулах шаардлагатай үйлчилгээ) болон шийдвэр гаргах логикийг хэрэгжүүлдэг функцийн кодыг сонгох шаардлагатай байв. Сонгосон үйлчилгээний дүрмийг байршуулах бүрт бид энэ үйл явдлын бүртгэлийг бичсэн. Админ самбар дээр та бүх үйл явдлын бүртгэлийг харж болно.
Бүх функцийн кодыг алсын Git репозиторид хадгалсан бөгөөд үүнийг админ самбарт тохируулах шаардлагатай байв. Кодыг хувилбар болгохын тулд бүх функцийг репозиторын өөр өөр салбаруудад хадгалсан. Админ самбар нь бичмэл скриптүүдэд тохируулга хийх боломжийг олгодог бөгөөд ингэснээр та функцийг үйлдвэрлэлд ашиглахаасаа өмнө зөвхөн бичсэн кодыг шалгахаас гадна шаардлагатай өөрчлөлтүүдийг хийх боломжтой.
Дүрмийн функцээс гадна бид мэдээллийн агуулах руу орох, гуравдагч талын үйлчилгээ рүү залгах, урьдчилсан тооцоо хийх боломжтой скриптүүд болох Баяжуулах функцийг ашиглан эх өгөгдлийг аажмаар баяжуулах боломжийг хэрэгжүүлсэн. . Бидний шийдлийг харуулахын тулд бид хүсэлтийг орхисон үйлчлүүлэгчийн зурхайн тэмдгийг тооцоолж, гуравдагч этгээдийн REST үйлчилгээг ашиглан үүрэн холбооны операторыг нь тодорхойлсон.
Платформын арын хэсгийг Java хэл дээр бичсэн бөгөөд Spring Boot програм болгон хэрэгжүүлсэн. Бид эхлээд админы мэдээллийг хадгалахын тулд Postgres програмыг ашиглахаар төлөвлөж байсан ч хакатоны нэг хэсэг болгон цаг хугацаа хэмнэхийн тулд энгийн H2 програмыг ашиглахаар шийдсэн. Ар талд нь асуулга баяжуулах функцууд болон дүрмийн скриптүүдийг хувилбар болгохын тулд Bitbucket-тай нэгтгэсэн. Алсын Git репозиторуудтай нэгтгэхийн тулд бид ашигласан , энэ нь CLI командуудын нэг төрлийн боодол бөгөөд тохиромжтой програм хангамжийн интерфейсийг ашиглан дурын git зааврыг гүйцэтгэх боломжийг олгодог. Тиймээс бид баяжуулах функц, дүрмийн хоёр тусдаа агуулахтай байсан бөгөөд бүх скриптүүд нь лавлах хэсэгт хуваагдсан. UI-ээр дамжуулан репозиторийн дурын салбарын скриптийн хамгийн сүүлийн үеийн амлалтуудыг сонгох боломжтой болсон. Админ самбараар дамжуулан кодонд өөрчлөлт оруулахдаа алсын хадгалах газарт өөрчлөгдсөн кодын амлалтуудыг үүсгэсэн.
Санаагаа хэрэгжүүлэхийн тулд бидэнд тохирох дэд бүтэц хэрэгтэй байсан. Бид Kubernetes кластераа үүлэн дээр байрлуулахаар шийдсэн. Бидний сонголт бол Google Cloud Platform байсан. Fission сервергүй хүрээг бид Gcloud дээр байрлуулсан Kubernetes кластер дээр суулгасан. Эхэндээ эх сурвалжийн өгөгдлийг баяжуулах үйлчилгээг k8s кластер доторх Pod-д ороосон тусдаа Java программ хэлбэрээр хэрэгжүүлсэн. Гэхдээ хакатон дундуур төслийнхөө урьдчилсан үзүүлбэрийн дараа бидэнд ирж буй програмуудын түүхий өгөгдлийг хэрхэн баяжуулахыг сонгох боломжийг олгохын тулд баяжуулах үйлчилгээг илүү уян хатан болгохыг санал болгов. Мөн бид баяжуулах үйлчилгээг сервергүй болгохоос өөр аргагүй болсон.
Fission-тэй ажиллахын тулд бид Fission CLI-г ашигласан бөгөөд үүнийг Kubernetes CLI дээр суулгасан байх ёстой. K8s кластерт функцуудыг байрлуулах нь маш энгийн бөгөөд та кластераас гадуур хандалт хийх шаардлагатай бол ирж буй урсгалыг зөвшөөрөхийн тулд дотоод чиглүүлэлт болон функцэд нэвтрэхэд л хангалттай. Нэг функцийг ашиглахад ихэвчлэн 10 секундээс илүүгүй хугацаа шаардагдана.
Төслийн эцсийн танилцуулга, дүгнэлт
Манай систем хэрхэн ажилладагийг харуулахын тулд бид алсын сервер дээр энгийн маягт байршуулсан бөгөөд та банкны аль нэг бүтээгдэхүүнд өргөдөл гаргах боломжтой. Хүсэлт гаргахын тулд та овог нэр, төрсөн огноо, утасны дугаараа оруулах ёстой.
Үйлчлүүлэгчийн маягтаас авсан мэдээлэл нь хянагч руу очсон бөгөөд тэр нь боломжтой бүх дүрмийн хүсэлтийг нэгэн зэрэг илгээж, өмнө нь заасан нөхцлийн дагуу өгөгдлийг баяжуулж, нийтлэг хадгалах санд хадгалсан. Нийтдээ бид ирж буй програмуудын талаар шийдвэр гаргадаг гурван функц, өгөгдөл баяжуулах 4 үйлчилгээг нэвтрүүлсэн. Өргөдөл гаргасны дараа үйлчлүүлэгч бидний шийдвэрийг хүлээн авлаа:
Татгалзах эсвэл зөвшөөрөхөөс гадна үйлчлүүлэгч бусад бүтээгдэхүүний жагсаалтыг хүлээн авсан бөгөөд бидний зэрэгцээ илгээсэн хүсэлтийг хүлээн авсан. Ингэж бид платформ дээрээ кросс борлуулалт хийх боломжтойг харуулсан.
Нийтдээ 3 хуурамч банкны бүтээгдэхүүн байсан:
- Зээл.
- Тоглоом
- Ипотекийн зээл.
Үзэсгэлэнгийн үеэр бид үйлчилгээ тус бүрт бэлтгэсэн функцууд болон баяжуулах скриптүүдийг байршуулсан.
Дүрэм бүр өөрийн оролтын өгөгдлийг шаарддаг. Тиймээс, ипотекийн зээлийг батлахын тулд бид үйлчлүүлэгчийн зурхайн тэмдгийг тооцоолж, үүнийг сарны хуанлийн логиктой холбосон. Тоглоом батлахын тулд үйлчлүүлэгчийг насанд хүрсэн эсэхийг шалгаж, зээл олгохын тулд үүрэн холбооны операторыг тодорхойлох гадны нээлттэй үйлчилгээнд хүсэлт илгээж, шийдвэр гаргасан.
Бид үзүүлбэрээ сонирхолтой, интерактив болгохыг хичээсэн тул хүрэлцэн ирсэн хүн бүр манай маягт руу орж, тэдэнд үзүүлэх зохиомол үйлчилгээ байгаа эсэхийг шалгаж болно. Танилцуулгын төгсгөлд бид хүлээн авсан өргөдлийн дүн шинжилгээг үзүүлсэн бөгөөд энэ нь манай үйлчилгээг хэдэн хүн ашигласан, зөвшөөрөл авсан, татгалзсан тоо зэргийг харуулсан болно.
Онлайнаар аналитик цуглуулахын тулд бид нээлттэй эхийн BI хэрэгслийг нэмж суулгасан мөн үүнийг манай хадгалах хэсэг рүү шургуулсан. Метабаза нь бидний сонирхож буй өгөгдлийн аналитик бүхий дэлгэцийг бүтээх боломжийг олгодог; та зөвхөн мэдээллийн санд холболтыг бүртгүүлж, хүснэгтүүдийг (бидний хувьд, MongoDB ашигласан тул мэдээллийн цуглуулга) сонгох хэрэгтэй. .
Үүний үр дүнд бид шийдвэр гаргах платформын сайн загвартай болсон бөгөөд үзүүлэнгийн үеэр сонсогч бүр түүний гүйцэтгэлийг биечлэн шалгах боломжтой болсон. Сонирхолтой шийдэл, бэлэн загвар, амжилттай үзүүлбэр нь бусад багуудын хүчтэй өрсөлдөөнийг үл харгалзан биднийг ялах боломжийг олгосон. Баг бүрийн төсөл дээр сонирхолтой нийтлэл бичиж болно гэдэгт итгэлтэй байна.
Эх сурвалж: www.habr.com