Нақты қолданбаларда ClickHouse қолдану теориясы мен тәжірибесі. Александр Зайцев (2018)

Қазір барлық жерде дерлік көптеген деректер бар екеніне қарамастан, аналитикалық деректер базасы әлі де экзотикалық болып табылады. Олар нашар белгілі және оларды тиімді пайдалана алады. Көбісі басқа сценарийлерге арналған MySQL немесе PostgreSQL көмегімен «кактусты жеуді» жалғастыруда, NoSQL-тен зардап шегеді немесе коммерциялық шешімдер үшін артық төлейді. ClickHouse ойын ережелерін өзгертеді және аналитикалық ДҚБЖ әлеміне кіру шегін айтарлықтай төмендетеді.

BackEnd Conf 2018 есебі және ол спикердің рұқсатымен жарияланады.

Мен кіммін және неге ClickHouse туралы айтып отырмын? Мен ClickHouse қолданбасын пайдаланатын LifeStreet компаниясының әзірлеу жөніндегі директорымын. Сонымен қатар, мен Altinity компаниясының негізін салушымын. Бұл ClickHouse-ты алға жылжытатын және Яндекске ClickHouse-ты табысты етуге көмектесетін Яндекс серіктесі. Сондай-ақ ClickHouse туралы біліммен бөлісуге дайын.

Ал мен Петя Зайцевтің ағасы емеспін. Менен бұл туралы жиі сұралады. Жоқ, біз ағайын емеспіз.

ClickHouse «барлығы біледі»:

• Өте жылдам,
• Өте ыңғайлы
• Яндексте қолданылады.

Қай компанияларда және қалай қолданылатыны азырақ белгілі.

Мен сізге Яндекстен басқа ClickHouse неге, қайда және қалай қолданылатынын айтып беремін.

Мен әртүрлі компанияларда ClickHouse көмегімен нақты тапсырмалар қалай шешілетінін, тапсырмаларыңыз үшін қандай ClickHouse құралдарын пайдалануға болатынын және олардың әртүрлі компанияларда қалай пайдаланылғанын айтып беремін.

Мен ClickHouse-ты әртүрлі бұрыштардан көрсететін үш мысалды таңдадым. Қызық болады деп ойлаймын.

Бірінші сұрақ: «Бізге ClickHouse не үшін қажет?». Бұл өте айқын сұрақ сияқты, бірақ оған бірнеше жауап бар.

• Бірінші жауап өнімділікке арналған. ClickHouse өте жылдам. ClickHouse сайтындағы аналитика да өте жылдам. Оны басқа нәрсе өте баяу немесе өте нашар болған жерде жиі қолдануға болады.
• Екінші жауап - шығындар. Және, ең алдымен, масштабтау құны. Мысалы, Vertica - бұл керемет дерекқор. Егер сізде терабайт деректер көп болмаса, ол өте жақсы жұмыс істейді. Бірақ жүздеген терабайтқа немесе петабайтқа келетін болсақ, лицензия мен қолдаудың құны айтарлықтай қомақты сомаға түседі. Және бұл қымбат. Ал ClickHouse тегін.
• Үшінші жауап - операциялық шығындар. Бұл сәл басқаша көзқарас. RedShift - тамаша аналог. RedShift-те сіз өте тез шешім қабылдай аласыз. Бұл жақсы жұмыс істейді, бірақ сонымен бірге, әр сағат сайын, күн сайын және ай сайын сіз Amazon-ға өте қымбат төлейсіз, өйткені бұл өте қымбат қызмет. Google BigQuery де. Егер біреу оны пайдаланған болса, онда ол жерде сіз бірнеше сұрауларды орындап, кенеттен жүздеген долларға шотты алуға болатынын біледі.

ClickHouse-да мұндай проблемалар жоқ.

ClickHouse қазір қайда қолданылады? Яндекс-тен басқа, ClickHouse әртүрлі кәсіпорындар мен компаниялар тобында қолданылады.

• Біріншіден, бұл веб-бағдарламалардың аналитикасы, яғни бұл Яндекстен келген пайдалану жағдайы.
• Көптеген AdTech компаниялары ClickHouse пайдаланады.
• Әртүрлі көздерден транзакция журналдарын талдау қажет көптеген компаниялар.
• Бірнеше компаниялар қауіпсіздік журналдарын бақылау үшін ClickHouse пайдаланады. Оларды ClickHouse-қа жүктеп салып, есептер жасайды және қажетті нәтижелерді алады.
• Компаниялар оны қаржылық талдауда қолдана бастайды, яғни бірте-бірте ірі бизнестер де ClickHouse-ға жақындайды.
• бұлт жарқылы. Егер біреу ClickHouse-ды бақылайтын болса, онда олар бұл компанияның атын естіген болуы мүмкін. Бұл қауымдастықтың маңызды үлескерлерінің бірі. Және оларда өте маңызды ClickHouse қондырғысы бар. Мысалы, олар ClickHouse үшін Кафка қозғалтқышын жасады.
• Байланыс компаниялары пайдалана бастады. Бірнеше компаниялар ClickHouse қолданбасын тұжырымдаманың дәлелі ретінде немесе қазірдің өзінде өндірісте пайдаланады.
• Бір компания өндірістік процестерді бақылау үшін ClickHouse пайдаланады. Олар микросұлбаларды тексереді, көптеген параметрлерді есептейді, шамамен 2 сипаттамалар бар. Содан кейін олар ойынның жақсы немесе жаман екенін талдайды.
• Блокчейннің аналитикасы. Bloxy.info сияқты ресейлік компания бар. Бұл ethereum желісін талдау. Олар мұны ClickHouse сайтында да жасады.

Және өлшемі маңызды емес. Бір шағын серверді пайдаланатын көптеген компаниялар бар. Және олардың мәселелерін шешуге мүмкіндік береді. Және одан да көп компаниялар көптеген серверлердің үлкен кластерлерін немесе ондаған серверлерді пайдаланады.

Ал жазбаларға қарасаңыз, онда:

