Теория и практика на използване на ClickHouse в реални приложения. Александър Зайцев (2018)

Въпреки факта, че сега има много данни почти навсякъде, аналитичните бази данни все още са доста екзотични. Те са слабо познати и още по-лошо могат да ги използват ефективно. Мнозина продължават да „ядат кактус“ с MySQL или PostgreSQL, които са предназначени за други сценарии, страдат с NoSQL или надплащат за търговски решения. ClickHouse променя правилата на играта и значително намалява прага за навлизане в света на аналитичните СУБД.

Доклад от 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 можете да вземете решение много бързо. Ще работи добре, но в същото време всеки час, всеки ден и всеки месец ще плащате доста скъпо на Amazon, защото това е значително скъпа услуга. Google BigQuery също. Ако някой го е използвал, той знае, че там можете да пуснете няколко заявки и изведнъж да получите сметка за стотици долари.

ClickHouse няма тези проблеми.

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

• На първо място, това е анализ на уеб приложения, т.е. това е случай на използване, който дойде от Yandex.
• Много рекламни компании използват ClickHouse.
• Множество компании, които трябва да анализират регистрационни файлове на транзакции от различни източници.
• Няколко компании използват ClickHouse за наблюдение на регистрационни файлове за сигурност. Те ги качват в ClickHouse, правят отчети и получават нужните резултати.
• Компаниите започват да го използват във финансовия анализ, т.е. постепенно големите бизнеси също се доближават до ClickHouse.
• cloudflare. Ако някой следва ClickHouse, вероятно е чувал името на тази компания. Това е един от основните участници от общността. И имат много сериозна инсталация на ClickHouse. Например те направиха Kafka Engine за ClickHouse.
• Телекомуникационните компании започнаха да използват. Няколко компании използват ClickHouse или като доказателство за концепцията, или вече в производство.
• Една компания използва ClickHouse за наблюдение на производствените процеси. Те тестват микросхеми, отписват куп параметри, има около 2 характеристики. И след това анализират дали играта е добра или лоша.
• Блокчейн анализи. Има такава руска компания като Bloxy.info. Това е анализ на мрежата ethereum. Те направиха това и в ClickHouse.

И размерът няма значение. Има много компании, които използват един малък сървър. И той им позволява да решават проблемите си. И още повече компании използват големи клъстери от много сървъри или десетки сървъри.

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

• Yandex: 500+ сървъра, те съхраняват 25 милиарда записа на ден там.
• LifeStreet: 60 сървъра, приблизително 75 милиарда записа на ден. Има по-малко сървъри, повече записи, отколкото в Yandex.
• CloudFlare: 36 сървъра, те спестяват 200 милиарда записа на ден. Те имат още по-малко сървъри и съхраняват още повече данни.
• Bloomberg: 102 сървъра, около трилион влизания на ден. Рекордьор.

Географски това също е много. Тази карта тук показва топлинна карта на това къде по света се използва ClickHouse. Тук ясно се открояват Русия, Китай, Америка. Малко са европейските държави. И има 4 клъстера.

Това е сравнителен анализ, няма нужда да търсим абсолютни цифри. Това е анализ на посетители, които четат англоезични материали на уебсайта Altinity, защото там няма рускоезични. И Русия, Украйна, Беларус, т.е. рускоезичната част от общността, това са най-многобройните потребители. Следват САЩ и Канада. Китай много наваксва. Преди шест месеца там почти нямаше Китай, сега Китай вече изпревари Европа и продължава да расте. Стара Европа също не изостава, а лидер в използването на ClickHouse е, колкото и да е странно, Франция.

Защо разказвам всичко това? Да покаже, че ClickHouse се превръща в стандартно решение за анализ на големи данни и вече се използва на много места. Ако го използвате, вие сте в правилната тенденция. Ако все още не го използвате, тогава не можете да се страхувате, че ще останете сами и никой няма да ви помогне, защото мнозина вече правят това.

Това са примери за реално използване на ClickHouse в няколко компании.

• Първият пример е рекламна мрежа: миграция от Vertica към ClickHouse. И познавам няколко компании, които са преминали от Vertica или са в процес на преход.
• Вторият пример е съхранение на транзакции в ClickHouse. Това е пример, изграден върху антимодели. Всичко, което не трябва да се прави в ClickHouse по съвет на разработчиците, се прави тук. И е направено толкова ефективно, че работи. И работи много по-добре от типичното решение за транзакции.
• Третият пример е разпределено изчисление на ClickHouse. Имаше въпрос как ClickHouse може да бъде интегриран в екосистемата Hadoop. Ще покажа пример за това как компания направи нещо подобно на контейнер за намаляване на картата в ClickHouse, следене на локализацията на данни и т.н., за да изчисли много нетривиална задача.

