Теорија и практика на користење на ClickHouse во реални апликации. Александар Зајцев (2018)

И покрај фактот дека сега има многу податоци речиси насекаде, аналитичките бази на податоци сè уште се прилично егзотични. Тие се слабо познати и уште полошо можат ефективно да ги користат. Многумина продолжуваат да „јадат кактус“ со MySQL или PostgreSQL, кои се дизајнирани за други сценарија, страдаат од NoSQL или преплаќаат за комерцијални решенија. ClickHouse ги менува правилата на игра и значително го намалува прагот за влез во светот на аналитичките DBMS.

Извештај од BackEnd Conf 2018 и е објавен со дозвола на говорникот.

Кој сум јас и зошто зборувам за ClickHouse? Јас сум директор за развој во LifeStreet, кој користи ClickHouse. Исто така, јас сум основач на Altinity. Тоа е партнер на Yandex кој го промовира ClickHouse и му помага на Yandex да го направи ClickHouse поуспешен. Исто така подготвен да сподели знаење за ClickHouse.

И јас не сум брат на Петја Заицев. Често ме прашуваат за ова. Не, ние не сме браќа.

„Сите знаат“ дека ClickHouse:

• Многу брзо,
• Многу удобно
• Се користи во Yandex.

Малку помалку се знае во кои фирми и како се користи.

Ќе ви кажам зошто, каде и како се користи ClickHouse, освен за Yandex.

Ќе ви кажам како се решаваат конкретни задачи со помош на ClickHouse во различни компании, кои алатки ClickHouse можете да ги користите за вашите задачи и како тие се користеле во различни компании.

Собрав три примери кои го прикажуваат ClickHouse од различни агли. Мислам дека ќе биде интересно.

Првото прашање е: „Зошто ни е потребен ClickHouse?“. Се чини дека е прилично очигледно прашање, но има повеќе од еден одговор на тоа.

• Првиот одговор е за перформансите. ClickHouse е многу брз. Анализата на ClickHouse е исто така многу брза. Често може да се користи кога нешто друго е многу бавно или многу лошо.
• Вториот одговор е цената. И пред сè, трошоците за скалирање. На пример, Vertica е апсолутно одлична база на податоци. Работи многу добро ако немате многу терабајти податоци. Но, кога станува збор за стотици терабајти или петабајти, цената на лиценцата и поддршката оди во прилично значителна сума. И тоа е скапо. И ClickHouse е бесплатен.
• Третиот одговор е оперативниот трошок. Ова е малку поинаков пристап. RedShift е одличен аналог. На RedShift, можете многу брзо да донесете одлука. Ќе работи добро, но во исто време, секој час, секој ден и секој месец, ќе го плаќате Амазон прилично скапо, бидејќи ова е значително скапа услуга. Google BigQuery исто така. Ако некој го користел, тогаш знае дека таму можете да извршите неколку барања и да добиете сметка за стотици долари одеднаш.

ClickHouse ги нема овие проблеми.

Каде се користи ClickHouse сега? Покрај Yandex, ClickHouse се користи во еден куп различни бизниси и компании.

• Пред сè, ова е аналитика на веб-апликации, односно ова е случај на употреба што доаѓа од Yandex.
• Многу AdTech компании користат ClickHouse.
• Бројни компании кои треба да ги анализираат дневниците за трансакции од различни извори.
• Неколку компании користат ClickHouse за следење на безбедносните дневници. Тие ги поставуваат на ClickHouse, прават извештаи и ги добиваат резултатите што им се потребни.
• Компаниите почнуваат да го користат во финансиската анализа, односно постепено големите бизниси се приближуваат и до ClickHouse.
• облаци. Ако некој го следи ClickHouse, тогаш веројатно го слушнал името на оваа компанија. Ова е еден од суштинските придонесувачи од заедницата. И тие имаат многу сериозна инсталација на ClickHouse. На пример, тие го направија Kafka Engine за ClickHouse.
• Телекомуникациските компании почнаа да користат. Неколку компании користат ClickHouse или како доказ за концепт или веќе во производство.
• Една компанија користи ClickHouse за следење на производствените процеси. Ги тестираат микроциркулите, отпишуваат еден куп параметри, има околу 2 карактеристики. И потоа анализираат дали играта е добра или лоша.
• Блокчејн аналитика. Постои таква руска компанија како Bloxy.info. Ова е анализа на мрежата ethereum. Тие исто така го направија ова на ClickHouse.