• Яндекс: 500+ серверлер, оларда күніне 25 миллиард жазба сақталады.
• LifeStreet: 60 сервер, күніне шамамен 75 миллиард жазба. Яндекске қарағанда серверлер аз, жазбалар көп.
• CloudFlare: 36 сервер, олар күніне 200 миллиард жазбаны сақтайды. Олардың серверлері одан да аз және одан да көп деректерді сақтайды.
• Bloomberg: 102 сервер, күніне шамамен триллион жазба. Рекорд ұстаушы.

Географиялық тұрғыдан бұл да көп. Бұл карта ClickHouse әлемде қай жерде қолданылып жатқанының жылу картасын көрсетеді. Бұл жерде Ресей, Қытай, Америка ерекше көзге түседі. Еуропа елдері аз. Және 4 кластер бар.

Бұл салыстырмалы талдау, абсолютті сандарды іздеудің қажеті жоқ. Бұл Altinity веб-сайтындағы ағылшын тіліндегі материалдарды оқитын келушілердің талдауы, өйткені онда орыс тілділер жоқ. Ал Ресей, Украина, Беларусь, яғни қауымдастықтың орыстілді бөлігі - бұл ең көп пайдаланушылар. Одан кейін АҚШ пен Канада келеді. Қытай өте қуып келеді. Алты ай бұрын ол жерде Қытай жоқтың қасы еді, қазір Қытай Еуропаны басып озды және өсуде. Ескі Еуропа да артта қалған жоқ, және ClickHouse қолдану бойынша көшбасшы, таң қаларлықтай, Франция.

Мұның бәрін неге айтып отырмын? ClickHouse үлкен деректерді талдау үшін стандартты шешімге айналып жатқанын және көптеген жерлерде қолданылғанын көрсету. Егер сіз оны қолдансаңыз, сіз дұрыс трендтесіз. Егер сіз оны әлі пайдаланбасаңыз, онда сіз жалғыз қаласыз және ешкім сізге көмектеспейді деп қорықпайсыз, өйткені көпшілігі мұны істеп жатыр.

Бұл бірнеше компанияларда нақты ClickHouse пайдалану мысалдары.

• Бірінші мысал - жарнамалық желі: Vertica-дан ClickHouse-қа көшу. Мен Vertica-дан ауысқан немесе ауысу процесінде тұрған бірнеше компанияны білемін.
• Екінші мысал - ClickHouse жүйесіндегі транзакциялық сақтау. Бұл антипаттерндерге негізделген мысал. Әзірлеушілердің кеңесі бойынша ClickHouse-да жасауға болмайтын нәрсенің бәрі осында жасалады. Және бұл өте тиімді жасалған, ол жұмыс істейді. Және ол әдеттегі транзакциялық шешімге қарағанда әлдеқайда жақсы жұмыс істейді.
• Үшінші мысал ClickHouse жүйесінде таратылған есептеулер болып табылады. ClickHouse қолданбасын Hadoop экожүйесіне қалай біріктіруге болатыны туралы сұрақ туындады. Мен компанияның ClickHouse-те картаны азайту контейнеріне ұқсас нәрсені қалай жасағанының мысалын көрсетемін, деректерді оқшаулауды қадағалайды және т.б., өте маңызды емес тапсырманы есептеу үшін.

• LifeStreet - жарнама желісімен бірге келетін барлық технологиялары бар Ad Tech компаниясы.
• Ол жарнаманы оңтайландырумен, бағдарламалық сауда-саттықпен айналысады.
• Көптеген деректер: күніне шамамен 10 миллиард оқиға. Сонымен бірге ондағы оқиғаларды бірнеше ішкі оқиғаларға бөлуге болады.
• Бұл деректердің көптеген клиенттері бар және бұл адамдар ғана емес, тағы басқалар - бұл бағдарламалық сауда-саттықпен айналысатын әртүрлі алгоритмдер.

Компания ұзақ және қиын жолдан өтті. Мен бұл туралы HighLoad бағдарламасында айттым. Біріншіден, LifeStreet MySQL-тен (Oracle-да қысқа аялдамамен) Vertica-ға көшті. Және бұл туралы әңгіме таба аласыз.

Және бәрі өте жақсы болды, бірақ деректердің өсіп келе жатқаны және Vertica қымбат екені тез белгілі болды. Сондықтан әртүрлі баламалар іздестірілді. Олардың кейбіреулері осында келтірілген. Шындығында, біз 13-16-шы жылдар аралығында нарықта қол жетімді және функционалдық тұрғыдан шамамен жарамды болған барлық дерлік дерекқорлардың тұжырымдамасын немесе кейде өнімділігін сынауды жасадық. Сондай-ақ мен олардың кейбіреулері туралы HighLoad бағдарламасында айттым.

Тапсырма бірінші кезекте Vertica-дан көшу болды, себебі деректер өсті. Және олар жылдар бойы экспоненциалды түрде өсті. Содан кейін олар сөреге шықты, бірақ соған қарамастан. Және бұл өсуді болжау, қандай да бір аналитика жасау қажет деректер көлеміне бизнес талаптары, петабайттардың жақын арада талқыланатыны анық болды. Ал петабайттарды төлеу қазірдің өзінде өте қымбат, сондықтан біз қайда баруға болатын балама іздедік.

Қайда бару керек? Ұзақ уақыт бойы қайда бару керектігі мүлдем түсініксіз болды, өйткені бір жағынан коммерциялық деректер базасы бар, олар жақсы жұмыс істейтін сияқты. Кейбіреулер Vertica сияқты жақсы жұмыс істейді, ал кейбіреулері нашар. Бірақ олардың бәрі қымбат, одан арзан және жақсы ештеңе табылмады.

Екінші жағынан, ашық бастапқы шешімдер бар, олар өте көп емес, яғни аналитика үшін оларды саусақпен санауға болады. Және олар тегін немесе арзан, бірақ баяу. Және оларда жиі қажетті және пайдалы функционалдық жетіспейді.

Коммерциялық дерекқорлардағы жақсылық пен ашық көздегі барлық тегінді біріктіретін ештеңе болмады.

Күтпеген жерден Яндекс ClickHouse-ны қалпақтан сиқыршы, қоян сияқты шығарып алғанға дейін ештеңе болмады. Бұл күтпеген шешім болды, олар әлі де: «Неге?» Деген сұрақты қояды, бірақ соған қарамастан.

