Тэорыя і практыка выкарыстання ClickHouse у рэальных дадатках. Аляксандр Зайцаў (2018г)

Нягледзячы на ​​тое, што дадзеных зараз шмат амаль усюды, аналітычныя БД усё яшчэ даволі экзатычныя. Іх дрэнна ведаюць і яшчэ горш умеюць эфектыўна выкарыстоўваць. Многія працягваюць "ёсць кактус" з MySQL або PostgreSQL, якія спраектаваны пад іншыя сцэнары, пакутаваць з NoSQL або пераплачваць за камерцыйныя рашэнні. ClickHouse мяняе правілы гульні і значна зніжае парог уваходжання ў свет аналітычных DBMS.

Даклад з 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 сочыць, то напэўна чуў назву гэтай кампаніі. Гэта адзін з істотных кантрыбутараў з community. І ў іх вельмі сур'ёзная ClickHouse-інсталяцыя. Напрыклад, яны зрабілі Kafka Engine для ClickHouse.
• Тэлекамунікацыйныя кампаніі пачалі выкарыстоўваць. Некалькі кампаній ClickHouse выкарыстоўваюць альбо як proof on concept, альбо ўжо ў production.
• Адна кампанія выкарыстоўвае ClickHouse для маніторынгу вытворчых працэсаў. Яны тэстуюць мікрасхемы, спісваюць кучу параметраў, там каля 2 000 характарыстык. І далей аналізуюць - добрая партыя ці дрэнная.
• Блакчэйн-аналітыка. Ёсць такая расейская кампанія, як 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 мільярдаў падзей у дзень. Пры гэтым там падзеі могуць на некалькі падпадзей дзяліцца.
• Шмат кліентаў гэтых дадзеных, прычым гэта не толькі людзі, значна больш - гэта розныя алгарытмы, якія займаюцца programmatic bidding.

Кампанія прайшла доўгі і цярністы шлях. І я пра яго расказваў на HighLoad. Спачатку LifeStreet перайшла з MySQL (з невялікім прыпынкам на Oracle) у Vertica. І можна пра гэта знайсці апавяданне.

І ўсё было вельмі добра, але досыць хутка стала зразумела, што дадзеныя растуць і Vertica гэта дорага. Таму шукаліся розныя альтэрнатывы. Некаторыя з іх тут пералічаны. І насамрэч мы зрабілі proof of concept ці часам performance testing амаль усіх баз дадзеных, якія з 13-го па 16-ы год былі даступныя на рынку і прыкладна падыходзілі па функцыянальнасці. І пра частку з іх я таксама расказаў на HighLoad.

Стаяла задача міграваць з Vertica у першую чаргу, таму што дадзеныя раслі. І раслі яны экспанентна некалькі гадоў. Пасля яны выйшлі на паліцу, але тым не менш. І прагназуючы гэты рост, патрабаванні бізнесу на аб'ём дадзеных, па якіх трэба рабіць нейкую аналітыку, было зразумела, што хутка пойдзе размова аб петабайт. А за петабайты плаціць ужо вельмі дорага, таму шукалі альтэрнатыву, куды ісці.

Куды ісці? І доўгі час было зусім не зразумела, куды сыходзіць, таму што з аднаго боку ёсць камерцыйныя базы дадзеных, яны быццам бы нядрэнна працуюць. Некаторыя працуюць амаль гэтак жа добра, як Vertica, некаторыя горай. Але яны ўсё дарагія, нічога танней і лепш знайсці не ўдавалася.

З іншага боку, ёсць open source рашэнні, якіх не вельмі шмат, т. е. для аналітыкі іх можна пералічыць па пальцах. І яны бясплатныя ці танныя, але працуюць павольна. І ў іх часта бракуе патрэбнай і карыснай функцыянальнасці.

І таго, каб сумяшчала тое добрае, што ёсць у камерцыйных базах дадзеных і ўсё тое бясплатнае, што ёсць у open source, - нічога не было.