• LifeStreet е компания за рекламни технологии, която разполага с цялата технология, идваща с рекламна мрежа.
• Занимава се с оптимизация на реклами, programmatic bidding.
• Много данни: около 10 милиарда събития на ден. В същото време събитията там могат да бъдат разделени на няколко подсъбития.
• Има много клиенти на тези данни и това не са само хора, много повече - това са различни алгоритми, които се занимават с програмно наддаване.

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

И всичко беше много добре, но бързо стана ясно, че данните растат и Vertica е скъпа. Затова бяха търсени различни алтернативи. Някои от тях са изброени тук. И всъщност направихме доказателство за концепция или понякога тестване на производителността на почти всички бази данни, които бяха налични на пазара от 13-та до 16-та година и бяха приблизително подходящи по отношение на функционалността. И аз също говорих за някои от тях на HighLoad.

Задачата беше да се мигрира от Vertica на първо място, защото данните нарастваха. И те нарастваха експоненциално през годините. След това отидоха на рафта, но въпреки това. И предвиждайки този растеж, бизнес изискванията за количеството данни, върху които трябва да се направи някакъв вид анализ, беше ясно, че петабайтите скоро ще бъдат обсъждани. И плащането на петабайти вече е много скъпо, така че търсихме алтернатива къде да отидем.

Къде да отидем? И дълго време изобщо не беше ясно къде да отидем, защото от една страна има търговски бази данни, те изглежда работят добре. Някои работят почти толкова добре, колкото Vertica, други по-лошо. Но всички те са скъпи, нищо по-евтино и по-добро не може да се намери.

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

И нямаше нищо, което да комбинира доброто, което е в търговските бази данни, и всичко безплатно, което е в отворен код.

Нямаше нищо, докато неочаквано Yandex извади ClickHouse, като магьосник от шапка, като заек. И това беше неочаквано решение, те все още задават въпроса: „Защо?“, Но въпреки това.

И веднага през лятото на 2016 г. започнахме да разглеждаме какво е ClickHouse. И се оказа, че понякога може да бъде по-бърз от Vertica. Тествахме различни сценарии при различни заявки. И ако заявката използва само една таблица, тоест без никакви съединения (join), тогава 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 няма програма за планиране на заявки. Абсолютно не.
• Въпреки това сложните заявки все още трябва да бъдат планирани. В какви случаи?
• Ако има множество обединения в заявката, вие ги обвивате в подизбори. И редът, в който се изпълняват, има значение.
• И второто - ако искането е разпределено. Тъй като в разпределена заявка само най-вътрешната подизбор се изпълнява разпределено, а всичко останало се предава на един сървър, към който сте се свързали и изпълнявате там. Следователно, ако сте разпределили заявки с много съединения (join), тогава трябва да изберете реда.

И дори в по-прости случаи, понякога също е необходимо да свършите работата на планировчика и да пренапишете заявките малко.

Ето един пример. От лявата страна има заявка, която показва първите 5 държави. И отнема 2,5 секунди според мен. И от дясната страна същата заявка, но леко пренаписана. Вместо групиране по низ, започнахме да групираме по ключ (int). И е по-бързо. И след това свързахме речник с резултата. Вместо 2,5 секунди, заявката отнема 1,5 секунди. Това е добре.

Подобен пример с филтри за пренаписване. Ето една молба за Русия. Работи за 5 секунди. Ако го пренапишем по такъв начин, че отново да сравняваме не низ, а числа с някакъв набор от онези ключове, които се отнасят до Русия, тогава ще бъде много по-бързо.

Има много такива трикове. И те ви позволяват значително да ускорите заявките, които смятате, че вече се изпълняват бързо или, обратно, се изпълняват бавно. Те могат да бъдат направени дори по-бързо.

• Максимална работа в разпределен режим.
• Сортиране по минимални типове, както направих по ints.
• Ако има някакви присъединявания (join), речници, тогава е по-добре да ги направите в краен случай, когато вече имате поне частично групирани данни, тогава операцията за присъединяване или извикването на речника ще се извиква по-малко пъти и ще бъде по-бързо .
• Подмяна на филтри.

Има и други техники и не само тези, които демонстрирах. И всички те понякога могат значително да ускорят изпълнението на заявките.

Да преминем към следващия пример. Компания X от САЩ. Какво прави тя?