2016 жылдың жазында біз ClickHouse дегеннің не екенін қарастыра бастадық. Ал кейде ол Vertica-дан жылдамырақ болатыны белгілі болды. Біз әртүрлі сұраулар бойынша әртүрлі сценарийлерді сынадық. Ал егер сұрау тек бір кестені пайдаланса, яғни ешқандай біріктірусіз (қосылу), онда ClickHouse Vertica-дан екі есе жылдам болды.

Мен тым жалқау емеспін және келесі күні Яндекс тесттерін қарадым. Бұл жерде бірдей: ClickHouse Vertica-дан екі есе жылдам, сондықтан олар бұл туралы жиі айтады.

Бірақ егер сұрауларда қосылулар болса, онда бәрі бір мағыналы емес. Ал ClickHouse Vertica-дан екі есе баяу болуы мүмкін. Ал егер сұрауды сәл түзетіп, қайта жазсаңыз, онда олар шамамен тең болады. Жаман емес. Және тегін.

Тест нәтижелерін алып, оған әртүрлі қырынан қарап, LifeStreet ClickHouse-қа барды.

Биыл 16 жыл, еске саламын. Бұл тышқандар туралы әзіл сияқты жылап, өздерін шаншып, бірақ кактусты жеуді жалғастырды. Және бұл егжей-тегжейлі сипатталды, бұл туралы бейне бар және т.б.

Сондықтан мен бұл туралы егжей-тегжейлі айтпай-ақ қояйын, мен тек нәтижелер туралы және сол кезде айтпаған бірнеше қызықты нәрселер туралы айтамын.

Нәтижелері:

• Сәтті көші-қон және бір жылдан астам жүйе қазірдің өзінде өндірісте жұмыс істейді.
• Өнімділік пен икемділік артты. Біз күніне, содан кейін қысқа уақытқа сақтауға болатын 10 миллиард жазбаның ішінде LifeStreet қазір күніне 75 миллиард жазбаны сақтайды және мұны 3 ай немесе одан да көп уақыт бойы жасай алады. Егер сіз шыңында есептесеңіз, бұл секундына миллион оқиғаға жетеді. Бұл жүйеге күніне миллионнан астам SQL сұраулары келеді, негізінен әртүрлі роботтардан.
• Vertica-ға қарағанда ClickHouse үшін көбірек серверлер пайдаланылғанына қарамастан, олар аппараттық құралдарды да үнемдеді, өйткені Vertica-да өте қымбат SAS дискілері пайдаланылды. ClickHouse SATA пайдаланды. Ал неге? Өйткені Vertica кірістіру синхронды болып табылады. Ал синхрондау дискілердің тым көп баяуламауын, сонымен қатар желінің тым баяулатпауын талап етеді, яғни өте қымбат операция. Ал ClickHouse ішіндегі кірістіру асинхронды болып табылады. Сонымен қатар, сіз әрқашан бәрін жергілікті түрде жаза аласыз, бұл үшін қосымша шығындар жоқ, сондықтан деректерді ClickHouse-қа Vertika-ға қарағанда әлдеқайда жылдам, тіпті баяу дискілерде де енгізуге болады. Ал оқу шамамен бірдей. SATA-да оқу, егер олар RAID-де болса, мұның бәрі жеткілікті жылдам.
• Лицензиямен шектелмейді, яғни 3 сервердегі 60 петабайт деректер (20 сервер - бір көшірме) және фактілер мен агрегаттардағы 6 триллион жазба. Vertica-да мұндай ештеңе мүмкін емес.

Енді мен осы мысалдағы практикалық нәрселерге жүгінемін.

• Біріншісі - тиімді схема. Көп нәрсе схемаға байланысты.
• Екіншісі - тиімді SQL генерациясы.

Әдеттегі OLAP сұрауы таңдау болып табылады. Кейбір бағандар топтастыруға, кейбір бағандар біріктіру функцияларына өтеді. Мұнда текше тілімдері ретінде көрсетуге болатын жер бар. Бүкіл топты проекция ретінде қарастыруға болады. Міне, сондықтан оны көп мәнді деректерді талдау деп атайды.

Көбінесе бұл жұлдызды схема түрінде модельденеді, бұл фактінің орталық фактісі мен сипаттамаларының жағында, сәулелердің бойында.

Физикалық дизайн тұрғысынан, оның үстелге қалай сәйкес келетіні, олар әдетте нормаланған көріністі жасайды. Қалыптыдан шығаруға болады, бірақ ол дискіде қымбат және сұрауларда өте тиімді емес. Сондықтан олар әдетте нормаланған көріністі, яғни фактілер кестесін және көптеген, көптеген өлшемдер кестелерін жасайды.

Бірақ бұл ClickHouse-да жақсы жұмыс істемейді. Екі себеп бар:

• Біріншісі, ClickHouse-да өте жақсы қосылыстар болмағандықтан, яғни біріктірулер бар, бірақ олар нашар. Жаман болған кезде.
• Екіншісі – кестелер жаңартылмайды. Әдетте жұлдыз тізбегінің айналасында орналасқан бұл тақталарда бір нәрсені өзгерту керек. Мысалы, тұтынушы аты, компания атауы және т.б. Және ол жұмыс істемейді.

Бұдан шығудың жолы ClickHouse-та бар. тіпті екі:

• Біріншісі – сөздіктерді пайдалану. Сыртқы сөздіктер 99% жұлдызды схемамен, жаңартулармен және т.б. мәселені шешуге көмектеседі.
• Екіншісі - массивтерді пайдалану. Массивтер сонымен қатар қосылулардан және қалыпқа келтіру проблемаларынан құтылуға көмектеседі.

• Қосылу қажет емес.
• Жаңартылатын. 2018 жылдың наурыз айынан бастап сөздіктерді ішінара, яғни өзгерген жазбаларды жаңарту үшін құжатсыз мүмкіндік пайда болды (мұны құжаттамада таба алмайсыз). Іс жүзінде бұл үстелге ұқсайды.
• Әрқашан жадта, сондықтан сөздікпен қосылу дискідегі кестеге қарағанда жылдамырақ жұмыс істейді және оның кэште екені әлі нақты емес, мүмкін емес.