Нічога не было да таго часу, пакуль нечакана Яндэкс не выцягнуў, як труса штукар з шапкі, ClickHouse. І гэта было рашэнне нечаканае, да гэтага часу задаюць пытанне: "Навошта?", але тым не менш.

І адразу ўлетку 2016-го гады мы сталі глядзець, што такое ClickHouse. І аказалася, што ён часам можа быць хутчэй Vertica. Мы тэсціравалі розныя сцэнары на розных запытах. І калі запыт выкарыстаў толькі адну табліцу, т. е. без усялякіх джойнаў (join), то ClickHouse быў хутчэй Vertica ў два разы.

Я не заленаваўся і паглядзеў яшчэ тэсты Яндэкса на днях. Там тое ж самае: у два разы ClickHouse хутчэй Vertica, таму яны часта пра гэта гавораць.

Але калі ў запытах ёсць джойны (join), тое ўсё атрымліваецца не вельмі адназначна. І ClickHouse можа быць павольней Vertica у два разы. А калі крыху запыт падправіць і перапісаць, то прыкладна роўныя. Не дрэнна. І бясплатна.

І атрымаўшы вынікі тэстаў, і паглядзеўшы з розных бакоў на гэта, LifeStreet паехаў на ClickHouse.

Гэта 16-ты год, нагадваю. Гэта было як у анекдоце пра мышэй, якія плакалі і калоліся, але працягвалі есці кактус. І пра гэта было падрабязна расказана, ёсць пра гэта відэа і т. д.

Я таму не буду падрабязна пра гэта расказваць, раскажу толькі пра вынікі і пра некалькі цікавых рэчаў, пра якія я не расказваў тады.

Вынікі - гэта:

• Паспяховая міграцыя і больш за год сістэма ўжо працуе ў прадакшэне.
• Прадукцыйнасць і гнуткасць выраслі. З 10 мільярдаў запісаў, якія мы маглі дазволіць сабе захоўваць у дзень і тое нядоўга, зараз LifeStreet захоўвае 75 мільярдаў запісаў у дзень і можа гэта рабіць 3 месяцы і больш. Калі палічыць у піку, то гэта да мільёна падзей за секунду захоўваецца. Больш за мільён SQL-запытаў у дзень прылятаюць у гэтую сістэму, у асноўным ад розных робатаў.
• Нягледзячы на ​​тое, што для ClickHouse сталі выкарыстоўваць больш сервераў, чым для Vertica, эканомія і на жалезе атрымалася, таму што ў Вертыцы выкарыстоўваліся дастаткова дарагія SAS-дыскі. У ClickHouse выкарыстоўваліся SATA. А чаму? Таму што ў Vertica insert сінхронны. І сінхранізацыя патрабуе, каб кружэлкі не вельмі моцна тармазілі, а таксама, каб сетка не вельмі тармазіла, т. е. досыць дарагая аперацыя. А ў ClickHouse insert асінхронны. Больш за тое, можна ўсё лакальна заўсёды пісаць, ніякіх дадатковых выдаткаў на гэта няма, таму дадзеныя ў ClickHouse можна ўстаўляць значна хутчэй, чым у Вертыку нават на не самых хуткіх дысках. А на чытанне прыкладна аднолькава. Чытанне на SATA, калі яны ў RAID сядзяць, тое гэта ўсё досыць хутка.
• Не абмежаваныя ліцэнзіяй, т. е. 3 петабайта дадзеных у 60 сервераў (20 сервераў - гэта адна рэпліка) і 6 трыльёнаў запісаў у фактах і агрэгатах. Нічога падобнага на Vertica дазволіць сабе не маглі.

Цяпер я пераходжу да практычных рэчаў у дадзеным прыкладзе.

• Першае - гэта эфектыўная схема. Ад схемы залежыць вельмі шматлікае.
• Другое - гэта генерацыя эфектыўнага SQL.

Тыповы OLAP-запыт - гэта select. Частка калонак ідзе ў group by, частка калонак ідзе ў агрэгатныя функцыі. Ёсць where, якую можна ўявіць як зрэз куба. Увесь group by можна ўявіць як праекцыю. І таму гэта называецца шматмерным аналізам дадзеных.

