Теорија и пракса коришћења ЦлицкХоусе-а у реалним апликацијама. Александар Зајцев (2018)

Упркос чињеници да сада постоји много података скоро свуда, аналитичке базе података су и даље прилично егзотичне. Они су слабо познати и још мање способни да их ефикасно користе. Многи настављају да „једу кактусе“ са МиСКЛ или ПостгреСКЛ, који су дизајнирани за друге сценарије, боре се са НоСКЛ-ом или преплаћују за комерцијална решења. ЦлицкХоусе мења игру и значајно снижава баријеру за улазак у свет аналитичких ДБМС-а.

Извештај је са БацкЕнд Цонф 2018 и објављен је уз дозволу говорника.

Ко сам ја и зашто говорим о ЦлицкХоусе-у? Ја сам директор развоја компаније ЛифеСтреет, која користи ЦлицкХоусе. Такође сам оснивач Алтинити-а. Ово је Иандек партнер који промовише ЦлицкХоусе и помаже Иандек-у да учини ЦлицкХоусе успешнијим. Такође сам спреман да поделим знање о ЦлицкХоусе-у.

А ја такође нисам брат Петје Зајцева. Често ме питају о овоме. Не, нисмо браћа.

„Сви знају“ да ЦлицкХоусе:

• Веома брзо,
• Врло повољно,
• Користи се у Иандек-у.

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

Рећи ћу вам зашто, где и како се ЦлицкХоусе користи, поред Иандек-а.

Рећи ћу вам како се конкретни проблеми решавају коришћењем ЦлицкХоусе-а у различитим компанијама, које ЦлицкХоусе алате можете да користите за своје задатке и како су коришћени у различитим компанијама.

Одабрао сам три примера који приказују ЦлицкХоусе са различитих страна. Мислим да ће бити занимљиво.

Прво питање је: „Зашто нам је потребан ЦлицкХоусе?“ Чини се да је питање сасвим очигледно, али постоји више од једног одговора на њега.

• Први одговор је из разлога перформанси. ЦлицкХоусе је веома брз. Аналитика на ЦлицкХоусе-у је такође веома брза. Често се може користити тамо где нешто друго ради веома споро или веома лоше.
• Други одговор је трошак. И пре свега, трошкови скалирања. На пример, Вертица је апсолутно одлична база података. Ради веома добро ако немате много терабајта података. Али када говоримо о стотинама терабајта или петабајта, цена лиценце и подршке износи прилично значајан износ. И скупо је. А ЦлицкХоусе је бесплатан.
• Трећи одговор је оперативни трошак. Ово је мало другачији приступ. РедСхифт је одличан аналог. Са РедСхифт-ом можете врло брзо да донесете одлуку. Радиће добро, али у исто време, сваки сат, сваки дан и сваки месец ћете платити доста Амазону, јер је то значајно скупа услуга. Гоогле БигКуери такође. Ако га је неко користио, онда зна да тамо можете покренути неколико упита и одједном добити рачун на стотине долара.

ЦлицкХоусе нема ових проблема.

Где се сада користи ЦлицкХоусе? Поред Иандек-а, ЦлицкХоусе се користи у гомили различитих предузећа и компанија.

• Пре свега, ово је аналитика веб апликација, односно ово је случај коришћења који је дошао из Иандек-а.
• Многе АдТецх компаније користе ЦлицкХоусе.
• Бројне компаније које треба да анализирају оперативне дневнике из различитих извора.
• Неколико компанија користи ЦлицкХоусе за праћење сигурносних дневника. Они их отпремају на ЦлицкХоусе, праве извештаје и добијају резултате који су им потребни.
• Компаније почињу да га користе у финансијској анализи, односно постепено се приближавају ЦлицкХоусе-у и велика предузећа.
• ЦлоудФларе. Ако неко прати ЦлицкХоусе, вероватно сте чули име ове компаније. Ово је један од значајних сарадника из заједнице. И имају веома озбиљну ЦлицкХоусе инсталацију. На пример, направили су Кафка Енгине за ЦлицкХоусе.
• Телекомуникационе компаније су почеле да користе. Неколико компанија користи ЦлицкХоусе или као доказ концепта или већ у производњи.
• Једна компанија користи ЦлицкХоусе за праћење производних процеса. Они тестирају микро кола, отписују гомилу параметара, има око 2 карактеристика. А онда анализирају да ли је серија добра или лоша.
• Блоцкцхаин аналитицс. Постоји руска компанија која се зове Блоки.инфо. Ово је анализа Етхереум мреже. То су такође урадили на ЦлицкХоусе-у.

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

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

