Nadharia na mazoezi ya kutumia ClickHouse katika matumizi halisi. Alexander Zaitsev (2018)

Licha ya ukweli kwamba sasa kuna data nyingi karibu kila mahali, hifadhidata za uchambuzi bado ni za kigeni kabisa. Hazijulikani sana na hata haziwezi kuzitumia kwa ufanisi. Wengi wanaendelea "kula cactus" na MySQL au PostgreSQL, ambayo imeundwa kwa matukio mengine, mapambano na NoSQL, au kulipa zaidi kwa ufumbuzi wa kibiashara. ClickHouse ni kibadilishaji mchezo na inapunguza kwa kiasi kikubwa kizuizi cha kuingia katika ulimwengu wa DBMS ya uchanganuzi.

Ripoti hiyo inatoka kwa BackEnd Conf 2018 na inachapishwa kwa ruhusa ya spika.

Mimi ni nani na kwa nini ninazungumza kuhusu ClickHouse? Mimi ni Mkurugenzi wa Maendeleo katika LifeStreet, ambayo hutumia ClickHouse. Mimi pia ni mwanzilishi wa Altinity. Huyu ni mshirika wa Yandex anayekuza ClickHouse na husaidia Yandex kufanya ClickHouse kufanikiwa zaidi. Pia niko tayari kushiriki maarifa kuhusu ClickHouse.

Na mimi pia sio kaka wa Petya Zaitsev. Mara nyingi mimi huulizwa juu ya hili. Hapana, sisi si ndugu.

"Kila mtu anajua" hiyo ClickHouse:

• Haraka sana,
• Inafaa sana,
• Inatumika katika Yandex.

Haijulikani kidogo katika kampuni gani na jinsi inatumiwa.

Nitakuambia kwa nini, wapi na jinsi ClickHouse inatumiwa, badala ya Yandex.

Nitakuambia jinsi matatizo maalum yanatatuliwa kwa kutumia ClickHouse katika makampuni tofauti, ni zana gani za ClickHouse unaweza kutumia kwa kazi zako, na jinsi zilivyotumiwa katika makampuni tofauti.

Nimechagua mifano mitatu inayoonyesha ClickHouse kutoka pande tofauti. Nadhani itakuwa ya kuvutia.

Swali la kwanza ni: "Kwa nini unahitaji ClickHouse?" Inaonekana kwamba swali ni dhahiri kabisa, lakini kuna majibu zaidi ya moja kwa hilo.

• Jibu la kwanza ni kwa sababu za utendaji. ClickHouse ni haraka sana. Uchambuzi kwenye ClickHouse pia ni haraka sana. Mara nyingi inaweza kutumika mahali ambapo kitu kingine kinafanya kazi polepole sana au vibaya sana.
• Jibu la pili ni gharama. Na kwanza kabisa, gharama ya kuongeza. Kwa mfano, Vertica ni hifadhidata bora kabisa. Inafanya kazi vizuri sana ikiwa huna terabaiti nyingi za data. Lakini tunapozungumza kuhusu mamia ya terabytes au petabytes, gharama ya leseni na usaidizi ni kiasi kikubwa sana. Na ni ghali. Na ClickHouse ni bure.
• Jibu la tatu ni gharama ya uendeshaji. Hii ni mbinu tofauti kidogo. RedShift ni analog nzuri. Ukiwa na RedShift unaweza kufanya uamuzi haraka sana. Itafanya kazi vizuri, lakini wakati huo huo, kila saa, kila siku na kila mwezi utalipa pesa nyingi kwa Amazon, kwa sababu ni huduma ya gharama kubwa. Google BigQuery pia. Ikiwa mtu yeyote ameitumia, basi anajua kwamba unaweza kuendesha maswali kadhaa huko na ghafla kupokea ankara kwa mamia ya dola.

ClickHouse haina matatizo haya.

ClickHouse inatumika wapi sasa? Mbali na Yandex, ClickHouse hutumiwa katika kundi la biashara na makampuni mbalimbali.

• Kwanza kabisa, hii ni uchambuzi wa programu ya wavuti, i.e. hii ni kesi ya utumiaji ambayo ilitoka kwa Yandex.
• Kampuni nyingi za AdTech hutumia ClickHouse.
• Makampuni mengi ambayo yanahitaji kuchambua kumbukumbu za uendeshaji kutoka kwa vyanzo tofauti.
• Makampuni kadhaa hutumia ClickHouse kufuatilia kumbukumbu za usalama. Wanazipakia kwa ClickHouse, hufanya ripoti, na kupata matokeo wanayohitaji.
• Makampuni yanaanza kuitumia katika uchanganuzi wa kifedha, i.e. polepole biashara kubwa pia inakaribia ClickHouse.
• CloudFlare. Ikiwa mtu yeyote anafuata ClickHouse, labda umesikia jina la kampuni hii. Huyu ni mmoja wa wachangiaji muhimu kutoka kwa jamii. Na wana usakinishaji mbaya sana wa ClickHouse. Kwa mfano, walifanya Kafka Engine kwa ClickHouse.
• Kampuni za mawasiliano zimeanza kutumia. Kampuni kadhaa hutumia ClickHouse kama dhibitisho juu ya dhana au tayari katika uzalishaji.
• Kampuni moja hutumia ClickHouse kufuatilia michakato ya uzalishaji. Wanajaribu microcircuits, kuandika rundo la vigezo, kuna sifa 2. Na kisha wanachambua ikiwa kundi ni nzuri au mbaya.
• Uchambuzi wa Blockchain. Kuna kampuni ya Kirusi inaitwa Bloxy.info. Huu ni uchambuzi wa mtandao wa Ethereum. Pia walifanya hivyo kwenye ClickHouse.

Kwa kuongeza, saizi haijalishi. Kuna makampuni mengi ambayo hutumia seva moja ndogo. Na anawaruhusu kutatua matatizo yao. Na hata makampuni mengi zaidi hutumia makundi makubwa ya seva nyingi au kadhaa ya seva.

Na ukiangalia rekodi, basi:

• Yandex: Seva 500+, huhifadhi rekodi bilioni 25 kwa siku huko.
• LifeStreet: Seva 60, takriban rekodi bilioni 75 kwa siku. Kuna seva chache na rekodi zaidi kuliko katika Yandex.
• CloudFlare: Seva 36, ​​huhifadhi rekodi bilioni 200 kwa siku. Wana seva chache zaidi na huhifadhi data zaidi.
• Bloomberg: seva 102, takriban rekodi trilioni kwa siku. Kishikilia rekodi.