Имаше задача:

• Офлайн свързване на рекламни транзакции.
• Моделиране на различни модели на подвързване.

Какъв е сценарият?

Един обикновен посетител идва на сайта например 20 пъти месечно от различни реклами или просто така понякога идва без никакви реклами, защото помни този сайт. Разглежда някои продукти, поставя ги в кошницата, вади ги от кошницата. И в крайна сметка нещо се купува.

Разумни въпроси: "Кой трябва да плати за реклама, ако е необходимо?" и „Каква реклама му е повлияла, ако има такава?“. Тоест защо е купил и как да накара хора като този човек също да купуват?

За да разрешите този проблем, трябва да свържете събитията, които се случват на уебсайта по правилния начин, тоест по някакъв начин да изградите връзка между тях. След това се изпращат за анализ в DWH. И въз основа на този анализ изградете модели на кого и какви реклами да показвате.

Рекламна транзакция е набор от свързани потребителски събития, които започват от показване на реклама, след това се случва нещо, след това може би покупка и след това може да има покупки в рамките на покупка. Например, ако това е мобилно приложение или мобилна игра, тогава инсталирането на приложението обикновено се извършва безплатно и ако нещо се направи там, тогава може да са необходими пари за това. И колкото повече човек харчи в приложението, толкова по-ценно е то. Но за това трябва да свържете всичко.

Има много модели на обвързване.

Най-популярните са:

• Последно взаимодействие, където взаимодействието е или кликване, или импресия.
• Първото взаимодействие, т.е. първото нещо, което е довело човек на сайта.
• Линейна комбинация - всички еднакво.
• Затихване.
• И т.н.

И как работи всичко това на първо място? Имаше Runtime и Cassandra. Cassandra беше използвана като хранилище за транзакции, т.е. всички свързани транзакции бяха съхранени в нея. И когато в Runtime дойде някакво събитие, например показване на някаква страница или нещо друго, тогава се отправи запитване към Касандра - има ли такъв човек или не. След това бяха получени транзакциите, които се отнасят до него. И връзката беше направена.

И ако има късмет заявката да има идентификатор на транзакция, тогава е лесно. Но обикновено няма късмет. Следователно беше необходимо да се намери последната транзакция или транзакцията с последното кликване и т.н.

И всичко работеше много добре, стига обвързването да беше до последното щракване. Защото има, да речем, 10 милиона кликвания на ден, 300 милиона на месец, ако зададем прозорец за един месец. И тъй като в Cassandra всичко трябва да е в паметта, за да работи бързо, защото Runtime трябва да реагира бързо, бяха необходими около 10-15 сървъра.

И когато искаха да свържат транзакция с дисплея, веднага се оказа, че не е толкова забавно. И защо? Вижда се, че трябва да се съхранят 30 пъти повече събития. И съответно имате нужда от 30 пъти повече сървъри. И се оказва, че това е някаква астрономическа цифра. Да поддържате до 500 сървъра, за да направите свързването, въпреки факта, че има значително по-малко сървъри в Runtime, тогава това е някаква грешна цифра. И започнаха да мислят какво да правят.

И отидохме в ClickHouse. И как да го направите в ClickHouse? На пръв поглед изглежда, че това е набор от антишаблони.

• Транзакцията расте, ние свързваме все повече и повече събития към нея, т.е. тя е променлива, а ClickHouse не работи много добре с променливи обекти.
• Когато посетител дойде при нас, трябва да изтеглим транзакциите му по ключ, по неговия идентификатор на посещение. Това също е точкова заявка, те не правят това в ClickHouse. Обикновено ClickHouse има големи …сканирания, но тук трябва да вземем някои записи. Също антимодел.
• Освен това транзакцията беше в json, но те не искаха да я пренапишат, така че искаха да съхраняват json по неструктуриран начин и, ако е необходимо, да извадят нещо от него. И това също е антимодел.

Тоест набор от антимодели.

Но въпреки това се оказа, че се прави система, която работи много добре.

Какво беше направено? Появи се ClickHouse, в който бяха хвърлени трупи, разделени на записи. Появи се приписана услуга, която получава регистрационни файлове от ClickHouse. След това за всяко влизане по идентификатор на посещение получих транзакции, които все още не могат да бъдат обработени, плюс моментни снимки, т.е. вече свързани транзакции, а именно резултатът от предишна работа. Вече направих логика от тях, избрах правилната транзакция, свързах нови събития. Влезте отново. Дневникът се върна в ClickHouse, т.е. това е постоянно циклична система. И освен това отидох в DWH да го анализирам там.