И големината не е важна. Има многу компании кои користат еден мал сервер. И им дозволува да си ги решат проблемите. И уште повеќе компании користат големи кластери од многу сервери или десетици сервери.

И ако ги погледнете записите, тогаш:

• Yandex: 500+ сервери, тие складираат 25 милијарди записи дневно таму.
• LifeStreet: 60 сервери, приближно 75 милијарди записи дневно. Има помалку сервери, повеќе записи отколку во Yandex.
• CloudFlare: 36 сервери, тие заштедуваат 200 милијарди записи дневно. Имаат уште помалку сервери и складираат уште повеќе податоци.
• Блумберг: 102 сервери, околу трилион записи дневно. Носител на рекорд.

Географски, ова е исто така многу. Оваа мапа овде покажува топлинска карта за тоа каде се користи ClickHouse во светот. Овде јасно се истакнуваат Русија, Кина, Америка. Има малку европски земји. И има 4 кластери.

Ова е компаративна анализа, нема потреба да се бараат апсолутни бројки. Ова е анализа на посетители кои читаат материјали на англиски јазик на веб-страницата Altinity, бидејќи таму нема руски јазик. А Русија, Украина, Белорусија, односно рускојазичниот дел од заедницата се најбројни корисници. Потоа доаѓаат САД и Канада. Кина многу фаќа чекор. Таму речиси и да немаше Кина пред шест месеци, сега Кина веќе ја престигна Европа и продолжува да расте. Старата Европа исто така не заостанува, а лидер во користењето на ClickHouse е, чудно е доволно, Франција.

Зошто го кажувам сето ова? Да се ​​покаже дека ClickHouse станува стандардно решение за анализа на големи податоци и веќе се користи на многу места. Ако го користите, вие сте во вистинскиот тренд. Ако сè уште не го користите, тогаш не можете да се плашите дека ќе останете сами и никој нема да ви помогне, бидејќи многумина веќе го прават тоа.

Ова се примери за вистинска употреба на ClickHouse во неколку компании.

• Првиот пример е рекламна мрежа: миграција од Vertica во ClickHouse. И јас познавам неколку компании кои преминале од Вертика или се во процес на транзиција.
• Вториот пример е трансакциско складирање на ClickHouse. Ова е пример изграден на антишеми. Сè што не треба да се прави во ClickHouse по совет на програмерите се прави овде. И тоа е направено толку ефикасно што функционира. И работи многу подобро од типичното трансакциско решение.
• Третиот пример е дистрибуирано пресметување на ClickHouse. Имаше прашање за тоа како ClickHouse може да се интегрира во екосистемот Hadoop. Ќе покажам пример како една компанија направи нешто слично на контејнер за намалување на картата на ClickHouse, следејќи ја локализацијата на податоците итн., за да пресмета многу нетривијална задача.

• LifeStreet е компанија за Ad Tech која ја има целата технологија што доаѓа со рекламна мрежа.
• Таа се занимава со оптимизација на реклами, програмско наддавање.
• Многу податоци: околу 10 милијарди настани дневно. Во исто време, настаните таму може да се поделат на неколку поднастани.
• Има многу клиенти на овие податоци, и тоа не се само луѓе, многу повеќе - ова се различни алгоритми кои се вклучени во програмско наддавање.

Компанијата помина долг и трнлив пат. И јас зборував за тоа на HighLoad. Прво, LifeStreet се пресели од MySQL (со кратко застанување во Oracle) во Vertica. И можете да најдете приказна за тоа.