Kijiografia, hii pia ni mengi. Ramani hii inaonyesha ramani ya joto ambapo ClickHouse inatumika ulimwenguni. Hapa Urusi, Uchina na Amerika zinaonekana wazi. Kuna nchi chache za Ulaya. Na vikundi 4 vinaweza kutofautishwa.

Huu ni uchambuzi wa kulinganisha, hakuna haja ya kutafuta nambari kamili. Huu ni uchambuzi wa wageni wanaosoma vifaa vya lugha ya Kiingereza kwenye tovuti ya Altinity, kwa sababu hakuna wasemaji wa Kirusi huko. Na Urusi, Ukraine, Belarusi, i.e. sehemu ya jamii inayozungumza Kirusi, ndio watumiaji wengi zaidi. Halafu inakuja USA na Canada. China inashika kasi sana. Karibu hakukuwa na Uchina huko miezi sita iliyopita; sasa Uchina tayari imeipita Ulaya na inaendelea kukua. Ulaya ya Kale pia haiko nyuma, na kiongozi katika matumizi ya ClickHouse ni, isiyo ya kawaida, Ufaransa.

Kwa nini nasema haya yote? Ili kuonyesha kuwa ClickHouse inakuwa suluhisho la kawaida kwa uchanganuzi mkubwa wa data na tayari inatumika katika maeneo mengi. Ikiwa unaitumia, uko kwenye mwelekeo sahihi. Ikiwa hutumii bado, basi huna kuogopa kwamba utaachwa peke yake na hakuna mtu atakayekusaidia, kwa sababu wengi tayari wanafanya hivyo.

Hizi ni mifano ya matumizi halisi ya ClickHouse katika makampuni kadhaa.

• Mfano wa kwanza ni mtandao wa utangazaji: uhamiaji kutoka Vertica hadi ClickHouse. Na najua kampuni kadhaa ambazo zimehama kutoka Vertica au ziko katika mchakato wa kubadili.
• Mfano wa pili ni uhifadhi wa shughuli kwenye ClickHouse. Huu ni mfano uliojengwa kwenye antipatterns. Kila kitu ambacho hakihitaji kufanywa katika ClickHouse kulingana na ushauri wa watengenezaji kinafanywa hapa. Na wakati huo huo inafanywa kwa ufanisi kwamba inafanya kazi. Na inafanya kazi vizuri zaidi kuliko suluhisho la kawaida la shughuli.
• Mfano wa tatu ni kompyuta iliyosambazwa kwenye ClickHouse. Kulikuwa na swali kuhusu jinsi ClickHouse inaweza kuunganishwa kwenye mfumo wa ikolojia wa Hadoop. Nitaonyesha mfano wa jinsi kampuni ilifanya kitu sawa na chombo cha kupunguza ramani kwenye ClickHouse, ufuatiliaji wa ujanibishaji wa data, nk, ili kuhesabu kazi isiyo ya kawaida sana.

• LifeStreet ni kampuni ya Ad Tech ambayo ina teknolojia zote zinazohusiana na mtandao wa utangazaji.
• Anajishughulisha na uboreshaji wa matangazo na zabuni za kiprogramu.
• Data nyingi: kuhusu matukio bilioni 10 kwa siku. Aidha, kuna matukio yanaweza kugawanywa katika matukio kadhaa madogo.
• Kuna wateja wengi wa data hii, na hawa si watu pekee, wengi zaidi ni algoriti mbalimbali zinazojihusisha na zabuni za kiprogramu.

Kampuni imekuja kwa njia ndefu na yenye miiba. Na nilizungumza juu yake kwenye HighLoad. Kwanza, LifeStreet ilihama kutoka MySQL (pamoja na kituo kifupi Oracle) hadi Vertica. Na unaweza kupata hadithi kuhusu hilo.

Na kila kitu kilikuwa kizuri sana, lakini haraka ikawa wazi kuwa data ilikuwa inakua na Vertica ilikuwa ghali. Kwa hiyo, njia mbadala mbalimbali zilitafutwa. Baadhi yao wameorodheshwa hapa. Na kwa kweli, tulifanya uthibitisho wa dhana au wakati mwingine upimaji wa utendaji wa karibu hifadhidata zote ambazo zilipatikana kwenye soko kutoka 13 hadi 16 na zilikuwa zinafaa katika utendakazi. Na pia nilizungumza juu ya baadhi yao kwenye HighLoad.

Jukumu lilikuwa kuhama kutoka Vertica kwanza, kwa sababu data ilikuwa ikiongezeka. Na walikua kwa kasi kwa miaka kadhaa. Kisha wakaenda kwenye rafu, lakini bado. Na kutabiri ukuaji huu, mahitaji ya biashara kwa kiasi cha data ambayo aina fulani ya uchambuzi inahitaji kufanywa, ilikuwa wazi kwamba hivi karibuni kutakuwa na majadiliano ya petabytes. Na tayari ni ghali sana kulipa petabytes, kwa hiyo tulikuwa tunatafuta njia mbadala ya kwenda.

Kwenda wapi? Na kwa muda mrefu ilikuwa haijulikani kabisa wapi pa kwenda, kwa sababu kwa upande mmoja kuna databases za kibiashara, zinaonekana kufanya kazi vizuri. Baadhi hufanya kazi karibu na Vertica, zingine mbaya zaidi. Lakini zote ni ghali, hakuna nafuu au bora zaidi inaweza kupatikana.

Kwa upande mwingine, kuna ufumbuzi wa chanzo wazi, ambao sio wengi sana, yaani kwa uchambuzi wanaweza kuhesabiwa kwa upande mmoja. Na ni za bure au za bei nafuu, lakini zinafanya kazi polepole. Na mara nyingi hawana utendaji muhimu na muhimu.

Na hakukuwa na kitu cha kuchanganya mambo mazuri ambayo yako katika hifadhidata za kibiashara na vitu vyote vya bure ambavyo viko kwenye chanzo wazi.

Hakuna kilichotokea hadi Yandex ghafla ilipotoa ClickHouse kutoka kwa kofia kama sungura wa mchawi. Na huu ulikuwa uamuzi usiotarajiwa; watu bado wanauliza swali: "Kwanini?", Lakini hata hivyo.