• Иандек: 500+ сервера, тамо чувају 25 милијарди записа дневно.
• ЛифеСтреет: 60 сервера, приближно 75 милијарди записа дневно. Има мање сервера и више записа него у Иандек-у.
• ЦлоудФларе: 36 сервера, они чувају 200 милијарди записа дневно. Имају још мање сервера и чувају још више података.
• Блоомберг: 102 сервера, приближно трилион записа дневно. Држач рекорда.

Географски, ово је такође много. Ова мапа приказује топлотну мапу где се ЦлицкХоусе користи у свету. Овде се јасно истичу Русија, Кина и Америка. Мало је европских земаља. И могу се разликовати 4 кластера.

Ово је компаративна анализа, нема потребе тражити апсолутне бројеве. Ово је анализа посетилаца који читају материјале на енглеском језику на сајту Алтинити, јер тамо нема говорника руског. А Русија, Украјина, Белорусија, односно руски говорни део заједнице, су најбројнији корисници. Затим долазе САД и Канада. Кина веома сустиже. Пре шест месеци тамо Кине готово да није било, сада је Кина већ претекла Европу и наставља да расте. Стара Европа такође не заостаје, а лидер у употреби ЦлицкХоусе-а је, зачудо, Француска.

Зашто све ово причам? Да покажемо да ЦлицкХоусе постаје стандардно решење за анализу великих података и да се већ користи на многим местима. Ако га користите, на правом сте тренду. Ако га још не користите, онда не морате да се плашите да ћете остати сами и нико вам неће помоћи, јер многи то већ раде.

Ово су примери стварне употребе ЦлицкХоусе-а у неколико компанија.

• Први пример је рекламна мрежа: миграција са Вертица на ЦлицкХоусе. И знам неколико компанија које су прешле са Вертице или су у процесу преласка.
• Други пример је трансакцијско складиштење на ЦлицкХоусе-у. Ово је пример изграђен на антиузорцима. Све што не треба да се ради у ЦлицкХоусе-у по савету програмера ради се овде. И у исто време то се ради тако ефикасно да функционише. И функционише много боље од типичног трансакционог решења.
• Трећи пример је дистрибуирано рачунарство на ЦлицкХоусе-у. Поставило се питање како се ЦлицкХоусе може интегрисати у Хадооп екосистем. Показаћу пример како је компанија урадила нешто слично контејнеру за смањење мапе на ЦлицкХоусе-у, праћење локализације података итд., како би израчунала врло нетривијалан задатак.

• ЛифеСтреет је Ад Тецх компанија која има све технологије повезане са рекламном мрежом.
• Бави се оптимизацијом огласа и програмским лицитирањем.
• Много података: око 10 милијарди догађаја дневно. Штавише, догађаји се могу поделити на неколико под-догађаја.
• Много је клијената ових података, а то нису само људи, много више су разни алгоритми који се баве програмским лицитирањем.

Компанија је прешла дуг и трновит пут. И причао сам о томе на ХигхЛоад-у. Прво, ЛифеСтреет је прешао са МиСКЛ-а (са кратким заустављањем у Орацле-у) на Вертица. И можете пронаћи причу о томе.

И све је било јако добро, али је брзо постало јасно да подаци расту и да је Вертица скупа. Стога су тражене различите алтернативе. Неки од њих су овде наведени. И у ствари, урадили смо проверу концепта или понекад тестирање перформанси скоро свих база података које су биле доступне на тржишту од 13. до 16. и биле су приближно одговарајуће по функционалности. И такође сам причао о некима од њих на ХигхЛоад-у.

Задатак је био да се прво мигрира из Вертице, јер су подаци расли. И расли су експоненцијално неколико година. Онда су отишли ​​на полицу, али ипак. А предвиђајући овај раст, пословне захтеве за обимом података о којој треба да се уради некаква аналитика, било је јасно да ће ускоро бити речи о петабајтима. И већ је веома скупо платити петабајте, па смо тражили алтернативу где да идемо.