И сè беше многу добро, но брзо стана јасно дека податоците растат и Вертика е скапа. Затоа, се бараа различни алтернативи. Некои од нив се наведени овде. И всушност, направивме доказ за концепт или понекогаш тестирање на перформансите на скоро сите бази на податоци кои беа достапни на пазарот од 13-та до 16-тата година и беа приближно соодветни во однос на функционалноста. И јас исто така зборував за некои од нив на HighLoad.

Задачата беше да мигрираат од Вертика на прво место, бидејќи податоците растеа. И тие растеа експоненцијално со текот на годините. Потоа отидоа на полицата, но сепак. И предвидувајќи го овој раст, деловните барања за количината на податоци за кои требаше да се направи некаква аналитика, беше јасно дека наскоро ќе се разговара за петабајти. И плаќањето за петабајти е веќе многу скапо, па баравме алтернатива каде да одиме.

Каде да се оди? И долго време воопшто не беше јасно каде да се оди, бидејќи од една страна има комерцијални бази на податоци, тие изгледаат добро. Некои работат речиси исто како Vertica, некои полошо. Но, сите се скапи, ништо поевтино и подобро не можеше да се најде.

Од друга страна, постојат решенија со отворен код, кои не се многубројни, односно за аналитика може да се избројат на прсти. И тие се бесплатни или евтини, но бавни. И често им недостасува потребната и корисна функционалност.

И немаше ништо да се комбинира доброто што е во комерцијалните бази на податоци и сето бесплатно што е во отворен код.

Немаше ништо додека, неочекувано, Yandex не го извади ClickHouse, како волшебник од капа, како зајак. И тоа беше неочекувана одлука, тие сè уште го поставуваат прашањето: „Зошто?“, но сепак.

И веднаш во летото 2016 година, почнавме да гледаме што е ClickHouse. И се покажа дека понекогаш може да биде побрзо од Вертика. Тестиравме различни сценарија на различни барања. И ако барањето користеше само една табела, односно без никакви спојувања (приклучување), тогаш ClickHouse беше двојно побрз од Vertica.

Не бев премногу мрзлив и ги погледнав тестовите на Yandex пред некој ден. Таму е исто: ClickHouse е двојно побрз од Vertica, па често зборуваат за тоа.

Но, ако има приклучоци во прашањата, тогаш сè излегува не многу недвосмислено. И ClickHouse може да биде двојно побавен од Vertica. И ако малку го поправите барањето и го преработите, тогаш тие се приближно еднакви. Не е лошо. И бесплатно.

И откако ги доби резултатите од тестот и гледајќи го од различни агли, LifeStreet отиде во ClickHouse.

Ве потсетувам ова е 16-та година. Тоа беше како шега за глувците кои плачеа и се боцкаа, но продолжија да го јадат кактусот. И ова беше детално опишано, има видео за ова, итн.

Затоа, нема да зборувам за тоа во детали, ќе зборувам само за резултатите и неколку интересни работи за кои тогаш не зборував.

Резултатите се:

• Успешна миграција и повеќе од една година системот веќе работи во производство.
• Продуктивноста и флексибилноста се зголемени. Од 10 милијарди записи што можевме да си дозволиме да ги складираме дневно, а потоа за кратко време, LifeStreet сега складира 75 милијарди записи дневно и може да го прави тоа 3 месеци или повеќе. Ако броите на врвот, тогаш ова е до милион настани во секунда. Повеќе од милион SQL барања дневно пристигнуваат во овој систем, главно од различни роботи.
• И покрај фактот што се користеа повеќе сервери за ClickHouse отколку за Vertica, тие исто така заштедуваа на хардвер, бидејќи во Vertica беа користени прилично скапи SAS дискови. ClickHouse користеше SATA. И зошто? Бидејќи во Vertica вметнувањето е синхроно. И синхронизацијата бара дисковите да не се забавуваат премногу, а исто така и мрежата да не успорува премногу, односно прилично скапа операција. И во ClickHouse вметнувањето е асинхроно. Покрај тоа, секогаш можете да пишувате сè локално, нема дополнителни трошоци за ова, така што податоците може да се вметнуваат во ClickHouse многу побрзо отколку во Vertika, дури и на побавни дискови. И читањето е приближно исто. Читајќи на SATA, ако тие се во RAID, тогаш сето ова е доволно брзо.
• Не е ограничено со лиценца, т.е. 3 петабајти податоци во 60 сервери (20 сервери се една реплика) и 6 трилиони записи во факти и агрегации. Вакво нешто не можеше да си дозволи во Вертика.