• Сізге қосылулар да қажет емес.
• Бұл 1-ден көпке дейінгі ықшам көрініс.
• Менің ойымша, массивтер гейктер үшін жасалған. Бұл лямбда функциялары және т.б.

Бұл қызыл сөздер үшін емес. Бұл өте қарапайым және талғампаз түрде көптеген нәрселерді жасауға мүмкіндік беретін өте қуатты функция.

Массивтерді шешуге көмектесетін типтік мысалдар. Бұл мысалдар жеткілікті қарапайым және түсінікті:

• Тегтер бойынша іздеу. Егер сізде хэштегтер болса және хэштег арқылы кейбір хабарламаларды тапқыңыз келсе.
• Кілт-мән жұптары бойынша іздеу. Сондай-ақ мәні бар кейбір атрибуттар бар.
• Басқа нәрсеге аудару қажет кілттер тізімдерін сақтау.

Барлық осы тапсырмаларды массивтерсіз шешуге болады. Тегтерді кейбір жолға қоюға және тұрақты өрнекпен немесе бөлек кестеде таңдауға болады, бірақ содан кейін біріктірулер жасау керек.

Ал ClickHouse-да ештеңе істеудің қажеті жоқ, хэштегтерге арналған жол массивін сипаттау немесе кілт-мән жүйелері үшін кірістірілген құрылымды жасау жеткілікті.

Кірістірілген құрылым ең жақсы атау болмауы мүмкін. Бұл атауында ортақ бөлігі және кейбір қатысты сипаттамалары бар екі массив.

Және тег бойынша іздеу өте оңай. Функциясы бар has, ол массивте элемент бар екенін тексереді. Барлығы біздің конференцияға қатысты барлық жазбаларды тапты.

Subid бойынша іздеу біршама күрделірек. Алдымен кілттің индексін табу керек, содан кейін осы индексі бар элементті алып, осы мән бізге қажет екенін тексеру керек. Дегенмен, бұл өте қарапайым және ықшам.

Егер сіз бәрін бір қатарда сақтасаңыз, жазғыңыз келетін тұрақты тіркес, біріншіден, ыңғайсыз болады. Екіншіден, ол екі массивтен әлдеқайда ұзағырақ жұмыс істеді.

Тағы бір мысал. Сізде идентификатор сақталатын массив бар. Және оларды атауларға аударуға болады. Функция arrayMap. Бұл әдеттегі ламбда функциясы. Сіз онда лямбда өрнектерін жібересіз. Және ол сөздіктен әрбір идентификатордың атауының мәнін шығарады.

Іздеуді дәл осылай жасауға болады. Элементтердің сәйкестігін тексеретін предикат функциясы беріледі.

Бұл заттар схеманы айтарлықтай жеңілдетеді және көптеген мәселелерді шешеді.

Бірақ бізде кездесетін келесі мәселе және мен атап өткім келеді, бұл тиімді сұраулар.

• ClickHouse бағдарламасында сұрауды жоспарлаушы жоқ. Мүлдем жоқ.
• Дегенмен, күрделі сұрауларды әлі де жоспарлау қажет. Қандай жағдайларда?
• Сұрауда бірнеше біріктіру болса, оларды ішкі таңдауларға орап аласыз. Ал олардың орындалу реті маңызды.
• Ал екіншісі – сұраныс таратылса. Өйткені таратылған сұрауда тек ішкі ішкі таңдау ғана таратылған орындалады, ал қалғандары сіз қосылған және сол жерде орындалған бір серверге жіберіледі. Сондықтан, егер сізде көптеген қосылыстар (қосылу) бар сұраныстар таратылған болса, онда сіз тапсырысты таңдауыңыз керек.

Тіпті қарапайым жағдайларда, кейде жоспарлаушының жұмысын орындау және сұрауларды аздап қайта жазу қажет.

Міне, мысал. Сол жақта ең жақсы 5 елді көрсететін сұрау бар. Және бұл менің ойымша 2,5 секундты алады. Ал оң жағында бірдей сұрау, бірақ сәл қайта жазылған. Жол бойынша топтастырудың орнына біз кілт (int) бойынша топтастыруды бастадық. Және бұл жылдамырақ. Содан кейін нәтижеге сөздікті қостық. 2,5 секундтың орнына сұрау 1,5 секундқа созылады. Бұл жақсы.

Сүзгілерді қайта жазумен ұқсас мысал. Міне, Ресейге өтініш. Ол 5 секундқа созылады. Егер біз оны қайтадан жолды емес, Ресейге қатысты кілттердің кейбір жиынтығымен сандарды салыстыратындай етіп қайта жазсақ, ол әлдеқайда жылдам болады.

Мұндай трюктар көп. Және олар қазірдің өзінде жылдам орындалады деп ойлайтын сұрауларды айтарлықтай жылдамдатуға мүмкіндік береді немесе, керісінше, баяу орындалады. Оларды одан да жылдам жасауға болады.

• Бөлінген режимдегі максималды жұмыс.
• Минималды түрлер бойынша сұрыптау, мен ints бойынша жасадым.
• Егер қосылыстар (қосылулар), сөздіктер болса, оларды соңғы шара ретінде жасаған дұрыс, егер сізде деректер кем дегенде ішінара топтастырылған болса, онда қосылу операциясы немесе сөздік шақыру азырақ шақырылады және ол жылдамырақ болады. .
• Сүзгілерді ауыстыру.

Мен көрсеткендер ғана емес, басқа да әдістер бар. Және олардың барлығы кейде сұраулардың орындалуын айтарлықтай жылдамдатуы мүмкін.

Келесі мысалға көшейік. АҚШ-тан X компаниясы. Ол не істеп жатыр?

Тапсырма болды:

• Жарнамалық транзакцияларды желіден тыс байланыстыру.
• Түрлі байланыстыру үлгілерін модельдеу.

Сценарий қандай?

Қарапайым кіруші сайтқа келеді, мысалы айына 20 рет әртүрлі жарнамалардан немесе сол сияқты кейде жарнамасыз келеді, өйткені ол бұл сайтты есіне алады. Кейбір бұйымдарды қарап, себетке салады, қоржыннан шығарады. Ақыр соңында, бірдеңе сатып алады.

