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

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

Доклад от BackEnd Conf 2018 г. и е публикуван с разрешението на докладчика.

Кой съм аз и защо говоря за ClickHouse? Аз съм директор по разработка в компанията LifeStreet, която използва ClickHouse. Освен това съм основател на Altinity. Това е партньор на Яндекс, който популяризира ClickHouse и помага на Яндекс да направи ClickHouse по-успешен. Също така съм готов да споделям знания за ClickHouse.

И освен това не съм брат на Петя Заицев. Често ме питат за това. Не, не сме братя.

„Всички знаят“, че ClickHouse:

• Много бърз,
• Много удобен,
• Използва се в Яндекс.

Малко по-малко известно е в кои компании и как се използва.

Ще ви разкажа за какво, къде и как се използва ClickHouse, освен в Яндекс.

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

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

Първият въпрос: „Защо е нужен ClickHouse?“. Въпросът изглежда достатъчно очевиден, но отговорите на него са повече от един.

• Първият отговор – заради производителността. ClickHouse е много бърз. Анализът на ClickHouse също е много бърз. Често може да се използва там, където нещо друго работи много бавно или много слабо.
• Вторият отговор – това е цената. И преди всичко цената на мащабирането. Например, Vertica – съвсем отлична база данни. Тя работи много добре, ако нямате много терабайти данни. Но когато става въпрос за стотици терабайти или за петабайти, цената на лиценза и поддръжката става доста сериозна. И това е скъпо. А ClickHouse е безплатен.
• Третият отговор е оперативната стойност. Това е подход, който разглежда въпроса от малко по-различна страна. RedShift е отличен аналог. На RedShift може да се направи решение много бързо. То ще работи добре, но на всеки час, всеки ден и всеки месец ще платите доста скъпо на Amazon, защото това е съществено скъп сервис. Google BigQuery също. Ако някой е ползвал, знае, че може да стартира няколко заявки и да получи сметка на стотици долари изведнъж.

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

Къде се използва ClickHouse в момента? Освен в Яндекс, ClickHouse се използва в много различни бизнеси и компании.

• На първо място това е анализ на уеб приложения, т.е. това е use case, който идва от Яндекс.
• Много AdTech компании използват ClickHouse.
• Многобройни компании, които трябва да анализират оперативни логове от различни източници.
• Няколко компании използват ClickHouse за мониторинг на сигурността на логовете. Те ги качват в ClickHouse, правят отчети, получават необходимите им резултати.
• Компаниите започват да го използват и за финансов анализ, т.е. постепенно голям бизнес също подбира ClickHouse.
• CloudFlare. Ако някой следи ClickHouse, сигурно е чул названието на тази компания. Това е един от съществените контрибутори от общността. И те имат много сериозна инсталация на ClickHouse. Например, те направиха Kafka Engine за ClickHouse.
• Телекомуникационни компании започнаха да го използват. Няколко компании използват ClickHouse или като proof of concept, или вече в производство.
• Една компания използва ClickHouse за мониторинг на производствени процеси. Те тестват микрочипове, записват много параметри, около 2000 характеристики. И после анализират – добра партида или лоша.
• Блокчейн аналитика. Има такава руска компания, наречена Bloxy.info. Това е анализ на ethereum мрежата. И те също го направиха на ClickHouse.

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

И ако погледнем рекорди, то:

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

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

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

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

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

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

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

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

Всичко беше много добре, но достатъчно бързо стана ясно, че данните растат и Vertica е скъпо. Затова бяха търсени различни алтернативи. Някои от тях са изброени тук. Всъщност направихме proof of concept или понякога performance testing почти на всички бази данни, които бяха на разположение на пазара от 2013 до 2016 година и съответстваха на функционалността. И за част от тях също разказах на HighLoad.

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

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

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

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

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

И веднага през лятото на 2016 г. започнахме да проучваме какво е ClickHouse. Оказа се, че понякога той може да бъде по-бърз от Vertica. Тествахме различни сценарии на различни запитвания. И ако запитването използваше само една таблица, т. е. без никакви джойн (join), ClickHouse беше два пъти по-бърз от Vertica.