Сега се свртувам кон практични работи во овој пример.

• Првата е ефикасна шема. Многу зависи од шемата.
• Втората е ефикасна генерација на 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 и Касандра. Касандра се користеше како складирање на трансакции, односно сите поврзани трансакции беа складирани во него. И кога ќе дојде некој настан во Runtime, на пример, покажува некоја страница или нешто друго, тогаш е побарано барање до Касандра - има ли таква личност или не. Тогаш се добиени трансакциите кои се однесуваат на тоа. И врската беше направена.

И ако има среќа што барањето има идентификација на трансакција, тогаш е лесно. Но, обично нема среќа. Затоа, беше потребно да се најде последната трансакција или трансакцијата со последниот клик итн.

И сето тоа функционираше многу добро се додека врзувањето беше до последниот клик. Затоа што има, да речеме, 10 милиони кликови дневно, 300 милиони месечно, ако поставиме прозорец за еден месец. И бидејќи во Касандра мора да биде целосно во меморија за да работи брзо, бидејќи Runtime треба брзо да реагира, потребни се околу 10-15 сервери.

И кога сакаа да поврзат трансакција со екранот, веднаш се покажа дека не е толку забавно. И зошто? Може да се види дека треба да се складираат 30 пати повеќе настани. И, соодветно, ви требаат 30 пати повеќе сервери. И излегува дека ова е некаква астрономска фигура. Да се ​​задржи до 500 сервери за да се изврши поврзувањето, и покрај фактот што има значително помалку сервери во Runtime, тогаш ова е некаква погрешна бројка. И почнаа да размислуваат што да прават.

И отидовме во ClickHouse. И како да го направите тоа на ClickHouse? На прв поглед се чини дека ова е збир на анти-шеми.

• Трансакцијата расте, прикачуваме сè повеќе настани на неа, т.е. е променлива, а ClickHouse не работи многу добро со променливи објекти.
• Кога некој посетител ќе дојде кај нас, треба да ги повлечеме неговите трансакции со клуч, со неговиот ID на посета. Ова е исто така точка барање, тие не го прават тоа во ClickHouse. Обично ClickHouse има големи ... скенирања, но тука треба да добиеме некои записи. Исто така антишаблон.
• Покрај тоа, трансакцијата беше во json, но тие не сакаа да ја препишат, па сакаа да го складираат json на неструктуриран начин, и доколку е потребно, да извлечат нешто од него. И ова е исто така антишаблон.

Тоа е, збир на антишеми.

Но, сепак се покажа дека направи систем кој функционираше многу добро.

Што беше направено? Се појави ClickHouse, во кој беа фрлени дневници, поделени на записи. Се појави атрибуирана услуга која прими логови од ClickHouse. После тоа, за секој запис, со ID на посета, добивав трансакции кои можеби сè уште не се обработени и плус снимки, односно веќе поврзани трансакции, имено резултат од претходната работа. Веќе направив логика од нив, ја избрав точната трансакција, поврзав нови настани. Повторно најавено. Дневникот се врати во ClickHouse, односно тоа е постојано цикличен систем. И покрај тоа, отидов во DWH да го анализирам таму.

Токму во оваа форма не функционираше многу добро. И за да му олеснат на ClickHouse, кога имаше барање по идентификација на посета, тие ги групираа овие барања во блокови од 1-000 идентификатори за посети и ги повлекоа сите трансакции за 2-000 луѓе. И тогаш сето тоа функционираше.

Ако погледнете внатре во ClickHouse, тогаш има само 3 главни табели кои го служат сето ова.

Првата табела во која се прикачуваат дневниците, а дневниците се поставени речиси без обработка.

