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