І часта гэта мадэлюецца ў выглядзе star-схемы, калі ёсць цэнтральны факт і характарыстыкі гэтага факта па баках, па прамянях.

І з пункту гледжання фізічнага дызайну, таго, як гэта кладзецца на табліцу, то звычайна робяць нармалізаванае ўяўленне. Можаце дэнармалізаваць, але гэта дорага па дыску і не вельмі эфектыўна па запытах. Таму звычайна робяць нармалізаванае ўяўленне, т. е. табліца фактаў і шматліка-шмат табліц вымярэнняў.

Але ў ClickHouse гэта працуе дрэнна. Ёсць дзве прычыны:

• Першая - гэта таму што ў ClickHouse не вельмі добрыя джойны (join), т. е. джойны (join) ёсць, але яны дрэнныя. Пакуль кепскія.
• Другая - гэта тое, што табліцы не абнаўляюцца. Звычайна ў гэтых таблічках, якія вакол star-схемы, трэба нешта мяняць. Напрыклад, назва кліента, назва кампаніі і іншае. І гэта не працуе.

І выйсце з гэтага ў ClickHouse ёсць. нават цэлых два:

• Першы - гэта выкарыстанне слоўнікаў. External Dictionaries - гэта тое, што дапамагае на 99% вырашыць праблему са star-схемай, з апдэйтамі і іншым.
• Другі - гэта выкарыстанне масіваў. Масівы таксама дапамагаюць пазбавіцца ад джойны (join) і ад праблем з нармалізацыяй.

• Не патрэбен джойны (join).
• Абнаўляемыя. З сакавіка 2018-га года з'явілася недакументаваная магчымасць (у дакументацыі вы пра гэта не знойдзеце) абнаўляць слоўнікі часткова, г.зн. тыя запісы, якія памяняліся. Практычна - гэта як табліца.
• Заўсёды ў памяці, таму джойны (join) са слоўнікам працуюць хутчэй, чым, калі б гэта была табліца, якая ляжыць на дыску і яшчэ не факт, што яна ў кэшы, хутчэй за ўсё, што не.

• Таксама не патрэбен джойны (join).
• Гэта кампактнае ўяўленне 1 да многіх.
• І на мой погляд, масівы зроблены для гікаў. Гэта лямбда-функцыі і іншае.

Гэта не для чырвонага слоўца. Гэта вельмі магутная функцыянальнасць, якая дазваляе рабіць многія рэчы вельмі проста і элегантна.

Тыповыя прыклады, якія дапамагаюць рашаць масівы. Гэтыя прыклады простыя і дастаткова наглядныя:

• Пошук па тэгах. Калі ў вас там ёсць хаштэгі і вы хочаце знайсці нейкія запісы па хаштэгу.
• Пошук па key-value парам. Таксама ёсць нейкія атрыбуты са значэннем.
• Захоўванне спісаў ключоў, якія вам трэба перавесці ў нешта іншае.

Усе гэтыя задачы можна рашыць без масіваў. Тэгі можна ў нейкі радок пакласці і рэгулярным выразам выбіраць або ў асобную табліцу, але тады давядзецца рабіць джойны (join).

А ў ClickHouse нічога не трэба рабіць, дастаткова апісаць масіў string для хэштэгаў або зрабіць укладзеную структуру для сістэм тыпу key-value.

Укладзеная структура - гэта, можа быць, не самая ўдалая назва. Гэта два масіва, якія маюць агульную частку ў назве і некаторыя звязаныя характарыстыкі.

І па тэгу шукаць вельмі проста. Ёсць функцыя has, якая правярае, што ў масіве ёсць элемент. Усё, знайшлі ўсе запісы, якія адносяцца да нашай канферэнцыі.

Пошук па subid крыху больш складана. Трэба нам спачатку знайсці азначнік ключа, а потым ужо ўзяць элемент з гэтым азначнікам і праверыць, што гэтае значэнне такое, якое нам трэба. Але тым не менш вельмі проста і кампактна.