Орынды сұрақтар: «Жарнама үшін қажет болса, кім төлеуі керек?» және «Оған қандай жарнама әсер етті, егер бар болса?». Яғни, ол не үшін сатып алды және осы адам сияқты адамдарды да сатып алуға қалай тарту керек?

Бұл мәселені шешу үшін веб-сайтта орын алған оқиғаларды дұрыс жолмен байланыстыру керек, яғни олардың арасында қандай да бір байланыс орнату керек. Содан кейін олар DWH талдауға жіберіледі. Және осы талдаудың негізінде кім және қандай жарнамаларды көрсететін үлгілерді құрастырыңыз.

Жарнамалық транзакция – бұл жарнаманы көрсетуден басталатын, содан кейін бірдеңе орын алатын, содан кейін сатып алу, содан кейін сатып алу кезінде сатып алулар болуы мүмкін байланысты пайдаланушы оқиғаларының жиынтығы. Мысалы, егер бұл мобильді қосымша немесе мобильді ойын болса, әдетте қосымшаны орнату тегін жүзеге асырылады, ал егер ол жерде бірдеңе жасалса, бұл үшін ақша қажет болуы мүмкін. Ал адам қосымшада неғұрлым көп жұмсаса, соғұрлым ол құнды болады. Бірақ бұл үшін бәрін қосу керек.

Көптеген байланыстыратын модельдер бар.

Ең танымалдары:

• Соңғы өзара әрекеттесу, онда өзара әрекеттесу не басу, не әсер ету.
• Бірінші өзара әрекеттесу, яғни адамды сайтқа әкелген бірінші нәрсе.
• Сызықтық комбинация – барлығы бірдей.
• Әлсіреу.
• Және тағы басқа.

Ал мұның бәрі бірінші кезекте қалай жұмыс істеді? Runtime және Cassandra болды. Кассандра транзакция қоймасы ретінде пайдаланылды, яғни оған қатысты барлық транзакциялар сақталды. Runtime-да қандай да бір оқиға келгенде, мысалы, қандай да бір бетті немесе басқа нәрсені көрсету, содан кейін Кассандраға сұрау жасалды - мұндай адам бар ма, жоқ па. Содан кейін оған қатысты мәмілелер алынды. Және байланыс орнатылды.

Ал егер сұрауда транзакция идентификаторы болғаны бақытты болса, бұл оңай. Бірақ әдетте сәттілік болмайды. Сондықтан соңғы транзакцияны немесе соңғы рет басу арқылы транзакцияны табу керек болды, т.б.

Және мұның бәрі өте жақсы жұмыс істеді, егер байланыстыру соңғы рет басуға дейін болды. Өйткені, бір айға терезе орнатсақ, күніне 10 миллион, айына 300 миллион клик бар. Кассандрада жылдам жұмыс істеу үшін оның барлығы жадта болуы керек болғандықтан, Runtime жылдам жауап беруі керек болғандықтан, шамамен 10-15 сервер қажет болды.

Олар транзакцияны дисплейге байланыстырғысы келгенде, бұл бірден қызықты емес болып шықты. Ал неге? Оқиғаларды 30 есе көп сақтау қажет екенін көруге болады. Және, сәйкесінше, сізге 30 есе көп серверлер қажет. Ал бұл астрономиялық фигуралардың бір түрі екені белгілі болды. Орындау уақытында серверлердің айтарлықтай аз болуына қарамастан, байланыстыру үшін 500 серверге дейін сақтау үшін, бұл дұрыс емес көрсеткіш. Және олар не істеу керектігін ойлай бастады.

Біз ClickHouse-ке бардық. Мұны ClickHouse-да қалай жасауға болады? Бір қарағанда, бұл анти-үлгілердің жиынтығы сияқты.

• Транзакция өседі, біз оған көбірек оқиғаларды қосамыз, яғни ол өзгермелі және ClickHouse өзгермелі нысандармен жақсы жұмыс істемейді.
• Келуші бізге келгенде, біз оның транзакцияларын кілт арқылы, оның келу идентификаторы арқылы шығаруымыз керек. Бұл да нүктелік сұрау, олар мұны ClickHouse қолданбасында жасамайды. Әдетте ClickHouse-да үлкен …сканерлеулер бар, бірақ мұнда кейбір жазбаларды алу керек. Сондай-ақ антипаттерн.
• Сонымен қатар, транзакция json тілінде болды, бірақ олар оны қайта жазғысы келмеді, сондықтан олар json файлын құрылымсыз түрде сақтағысы келді, қажет болса, одан бірдеңе шығарып тастады. Және бұл да антипаттерн.

Яғни, антипаттерндердің жиынтығы.

Бірақ соған қарамастан, ол өте жақсы жұмыс істейтін жүйені жасады.

Не істелді? ClickHouse пайда болды, оған журналдар лақтырылды, жазбаларға бөлінеді. ClickHouse журналынан алынған атрибутталған қызмет пайда болды. Осыдан кейін әрбір жазба үшін кіру идентификаторы бойынша мен әлі өңделмеген транзакцияларды және қосымша суреттерді, яғни бұрыннан қосылған транзакцияларды, атап айтқанда алдыңғы жұмыстың нәтижесін алдым. Мен олардан логика жасадым, дұрыс транзакцияны таңдадым, жаңа оқиғаларды байланыстырдым. Қайтадан тіркелді. Журнал ClickHouse-қа қайта оралды, яғни бұл тұрақты циклдік жүйе. Сонымен қатар, мен оны талдау үшін DWH-ге бардым.

Дәл осы пішінде ол өте жақсы жұмыс істемеді. ClickHouse-ке кіруді жеңілдету үшін, кіру идентификаторы бойынша сұрау болған кезде, олар бұл сұрауларды 1-000 келу идентификаторларының блоктарына топтап, 2-000 адамға арналған барлық транзакцияларды алып тастады. Содан кейін бәрі жұмыс істеді.

Егер сіз ClickHouse ішіне қарасаңыз, мұның бәріне қызмет ететін тек 3 негізгі кесте бар.

Журналдар жүктелетін бірінші кесте және журналдар дерлік өңделмей жүктеп салынады.