Не се уморих и прегледах допълнителни тестове на Яндекс преди дни. Там положението е същото: ClickHouse е два пъти по-бърз от Vertica, затова те често споменават това.

Но ако в запитванията има джойни (join), всичко става не много еднозначно. И ClickHouse може да бъде два пъти по-бавен от Vertica. А ако малко коригираме запитването и го пренапишем, то се оказва приблизително равно. Не е зле. И безплатно.

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

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

Затова не искам да говоря подробно, ще споделя само резултатите и няколко интересни неща, за които не бях говорил тогава.

Резултатите – това е:

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

Сега преминавам към практическия аспект в този пример.

• Първото е ефективната схема. От схемата зависи много.
• Второто е генерирането на ефективен SQL.

Типичната OLAP заявка е select. Част от колоните се използват в group by, друга част от колоните отива в агрегатни функции. Има where, която може да се разглежда като срез на куба. Целият group by може да се представи като проекция. Затова това се нарича многомерен анализ на данни.

Често това се моделира във вида на star-схема, когато има централен факт и характеристики на този факт отстрани, по лъчите.

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

Но в ClickHouse това не работи добре. Има две причини:

• Първата е, че в ClickHouse нямаме много добри join-ове, т.е. join-ове има, но са некачествени. Все още некачествени.
• Втората е, че таблиците не се актуализират. Обикновено в тези таблици, които обикалят star-схемата, трябва да се променя нещо. Например, името на клиента, името на компанията и така нататък. И това не работи.

И решение на това в ClickHouse съществува. дори цели две:

• Първото е използването на речници. Външните речници решават проблема с star-схемата, с актуализациите и други в 99%.
• Второто е използването на масиви. Масивите също помагат да се избегнат join-ове и проблеми с нормализацията.

• Не е необходим join.
• Актуализируеми. От март 2018 г. се появи недокументирана възможност (не можете да го намерите в документацията) за частично актуализиране на речниците, т.е. записите, които са се променили. Практически, това е като таблица.
• Винаги в паметта, затова join-ове с речника работят по-бързо, отколкото ако това беше таблица, която е на диска и съвсем не е факт, че е в кеша, по-скоро не е.

• Също така не е необходим join.
• Това е компактно представяне 1 към много.
• И на моето мнение, масивите са направени за гикове. Това са лямбда функции и други.

Това не е за краснословие. Това е много мощна функционалност, която позволява да се правят много неща много просто и елегантно.

Типични примери, които помагат за решаване на масиви. Тези примери са прости и достатъчно нагледни:

• Търсене по тагове. Ако имате хаштаг и искате да намерите записи по хаштаг.
• Търсене по key-value двойки. Има някакви атрибути със стойност.
• Съхранение на списъци с ключове, които трябва да преведете в нещо друго.

Всички тези задачи могат да бъдат решени без масиви. Таговете могат да бъдат поставени в една строга и да се избират с регулярни изрази или в отделна таблица, но тогава ще трябва да правите джойн (join).

А в ClickHouse не е необходимо нищо да правите, достатъчно е да опишете масив от стрингове за хаштаг или да направите вложена структура за системи от тип key-value.

Вложената структура може би не е най-удачното название. Това са два масива, които имат обща част в името и някои свързани характеристики.

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

Търсенето по subid е малко по-сложно. Първо трябва да намерим индекса на ключа, а после да вземем елемента с този индекс и да проверим дали стойността е точно тази, която ни трябва. Но все пак е много просто и компактно.

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

Друг пример. Имате масив, в който съхранявате ID-та. И можете да ги преведете в имена. Функция arrayMap. Това е типична ламбда-функция. Предавате там ламбда-изрази. И тя извлича стойността на името за всяко ID от речника.

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

Тези неща значително опростяват схемата и решават куп проблеми.

Но следващият проблем, с който се сблъскахме и за който искам да спомена, са ефективните заявки.