Рэгулярны выраз, які вы захацелі б напісаць, калі б вы ўсё гэта захоўвалі ў адным радку, ён быў бы, па-першае, каравым. А, па-другое, працавала значна даўжэй, чым два масівы.

Іншы прыклад. У вас ёсць масіў, у якім вы захоўваеце ID. І вы можаце перавесці іх у імёны. Функцыя arrayMap. Гэта тыповая лямбда-функцыя. Вы перадаеце туды лямбда-выразы. І яна кожнаму ID са слоўніка выцягвае значэнне імя.

Аналагічнай выявай можна зрабіць і пошук. Перадаецца функцыя прэдыкатаў, якая правярае чаму адпавядаюць элементы.

Вось гэтыя рэчы моцна спрашчаюць схему і вырашаюць кучу праблем.

Але наступная праблема, з якой мы сутыкнуліся і пра якую я хацеў бы згадаць, гэта эфектыўныя запыты.

• У ClickHouse няма планавальніка запытаў. Наогул няма.
• Але тым не менш складаныя запыты ўсё роўна планаваць трэба. У якіх выпадках?
• Калі ў запыце ёсць некалькі джойны (join), якія вы заварочваеце ў падселекты. І парадак, у якім яны выконваюцца, мае значэнне.
• І другое - калі запыт размеркаваны. Бо ў размеркаваным запыце толькі самы ўнутраны падселект выконваецца размеркавана, а ўсё астатняе перадаецца на адзін сервер, да якога вы падключыліся і выконваецца там. Таму калі ў вас размеркаваныя запыты са шматлікімі джойны (join), тое трэба выбіраць парадак.

І нават у прасцейшых выпадках таксама часам варта выконваць працу планавальніка і запыты ледзь-ледзь перапісваць.

Вось прыклад. У левай частцы запыт, які паказвае топ-5 краін. І ён выконваецца 2,5 секунды, па-мойму. А ў правай частцы той жа запыт, але крыху перапісаны. Мы замест таго, каб групаваць па радку, сталі групаваць па ключы (int). І гэта хутчэй. А потым мы да выніку падключылі слоўнік. Замест 2,5 секунды запыт выконваецца 1,5 секунды. Гэта добра.

Падобны прыклад з перапісваннем фільтраў. Тут запыт па Расіі. Ён выконваецца 5 секунд. Калі мы яго перапішам такім чынам, што будзем параўноўваць зноў не радок, а лічбы з нейкім сэтам тых ключоў, якія адносяцца да Расіі, то гэта будзе значна хутчэй.

Такіх трукаў шмат. І яны дазваляюць істотна паскорыць запыты, якія вам здаецца, што ўжо працуюць хутка, ці, наадварот, працуюць марудна. Іх можна зрабіць яшчэ хутчэй.

• Максімум працы ў размеркаваным рэжыме.
• Сартаванне па мінімальных тыпах, як я гэта рабіў па інтах.
• Калі ёсць нейкія джойны (join), слоўнікі, то іх лепш рабіць у самую апошнюю чаргу, калі ў вас ужо дадзеныя хаця б часткова згрупаваныя, тады аперацыя джойны (join) або выклік слоўніка будзе менш разоў выклікацца і гэта будзе хутчэй.
• Замена фільтраў.

Ёсць яшчэ іншыя тэхнікі, а не толькі тыя, якія я прадэманстраваў. І ўсе яны дазваляюць часам істотна паскорыць выкананне запытаў.

Пераходзім да наступнага прыкладу. Кампанія Х з ЗША. Што яна робіць?

Была задача:

• Афлайн-звязванне транзакцый рэкламы.
• Мадэляванне розных мадэлей звязвання.

У чым сцэнар?

Звычайны наведвальнік заходзіць на сайт, напрыклад, 20 разоў у месяц з розных аб'яваў ці проста так часам прыходзіць без усялякіх аб'яваў, таму што памятае гэты сайт. Глядзіць нейкія прадукты, кладзе іх у кошык, вымае іх з кошыка. І, у рэшце рэшт, нешта купляе.