Na mara moja katika majira ya joto ya 2016, tulianza kuangalia nini ClickHouse ni. Na ikawa kwamba wakati mwingine inaweza kuwa haraka kuliko Vertica. Tulijaribu hali tofauti kwa maombi tofauti. Na ikiwa swali lilitumia jedwali moja tu, i.e. bila viungo vyovyote, basi ClickHouse ilikuwa haraka mara mbili ya Vertica.

Sikuwa mvivu sana na niliangalia majaribio zaidi ya Yandex siku nyingine. Ni sawa huko: ClickHouse ni haraka mara mbili kama Vertica, kwa hivyo mara nyingi huzungumza juu yake.

Lakini ikiwa maswali yana viungo, basi kila kitu kinageuka kuwa si wazi sana. Na ClickHouse inaweza kuwa polepole mara mbili kama Vertica. Na ukirekebisha na kuandika ombi tena kidogo, basi watakuwa takriban sawa. Sio mbaya. Na ni bure.

Na baada ya kupokea matokeo ya mtihani, na kuiangalia kutoka pembe tofauti, LifeStreet ilikwenda kwa ClickHouse.

Huu ni mwaka wa 16, nakukumbusha. Ilikuwa kama utani wa panya ambao walilia na kujidunga, lakini waliendelea kula cactus. Na hii ilijadiliwa kwa undani, kuna video kuhusu hili, nk.

Kwa hivyo, sitazungumza juu ya hili kwa undani, nitazungumza tu juu ya matokeo na mambo machache ya kupendeza ambayo sikuzungumza wakati huo.

Matokeo ni:

• Uhamiaji uliofanikiwa na mfumo umekuwa katika uzalishaji kwa zaidi ya mwaka mmoja.
• Uzalishaji na unyumbufu umeongezeka. Kutoka kwa rekodi bilioni 10 ambazo tungeweza kumudu kuhifadhi kwa siku kwa muda mfupi tu, LifeStreet sasa huhifadhi rekodi bilioni 75 kwa siku na inaweza kufanya hivyo kwa miezi 3 au zaidi. Ikiwa unahesabu kilele, basi hii inahifadhiwa hadi matukio milioni kwa sekunde. Zaidi ya hoja milioni moja za SQL kwa siku hutumwa kwa mfumo huu, hasa kutoka kwa roboti mbalimbali.
• Licha ya ukweli kwamba ClickHouse ilianza kutumia seva zaidi kuliko Vertica, akiba pia ilifanywa kwenye vifaa, kwa sababu Vertica ilitumia diski za gharama kubwa za SAS. ClickHouse imetumia SATA. Na kwa nini? Kwa sababu katika Vertica kuingiza ni synchronous. Na maingiliano inahitaji kwamba disks hazipunguzi sana, na pia kwamba mtandao haupunguzi sana, yaani, operesheni ya gharama kubwa. Na katika ClickHouse kuingiza ni asynchronous. Zaidi ya hayo, unaweza daima kuandika kila kitu ndani ya nchi, hakuna gharama za ziada kwa hili, hivyo data inaweza kuingizwa kwenye ClickHouse kwa kasi zaidi kuliko kwenye Vertika, hata kwenye si disks za haraka zaidi. Na kusoma ni sawa. Kusoma kwenye SATA, ikiwa wako kwenye RAID, basi yote ni haraka vya kutosha.
• Bila kikomo na leseni, yaani, petabytes 3 za data katika seva 60 (seva 20 ni nakala moja) na rekodi trilioni 6 za ukweli na jumla. Vertica haikuweza kumudu kitu kama hiki.

Sasa ninaenda kwenye vitu vya vitendo katika mfano huu.

• Ya kwanza ni mpango wa ufanisi. Mengi inategemea mpango.
• Ya pili ni kutoa SQL bora.

Swali la kawaida la OLAP linachaguliwa. Baadhi ya safu wima huenda kwa kundi baada ya nyingine, safu wima zingine huenda kujumlisha utendakazi. Kuna mahali, ambayo inaweza kuzingatiwa kama kipande cha mchemraba. Kundi zima linaweza kuzingatiwa kama makadirio. Na ndiyo sababu inaitwa uchambuzi wa data wa multivariate.

Na mara nyingi hii inafanywa kwa namna ya mchoro wa nyota, wakati kuna ukweli kuu na sifa za ukweli huu kwenye pande, kando ya mionzi.

Na kutoka kwa mtazamo wa muundo wa mwili, jinsi inafaa kwenye meza, kawaida hufanya uwakilishi wa kawaida. Unaweza kubadilisha hali ya kawaida, lakini ni ghali kwenye diski na haifai sana kwa maswali. Kwa hiyo, kwa kawaida hufanya mtazamo wa kawaida, yaani, meza ya ukweli na meza nyingi za vipimo.

Lakini hii haifanyi kazi vizuri katika ClickHouse. Kuna sababu mbili:

• Ya kwanza ni kwa sababu ClickHouse haina viungio vizuri sana, i.e. kuna viungio, lakini ni vibaya. Hadi sasa wao ni wabaya.
• Ya pili ni kwamba meza hazijasasishwa. Kawaida katika ishara hizi ambazo ziko karibu na mchoro wa nyota, kitu kinahitaji kubadilishwa. Kwa mfano, jina la mteja, jina la kampuni, nk. Na haifanyi kazi.

Na kuna njia ya kutoka kwa hii katika ClickHouse. hata mbili:

• Ya kwanza ni matumizi ya kamusi. Kamusi za Nje ndizo zinazosaidia 99% kutatua tatizo na mpango wa nyota, na sasisho na kadhalika.
• Ya pili ni matumizi ya safu. Safu pia husaidia kuondoa viungo na shida na kuhalalisha.

• Hakuna haja ya kujiunga.
• Inaweza kusasishwa. Tangu Machi 2018, fursa isiyo na hati imeonekana (hutapata hii kwenye nyaraka) kusasisha kamusi kwa sehemu, i.e. maingizo yale ambayo yamebadilika. Kwa mazoezi, ni kama meza.
• Daima katika kumbukumbu, hivyo hujiunga na kamusi hufanya kazi kwa kasi zaidi kuliko ikiwa ni meza ambayo iko kwenye diski na sio ukweli kwamba iko kwenye cache, uwezekano mkubwa sio.

