Бұл аналитикалық жүйелер туралы мақалалар топтамасының екінші бөлімі ().
Бүгінгі таңда деректерді мұқият өңдеу және нәтижелерді интерпретациялау бизнестің кез келген түріне дерлік көмектесетініне күмән жоқ. Осыған байланысты аналитикалық жүйелер барған сайын параметрлермен жүктелуде және қолданбалардағы триггерлер мен пайдаланушы оқиғаларының саны өсуде.
Осыған байланысты компаниялар өз талдаушыларына талдау және дұрыс шешім қабылдау үшін көбірек шикі ақпаратты береді. Компания үшін аналитикалық жүйенің маңыздылығын бағаламау керек, ал жүйенің өзі сенімді және тұрақты болуы керек.
Клиент талдаушылары
Тұтынушының аналитикасы – компания ресми 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
Құрылған жүйеге фронтенді қосу керек. Жақсы мысал - қызмет көрсету , бақылау тақталарын құруға көмектесетін дерекқордың графикалық интерфейсі. Өзара әрекеттесу қалай жұмыс істейді:
- Пайдаланушы SQL сұрауын жасайды.
- Жауап ретінде ол белгі алады.
- Ол үшін «жаңа визуализация» жасайды және өзіңіз үшін сақтауға болатын әдемі графикті алады.
Қызметтегі визуализациялар автоматты түрде жаңартылады, сіз өз бақылауыңызды теңшеуге және бақылауға болады. Редаш өздігінен орналастырылған болса тегін, бірақ SaaS ретінде айына $50 тұрады.
қорытынды
Жоғарыдағы барлық қадамдарды орындағаннан кейін сіз сервер талдауын жасайсыз. Бұл тұтынушылардың аналитикасын қосу сияқты оңай емес екенін ескеріңіз, себебі барлығын өзіңіз конфигурациялау керек. Сондықтан, өз жүйеңізді жасамас бұрын, маңызды аналитикалық жүйенің қажеттілігін оған бөлуге дайын ресурстармен салыстырған жөн.
Егер сіз математиканы орындап, шығындардың тым жоғары екенін тапсаңыз, келесі бөлімде мен серверлік аналитиканың арзан нұсқасын қалай жасауға болатыны туралы айтатын боламын.
Оқығаныңызға рахмет! Түсініктемелерде сұрақтар қоюға қуаныштымын.
Ақпарат көзі: www.habr.com