Втора табела. Преку материјализираниот поглед, од овие трупци беа изгризани настани кои сè уште не се припишани, односно неповрзани. И преку материјализираниот приказ, трансакциите беа извлечени од овие дневници за да се изгради слика. Тоа е, посебен материјализиран поглед изгради слика, имено последната акумулирана состојба на трансакцијата.

Еве го текстот напишан во SQL. Би сакал да коментирам неколку важни работи во него.

Првата важна работа е можноста да се извлечат колони и полиња од json во ClickHouse. Односно, ClickHouse има некои методи за работа со json. Тие се многу, многу примитивни.

visitParamExtractInt ви овозможува да извлечете атрибути од json, т.е. првиот удар работи. И на овој начин можете да го извадите ID на трансакцијата или да го посетите ID. Овој пат.

Второ, овде се користи незгодно материјализирано поле. Што значи тоа? Тоа значи дека не можете да го вметнете во табелата, т.е. не е вметнат, се пресметува и се складира при вметнување. При вметнување, ClickHouse ја врши работата наместо вас. И она што ви треба подоцна е веќе извлечено од json.

Во овој случај, материјализираниот поглед е за необработени редови. И првата табела со практично необработени трупци штотуку се користи. И што прави тој? Прво, го менува сортирањето, т.е. сортирањето сега оди по ID на посета, бидејќи треба брзо да ја повлечеме неговата трансакција за одредена личност.

Втората важна работа е index_granularity. Ако сте го виделе MergeTree, тоа е обично 8 стандардно index_granularity. Што е тоа? Ова е параметарот на реткост на индексот. Во ClickHouse индексот е редок, никогаш не го индексира секој запис. Тоа го прави на секои 192. И ова е добро кога се потребни многу податоци за да се пресметаат, но лошо е кога се малку, бидејќи има големи трошоци. И ако ја намалиме грануларноста на индексот, тогаш ги намалуваме трошоците. Не може да се сведе на еден, бидејќи можеби нема доволно меморија. Индексот секогаш се чува во меморијата.

Snapshot користи и некои други интересни функции на ClickHouse.

Прво, тоа е AggregatingMergeTree. И AggregatingMergeTree складира argMax, т.е. ова е состојбата на трансакцијата што одговара на последниот временски печат. Трансакциите се генерираат цело време за даден посетител. И во последната состојба на оваа трансакција, додадовме настан и имаме нова состојба. Повторно го погоди ClickHouse. И преку argMax во овој материјализиран поглед, секогаш можеме да ја добиеме моменталната состојба.

• Врзувањето е „откачено“ од Runtime.
• Месечно се складираат и обработуваат до 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 паралелно и независно, сето ова се случува досега паралелно и дистрибуирано.

Тогаш решивме да ги намалиме овие податоци, а притоа да не ја изгубиме експресивноста. Намалете со користење низи, т.е. за секој временски период, направете низа акции и низа цени. Затоа, зазема многу помалку простор за податоци. И со нив е малку полесна за работа. Ова се речиси паралелни операции, односно делумно читаме паралелно, а потоа пишуваме на серверот.

После тоа, може да се реплицира. Буквата „р“ значи дека ги реплициравме овие податоци. Односно, имаме исти податоци на сите три сервери - тоа се низите.

А потоа со специјална скрипта од овој сет од 12,5 милиони корелации што треба да се пресметаат, можете да направите пакети. Односно 2 задачи со 500 пара корелации. И оваа задача треба да се пресмета на одреден сервер ClickHouse. Ги има сите податоци, бидејќи податоците се исти и може последователно да ги пресмета.

Уште еднаш, вака изгледа. Прво, ги имаме сите податоци во оваа структура: време, акции, цена. Потоа го пресметавме logReturn, односно податоци од иста структура, но наместо цената веќе имаме logReturn. Потоа тие беа преработени, т.е. добивме време и groupArray за акции и цени. Реплицирано. И после тоа, генериравме еден куп задачи и ги нахранивме на ClickHouse за да ги брои. И тоа функционира.

На доказ за концепт, задачата беше подзадача, т.е. беа земени помалку податоци. И само три сервери.