• Huna haja ya kujiunga pia.
• Huu ni uwakilishi wa 1 kwa wengi.
• Na kwa maoni yangu, safu zinatengenezwa kwa geeks. Hizi ni kazi za lambda na vitu.

Hii si kwa ajili ya maneno. Huu ni utendakazi wenye nguvu sana ambao hukuruhusu kufanya mambo mengi kwa urahisi na kifahari.

Mifano ya kawaida ambayo husaidia kutatua safu. Mifano hii ni rahisi na wazi kabisa:

• Tafuta kwa lebo. Ikiwa una lebo za reli hapo na unataka kupata machapisho kadhaa kwa hashtag.
• Tafuta kwa jozi za thamani-msingi. Pia kuna baadhi ya sifa zenye maana.
• Kuhifadhi orodha za funguo ambazo unahitaji kutafsiri katika kitu kingine.

Matatizo haya yote yanaweza kutatuliwa bila safu. Vitambulisho vinaweza kuwekwa kwenye mstari fulani na kuchaguliwa kwa kutumia usemi wa kawaida, au kwenye jedwali tofauti, lakini basi itabidi uunganishe.

Lakini katika ClickHouse huna haja ya kufanya chochote, elezea tu safu ya kamba kwa hashtag au unda muundo uliowekwa kwa mifumo ya thamani-msingi.

Muundo uliowekwa kiota hauwezi kuwa jina bora. Hizi ni safu mbili ambazo zina sehemu ya kawaida katika jina na sifa zingine zinazohusiana.

Na ni rahisi sana kutafuta kwa lebo. Kuna kipengele has, ambayo hukagua kuwa safu ina kipengele. Kila mtu, tulipata maingizo yote yanayohusiana na mkutano wetu.

Kutafuta kwa subid ni ngumu zaidi. Kwanza tunahitaji kupata index ya ufunguo, na kisha kuchukua kipengele na index hii na kuangalia kwamba thamani hii ni nini tunahitaji. Lakini hata hivyo ni rahisi sana na kompakt.

Usemi wa kawaida ambao ungetaka kuandika, ikiwa utaihifadhi yote katika mstari mmoja, itakuwa, kwanza kabisa, ngumu. Na, pili, ilifanya kazi kwa muda mrefu zaidi ya safu mbili.

Mfano mwingine. Una safu ambayo unahifadhi vitambulisho. Na unaweza kutafsiri kwa majina. Kazi arrayMap. Hii ni kazi ya kawaida ya lambda. Unapitisha maneno ya lambda hapo. Na yeye huchota thamani ya jina kwa kila kitambulisho kutoka kwa kamusi.

Unaweza kufanya utafutaji kwa njia sawa. Kitendaji cha kihusishi hupitishwa, ambacho hukagua vipengele vinavyolingana.

Vitu hivi hurahisisha sana mzunguko na kutatua rundo la shida.

Lakini shida inayofuata ambayo tulikutana nayo na ambayo ningependa kutaja ni maswali bora.

• ClickHouse haina mpangilio wa hoja. Sivyo kabisa.
• Lakini hata hivyo, maswali magumu bado yanahitaji kupangwa. Katika kesi gani?
• Ikiwa ombi lina viungio kadhaa, ambavyo unavifunga kwa vichaguo vidogo. Na mpangilio unaotekelezwa ni muhimu.
• Na pili, ikiwa ombi linasambazwa. Kwa sababu katika hoja iliyosambazwa, uteuzi mdogo wa ndani pekee ndio unaotekelezwa kwa njia iliyosambazwa, na kila kitu kingine hutumwa kwa seva moja uliyounganisha na kutekelezwa hapo. Kwa hiyo, ikiwa umesambaza maswali na viungo vingi, basi unahitaji kuchagua amri.

Na hata katika hali rahisi, wakati mwingine unahitaji pia kufanya kazi ya mpangaji na kuandika tena maswali kidogo.

Hapa kuna mfano. Upande wa kushoto kuna swali linaloonyesha nchi 5 bora. Na inaendesha kwa sekunde 2,5, nadhani. Na upande wa kulia ni ombi sawa, lakini imeandikwa upya kidogo. Badala ya kuweka vikundi kwa kamba, tulianza kuweka vikundi kwa ufunguo (int). Na ni kasi zaidi. Na kisha tukaunganisha kamusi kwa matokeo. Badala ya sekunde 2,5, ombi huchukua sekunde 1,5. Hii ni nzuri.

Mfano sawa na vichujio vya kuandika upya. Hapa kuna ombi kwa Urusi. Inaendesha kwa sekunde 5. Ikiwa tunaandika tena kwa namna ambayo sisi tena kulinganisha si kamba, lakini nambari na seti fulani ya funguo hizo zinazohusiana na Urusi, basi itakuwa kasi zaidi.

Kuna hila nyingi kama hizo. Na hukuruhusu kuharakisha kwa kiasi kikubwa maswali ambayo unadhani tayari yanaendesha haraka, au, kinyume chake, yanaendesha polepole. Wanaweza kufanywa hata kwa kasi zaidi.

• Upeo wa kazi katika hali ya kusambazwa.
• Kupanga kwa aina ndogo, kama nilivyofanya kwa ints.
• Ikiwa kuna viungio au kamusi, basi ni bora kuzifanya mwisho, wakati tayari una data angalau sehemu ya kikundi, basi operesheni ya kujiunga au kupiga simu kwa kamusi itaitwa mara chache na itakuwa haraka.
• Kubadilisha vichungi.

Kuna mbinu zingine, sio tu zile nilizoonyesha. Na zote wakati mwingine hukuruhusu kuharakisha sana utekelezaji wa maswali.

Hebu tuendelee kwenye mfano unaofuata. Kampuni X kutoka Marekani. Anafanya nini?

Kulikuwa na kazi:

• Kuunganisha nje ya mtandao kwa shughuli za utangazaji.
• Uigaji wa mifano tofauti ya kumfunga.

Je, ni mazingira gani?

Mgeni wa kawaida hutembelea tovuti, kwa mfano, mara 20 kwa mwezi kutoka kwa matangazo tofauti, au wakati mwingine huja tu bila matangazo yoyote, kwa sababu anakumbuka tovuti hii. Inatazama baadhi ya bidhaa, kuziweka kwenye kikapu, kuzitoa nje ya kikapu. Na, mwishowe, ananunua kitu.