Где да одем? И дуго је било потпуно нејасно куда ићи, јер с једне стране постоје комерцијалне базе података, које изгледа добро функционишу. Неки раде скоро једнако добро као Вертица, неки лошије. Али сви су скупи, ништа јефтиније или боље се није могло наћи.

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

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

Ништа се није догодило док Иандек изненада није извукао ЦлицкХоусе из шешира као мађионичарског зеца. И ово је била неочекивана одлука; људи се и даље питају: „Зашто?“, али ипак.

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

Нисам био превише лењ и погледао сам више Иандек тестова пре неки дан. И тамо је исто: ЦлицкХоусе је двоструко бржи од Вертица-е, па често причају о томе.

Али ако упити садрже спојеве, испада да све није баш јасно. А ЦлицкХоусе може бити дупло спорији од Вертица. А ако мало исправите и препишете захтев, онда ће они бити приближно једнаки. Није лоше. И то је бесплатно.

И након што је примио резултате теста и погледао их из различитих углова, ЛифеСтреет је отишао у ЦлицкХоусе.

Ово је 16. година, подсећам. Било је то као у шали о мишевима који су плакали и убризгавали се, али су наставили да једу кактус. И о томе се детаљно разговарало, постоји видео о томе итд.

Стога, нећу о овоме детаљно, говорићу само о резултатима и неколико занимљивости о којима тада нисам говорио.

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

• Успешна миграција и систем је у производњи више од годину дана.
• Повећане су продуктивност и флексибилност. Од 10 милијарди записа које смо могли да приуштимо да чувамо дневно само у кратком временском периоду, ЛифеСтреет сада складишти 75 милијарди записа дневно и то може да ради 3 месеца или више. Ако рачунате на врхунцу, онда се ово чува до милион догађаја у секунди. Више од милион СКЛ упита дневно се шаље овом систему, углавном од разних робота.
• Упркос чињеници да је ЦлицкХоусе почео да користи више сервера него Вертица, уштедело се и на хардверу, јер је Вертица користила прилично скупе САС дискове. ЦлицкХоусе користи САТА. И зашто? Зато што је у Вертици инсерт синхрони. А синхронизација захтева да дискови не успоравају много, а такође и да мрежа не успорава превише, односно, прилично скупа операција. А у ЦлицкХоусе уметање је асинхроне. Штавише, увек можете све писати локално, нема додатних трошкова за то, па се подаци могу убацити у ЦлицкХоусе много брже него у Вертику, чак и на не најбржим дисковима. И читање је отприлике исто. Читајући на САТА, ако су у РАИД-у, онда је све довољно брзо.
• Неограничено лиценцом, тј. 3 петабајта података на 60 сервера (20 сервера је једна реплика) и 6 трилиона записа у чињеницама и агрегатима. Овако нешто Вертица није могла себи да приушти.

Сада прелазим на практичне ствари у овом примеру.

• Прва је ефикасна шема. Много зависи од шеме.
• Други је генерисање ефикасног СКЛ-а.

Типичан ОЛАП упит је селецт. Неке колоне иду у групе према, неке колоне иду у агрегатне функције. Има где, што се може замислити као парче коцке. Цела група се може посматрати као пројекција. И зато се то зове мултиваријантна анализа података.

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

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

Али ово не функционише добро у ЦлицкХоусе-у. Постоје два разлога:

• Први је зато што ЦлицкХоусе нема баш добре спојеве, односно има спојева, али су лоши. За сада су лоши.
• Други је да се табеле не ажурирају. Обично у овим знацима који се налазе око дијаграма звезда нешто треба променити. На пример, име клијента, назив компаније итд. И не ради.

И постоји излаз из овога у ЦлицкХоусе-у. чак два:

• Први је употреба речника. Спољни речници су оно што помаже у 99% решавања проблема са шемом звезда, са ажурирањима и тако даље.
• Други је употреба низова. Низови такође помажу да се решите спајања и проблема са нормализацијом.