Првите две фази: пресметувањето на Log_return и завиткувањето во низи траеше околу еден час.

А пресметката на корелацијата е околу 50 часа. Но, 50 часа не се доволни, бидејќи порано работеа со недели. Тоа беше голем успех. И ако броите, тогаш 70 пати во секунда сè се сметаше на овој кластер.

Но, најважно е што овој систем е практично без тесни грла, т.е. скалира речиси линеарно. И тие го проверија. Успешно го зголеми.

• Правилната шема е половина од успехот. И вистинската шема е употребата на сите потребни ClickHouse технологии.
• Summing/AggregatingMergeTrees се технологии кои ви дозволуваат да соберете или да ја разгледате состојбата на снимката како посебен случај. И тоа во голема мера поедноставува многу работи.
• Материјализираните прегледи ви дозволуваат да ја заобиколите границата на еден индекс. Можеби не кажав многу јасно, но кога ги вчитавме дневниците, необработените дневници беа во табелата со еден индекс, а дневниците на атрибутите беа во табелата, односно истите податоци, само филтрирани, но индексот беше целосно други. Се чини дека се исти податоци, но различно сортирање. А материјализираните погледи ви овозможуваат, доколку ви треба, да го заобиколите таквото ограничување на ClickHouse.
• Намалете ја грануларноста на индексот за точките барања.
• И паметно дистрибуирајте ги податоците, обидете се да ги локализирате податоците во серверот колку што е можно повеќе. И обидете се да се осигурате дека барањата исто така користат локализација каде што е можно колку што е можно повеќе.

И сумирајќи го овој краток говор, можеме да кажеме дека ClickHouse сега цврсто ја окупира територијата и на комерцијалните бази на податоци и на базите на податоци со отворен код, т.е., специјално за аналитика. Тој совршено се вклопува во овој пејзаж. И уште повеќе, полека почнува да ги истиснува другите, бидејќи кога имате ClickHouse, не ви треба InfiniDB. Вертика можеби нема да биде потребна наскоро ако имаат нормална поддршка за SQL. Уживајте!

-Ви благодариме за извештајот! Многу интересно! Имаше ли споредби со Apache Phoenix?

Не, не сум слушнал некој да споредува. Ние и Yandex се обидуваме да ги следиме сите споредби на ClickHouse со различни бази на податоци. Затоа што ако одеднаш нешто се покаже дека е побрзо од ClickHouse, тогаш Леша Миловидов не може да спие ноќе и почнува брзо да го забрзува. Не сум слушнал за таква споредба.

• (Алексеј Миловидов) Apache Phoenix е SQL мотор напојуван од Hbase. 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 не работи долго време? Најверојатно не. Работи сигурно од 2012-2013 година на ClickHouse. Можам да го кажам истото за моето искуство. Никогаш не сме имале целосни неуспеси. Некои делумни работи може да се случат, но тие никогаш не биле доволно критични за сериозно да влијаат на бизнисот. Тоа никогаш не се случило. ClickHouse е доста сигурен и не паѓа случајно. Не треба да се грижите за тоа. Тоа не е сурова работа. Ова е докажано од многу компании.

Здраво! Рековте дека треба веднаш да размислите за шемата за податоци. Што ако се случи? Моите податоци се слеваат и се слеваат. Поминуваат шест месеци и разбирам дека е невозможно да се живее вака, треба повторно да ги подигнам податоците и да направам нешто со нив.

Се разбира, ова зависи од вашиот систем. Постојат неколку начини да го направите ова практично без прекин. На пример, можете да креирате материјализиран приказ во кој ќе направите различна структура на податоци ако може уникатно да се мапира. Односно, ако дозволува мапирање со помош на ClickHouse, т.е. извлечете некои работи, сменете го примарниот клуч, промените партиција, тогаш можете да направите материјализиран приказ. Пребришете ги вашите стари податоци таму, новите ќе се напишат автоматски. А потоа само префрлете се на користење на материјализираниот приказ, потоа префрлете го записот и убијте ја старата табела. Ова е генерално нон-стоп метод.

Ви благодариме.

Извор: www.habr.com