• В ClickHouse няма планировчик на заявки. Изобщо няма.
• Но все пак сложните заявки трябва да се планират. В кои случаи?
• Ако в заявката има няколко обединения (join), които обвивате в подзаявки. И редът, в който те се изпълняват, е важен.
• И второто – ако заявката е разпределена. Защото в разпределената заявка само най-вътрешната подзаявка се изпълнява разпределено, а всичко останало се предава на един сървър, на който сте се свързали и се изпълнява там. Затова, ако имате разпределени заявки с много обединения (join), трябва да избирате реда.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Съществуват много модели на свързване.

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

• Last Interaction, където interaction – това е или клик, или показване.
• First Interaction, тоест първото нещо, което е довело потребителя до сайта.
• Линейна комбинация – на всички равно.
• Затихване.
• И други.

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

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

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

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

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

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

Т.е. набор от антипатерни.

Но все пак успяхме да направим система, която работеше много добре.

Какво беше направено? Появи се ClickHouse, в който се зареждаха логовете, разделени на записи. Появи се атрибутираният сервиз, който получаваше логовете от ClickHouse. След това, за всяка запис по visit id, получаваше транзакции, които можеха да бъдат още необработени, и плюс снимки, т.е. транзакции, вече свързани, а именно резултат от предишната работа. От тях се изграждаше логиката, избираше правилната транзакция, свързваха се новите събития. Отново записваше в лог. Логът се връщаше обратно в ClickHouse, т.е. това е постоянно циклична система. Освен това, се изпращаше в DWH, за да бъде анализирано там.

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

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

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

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

Тук е написан текст на SQL. Искам да коментирам няколко важни неща в него.

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

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

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

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

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

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

На първо място, това е AggregatingMergeTree. В AggregatingMergeTree се съхранява argMax, т.е. състоянието на транзакцията, съответстващо на последния timestamp. За даден посетител постоянно се генерират нови транзакции. В най-новото състояние на тази транзакция добавихме събитие и получихме ново състояние. То отново попадна в ClickHouse. И чрез argMax в това материализирано представление винаги можем да получим актуалното състояние.

• Свързването е "отделено" от Runtime.
• Съхраняват се и се обработват до 3 милиарда транзакции на месец. Това е порядък повече от това, което беше в Cassandra, т.е. в типична транзакционна система.
• Клъстер от 2x5 сървъра ClickHouse. 5 сървъра и всеки сървър има реплика. Това е дори по-малко, отколкото беше в Cassandra, за да се направи атрибуция на въз основа на клик, а тук имаме атрибуция на основа на импресии. Т.е. вместо да увеличим броя на сървърите 30 пъти, успяхме да го намалим.

И последният пример е финансова компания Y, която анализираше корелации в измененията на котировките на акции.

Задачата беше следната:

• Има около 5 000 акции.
• Котировките са известни на всеки 100 милисекунди.
• Данните са натрупани за 10 години. Явно, за някои компании повечко, за други по-малко.
• Общо около 100 милиарда реда.

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

Тук има две акции и техните котировки. Ако една върви нагоре и втората върви нагоре, то това е положителна корелация, т.е. едната расте, а другата също расте. Ако едната върви нагоре, както в края на графика, а втората надолу, то това е отрицателна корелация, т.е. когато едната расте, другата пада.

Анализирайки тези взаимни изменения, могат да се правят предсказания на финансовия пазар.

Но задачата е сложна. Какво правим за това? Има 100 милиарда записа, в които има: време, акция и цена. Първо трябва да изчислим 100 милиарда пъти runningDifference от алгоритъма на цената. RunningDifference е функция в ClickHouse, която последователно изчислява разликата между два реда.

След това трябва да се изчисли корелацията, и то за всяка двойка. За 5 000 акции това са 12,5 милиона двойки. И това е много, т.е. 12,5 пъти трябва да изчислим такава функция за корелация.

И ако някой е забравил, x и y са математическите очаквания по извадката. Тоест, трябва да се изчислят не само корените и сумите, а и вътре в тези суми да се направят нови суми. Нужно е да се извършат безброй изчисления 12,5 милиона пъти, и освен това трябва да се групират по часове. А часовете също не са малко. И всичко това трябва да се свърши за 60 секунди. Това е шега.

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