• Нема потребе за спојевима.
• Може се ажурирати. Од марта 2018. године појавила се недокументована могућност (ово нећете наћи у документацији) да се делимично ажурирају речници, односно они уноси који су промењени. У пракси, то је као сто.
• Увек у меморији, тако да спојеви са речником раде брже него да је табела која лежи на диску и није чињеница да је у кешу, највероватније не.

• Не требају вам ни спојеви.
• Ово је компактна репрезентација 1 према много.
• А по мом мишљењу, низови су направљени за штреберке. Ово су ламбда функције и ствари.

Ово није ради речи. Ово је веома моћна функционалност која вам омогућава да многе ствари радите веома једноставно и елегантно.

Типични примери који помажу у решавању низова. Ови примери су једноставни и прилично јасни:

• Претрага по ознакама. Ако тамо имате хасхтагове и желите да пронађете неке постове по хештегу.
• Претражујте по паровима кључ/вредност. Постоје и неки атрибути са значењем.
• Чување спискова кључева које треба да преведете у нешто друго.

Сви ови проблеми се могу решити без низова. Ознаке се могу поставити у неки ред и изабрати помоћу регуларног израза, или у посебну табелу, али тада ћете морати да направите спојеве.

Али у ЦлицкХоусе-у не морате ништа да радите, само опишите низ стрингова за хасхтагове или направите угнежђену структуру за системе кључ/вредност.

Угнежђена структура можда није најбоље име. То су два низа која имају заједнички део у називу и неке повезане карактеристике.

И веома је лако претраживати по ознаци. Постоји функција has, који проверава да ли низ садржи елемент. Сви, пронашли смо све уносе који се односе на нашу конференцију.

Претраживање по субид-у је мало компликованије. Прво треба да пронађемо индекс кључа, а затим узмемо елемент са овим индексом и проверимо да ли је ова вредност оно што нам треба. Али ипак врло једноставан и компактан.

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

Други пример. Имате низ у који чувате ИД-ове. И можете их превести у имена. Функција arrayMap. Ово је типична ламбда функција. Ту прослеђујете ламбда изразе. И она извлачи вредност имена за сваки ИД из речника.

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

Ове ствари у великој мери поједностављују коло и решавају гомилу проблема.

Али следећи проблем на који смо наишли и који бих желео да поменем су ефикасни упити.

• ЦлицкХоусе нема планер упита. Апсолутно не.
• Али ипак, сложене упите и даље треба планирати. У којим случајевима?
• Ако захтев има неколико спојева, које умотавате у подселекте. Битан је и редослед којим се изводе.
• И друго, ако се захтев дистрибуира. Јер у дистрибуираном упиту, само најдубљи подселект се извршава на дистрибуиран начин, а све остало се шаље на један сервер на који сте се повезали и тамо извршили. Стога, ако имате дистрибуиране упите са много спојева, онда морате да изаберете редослед.

А чак иу једноставнијим случајевима, понекад је потребно да урадите и посао планера и мало препишете упите.

Ево примера. На левој страни је упит који приказује првих 5 земаља. И ради за 2,5 секунде, мислим. А на десној страни је исти захтев, али мало преписан. Уместо груписања по низу, почели смо да групишемо по кључу (инт). И то је брже. А онда смо на резултат повезали речник. Уместо 2,5 секунде, захтев траје 1,5 секунде. Ово је добро.

Сличан пример са преписивањем филтера. Ево захтева за Русију. Ради 5 секунди. Ако га препишемо тако да поново упоредимо не низ, већ бројеве са неким скупом оних кључева који се односе на Русију, онда ће то бити много брже.

Постоји много таквих трикова. И омогућавају вам да значајно убрзате упите за које мислите да већ раде брзо или, обрнуто, споро. Могу се направити још брже.

• Максималан рад у дистрибуираном режиму.
• Сортирање по минималним типовима, као што сам ја радио по интс.
• Ако постоје спојеви или речници, онда је боље да их урадите последњи, када већ имате податке бар делимично груписани, тада ће се операција придруживања или позивање речника позивати мање пута и биће брже.
• Замена филтера.

Постоје и друге технике, не само оне које сам демонстрирао. И сви они вам понекад омогућавају да значајно убрзате извршавање упита.

Пређимо на следећи пример. Компанија Кс из САД. Шта она ради?

Постојао је задатак:

• Ванмрежно повезивање рекламних трансакција.
• Симулација различитих модела везивања.