Екінші кесте. Материалдандырылған көрініс арқылы осы журналдардан әлі жатқызылмаған оқиғалар, яғни байланысы жоқ оқиғалар шағып алынды. Материалдандырылған көрініс арқылы транзакциялар суретті құру үшін осы журналдардан шығарылды. Яғни, арнайы материалдандырылған көрініс суретті, атап айтқанда транзакцияның соңғы жинақталған күйін құрады.

Мұнда SQL тілінде жазылған мәтін берілген. Мен ондағы бірнеше маңызды нәрселерге түсініктеме бергім келеді.

Бірінші маңызды нәрсе - ClickHouse ішіндегі json ішінен бағандар мен өрістерді шығару мүмкіндігі. Яғни ClickHouse-да json-мен жұмыс істеудің кейбір әдістері бар. Олар өте, өте қарабайыр.

visitParamExtractInt сізге json атрибуттарын шығаруға мүмкіндік береді, яғни бірінші хит жұмыс істейді. Осылайша сіз транзакция идентификаторын шығара аласыз немесе идентификаторға кіре аласыз. Бұл жолы.

Екіншіден, мұнда күрделі материалдандырылған өріс қолданылады. Бұл нені білдіреді? Бұл кестеге кірістіру мүмкін емес дегенді білдіреді, яғни ол енгізілмейді, ол кірістіру кезінде есептеледі және сақталады. Қою кезінде ClickHouse сіз үшін жұмыс істейді. Сізге кейінірек қажет нәрсе json ішінен шығарылды.

Бұл жағдайда материалдандырылған көрініс өңделмеген жолдарға арналған. Ал іс жүзінде өңделмеген журналдары бар бірінші кесте жай ғана пайдаланылады. Ал ол не істейді? Біріншіден, ол сұрыптауды өзгертеді, яғни сұрыптау енді кіру идентификаторы бойынша жүреді, өйткені біз оның транзакциясын белгілі бір тұлға үшін жылдам шығарып алуымыз керек.

Екінші маңызды нәрсе - index_granularity. MergeTree қолданбасын көрген болсаңыз, ол әдетте әдепкі index_granularity бойынша 8 болады. Бұл не? Бұл индекстің сиректік параметрі. ClickHouse бағдарламасында индекс сирек, ол ешқашан әрбір жазбаны индекстемейді. Ол мұны әрбір 192 рет жасайды. Және бұл көп деректерді есептеу қажет болғанда жақсы, бірақ аздаған кезде жаман, өйткені үлкен үстеме шығындар бар. Ал егер индекстің түйіршіктілігін төмендетсек, онда үстеме шығындарды азайтамыз. Оны біреуге азайту мүмкін емес, себебі жад жеткіліксіз болуы мүмкін. Индекс әрқашан жадта сақталады.

Snapshot сонымен қатар басқа кейбір қызықты ClickHouse мүмкіндіктерін пайдаланады.

Біріншіден, бұл AggregatingMergeTree. Ал AggregatingMergeTree argMax сақтайды, яғни бұл соңғы уақыт белгісіне сәйкес транзакцияның күйі. Транзакциялар барлық уақытта белгілі бір келуші үшін жасалады. Осы транзакцияның ең соңғы күйінде біз оқиға қостық және бізде жаңа күй бар. Ол ClickHouse-қа қайтадан әсер етті. Осы материалдандырылған көріністегі argMax арқылы біз әрқашан ағымдағы күйді ала аламыз.

• Байланыстыру Орындалу уақытынан "ажыратылған".
• Айына 3 миллиардқа дейін транзакция сақталады және өңделеді. Бұл Кассандрадағыдан, яғни әдеттегі транзакциялық жүйедегіден үлкен дәреже.
• 2x5 ClickHouse серверлерінің кластері. 5 сервер және әрбір серверде көшірме бар. Басуға негізделген атрибуцияны жасау үшін бұл Кассандрадағыдан да аз және бізде әсерге негізделген. Яғни, серверлер санын 30 есе көбейтудің орнына, қысқартуға қол жеткізді.

Ал соңғы мысал – акциялар бағасының өзгеруінің корреляциясын талдаған қаржы компаниясы Y.

Ал тапсырма:

• 5-ға жуық акция бар.
• Әр 100 миллисекунд сайын дәйексөздер белгілі.
• Деректер 10 жыл бойы жинақталған. Шамасы, кейбір компаниялар үшін көп, біреулер үшін аз.
• Барлығы шамамен 100 миллиард жол бар.

Және өзгерістердің корреляциясын есептеу қажет болды.

Мұнда екі акция және олардың баға белгіленімі берілген. Егер біреуі көтерілсе, екіншісі көтерілсе, онда бұл оң корреляция, яғни біреуі жоғары, екіншісі жоғарылайды. Біреуі графиктің соңындағыдай жоғары көтерілсе, ал екіншісі төмендесе, онда бұл теріс корреляция, яғни біреуі көтерілгенде, екіншісі төмендейді.

Осы өзара өзгерістерді талдай отырып, қаржы нарығында болжам жасауға болады.

Бірақ тапсырма қиын. Бұл үшін қандай жұмыстар атқарылуда? Бізде 100 миллиард жазба бар: уақыт, қор және баға. Бізге баға алгоритмінен 100 миллиард есе жұмыс істейтін айырмашылықты есептеу керек. RunningDifference - екі жол арасындағы айырмашылықты ретімен есептейтін ClickHouse ішіндегі функция.

Ал одан кейін корреляцияны есептеу керек, ал корреляция әрбір жұп үшін есептелуі керек. 5 акция үшін жұптар 000 млн. Және бұл өте көп, яғни 12,5 есе дәл осындай корреляциялық функцияны есептеу керек.

Ал егер біреу ұмытып кетсе, онда ͞x және ͞y мат болып табылады. таңдауды күту. Яғни, түбірлер мен қосындыларды есептеп қана қоймай, осы қосындылардың ішіндегі тағы бір соманы да есептеу керек. Көптеген есептеулерді 12,5 миллион рет жасау керек, тіпті сағаттар бойынша топтастыру керек. Біздің де сағатымыз көп. Ал сіз мұны 60 секундта орындауыңыз керек. Бұл әзіл.

Кем дегенде қандай да бір түрде уақыт қажет болды, өйткені мұның бәрі ClickHouse келгенге дейін өте, өте баяу жұмыс істеді.