Слушныя пытанні: «Каму трэба заплаціць за рэкламу, калі трэба?» і "Якая рэклама на яго паўплывала, калі паўплывала?". Г. зн. чаму ён купіў і як зрабіць так, каб людзі, падобныя да гэтага чалавека, таксама куплялі?

Для таго каб гэтую задачу вырашыць, трэба звязваць падзеі, якія адбываюцца на вэб-сайце правільнай выявай, т. е. неяк паміж імі выбудоўваць сувязь. Затым іх перадаваць для аналізу ў DWH. І на падставе гэтага аналізу будаваць мадэлі, каму і якую рэкламу паказваць.

Рэкламная транзакцыя - гэта набор звязаных падзей карыстальніка, якія пачынаюцца ад паказу аб'явы, далей нешта адбываецца, потым, можа быць, купля, а потым могуць быць пакупкі ў куплі. Напрыклад, калі гэта мабільнае прыкладанне або мабільная гульня, то звычайна ўстаноўка дадатку бясплатна адбываецца, а калі там нешта далей робіцца, то на гэта могуць спатрэбіцца грошыкі. І чым больш чалавек выдаткуе ў дадатку, тым ён больш каштоўны. Але для гэтага трэба ўсё звязаць.

Ёсць шмат мадэляў звязвання.

Самыя папулярныя - гэта:

• Last Interaction, дзе interaction - гэта або клік, або паказ.
• First Interaction, т. е. першае, што прывяло чалавека на сайт.
• Лінейная камбінацыя - усім пароўну.
• Згасанне.
• І іншае.

І як гэта ўсё працавала першапачаткова? Быў Runtime і Cassandra. Cassandra выкарыстоўвалася як transaction storage, т. е. у ёй захоўваліся ўсе злучаныя транзакцыі. І калі прыходзіць нейкая падзея ў Runtime, напрыклад, паказ нейкай старонкі ці нешта яшчэ, то рабіўся запыт у Cassandra - ёсць такі чалавек ці не. Потым даставаліся транзакцыі, якія да яго адносяцца. І рабілася звязванне.

І калі павезла, што ў запыце ёсць transaction id, тое гэта лёгка. Але звычайна не шанцуе. Таму трэба было знайсці апошнюю транзакцыю ці транзакцыю з апошнім клікам і т. д.

І гэта ўсё вельмі добра працавала, пакуль звязванне было да апошняга кліку. Таму што клікаў, скажам, 10 мільёнаў за дзень, 300 мільёнаў за месяц, калі на месяц ставіць акно. І паколькі ў Cassandra гэта павінна быць усё ў памяці для таго, каб працавала хутка, таму што патрабуецца Runtime адказаць хутка, тое патрабавалася прыкладна 10-15 сервераў.

А калі захацелі да паказу прывязваць транзакцыю, дык адразу атрымалася не так весела. А чаму? Відаць, што ў 30 разоў больш падзеяў трэба захоўваць. І, адпаведна, трэба ў 30 разоў больш сервераў. І атрымліваецца, што гэта нейкая астранамічная лічба. Трымаць да 500 сервераў для таго, каб рабіць звязванне, пры тым, што ў Runtime сервераў істотна менш, то гэта нейкая няправільная лічба. І пачалі думаць, што рабіць.

І выйшлі на ClickHouse. А як гэта рабіць на ClickHouse? На першы погляд здаецца, што гэта набор антыпатэрнаў.

• Транзакцыя расце, мы да яе падчапляем усё новыя і новыя івэнты, т. е. яна mutable, а ClickHouse не вельмі добрае працуе з mutable-аб'ектамі.
• Калі да нас прыходзіць наведвальнік, то нам трэба выцягнуць ягоныя транзакцыі па ключы, па ягоных visit id. Гэта таксама point query, у ClickHouse так не робяць. Звычайна ў ClickHouse вялікія …сканы, а тут нам трэба дастаць некалькі запісаў. Таксама антыпатэрн.
• Акрамя таго, транзакцыя была ў json, але перапісваць не жадалі, таму жадалі захоўваць json не структуравана, а калі трэба, то з яго нешта выцягваць. І гэта таксама антыпатэрн.