Maswali yanayofaa: "Nani anapaswa kulipa kwa utangazaji, ikiwa ni lazima?" na "Ni matangazo gani, ikiwa yapo, yaliyomshawishi?" Hiyo ni, kwa nini alinunua na jinsi ya kuhakikisha kuwa watu sawa na mtu huyu pia wananunua?

Ili kutatua tatizo hili, unahitaji kuunganisha matukio yanayotokea kwenye tovuti kwa njia sahihi, yaani, kwa namna fulani kujenga uhusiano kati yao. Kisha zinahamishwa kwa ajili ya uchambuzi hadi DWH. Na kwa kuzingatia uchanganuzi huu, jenga mifano ya nani wa kuonyesha ni utangazaji gani.

Muamala wa utangazaji ni seti ya matukio yanayohusiana ya mtumiaji ambayo huanza na tangazo kuonyeshwa, kisha kitu kitatokea, kisha labda ununuzi, na kisha kunaweza kuwa na ununuzi ndani ya ununuzi. Kwa mfano, ikiwa hii ni programu ya simu au mchezo wa simu, basi kwa kawaida kufunga programu ni bure, lakini ikiwa kitu kingine kinafanyika huko, basi inaweza kuhitaji pesa. Na zaidi mtu anatumia katika programu, ni ya thamani zaidi. Lakini kwa hili unahitaji kuunganisha kila kitu.

Kuna mifano mingi ya kufunga.

Maarufu zaidi ni:

• Mwingiliano wa Mwisho, ambapo mwingiliano ni wa kubofya au onyesho.
• Mwingiliano wa Kwanza, yaani, jambo la kwanza ambalo lilimleta mtu kwenye tovuti.
• Mchanganyiko wa mstari - sehemu sawa kwa kila mtu.
• Attenuation.
• Nakadhalika.

Na yote yalifanyaje kazi mwanzoni? Kulikuwa na Runtime na Cassandra. Cassandra ilitumika kama hifadhi ya muamala, yaani, miamala yote inayohusiana ilihifadhiwa ndani yake. Na tukio fulani linapotokea wakati wa Runtime, kwa mfano, onyesho la ukurasa au kitu kingine, ombi hutolewa kwa Cassandra ikiwa kuna mtu kama huyo au la. Kisha miamala inayohusiana nayo ilipokelewa. Na kufunga kulifanyika.

Na ikiwa una bahati kwamba ombi lina kitambulisho cha shughuli, basi hii ni rahisi. Lakini kwa kawaida huna bahati. Kwa hiyo, ilikuwa ni lazima kupata shughuli ya mwisho au shughuli kwa kubofya mwisho, nk.

Na yote ilifanya kazi vizuri sana hadi unganisho ulikuwa wa kubofya mwisho. Kwa sababu kuna, sema, kubofya milioni 10 kwa siku, milioni 300 kwa mwezi, ikiwa utaweka dirisha kwa mwezi. Na kwa kuwa katika Cassandra yote yanapaswa kuwa katika kumbukumbu ili kufanya kazi haraka, kwa sababu Runtime inahitajika kujibu haraka, takriban seva 10-15 zilihitajika.

Na walipotaka kuunganisha shughuli kwenye onyesho, mara moja ikawa sio ya kufurahisha sana. Na kwa nini? Inaweza kuonekana kuwa matukio mara 30 zaidi yanahitaji kuhifadhiwa. Na, ipasavyo, unahitaji seva mara 30 zaidi. Na inageuka kuwa hii ni aina fulani ya takwimu ya astronomia. Kuweka hadi seva 500 ili kuunganisha, licha ya ukweli kwamba kuna seva chache sana katika Runtime, ni aina fulani ya takwimu mbaya. Na wakaanza kufikiria nini cha kufanya.

Na tukaenda kwa ClickHouse. Jinsi ya kufanya hivyo kwenye ClickHouse? Kwa mtazamo wa kwanza, inaonekana kwamba hii ni seti ya antipatterns.

• Muamala unakua, tunaambatisha matukio zaidi na zaidi kwake, i.e. inaweza kubadilika, na ClickHouse haifanyi kazi vizuri na vitu vinavyoweza kubadilika.
• Wakati mgeni anakuja kwetu, tunahitaji kurejesha shughuli zake kwa ufunguo, kwa kitambulisho chake cha kutembelea. Hili pia ni hoja ya hoja; ClickHouse haifanyi hivyo. Kawaida ClickHouse ina…skani kubwa, lakini hapa tunahitaji kupata rekodi kadhaa. Pia antipattern.
• Kwa kuongeza, shughuli hiyo ilikuwa katika json, lakini hawakutaka kuiandika tena, kwa hiyo walitaka kuhifadhi json isiyo na muundo, na ikiwa ni lazima, kuvuta kitu kutoka kwake. Na hii pia ni antipattern.

Hiyo ni, seti ya antipatterns.

Lakini hata hivyo, tuliweza kuunda mfumo ambao ulifanya kazi vizuri sana.

Nini kilifanyika? ClickHouse ilionekana, ambayo magogo, yaliyogawanywa katika rekodi, yalitupwa. Huduma iliyohusishwa ilionekana ambayo ilipokea kumbukumbu kutoka kwa ClickHouse. Baada ya hapo, kwa kila kiingilio kwa kitambulisho cha kutembelea, nilipokea miamala ambayo bado haijashughulikiwa na vijisehemu zaidi, i.e. shughuli ambazo tayari zimeunganishwa, ambayo ni matokeo ya kazi ya hapo awali. Tayari nimefanya mantiki kutoka kwao, nikachagua muamala sahihi, na nikaunganisha matukio mapya. Imeingia tena. Logi ilirudi kwa ClickHouse, i.e. ni mfumo wa mzunguko wa kila wakati. Na zaidi ya hayo, nilienda kwa DWH ili kuichanganua huko.

Haikufanya kazi vizuri sana katika fomu hii. Na ili kurahisisha ClickHouse, wakati kulikuwa na ombi la kitambulisho cha kutembelea, waliweka maombi haya katika vikundi vya vitambulisho vya kutembelea 1-000 na kutoa shughuli zote za watu 2-000. Na kisha yote yalifanya kazi.