Олар оны Hadoop-та, Spark-те, Greenplum-те есептеуге тырысты. Және мұның бәрі өте баяу немесе қымбат болды. Яғни, әйтеуір есептеуге болатын, бірақ кейін қымбат болды.

Содан кейін ClickHouse пайда болды және бәрі жақсарды.

Бізде деректердің орналасуына қатысты мәселе бар екенін еске саламын, өйткені корреляцияларды локализациялау мүмкін емес. Біз деректердің бір бөлігін бір серверге, кейбірін басқа серверге қойып, есептей алмаймыз, бізде барлық деректер барлық жерде болуы керек.

Олар не істеді? Бастапқыда деректер локализацияланады. Әрбір сервер белгілі бір акциялар жиынының бағасы туралы деректерді сақтайды. Және олар бір-біріне сәйкес келмейді. Сондықтан logReturn-ді параллель және тәуелсіз есептеуге болады, мұның бәрі осы уақытқа дейін параллельді және таратылады.

Содан кейін біз экспрессивтілігін жоғалтпай, бұл деректерді азайтуды шештік. Массивтерді пайдалануды азайтыңыз, яғни әр уақыт кезеңі үшін қорлар массивін және бағалар массивін жасаңыз. Сондықтан ол деректер кеңістігін әлдеқайда аз алады. Және олармен жұмыс істеу біршама оңайырақ. Бұл дерлік параллельді операциялар, яғни біз ішінара параллель оқимыз, содан кейін серверге жазамыз.

Осыдан кейін оны қайталауға болады. «r» әрпі бұл деректерді қайталағанымызды білдіреді. Яғни, бізде барлық үш серверде бірдей деректер бар - бұл массивтер.

Содан кейін есептеуді қажет ететін 12,5 миллион корреляция жиынтығынан арнайы сценарий арқылы сіз пакеттер жасай аласыз. Яғни, 2 жұп корреляциясы бар 500 тапсырма. Және бұл тапсырма белгілі бір ClickHouse серверінде есептелуі керек. Оның барлық деректері бар, өйткені деректер бірдей және ол оларды ретімен есептей алады.

Тағы да қайталаймын, ол осылай көрінеді. Біріншіден, бізде бұл құрылымда барлық деректер бар: уақыт, акциялар, баға. Содан кейін біз logReturn есептедік, яғни сол құрылымның деректері, бірақ бағаның орнына бізде logReturn бар. Содан кейін олар қайта жасалды, яғни біз акциялар мен бағалар үшін уақыт пен groupArray алдық. Көшірілген. Осыдан кейін біз көптеген тапсырмаларды жасап, оларды санау үшін ClickHouse-қа жібердік. Және ол жұмыс істейді.

Тұжырымдаманы дәлелдеу бойынша тапсырма қосалқы тапсырма болды, яғни аз деректер алынды. Және тек үш сервер.

Бұл алғашқы екі кезең: Log_return есептеу және массивтерге орау шамамен бір сағатқа созылды.

Ал корреляцияны есептеу шамамен 50 сағатты құрайды. Бірақ 50 сағат жеткіліксіз, өйткені олар апталап жұмыс істейтін. Бұл үлкен жетістік болды. Ал есептесеңіз, секундына 70 рет осы кластерде барлығы есептелген.

Бірақ ең бастысы, бұл жүйе іс жүзінде кедергісіз, яғни ол сызықты түрде дерлік масштабталады. Және олар оны тексерді. Оны сәтті кеңейтті.

• Дұрыс схема - сәттіліктің жартысы. Ал дұрыс схема - барлық қажетті ClickHouse технологияларын пайдалану.
• Summing/AggregatingMergeTrees — күй суретін ерекше жағдай ретінде біріктіруге немесе қарастыруға мүмкіндік беретін технологиялар. Және бұл көп нәрсені жеңілдетеді.
• Материалдандырылған көріністер бір индекс шегін айналып өтуге мүмкіндік береді. Мүмкін мен оны анық айтқан жоқпын, бірақ біз журналдарды жүктеген кезде, өңделмеген журналдар бір индексі бар кестеде болды, ал төлсипат журналдары кестеде болды, яғни бірдей деректер, тек сүзгіден өтті, бірақ индекс толығымен болды. басқалар. Бұл бірдей деректер сияқты, бірақ сұрыптау әртүрлі. Материалдандырылған көріністер сізге қажет болса, осындай ClickHouse шектеуін айналып өтуге мүмкіндік береді.
• Нүкте сұраулары үшін индекстің түйіршіктігін азайтыңыз.
• Деректерді ақылды түрде таратыңыз, мүмкіндігінше сервердегі деректерді локализациялауға тырысыңыз. Сондай-ақ сұраулар мүмкіндігінше локализацияны пайдалануын қамтамасыз етуге тырысыңыз.

Осы қысқаша сөзді қорытындылай келе, ClickHouse енді коммерциялық деректер базаларының да, ашық бастапқы дерекқорлардың да аумағын, яғни аналитика үшін нақты түрде иеленді деп айта аламыз. Ол бұл пейзажға өте жақсы сәйкес келеді. Оның үстіне ол баяу басқаларды ығыстыра бастайды, өйткені ClickHouse болған кезде сізге InfiniDB қажет емес. Егер олар қалыпты SQL қолдауын жасаса, Vertika жақын арада қажет болмауы мүмкін. Ләззат алыңыз!

-Есеп үшін рахмет! Өте қызық! Apache Phoenix-пен салыстыру болды ма?

Жоқ, ешкімді салыстырғанын естіген жоқпын. Біз және Яндекс әр түрлі дерекқорлармен барлық ClickHouse салыстыруларын қадағалауға тырысамыз. Өйткені кенеттен бірдеңе ClickHouse-дан жылдамырақ болып шықса, Леша Миловидов түнде ұйықтай алмай, оны жылдамдатуға кіріседі. Мен мұндай салыстыруды естімеппін.