Т. е. набор антыпатэрнаў.

Але тым не менш атрымалася зрабіць сістэму, якая вельмі добрая працавала.

Што было зроблена? З'явіўся ClickHouse, у які закідваліся логі, пабітыя на запісы. З'явіўся attributed сервіс, які атрымліваў з ClickHouse логі. Пасля гэтага для кожнага запісу па visit id атрымліваў транзакцыі, якія маглі быць яшчэ не даапрацаваныя і плюс снапшоты, т. е. транзакцыі ўжо злучаныя, а менавіта вынік папярэдняй працы. З іх ужо рабіў логіку, выбіраў правільную транзакцыю, далучаў новыя падзеі. Зноў запісваў у лог. Лог сыходзіў назад у ClickHouse, т. е. гэта ўвесь час цыклічная сістэма. І акрамя таго, сыходзіў у DWH, каб тамака гэта аналізаваць.

Менавіта ў такім выглядзе гэта працавала не надта добра. І каб ClickHouse было прасцей, калі ішоў запыт па visit id, то групавалі гэтыя запыты ў блокі па 1 000-2 000 visit id і выцягвалі для 1 000-2 000 чалавек усе транзакцыі. І тады ўсё гэта зарабіла.

Калі паглядзець унутр ClickHouse, то тамака ўсяго 3 асноўных табліц, якія ўсё гэта абслугоўваюць.

Першая табліца, у якую заліваюцца логі, прычым логі заліваюцца практычна без апрацоўкі.

Другая табліца. Праз materialized view з гэтых логаў выкусваліся, якія яшчэ не attributed івэнты, т. е. незвязаныя. І праз materialized view з гэтых логаў выцягваліся транзакцыі для пабудовы снапшота. Г. зн. спецыяльным materialized view будаваў снапшот, а менавіта апошні назапашаны стан транзакцыі.

Вось тут напісаны тэкст на SQL. Я хацеў бы пракаментаваць у ім некалькі важных рэчаў.

Першая важная рэч - гэта магчымасць у ClickHouse з json выцягваць калонкі, палі. Т. е. у ClickHouse ёсць некаторыя метады для працы з json. Яны вельмі-вельмі прымітыўныя.

visitParamExtractInt дазваляе з json выцягваць атрыбуты, т. е. першае трапленне спрацоўвае. І такім чынам можна выцягнуць transaction id ці visit id. Гэта раз.

Другое - тут выкарыстана хітрае materialized поле. Што гэта значыць? Гэта значыць, што вы яго ў табліцу ўставіць не можаце, т. е. яно не ўстаўляецца, яно вылічаецца і захоўваецца пры ўстаўцы. Пры ўстаўцы ClickHouse робіць за вас працу. І ўжо выцягваецца з json тое, што вам потым спатрэбіцца.

У дадзеным выпадку materialized view - гэта для неапрацаваных радкоў. І якраз выкарыстоўваецца першая табліца з практычна волкімі логамі. І што робіць? Па-першае, змяняе сартаванне, т. е. сартаванне зараз ідзе па visit id, таму што нам трэба хутка выцягваць менавіта па пэўным чалавеку яго транзакцыю.

Другая важная рэч - гэта index_granularity. Калі вы бачылі MergeTree, то звычайна па дэфолце 8 варта index_granularity. Што гэта такое? Гэта параметр разрэджанасці азначніка. У ClickHouse індэкс разрэджаны, ён ніколі не індэксуе кожны запіс. Ён гэта робіць праз кожныя 192. І гэта добра, калі патрабуецца шмат дадзеных падлічыць, але дрэнна, калі крышку, таму што вялікі overhead. І калі памяншаць index granularity, то мы памяншаем overhead. Паменшыць да адзінкі нельга, бо можа памяці не хапіць. Індэкс заўсёды ў памяці захоўваецца.

А снапшот выкарыстоўвае яшчэ некаторыя цікавыя функцыі ClickHouse.