Какав је сценарио?

Обичан посетилац посети сајт, на пример, 20 пута месечно из различитих реклама, или понекад једноставно дође без реклама, јер се сећа овог сајта. Гледа неке производе, ставља их у корпу, вади из корпе. И, на крају, нешто купи.

Разумна питања: „Ко треба да плати оглашавање, ако је потребно?“ и „Које је оглашавање, ако је било, утицало на њега?“ Односно, зашто је купио и како се побринути да људи слични овој особи такође купују?

Да бисте решили овај проблем, потребно је да на исправан начин повежете догађаје који се дешавају на сајту, односно да некако изградите везу између њих. Затим се преносе на анализу у ДВХ. И на основу ове анализе изградите моделе коме да покажете шта рекламира.

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

Постоји много модела везивања.

Најпопуларнији су:

• Последња интеракција, где је интеракција или клик или приказ.
• Прва интеракција, односно прва ствар која је довела особу на сајт.
• Линеарна комбинација - једнак удео за све.
• Слабљење.
• И тако даље.

И како је све то у почетку функционисало? Постојали су Рунтиме и Цассандра. Цассандра је коришћена као складиште трансакција, односно све повезане трансакције су биле ускладиштене у њему. А када се у Рунтиме-у деси неки догађај, на пример, приказ странице или нешто друго, Касандри се поставља захтев да ли постоји таква особа или не. Тада су примљене трансакције које се односе на то. И везивање је обављено.

А ако имате среће да захтев садржи ИД трансакције, онда је то лако. Али обично немате среће. Стога је било потребно пронаћи последњу трансакцију или трансакцију са последњим кликом итд.

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

А када су хтели да повежу трансакцију са екраном, одмах се испоставило да није тако забавно. И зашто? Види се да је потребно ускладиштити 30 пута више догађаја. И, сходно томе, потребно вам је 30 пута више сервера. И испоставило се да је ово нека врста астрономске фигуре. Чување до 500 сервера да би се извршило повезивање, упркос чињеници да има знатно мање сервера у Рунтиме-у, нека је погрешна цифра. И почели су да размишљају шта да раде.

И отишли ​​смо у ЦлицкХоусе. Како то учинити на ЦлицкХоусе-у? На први поглед се чини да се ради о скупу антишаблона.

• Трансакција расте, додајемо јој све више догађаја, односно променљива је, а ЦлицкХоусе не ради баш добро са променљивим објектима.
• Када посетилац дође код нас, потребно је да преузмемо његове трансакције по кључу, по његовом ИД-у посете. Ово је такође тачки упит; ЦлицкХоусе то не ради. Обично ЦлицкХоусе има велике…скенове, али овде треба да добијемо неколико записа. Такође антиузорак.
• Поред тога, трансакција је била у јсон-у, али нису хтели да је препишу, па су желели да сачувају јсон неструктуриран, и ако је потребно, извуку нешто из њега. И ово је такође антиузорак.

То јест, скуп антишаблона.

Али ипак смо успели да направимо систем који је веома добро функционисао.

Шта је урађено? Појавио се ЦлицкХоусе у који су бачени балвани подељени на записе. Појавио се приписани сервис који је примао дневнике од ЦлицкХоусе-а. Након тога, за сваки унос по ИД-у посете, добијао сам трансакције које још нису могле бити обрађене и плус снимке, односно трансакције које су већ повезане, односно резултат претходног рада. Већ сам направио логику од њих, изабрао исправну трансакцију и повезао нове догађаје. Поново га евидентирао. Дневник се вратио у ЦлицкХоусе, односно то је константно цикличан систем. Осим тога, отишао сам у ДВХ да то анализирам тамо.

Није добро функционисало у овој форми. И да би олакшали ЦлицкХоусе-у, када је постојао захтев за ИД посете, груписали су ове захтеве у блокове од 1-000 ИД-ова посета и извлачили све трансакције за 2-000 људи. А онда је све успело.

Ако погледате унутра ЦлицкХоусе, постоје само 3 главна стола који служе свему овоме.

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