Ukiangalia ndani ya ClickHouse, kuna meza kuu 3 tu zinazohudumia haya yote.

Jedwali la kwanza ambalo kumbukumbu hupakiwa, na kumbukumbu zinapakiwa bila usindikaji wowote.

Jedwali la pili. Kupitia mtazamo wa kimwili, matukio ambayo bado hayajahusishwa, yaani, yasiyohusiana, yalitolewa kutoka kwenye kumbukumbu hizi. Na kupitia mwonekano wa kimaumbile, shughuli zilitolewa kutoka kwa magogo haya ili kuunda picha. Hiyo ni, snapshot iliundwa kwa mtazamo maalum wa kimwili, yaani hali ya mwisho ya kusanyiko ya shughuli.

Hapa maandishi yameandikwa katika SQL. Ningependa kutoa maoni juu ya mambo kadhaa muhimu ndani yake.

Jambo la kwanza muhimu ni uwezo katika ClickHouse kutoa safu na uwanja kutoka kwa json. Hiyo ni, ClickHouse ina njia kadhaa za kufanya kazi na json. Wao ni sana, sana.

visitParamExtractInt hukuruhusu kutoa sifa kutoka kwa json, i.e. hit ya kwanza imeanzishwa. Na kwa njia hii unaweza kuvuta kitambulisho cha muamala au tembelea kitambulisho. Wakati huu.

Pili, uwanja wa ujanja wa nyenzo hutumiwa hapa. Ina maana gani? Hii ina maana kwamba huwezi kuiingiza kwenye meza, yaani, haijaingizwa, imehesabiwa na kuhifadhiwa wakati wa kuingizwa. Unapoingiza, ClickHouse hukufanyia kazi. Na kile utahitaji baadaye hutolewa kutoka kwa json.

Katika kesi hii, mtazamo wa nyenzo ni wa kamba mbichi. Na meza ya kwanza yenye magogo karibu ghafi hutumiwa. Na inafanya nini? Kwanza, inabadilisha upangaji, i.e. upangaji sasa unafanywa kwa kitambulisho cha kutembelea, kwa sababu tunahitaji kutoa muamala wake haraka haswa kwa mtu maalum.

Jambo la pili muhimu ni index_granularity. Ikiwa umeona MergeTree, basi kwa kawaida thamani chaguo-msingi ni 8 index_granularity. Ni nini? Hii ndio parameta ya sparsity index. Katika ClickHouse, faharisi ni chache; haiashirii kila rekodi. Inafanya hivyo kila 192. Na hii ni nzuri wakati unahitaji kuhesabu data nyingi, lakini ni mbaya wakati unahitaji kuhesabu kidogo, kwa sababu kuna mengi ya juu. Na ikiwa tunapunguza granularity index, basi sisi kupunguza overhead. Huwezi kuipunguza hadi moja, kwa sababu kunaweza kuwa hakuna kumbukumbu ya kutosha. Fahirisi huhifadhiwa kila wakati kwenye kumbukumbu.

Na snapshot hutumia kazi zingine za kuvutia za ClickHouse.

Kwanza ni AggregatingMergeTree. Na maduka ya AggregatingMergeTree argMax, yaani, hii ndiyo hali ya muamala inayolingana na muhuri wa muda wa mwisho. Shughuli mpya hutolewa kila mara kwa mgeni huyu. Na katika hali ya mwisho kabisa ya shughuli hii, tuliongeza tukio na tulikuwa na hali mpya. Iligonga ClickHouse tena. Na kupitia argMax katika mwonekano huu wa kimaumbile tunaweza kupata hali ya sasa kila wakati.

• Kufunga "hakuunganishwa" kutoka kwa Runtime.
• Hadi miamala ya bilioni 3 kwa mwezi huhifadhiwa na kuchakatwa. Huu ni utaratibu wa ukubwa zaidi kuliko katika Cassandra, yaani, katika mfumo wa kawaida wa shughuli.
• Kundi la seva 2x5 za ClickHouse. Seva 5 na kila seva ina nakala. Hii ni kidogo hata kuliko ilivyokuwa katika Cassandra ili kufanya mibofyo kulingana na maelezo, lakini hapa tuna mwonekano kulingana. Hiyo ni, badala ya kuongeza idadi ya seva kwa mara 30, zilipunguzwa.

Na mfano wa mwisho ni kampuni ya kifedha Y, ambayo ilichambua uwiano wa mabadiliko ya bei ya hisa.

Na kazi ilikuwa hii:

• Kuna takriban hisa 5.
• Nukuu kila baada ya milisekunde 100 zinajulikana.
• Data imekusanya zaidi ya miaka 10. Inavyoonekana, kwa kampuni zingine ni zaidi, kwa zingine ni kidogo.
• Kuna takriban safu bilioni 100 kwa jumla.

Na ilikuwa ni lazima kuhesabu uwiano wa mabadiliko.

Hapa kuna hisa mbili na nukuu zao. Ikiwa moja inapanda na nyingine inapanda, basi hii ni uwiano mzuri, yaani, moja huenda juu na nyingine huenda juu. Ikiwa moja itapanda, kama mwisho wa grafu, na nyingine inashuka, basi hii ni uwiano mbaya, yaani, wakati mmoja anapanda, mwingine anashuka.

Kwa kuchambua mabadiliko haya ya pande zote, mtu anaweza kufanya utabiri katika soko la fedha.

Lakini kazi ni ngumu. Nini kinafanyika kwa hili? Tuna rekodi bilioni 100 ambazo zina: wakati, hisa na bei. Tunahitaji kwanza kukokotoa mara bilioni 100 ya Difference inayoendesha kutoka kwa algoriti ya bei. RunningDifference ni chaguo za kukokotoa katika ClickHouse ambayo hukokotoa tofauti kati ya mistari miwili mfululizo.

Na baada ya hayo tunahitaji kuhesabu uwiano, na uwiano lazima uhesabiwe kwa kila jozi. Kwa hisa 5, jozi ni milioni 000. Na hii ni nyingi, i.e. mara 12,5 unahitaji kuhesabu kazi hii ya uunganisho.