Опитваха се да изчисляват това на Hadoop, на Spark, на Greenplum. И всичко това беше много бавно или скъпо. Тоест, можеше да се направи някакво изчисление, но след това беше скъпо.

А после дойде ClickHouse и всичко стана много по-добре.

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

Какво направиха те? Първоначално данните са локализирани. На всеки от сървърите се съхраняват данни по ценообразуването на определен набор от акции. И те не се припокриват. Затова може да се изчислява logReturn паралелно и независимо, всичко това става докато е паралелно и разпределено.

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

След това това може да бъде репликирано. Буквата „r“ означава, че тези данни сме репликирали. Тоест, на трите ни сървъра се намират идентични данни – тези масиви.

И след това специален скрипт от този набор от 12,5 милиона корелации, които трябва да се изчислят, може да направи пакети. Тоест, 2 500 задачи по 5 000 двойки корелации. И задачата да се изчислява на конкретен ClickHouse-сървър. Всички данни са налични, защото данните са идентични и той може последователно да ги изчислява.

Още веднъж, как изглежда всичко това. Първо, имаме данните в такава структура: време, акции, цена. След това изчислихме logReturn, т.е. данни със същата структура, но вместо цена имаме logReturn. След това ги трансформирахме, т.е. получихме време и groupArray по акции и по цени. Среплицирахме. И след това генерирахме много задачи и ги предоставихме на ClickHouse, за да ги обработи. И това работи.

На proof of concept задачата беше подзадача, т.е. взехме по-малко данни. И всичко това на три сървъра.

Първите два етапа: изчисление на Log_return и обвиване в масиви отнеха около час.

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

Но най-важното е, че тази система практически няма тясно места, т.е. мащабира се почти линейно. И те провериха това. Успешно я мащабираха.

• Правилната схема е половината от успеха. И правилната схема е използването на всички необходими технологии на ClickHouse.
• Summing/AggregatingMergeTrees са технологии, които позволяват да се агрегира или изчисли snapshot state като специален случай. И това съществено опростява много неща.
• Materialized Views позволяват да се избегне ограничението на един индекс. Може би не го казах много ясно, но когато качвахме логовете, суровите логове бяха в таблица с един индекс, а на attribute логовете бяха в таблица, т.е. същите данни, но филтрирани, но индексът беше напълно различен. Изглеждат същите данни, но с различна подредба. И Materialized Views позволяват, ако това е необходимо, да се избегне такова ограничение на ClickHouse.
• Намалете грануларността на индекса за точкови заявки.
• И разпределяйте данните разумно, старайте се да максимализирате локализацията на данните в рамките на сървъра. И се старайте заявките също да използват локализация там, където е възможно максимално.

В заключение этого небольшого выступления можно сказать, что ClickHouse уверенно занял позиции как среди коммерческих баз данных, так и среди open source решений, особенно в области аналитики. Он отлично вписался в этот ландшафт. Более того, он постепенно начинает вытеснять других игроков, потому что, имея ClickHouse, вам не нужен InfiniDB. Вертика, возможно, скоро станет ненужной, если они реализуют полноценную поддержку SQL. Пользуйтесь!

—Благодарю за доклад! Очень интересно! Были ли сравнительные анализы с Apache Phoenix?

- Нет, я не слышал, чтобы кто-то проводил сравнения. Мы и Яндекс стараемся отслеживать все сравнения ClickHouse с различными базами данных. Если вдруг найдется что-то быстрее ClickHouse, Леша Миловидов не сможет спать по ночам и начнет активно работать над его ускорением. О таком сравнении я не слышал.

• (Алексей Миловидов) Apache Phoenix – это SQL-движок на базе Hbase. Hbase в основном предназначен для сценариев работы типа key-value. В каждой строке может быть произвольное количество столбцов с произвольными именами. Это справедливо для таких систем, как Hbase и Cassandra. На них тяжелые аналитические запросы нормально не работают. Или вы можете подумать, что они работают нормально, если у вас не было опыта работы с ClickHouse.