Други сто. Кроз материјализовани поглед, догађаји који још нису приписани, односно неповезани, извучени су из ових дневника. И кроз материјализовани приказ, трансакције су извучене из ових евиденција да би се направио снимак. То јест, направљен је снимак са посебним материјализованим погледом, односно последњим акумулираним стањем трансакције.

Овде је текст написан у СКЛ-у. Желео бих да у њему прокоментаришем неколико важних ствари.

Прва важна ствар је могућност у ЦлицкХоусе-у да издвоји колоне и поља из јсон-а. То јест, ЦлицкХоусе има неке методе за рад са јсон-ом. Они су веома, веома примитивни.

виситПарамЕктрацтИнт вам омогућава да извучете атрибуте из јсон-а, тј. активира се први погодак. И на овај начин можете извући ИД трансакције или ИД посете. Овај пут.

Друго, овде се користи лукаво материјализовано поље. Шта то значи? То значи да не можете да га убаците у табелу, тј. не убацује се, већ се израчунава и чува када се убаци. Када убаците, ЦлицкХоусе ради посао за вас. А оно што ће вам касније требати је извучено из јсон-а.

У овом случају, материјализовани приказ је за необрађене жице. И користи се прва табела са скоро сировим трупцима. И шта то ради? Прво, мења сортирање, односно сортирање се сада врши по ИД-у посете, јер морамо брзо да извучемо његову трансакцију посебно за одређену особу.

Друга важна ствар је грануларност индекса. Ако сте видели МергеТрее, онда је обично подразумевана вредност 8 индек_грануларити. Шта је то? Ово је параметар реткости индекса. У ЦлицкХоусеу, индекс је оскудан; никада не индексира сваки запис. То ради сваких 192 8. И ово је добро када треба да израчунате много података, али је лоше када треба да израчунате мало, јер има много додатних трошкова. А ако смањимо грануларност индекса, онда ћемо смањити трошкове. Не можете га свести на један, јер можда нема довољно меморије. Индекс се увек чува у меморији.

А снимак користи неке друге занимљиве функције ЦлицкХоусе.

Прво је АггрегатингМергеТрее. А АггрегатингМергеТрее складишти аргМак, тј. ово је стање трансакције које одговара последњој временској ознаци. Нове трансакције се увек генеришу за овог посетиоца. И у последњем стању ове трансакције, додали смо догађај и имали смо ново стање. Поново је погодио ЦлицкХоусе. А кроз аргМак у овом материјализованом погледу увек можемо добити тренутно стање.

• Везивање је „невезано“ од времена извршавања.
• До 3 милијарде трансакција месечно се чува и обрађује. Ово је ред величине већи него у Цассандри, односно у типичном трансакционом систему.
• Кластер 2к5 ЦлицкХоусе сервера. 5 сервера и сваки сервер има реплику. Ово је чак мање него што је било у Цассандри да би се извршила атрибуција заснована на кликовима, али овде имамо засновану на утиску. То јест, уместо повећања броја сервера за 30 пута, они су смањени.

И последњи пример је финансијска компанија И, која је анализирала корелације промена цена акција.

А задатак је био следећи:

• Има око 5 акција.
• Познати су цитати на сваких 100 милисекунди.
• Подаци су се сакупљали током 10 година. По свему судећи, за неке компаније је више, за неке мање.
• Укупно има око 100 милијарди редова.

И требало је израчунати корелацију промена.

Ево две акције и њихових котација. Ако један иде горе, а други иде горе, онда је ово позитивна корелација, односно један иде горе, а други иде горе. Ако један иде нагоре, као на крају графикона, а други наниже, онда је ово негативна корелација, односно када један иде горе, други пада.

Анализирајући ове међусобне промене, могуће је прогнозирати на финансијском тржишту.

Али задатак је тежак. Шта се ради за ово? Имамо 100 милијарди записа који садрже: време, залихе и цену. Морамо прво да израчунамо 100 милијарди пута већу разлику од алгоритма цене. РуннингДифференце је функција у ЦлицкХоусе-у која секвенцијално израчунава разлику између две линије.

И након тога треба да израчунамо корелацију, а корелација се мора израчунати за сваки пар. За 5 акција, парови су 000 милиона. А ово је много, односно 12,5 пута треба да израчунате ову корелацију.