Na ikiwa mtu yeyote alisahau, ͞x na ͞y ni wenzako. matarajio ya sampuli. Hiyo ni, unahitaji sio tu kuhesabu mizizi na hesabu, lakini pia hesabu zingine ndani ya hesabu hizi. Mahesabu mengi na mengi yanahitajika kufanywa mara milioni 12,5, na pia yanahitaji kuunganishwa kwa saa. Na pia tuna masaa mengi. Na lazima uifanye katika sekunde 60. Ni mzaha.

Ilitubidi kuifanya kwa njia fulani, kwa sababu yote ilifanya kazi polepole sana kabla ya ClickHouse kufika.

Walijaribu kuhesabu hii kwenye Hadoop, kwenye Spark, kwenye Greenplum. Na hii yote ilikuwa polepole sana au ghali. Hiyo ni, iliwezekana kwa namna fulani kuhesabu, lakini basi ilikuwa ghali.

Na kisha ClickHouse ilikuja na kila kitu kikawa bora zaidi.

Acha nikukumbushe kwamba tuna tatizo na eneo la data, kwa hivyo maunganisho hayawezi kujanibishwa. Hatuwezi kuongeza baadhi ya data kwenye seva moja, nyingine hadi nyingine na kukokotoa; lazima tuwe na data zote kila mahali.

Walifanya nini? Hapo awali, data imejanibishwa. Kila seva huhifadhi data ya bei kwa seti maalum ya hisa. Na haziingiliani. Kwa hivyo, inawezekana kuhesabu logiKurudi kwa sambamba na kwa kujitegemea; yote haya hutokea kwa sambamba na kusambazwa.

Kisha tuliamua kupunguza data hii bila kupoteza kujieleza. Punguza kutumia safu, yaani kwa kila kipindi cha muda tengeneza safu ya hifadhi na bei mbalimbali. Kwa hivyo inachukua nafasi ndogo zaidi ya data. Na zinafaa zaidi kufanya kazi nazo. Hizi ni karibu shughuli zinazolingana, yaani, tunahesabu sehemu sambamba na kisha tunaandika kwa seva.

Hii basi inaweza kuigwa. Herufi "r" inamaanisha kuwa tuliiga data hii. Hiyo ni, tuna data sawa kwenye seva zote tatu - hizi ni safu.

Na kisha, kwa kutumia script maalum, unaweza kufanya vifurushi kutoka kwa seti hii ya uwiano wa milioni 12,5 ambao unahitaji kuhesabiwa. Hiyo ni, kazi 2 na jozi 500 za uunganisho. Na kazi hii lazima ihesabiwe kwenye seva maalum ya ClickHouse. Ana data zote kwa sababu data ni sawa na anaweza kuihesabu kwa mfuatano.

Hivi ndivyo inavyoonekana tena. Kwanza, tuna data zote katika muundo wafuatayo: wakati, hisa, bei. Kisha tukahesabu logReturn, i.e. data ya muundo sawa, badala ya bei tuna logReturn. Kisha zikafanywa upya, yaani, tulipata muda na groupArray kwa matangazo na orodha za bei. Imeigwa. Na baada ya hapo, walitoa rundo la kazi na kuzilisha kwa ClickHouse ili iweze kuzihesabu. Na inafanya kazi.

Katika uthibitisho wa dhana, kazi ilikuwa kazi ndogo, i.e. walichukua data kidogo. Na kwenye seva tatu tu.

Hatua hizi mbili za kwanza: kukokotoa Log_return na kuifunga kwa safu kulichukua takriban saa moja kila moja.

Na kuhesabu uunganisho huchukua kama masaa 50. Lakini saa 50 haitoshi, kwa sababu hapo awali ilifanya kazi kwao kwa wiki. Ilikuwa ni mafanikio makubwa. Na ukihesabu, basi kila kitu kilihesabiwa mara 70 kwa sekunde kwenye nguzo hii.

Lakini jambo la muhimu zaidi ni kwamba mfumo huu hauna vizuizi, i.e. unapunguza karibu mstari. Nao wakaikagua. Iliongezwa kwa mafanikio.

• Mpango sahihi ni nusu ya mafanikio. Na mpango sahihi ni kutumia teknolojia zote muhimu za ClickHouse.
• Summing/AggregatingMergeTrees ni teknolojia zinazokuruhusu kujumlisha au kuhesabu picha ya hali kama kesi maalum. Na hii hurahisisha mambo mengi sana.
• Mionekano Inayotumika hukuruhusu kuzunguka kikomo cha faharasa moja. Labda sikusema hivi kwa uwazi sana, lakini tulipopakia magogo, magogo mabichi yalikuwa kwenye jedwali yenye faharisi moja, na kwa sifa magogo yalikuwa kwenye jedwali, yaani data ile ile, ilichujwa tu, lakini faharisi ilikuwa. kabisa kwa wengine. Inaonekana kuwa data sawa, lakini upangaji tofauti. Na Maoni ya Nyenzo hukuruhusu, ikiwa unaihitaji, kupita kikomo hiki cha ClickHouse.
• Punguza uzito wa faharasa kwa hoja za hoja.
• Na usambaze data kwa busara, jaribu kubinafsisha data ndani ya seva iwezekanavyo. Na jaribu kuhakikisha kuwa maombi pia yanatumia ujanibishaji inapowezekana kadri iwezekanavyo.

Na kwa muhtasari wa hotuba hii fupi, tunaweza kusema kwamba ClickHouse sasa imechukua eneo la hifadhidata zote mbili za kibiashara na hifadhidata huria, i.e. haswa kwa uchanganuzi. Anafaa kabisa katika mazingira haya. Na zaidi ya hayo, inaanza polepole kuondoa wengine, kwa sababu wakati ClickHouse iko, hauitaji InfiniDB. Wima huenda isihitajike hivi karibuni ikiwa watatoa usaidizi wa kawaida wa SQL. Itumie!

-Asante kwa ripoti! Inavutia sana! Je! kumekuwa na ulinganisho wowote na Apache Phoenix?

- Hapana, sijasikia mtu yeyote akilinganisha. Sisi na Yandex tunajaribu kufuatilia ulinganisho wote wa ClickHouse na hifadhidata tofauti. Kwa sababu ikiwa ghafla kitu kinageuka kuwa kasi zaidi kuliko ClickHouse, basi Lesha Milovidov hawezi kulala usiku na huanza haraka kuharakisha. Sijasikia kulinganisha kama hii.