• (Алексей Миловидов) Apache Phoenix - Hbase басқаратын SQL қозғалтқышы. Hbase негізінен кілт-мән жұмысының сценарийіне арналған. Онда әр жолда ерікті атаулары бар бағандардың ерікті саны болуы мүмкін. Бұл Hbase, Cassandra сияқты жүйелер туралы айтуға болады. Және бұл олар үшін қалыпты жұмыс істемейтін дәл ауыр аналитикалық сұраулар. Немесе ClickHouse қолданбасымен тәжірибе алмасаңыз, олар жақсы жұмыс істейді деп ойлауыңыз мүмкін.

• сізге рахмет

  • Қайырлы күн! Мені бұл тақырып қазірдің өзінде қызықтырады, өйткені менде аналитикалық ішкі жүйе бар. Бірақ мен ClickHouse-ға қараған кезде, ClickHouse оқиғаны талдауға өте қолайлы, өзгермелі деген сезімді аламын. Егер мен көптеген үлкен кестелермен көптеген бизнес деректерін талдау керек болса, онда ClickHouse, менің түсінуімше, мен үшін өте қолайлы емес пе? Әсіресе, егер олар өзгерсе. Бұл дұрыс па немесе мұны жоққа шығаратын мысалдар бар ма?

  • Бұл дұрыс. Бұл мамандандырылған аналитикалық деректер қорларының көпшілігіне қатысты. Олар өзгермелі бір немесе бірнеше үлкен кестелер болуы үшін және баяу өзгеретін көптеген кішкентай кестелер үшін бейімделген. Яғни, ClickHouse Oracle сияқты емес, мұнда барлығын салып, өте күрделі сұрауларды құрастыруға болады. ClickHouse қызметін тиімді пайдалану үшін схеманы ClickHouse бағдарламасында жақсы жұмыс істейтін етіп құру керек. Яғни, шамадан тыс нормадан аулақ болыңыз, сөздіктерді пайдаланыңыз, ұзын сілтемелерді азырақ жасауға тырысыңыз. Ал егер схема осылай құрастырылса, ұқсас бизнес тапсырмаларын дәстүрлі реляциялық дерекқорға қарағанда ClickHouse-да әлдеқайда тиімді шешуге болады.

Есеп үшін рахмет! Менің соңғы қаржылық жағдайға қатысты сұрағым бар. Олардың аналитикасы болды. Олардың қалай көтеріліп, бірде төмендейтінін салыстыру қажет болды. Сіз жүйені осы аналитика үшін арнайы жасағаныңызды түсінемін бе? Егер ертең, мысалы, оларға осы деректер бойынша басқа есеп қажет болса, оларға схеманы қайта құру және деректерді жүктеп салу қажет пе? Яғни, сұрауды алу үшін қандай да бір алдын ала өңдеуді жасау керек пе?

Әрине, бұл өте нақты тапсырма үшін ClickHouse пайдалану. Оны дәстүрлі түрде Hadoop ішінде шешуге болады. Hadoop үшін бұл тамаша тапсырма. Бірақ Hadoop-та бұл өте баяу. Менің мақсатым - ClickHouse әдетте мүлдем басқа әдістермен шешілетін, бірақ сонымен бірге оны әлдеқайда тиімдірек орындайтын тапсырмаларды шеше алатындығын көрсету. Бұл белгілі бір тапсырмаға бейімделген. Ұқсас нәрсеге қатысты мәселе болса, оны ұқсас жолмен шешуге болатыны анық.

Ол түсінікті. Сіз 50 сағат өңделгенін айттыңыз. Бұл ең басынан ба, деректерді қашан жүктедіңіз немесе нәтиже алдыңыз ба?

Иә Иә.

Жарайды көп рахмет.

Бұл 3 сервер кластерінде.

Сәлем! Есеп үшін рахмет! Барлығы өте қызықты. Мен функционалдық туралы аз сұрамаймын, бірақ тұрақтылық тұрғысынан ClickHouse пайдалану туралы. Яғни, сізде бар ма, қалпына келтіру керек пе? Бұл жағдайда ClickHouse қалай әрекет етеді? Сізде де көшірме болды ма? Мысалы, ол әлі де шегінен шығып, құлаған кезде ClickHouse мәселесіне тап болдық.

Әрине, идеалды жүйелер жоқ. ClickHouse-тың да өз проблемалары бар. Бірақ сіз Yandex.Metrica ұзақ уақыт бойы жұмыс істемейтіні туралы естідіңіз бе? Бәлкім жоқ. Ол ClickHouse-те 2012-2013 жылдардан бері сенімді жұмыс істейді. Мен өз тәжірибем туралы да айта аламын. Бізде ешқашан толық сәтсіздіктер болған емес. Кейбір ішінара нәрселер болуы мүмкін, бірақ олар ешқашан бизнеске елеулі әсер ететіндей маңызды емес. Бұл ешқашан болған емес. ClickHouse өте сенімді және кездейсоқ бұзылмайды. Бұл туралы уайымдаудың қажеті жоқ. Бұл шикі нәрсе емес. Мұны көптеген компаниялар дәлелдеген.

Сәлеметсіз бе! Сіз деректер схемасын дереу ойластыру керек деп айттыңыз. Бұл болған болса ше? Деректерім құйылып, төгіліп жатыр. Алты ай өтеді, мен бұлай өмір сүру мүмкін емес екенін түсінемін, деректерді қайта жүктеп, олармен бірдеңе істеуім керек.

Бұл, әрине, сіздің жүйеңізге байланысты. Мұны іс жүзінде тоқтаусыз жасаудың бірнеше жолы бар. Мысалы, егер ол бірегей салыстыруға болатын болса, басқа деректер құрылымын жасайтын Материалдандырылған көрініс жасай аласыз. Яғни, егер ол ClickHouse көмегімен салыстыруға мүмкіндік берсе, яғни кейбір нәрселерді шығарып, негізгі кілтті өзгертіп, бөлімді өзгертуге мүмкіндік берсе, онда сіз Материалдандырылған көрініс жасай аласыз. Онда ескі деректеріңізді қайта жазыңыз, жаңалары автоматты түрде жазылады. Содан кейін жай ғана Материалдандырылған көріністі пайдалануға ауысыңыз, содан кейін жазбаны ауыстырыңыз және ескі кестені жойыңыз. Бұл әдетте тоқтаусыз әдіс.

рахмет.

Ақпарат көзі: www.habr.com