Па-першае, гэта AggregatingMergeTree. І ў AggregatingMergeTree захоўваецца argMax, т. е. гэты стан транзакцыі, які адпавядае апошняму timestamp. Транзакцыі ўвесь час новыя генеруюцца для гэтага наведвальніка. І ў самы апошні стан гэтай транзакцыі мы дадалі івэнт і ў нас зьявіўся новы стан. Яно зноў патрапіла ў ClickHouse. І праз argMax у гэтым матэрыялізаваным уяўленні мы заўсёды можам атрымаць актуальны стан.

• Звязванне адвязана ад Runtime.
• Захоўваецца і апрацоўваецца да 3 мільярдаў транзакцый за месяц. Гэта на парадак больш, чым было ў Cassandra, т. е. у тыповай транзакцыйнай сістэме.
• Кластар 2х5 сервераў ClickHouse. 5 сервераў і кожны сервер мае рэпліку. Гэта нават менш, чым было ў Cassandra для таго, каб зрабіць click based атрыбуцыю, а тут у нас impression based. Т. е. замест таго, каб павялічваць колькасць сервераў у 30 раз, іх атрымалася паменшыць.

І апошні прыклад - гэта фінансавая кампанія Y, якая аналізавала карэляцыі змяненняў каціровак акцый.

І задача стаяла такая:

• Ёсць прыкладна 5 акцый.
• Каціроўкі кожныя 100 мілісекунды вядомыя.
• Звесткі назапасіліся за 10 гадоў. Мабыць, для некаторых кампаній пабольш, для некаторых паменш.
• Усяго прыкладна 100 мільярдаў радкоў.

І трэба было палічыць карэляцыю змен.

Тут ёсць дзве акцыі і іх каціроўкі. Калі адна ідзе ўверх, і другая ідзе ўверх, тое гэта дадатная карэляцыя, т. е. адна расце, і другая расце. Калі адна ідзе ўверх, як у канцы графіка, а другая ўніз, тое гэта адмоўная карэляцыя, т. е. калі адна расце, іншая падае.

Аналізуючы гэтыя ўзаемныя змены можна рабіць прадказанні на фінансавым рынку.

Але задача складаная. Што дзеля гэтага робіцца? У нас ёсць 100 мільярдаў запісаў, у якіх ёсць: час, акцыя і кошт. Нам трэба палічыць спачатку 100 мільярдаў разоў runningDifference ад алгарытму цаны. RunningDifference - гэта функцыя ў ClickHouse, якая розніцу паміж двума радкамі паслядоўна вылічае.

А пасля гэтага трэба палічыць карэляцыю, прычым карэляцыю трэба палічыць для кожнай пары. Для 5 акцый пар 000 мільёнаў. І гэта шмат, т. е. 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 - гэта тэхналогіі, якія дазваляюць агрэгаваць або лічыць снапшот 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 вельмі добрае падыходзіць для аналізу івэнтаў, mutable. І калі мне трэба аналізаваць шмат бізнэс-дадзеных з кучай вялікіх табліц, то ClickHouse, наколькі я разумею, мне не вельмі падыходзіць? Асабліва, калі яны мяняюцца. Ці правільна гэта ці ёсць прыклады, якія могуць абвергнуць гэта?

  • Гэта правільна. І гэта праўда пра большасць спецыялізаваных аналітычных баз даных. Яны заменчаны пад тое, што ёсць адна ці некалькі вялікіх табліц, якія mutable, і пад шмат маленькіх, якія павольна мяняюцца. Г. зн. ClickHouse не як Oracle, куды можна пакласці ўсё і будаваць нейкія вельмі складаныя запыты. Для таго каб ClickHouse эфектыўна выкарыстоўваць, трэба схему выбудоўваць тым чынам, які ў ClickHouse добра працуе. Т. е. пазбягаць залішняй нармалізацыі, выкарыстоўваць слоўнікі, імкнуцца рабіць менш доўгіх сувязяў. І калі схему такім чынам пабудаваць, то тады аналагічныя бізнес-задачы на ​​ClickHouse могуць быць вырашаны значна больш эфектыўна, чым традыцыйнай рэляцыйнай базе даных.