Именно в тази форма не се получи много добре. И за да улеснят ClickHouse, когато имаше заявка по идентификатор на посещение, те групираха тези заявки в блокове от 1-000 идентификатора на посещения и извадиха всички транзакции за 2-000 души. И тогава всичко проработи.

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

Първата таблица, в която се качват регистрационни файлове и регистрационните файлове се качват почти без обработка.

Втора маса. Чрез материализирания изглед, от тези трупи, събития, които все още не са приписани, т.е. несвързани, са били изхапани. И чрез материализирания изглед транзакциите бяха извадени от тези регистрационни файлове, за да се създаде моментна снимка. Тоест специален материализиран изглед изгради моментна снимка, а именно последното натрупано състояние на транзакцията.

Ето текста, написан на SQL. Бих искал да коментирам няколко важни неща в него.

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

visitParamExtractInt ви позволява да извличате атрибути от json, т.е. първото попадение работи. И по този начин можете да извадите идентификатор на транзакция или идентификатор на посещение. Този път.

Второ, тук се използва сложно материализирано поле. Какво означава? Това означава, че не можете да го вмъкнете в таблицата, т.е. не се вмъква, а се изчислява и съхранява при вмъкване. Когато поставяте, ClickHouse върши работата вместо вас. И това, от което се нуждаете по-късно, вече е изтеглено от json.

В този случай материализираният изглед е за необработени редове. И първата маса с практически необработени регистрационни файлове току-що е използвана. И какво прави? Първо, променя се сортирането, т.е. сортирането вече става по идентификатор на посещение, защото трябва бързо да извадим транзакцията му за конкретен човек.

Второто важно нещо е index_granularity. Ако сте виждали MergeTree, обикновено е 8 по подразбиране index_granularity. Какво е? Това е параметърът за разреденост на индекса. В ClickHouse индексът е рядък, той никога не индексира всеки запис. Прави това на всеки 192 8. И това е добре, когато се изискват много данни за изчисляване, но е лошо, когато са малко, защото има голямо натоварване. И ако намалим детайлността на индекса, тогава намаляваме режийните разходи. Не може да се намали до един, защото може да няма достатъчно памет. Индексът винаги се съхранява в паметта.

Snapshot също използва някои други интересни функции на ClickHouse.

Първо, това е AggregatingMergeTree. А AggregatingMergeTree съхранява argMax, т.е. това е състоянието на транзакцията, съответстващо на последния времеви печат. Транзакциите се генерират през цялото време за даден посетител. И в последното състояние на тази транзакция добавихме събитие и имаме ново състояние. Отново удари ClickHouse. И чрез argMax в този материализиран изглед винаги можем да получим текущото състояние.

• Свързването е "отделено" от Runtime.
• До 3 милиарда транзакции на месец се съхраняват и обработват. Това е с порядък повече, отколкото беше в Cassandra, т.е. в типична транзакционна система.
• Клъстер от 2x5 ClickHouse сървъри. 5 сървъра и всеки сървър има реплика. Това е дори по-малко, отколкото беше в Cassandra, за да направим приписване въз основа на кликване, а тук имаме въз основа на импресии. Тоест, вместо да увеличат броя на сървърите с 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 са технологии, които ви позволяват да агрегирате или разглеждате моментна снимка на състоянието като специален случай. И значително опростява много неща.
• Материализираните изгледи ви позволяват да заобиколите ограничението от един индекс. Може би не го казах много ясно, но когато заредихме регистрационните файлове, необработените регистрационни файлове бяха в таблицата с един индекс, а регистрационните файлове на атрибутите бяха в таблицата, т.е. същите данни, само филтрирани, но индексът беше напълно други. Изглежда едни и същи данни, но различно сортиране. А Materialized Views ви позволява, ако имате нужда, да заобиколите такова ограничение на ClickHouse.
• Намаляване на детайлността на индекса за заявки за точки.
• И разпределете данните интелигентно, опитайте се да локализирате данните в рамките на сървъра, доколкото е възможно. И се опитайте да гарантирате, че заявките също използват локализация, където е възможно, колкото е възможно повече.

И обобщавайки тази кратка реч, можем да кажем, че ClickHouse вече твърдо заема територията както на търговските бази данни, така и на базите данни с отворен код, т.е. специално за анализи. Той се вписва идеално в този пейзаж. И нещо повече, бавно започва да измества другите, защото когато имате ClickHouse, не ви трябва InfiniDB. Vertika може да не е необходима скоро, ако направят нормална поддръжка на 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