• Благодаря

  • Добрый день! Я уже довольно давно интересуюсь этой темой, так как у меня есть аналитическая подсистема. Но когда я смотрю на ClickHouse, у меня создается впечатление, что он отлично подходит для анализа иммутабельных событий. И если мне нужно анализировать большое количество бизнес-данных с множеством больших таблиц, то, насколько я понимаю, ClickHouse мне не очень подходит? Особенно если данные часто меняются. Это так, или есть примеры, опровергающие это мнение?

  • Това е вярно. И това е вярно за повечето специализирани аналитични бази данни. Те са адаптирани за работа с една или няколко големи таблици, които са изменяеми, и много малки, които се променят бавно. Т.е. ClickHouse не работи като Oracle, където можете да сложите всичко и да изградите много сложни заявки. За да използвате ClickHouse ефективно, трябва да изградите схемата по начин, който работи добре в ClickHouse. Т.е. да избягвате излишната нормализация, да използвате речници и да се стремите да правите по-малко дълги връзки. Ако схемата бъде изградена по този начин, то тогава подобни бизнес задачи в ClickHouse могат да бъдат решени много по-ефективно, отколкото в традиционна релационна база данни.

Благодаря за доклада! Имам въпрос относно последния финансов случай. Те имаха аналитика. Трябваше да сравнят как вървят нагоре-надолу. И разбирам, че сте изградили системата именно за тази аналитика? Ако утре, да речем, им потрябва друг отчет по тези данни, трябва ли отново да се изгражда схемата и да се заредят данните? Т.е. да направят някаква предварителна обработка, за да получат заявка?

Разбира се, че това е използването на ClickHouse за конкретна задача. Тя по-традиционно можеше да бъде решена в рамките на Hadoop. За Hadoop – това е идеална задача. Но на Hadoop това е много бавно. И моята цел е да демонстрирам, че в ClickHouse могат да се решават задачи, които обикновено се решават с напълно различни средства, но при това да бъдат много по-ефективни. Това е адаптирано за конкретна задача. Ясно е, че ако има задача, подобна на нещо, може да се решава по подобен начин.

Разбрах. Вие казахте, че са обработвани 50 часа. Това ли е от самото начало, когато сте заредили данните или когато сте получили резултатите?

Да-да.

Добре, благодаря много.

Това е на 3-серверен клъстер.

Здравейте! Благодаря за доклада! Всичко е много интересно. Ще попитам нещо не за функционалността, а за използването на ClickHouse от гледна точка на стабилността. Случвало ли ви се е нещо, наложило ли е възстановяване? Как ClickHouse се държи при това? Случвало ли се е да имате проблеми с репликата? Ние, например, сме имали проблем с ClickHouse, когато все пак излиза от лимита си и пада.

Разбира се, няма идеални системи. И ClickHouse има своите проблеми. Но чували ли сте, че Яндекс.Метрика дълго време не е работила? Вероятно не. Тя работи надеждно от 2012-2013 година на ClickHouse. Мога да говоря и за моят опит. Ние никога не сме имали пълни откази. Могат да се случат частични проблеми, но те никога не са били критични, за да повлияят сериозно на бизнеса. Такова никога не е ставало. ClickHouse е доста надежден и не спира случайно. Можете да не се притеснявате за това. Това не е недоизпипана технология. Това е доказано от много компании.

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

Разбира се, това зависи от вашата система. Има няколко начина да направите това практически без спиране. Например, можете да създадете Materialized View, в който да направите различна структура на данните, ако тя може да бъде однозначно мапирана. Тоест, ако допуска мапиране с помощта на ClickHouse, т.е. извличане на определени елементи, промяна на основния ключ, промяна на партиционирането, тогава можете да създадете Materialized View. Вашите стари данни ще бъдат записани там, а новите ще се добавят автоматично. След това просто ще превключите на използване на Materialized View, след което ще смените записите и старата таблица ще бъде изтрита. Това е начин без спиране.

Благодаря.

Източник: habr.com