Дзякуй за даклад! У мяне пытанне па апошнім фінансавым кейсе. У іх была аналітыка. Трэба было параўнаць, як ідуць уверх-уніз. І я так разумею, што вы сыстэму пабудавалі менавіта пад гэтую аналітыку? Калі ім заўтра, дапусцім, спатрэбіцца, нейкая іншая справаздача па гэтых дадзеных, трэба зноўку схему будаваць і загружаць дадзеныя? Т. е. рабіць нейкую перадапрацоўку, каб атрымаць запыт?

Вядома, гэта выкарыстанне ClickHouse для цалкам канкрэтнай задачы. Яна больш традыцыйна магла б быць вырашана ў рамках Hadoop. Для Hadoop - гэта ідэальная задача. Але на Hadoop гэта вельмі марудна. І мая мэта - гэта прадэманстраваць тое, што на ClickHouse можна вырашаць задачы, якія звычайна вырашаюцца зусім іншымі сродкамі, але пры гэтым зрабіць значна больш эфектыўна. Гэта пад пэўную задачу заменчана. Зразумела, што калі ёсць задача нечым падобная, то можна яе падобнай выявай вырашаць.

Зразумела. Вы сказалі, што 50 гадзінаў апрацоўвалася. Гэта пачынаючы з самага пачатку, калі загрузілі дадзеныя ці атрымалі вынікі?

Так.

Добра, дзякуй вялікі.

Гэта на 3-х серверным кластары.

Вітаю! Дзякуй за даклад! Усё вельмі цікава. Я крыху не пра функцыянал спытаю, а пра выкарыстанне ClickHouse з пункту гледжання стабільнасці. Т. е. ці здараліся ў вас нейкія, ці даводзілася аднаўляць? Як пры гэтым сябе паводзіць ClickHouse? І ці здаралася так, што ў вас вылятала і рэпліка ў тым ліку? Мы, дапусцім, у ClickHouse сутыкаліся з праблемай, калі ён вылазіць усёткі за свой ліміт і падае.

Вядома, ідэальных сістэм няма. І ў ClickHouse таксама ёсць свае праблемы. Але вы чулі пра тое, каб Яндекс.Метрика доўга не працавала? Мусіць, не. Яна працуе надзейна недзе з 2012-2013-га года на ClickHouse. Пра мой досвед я таксама магу сказаць. У нас ніколі не было поўных адмоў. Нейкія частковыя рэчы маглі здарацца, але яны ніколі не былі крытычнымі настолькі, каб сур'ёзна паўплываць на бізнэс. Ніколі такога не было. ClickHouse - дастаткова надзейны і не падае выпадковым чынам. Можна пра гэта не турбавацца. Гэта не волкая рэч. Гэта даказана многімі кампаніямі.

Добры дзень! Вы сказалі, што трэба адразу добра прадумаць схему даных. А калі гэта адбылося? У мяне дадзеныя льюцца-льюцца. Праходзіць паўгода, і я разумею, што так жыць нельга, мне трэба перазаліваць дадзеныя і нешта з імі рабіць.

Гэта залежыць, канешне, ад вашай сістэмы. Ёсць некалькі спосабаў зрабіць гэта практычна без прыпынку. Напрыклад, вы можаце стварыць Materialized View, у якім зрабіць іншую структуру дадзеных, калі яе можна адназначна змапіраваць. Т. е. калі яна дапушчае мапіраванне сродкамі ClickHouse, т. е. extract нейкіх рэчаў, памяняць primary key, памяняць партыцыянаванне, то можна зрабіць Materialized View. Туды вашыя старыя дадзеныя перапісаць, новыя будуць пісацца аўтаматычна. А потым проста пераключыцца на выкарыстанне Materialized View, потым пераключыць запіс і старую табліцу забіць. Гэта ўвогуле без прыпынку спосаб.

Дзякуй.

Крыніца: habr.com