А у случају да је неко заборавио, к и и су мат. очекивање узорка. Односно, потребно је да израчунате не само корене и суме, већ и друге суме унутар ових сума. Много и много прорачуна треба урадити 12,5 милиона пута, а такође их је потребно груписати по сатима. И такође имамо много сати. И то морате учинити за 60 секунди. То је шала.

Морали смо некако да успемо, јер је све функционисало веома, веома споро пре него што је ЦлицкХоусе стигао.

Покушали су да израчунају ово на Хадооп-у, на Спарк-у, на Греенплум-у. И све је то било веома споро или скупо. Односно, било је могуће некако израчунати, али је тада било скупо.

А онда је дошао ЦлицкХоусе и све је постало много боље.

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

Шта су радили? У почетку су подаци локализовани. Сваки сервер чува податке о ценама за одређени скуп акција. И не секу се. Стога је могуће израчунати логРетурн паралелно и независно; све се то дешава паралелно и дистрибуирано.

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

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

А онда, користећи посебну скрипту, можете направити пакете из овог скупа од 12,5 милиона корелација које треба израчунати. Односно 2 задатака са 500 парова корелација. И овај задатак мора бити израчунат на одређеном ЦлицкХоусе серверу. Он има све податке јер су подаци исти и може да их израчуна узастопно.

Ево како то опет изгледа. Прво, имамо све податке у следећој структури: време, акције, цена. Затим смо израчунали логРетурн, односно податке исте структуре, само што уместо цене имамо логРетурн. Затим су они преуређени, односно добили смо тиме и гроупАрраи по промоцијама и ценовницима. Реплицатед. И након тога, генерисали су гомилу задатака и дали их ЦлицкХоусе-у како би их могао пребројати. И ради.

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

Ове прве две фазе: израчунавање Лог_ретурн-а и умотавање у низове трајало је око сат времена.

А израчунавање корелације траје око 50 сати. Али 50 сати није довољно, јер им је раније радило недељама. Био је то велики успех. А ако рачунате, онда се на овом кластеру све бројало 70 пута у секунди.

Али најважније је да овај систем практично нема уских грла, односно да се скалира скоро линеарно. И они су то проверили. Успешно је скалиран.

• Права шема је пола успеха. А исправна шема је коришћење свих потребних ЦлицкХоусе технологија.
• Сумминг/АггрегатингМергеТреес су технологије које вам омогућавају да агрегирате или рачунате снимак стања као посебан случај. А ово у великој мери поједностављује многе ствари.
• Материјализовани прикази вам омогућавају да заобиђете ограничење једног индекса. Можда ово нисам баш јасно рекао, али када смо учитали евиденције, необрађене евиденције су биле у табели са једним индексом, а на атрибуту су евиденције били у табели, односно исти подаци, само филтрирани, али је индекс био потпуно другима. Чини се да су то исти подаци, али различито сортирање. А материјализовани погледи вам омогућавају, ако вам затреба, да заобиђете ово ЦлицкХоусе ограничење.
• Смањите грануларност индекса за упите са тачкама.
• И паметно дистрибуирајте податке, покушајте да локализујете податке унутар сервера што је више могуће. И покушајте да обезбедите да захтеви такође користе локализацију у највећој могућој мери.

И да резимирамо овај кратки говор, можемо рећи да је ЦлицкХоусе сада чврсто заузео територију и комерцијалних база података и база података отвореног кода, односно посебно за аналитику. Он се савршено уклапа у овај пејзаж. И шта више, полако почиње да замењује друге, јер када је ЦлицкХоусе ту, не треба вам ИнфиниДБ. Вертицал ускоро можда неће бити потребна ако обезбеде нормалну СКЛ подршку. Искористи то!

-Хвала на извештају! Веома занимљиво! Да ли је било поређења са Апацхе Пхоеником?

-Не, нисам чуо да неко упоређује. Ми и Иандек покушавамо да пратимо сва поређења ЦлицкХоусе-а са различитим базама података. Јер ако се изненада нешто покаже брже од ЦлицкХоусе-а, онда Леша Миловидов не може да спава ноћу и почиње брзо да убрза. Нисам чуо за такво поређење.