• (Alexey Milovidov) Apache Phoenix ni injini ya SQL kulingana na Hbase. Hbase imeundwa kwa ajili ya hali ya kazi ya aina ya ufunguo wa thamani. Huko, kila mstari unaweza kuwa na idadi kiholela ya safu wima zilizo na majina ya kiholela. Hii inaweza kusemwa kuhusu mifumo kama vile Hbase na Cassandra. Na ni maswali mazito ya uchambuzi ambayo hayatafanya kazi kawaida kwao. Au unaweza kufikiria zinafanya kazi vizuri ikiwa haujapata uzoefu wowote na ClickHouse.

• Shukrani

  • Habari za mchana Tayari ninavutiwa sana na mada hii, kwa sababu nina mfumo mdogo wa uchambuzi. Lakini ninapoangalia ClickHouse, ninapata hisia kwamba ClickHouse inafaa sana kwa uchambuzi wa tukio, inayoweza kubadilika. Na ikiwa ninahitaji kuchambua data nyingi za biashara na kundi la meza kubwa, basi ClickHouse, kwa kadiri ninavyoelewa, haifai sana kwangu? Hasa ikiwa wanabadilika. Je, hii ni sahihi au kuna mifano ambayo inaweza kukanusha hili?

  • Hii ni sawa. Na hii ni kweli kuhusu hifadhidata maalumu zaidi za uchanganuzi. Zimeundwa kwa ukweli kwamba kuna meza moja au kadhaa kubwa ambazo zinaweza kubadilika, na nyingi ndogo ambazo hubadilika polepole. Hiyo ni, ClickHouse sio kama Oracle, ambapo unaweza kuweka kila kitu na kuunda maswali magumu sana. Ili kutumia ClickHouse kwa ufanisi, unahitaji kujenga mpango kwa njia ambayo inafanya kazi vizuri katika ClickHouse. Hiyo ni, epuka kuhalalisha kupita kiasi, tumia kamusi, jaribu kufanya viunganisho vichache vya muda mrefu. Na ikiwa mpango umejengwa kwa njia hii, basi shida zinazofanana za biashara zinaweza kutatuliwa kwenye ClickHouse kwa ufanisi zaidi kuliko kwa hifadhidata ya jadi ya uhusiano.

Asante kwa ripoti! Nina swali kuhusu kesi ya hivi punde ya kifedha. Walikuwa na uchanganuzi. Ilikuwa ni lazima kulinganisha jinsi wanavyopanda na kushuka. Na ninaelewa kuwa umeunda mfumo mahususi kwa uchanganuzi huu? Ikiwa kesho, hebu sema, wanahitaji ripoti nyingine juu ya data hii, wanahitaji kujenga mchoro tena na kupakia data? Hiyo ni, kufanya aina fulani ya usindikaji ili kupokea ombi?

Kwa kweli, hii ni kutumia ClickHouse kwa kazi maalum. Inaweza kutatuliwa kijadi zaidi ndani ya Hadoop. Kwa Hadoop hii ni kazi bora. Lakini kwenye Hadoop ni polepole sana. Na lengo langu ni kuonyesha kuwa ClickHouse inaweza kutatua shida ambazo kawaida hutatuliwa kwa njia tofauti kabisa, lakini wakati huo huo fanya kwa ufanisi zaidi. Hii imeundwa kwa ajili ya kazi maalum. Ni wazi kwamba ikiwa kuna tatizo ambalo linafanana kwa kiasi fulani, basi linaweza kutatuliwa kwa njia sawa.

Ni wazi. Ulisema ilichukua saa 50 kuchakata. Je, ni kuanzia mwanzo, ulipopakia data au kupokea matokeo?

Ndiyo ndiyo.

Sawa Asante sana.

Hii ni kwenye nguzo ya seva 3.

Salamu! Asante kwa ripoti! Kila kitu kinavutia sana. Siulizi kidogo juu ya utendaji, lakini juu ya kutumia ClickHouse kutoka kwa mtazamo wa utulivu. Yaani ulikuwa na matatizo na ulilazimika kuyarejesha? ClickHouse inafanyaje? Je, imewahi kutokea kwamba nakala yako pia ilianguka? Kwa mfano, tulikumbana na tatizo na ClickHouse wakati bado ilivuka kikomo chake na ikaanguka.

Bila shaka, hakuna mifumo bora. Na ClickHouse pia ina shida zake. Lakini umesikia kuhusu Yandex.Metrica haifanyi kazi kwa muda mrefu? Pengine si. Imekuwa ikifanya kazi kwa uhakika tangu 2012-2013 kwenye ClickHouse. Ninaweza kusema vivyo hivyo kuhusu uzoefu wangu. Hatujawahi kushindwa kabisa. Baadhi ya mambo kidogo yanaweza kutokea, lakini hayakuwa muhimu vya kutosha kuathiri sana biashara. Hii haijawahi kutokea kabla. ClickHouse ni ya kuaminika kabisa na haifanyi kazi nasibu. Huna haja ya kuwa na wasiwasi kuhusu hilo. Si jambo mbichi. Hii imethibitishwa na makampuni mengi.

Habari! Ulisema kwamba unahitaji kufikiria mara moja kwa uangalifu juu ya schema ya data. Je, kama hili lingetokea? Data yangu inamiminika na kutoka. Miezi sita inapita, na ninaelewa kuwa siwezi kuishi hivi, ninahitaji kupakia tena data na kufanya kitu nayo.

Hii inategemea, bila shaka, kwenye mfumo wako. Kuna njia kadhaa za kufanya hivi karibu bila kuacha. Kwa mfano, unaweza kuunda Mwonekano Ulioboreshwa ambamo unaweza kuunda muundo tofauti wa data ikiwa unaweza kuchorwa kipekee. Hiyo ni, ikiwa inaruhusu uchoraji wa ramani kwa kutumia ClickHouse, i.e. kutoa vitu kadhaa, kubadilisha ufunguo wa msingi, kubadilisha kizigeu, basi unaweza kutengeneza Mtazamo wa Nyenzo. Hapo data yako ya zamani itaandikwa upya, mpya itaandikwa kiotomatiki. Na kisha ubadilishe tu kutumia Maoni ya Nyenzo, kisha ubadilishe rekodi na uue jedwali la zamani. Hii ni njia isiyo ya kawaida kwa ujumla.

Asante.

Chanzo: mapenzi.com