Data Engineer

Kādus papildu parametrus DDL/CREATE TABLE ClickHouse jūs zināt, uz ko tie ietekmē un kādos gadījumos tie tiek izmantoti?

Kā tika izveidotas klastera tabulas un kā tika risināta problēma, kad ZooKeeper dēļ trūka replikas uz viena shard?

Kā nevienmērīgi sadalīt šīs vitriņas datus trīs shardos: 50% pirmajā un pa 25% pārējos divos?

Kā tieši jūs lasījāt Parquet?

Kā jūs risinājāt optimizācijas problēmas, kad vaicājums ilgstoši darbojas un veic pilnu skenēšanu? Kā pieietu jaunai līdzīgai uzdevumam?

Kādos gadījumos Materialized View ClickHouse var izlaist datus vai, gluži pretēji, dublēt tos?

Vai esat kādreiz saskārušies ar ClickHouse `Too many parts` kļūdu ievietošanas laikā? Kā to risinājāt?

Ar kurām Python bibliotēkām jūs strādājāt?

Pastāstiet vairāk par datu izliekumu starp shardiem: kā tas tika noteikts un kā tika izmantota atbilstošā funkcija/mekanisms?

Vai jūs esat iepazinies ar UDF (Lietotāja definētas funkcijas) ClickHouse, vai esat ar tām strādājis?

Kā jūs labojāt datu novirzi ar client_id, kad viens klients bija būtiski lielāks par pārējiem? Kādas ir iespējas?

Ar kādiem Distributed motora parametriem jūs esat iepazinies ClickHouse?

Kā jūs rīkotos ar Materialized View ķēdi caur starpposma ReplacingMergeTree tabulu, lai pareizi aizpildītu jau esošos datus pirms jaunas MV palaišanas?

Ar kuru Airflow versiju jūs strādājāt?

Kādās laukos notika datu apvienošana un kā tika izņemti dublikāti no vitrina?

Kā organizēt datu ielādi ClickHouse lielā PostgreSQL tabulā, kur pastāvīgi ienāk jauni ieraksti ar monotoniski pieaugošu primāro atslēgu?

Vai jūs pazīstat ReplicatedQueue? Vai jums ir pieredze ar tās izmantošanu?