• (Алексеј Миловидов) Апацхе Пхоеник је СКЛ мотор заснован на Хбасе-у. Хбасе је углавном дизајниран за радни сценарио типа кључ/вредност. Тамо сваки ред може имати произвољан број колона са произвољним именима. Ово се може рећи за системе као што су Хбасе и Цассандра. А управо тешки аналитички упити неће радити нормално за њих. Или можда мислите да раде добро ако нисте имали искуства са ЦлицкХоусе-ом.

• захвалити

  • Добар дан Ова тема ме већ прилично занима, јер имам аналитички подсистем. Али када погледам ЦлицкХоусе, имам осећај да је ЦлицкХоусе веома погодан за анализу догађаја, променљив. А ако треба да анализирам много пословних података са гомилом великих табела, онда ми ЦлицкХоусе, колико разумем, није баш погодан? Поготово ако се промене. Да ли је то тачно или постоје примери који би то могли оповргнути?

  • Ово је право. И то важи за већину специјализованих аналитичких база података. Скројени су тако да постоји једна или неколико великих табела које су променљиве, и много малих које се споро мењају. То јест, ЦлицкХоусе није као Орацле, где можете ставити све и направити неке веома сложене упите. Да бисте ефикасно користили ЦлицкХоусе, потребно је да направите шему на начин који добро функционише у ЦлицкХоусе-у. То јест, избегавајте прекомерну нормализацију, користите речнике, покушајте да направите мање дугих веза. А ако је шема изграђена на овај начин, онда се слични пословни проблеми могу решити на ЦлицкХоусе-у много ефикасније него на традиционалној релационој бази података.

Хвала на извештају! Имам питање о последњем финансијском случају. Имали су аналитику. Требало је упоредити како иду горе-доле. И колико сам разумео да сте направили систем посебно за ову аналитику? Ако им сутра, рецимо, треба неки други извештај о овим подацима, да ли треба поново да направе дијаграм и учитају податке? Односно, урадите неку врсту предобраде да бисте примили захтев?

Наравно, ово користи ЦлицкХоусе за врло специфичан задатак. То би могло да се реши традиционалније у оквиру Хадооп-а. За Хадооп ово је идеалан задатак. Али на Хадооп-у је веома споро. А мој циљ је да покажем да ЦлицкХоусе може да реши проблеме који се обично решавају потпуно другачијим средствима, али да то истовремено ради много ефикасније. Ово је скројено за одређени задатак. Јасно је да ако постоји проблем који је донекле сличан, онда се може решити на сличан начин.

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

Да да.

ОК хвала Вам пуно.

Ово је на кластеру од 3 сервера.

Велики поздрав! Хвала на извештају! Све је веома интересантно. Не питам мало о функционалности, већ о коришћењу ЦлицкХоусе-а са становишта стабилности. Односно, да ли сте имали проблема и да ли сте морали да их вратите? Како се понаша ЦлицкХоусе? А да ли се икада десило да се и ваша реплика сруши? На пример, наишли смо на проблем са ЦлицкХоусе-ом када је ипак прешао своје границе и пао.

Наравно, не постоје идеални системи. И ЦлицкХоусе такође има својих проблема. Али да ли сте чули да Иандек.Метрица не ради дуго? Вероватно не. Поуздано ради од отприлике 2012-2013 на ЦлицкХоусе-у. Исто могу рећи и о свом искуству. Никада нисмо имали потпуне неуспехе. Могле су се десити неке делимичне ствари, али никада нису биле довољно критичне да озбиљно утичу на пословање. Ово се никада раније није догодило. ЦлицкХоусе је прилично поуздан и не руши се насумично. Не морате да бринете о томе. То није сирова ствар. То су доказале многе компаније.

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

Ово зависи, наравно, од вашег система. Постоји неколико начина да се то уради скоро без престанка. На пример, можете креирати материјализовани приказ у коме можете креирати другачију структуру података ако се може јединствено мапирати. То јест, ако дозвољава мапирање помоћу ЦлицкХоусе-а, тј. издвајање неких ствари, промену примарног кључа, промену партиционисања, онда можете направити материјализовани приказ. Тамо ће ваши стари подаци бити преписани, нови ће бити аутоматски уписани. А онда само пређите на коришћење материјализованог приказа, затим промените запис и убијте стару табелу. Ово је генерално нон-стоп начин.

Хвала.

Извор: ввв.хабр.цом