Data Engineer

ClickHouse-ში DDL/CREATE TABLE-ის დამატებითი პარამეტრები რომელი იცით, რა გავლენას ახდენენ და რა შემთხვევებში გამოიყენება?

როგორ შეიქმნა სია კლასტერში და როგორ გადაწყდა პრობლემა, როდესაც ZooKeeper-ის გამო შარდზე რეპლიკა არ იყო?

როგორ განაწილდეს მონაცემები ამ витრინაზე სამ shard-ზე: 50% პირველზე და 25% ორ სხვა-ზე?

როგორ წაიკითხეთ ზუსტად Parquet?

როგორ გადაჭრიდით ოპტიმიზაციის პრობლემებს, როდესაც სერვისი დიდხანს მუშაობს და სრულ სკანირებას ახორციელებს? როგორ მი 접근ებოდით ასეთ ახალ ამოცანას?

რა შემთხვევებში შეიძლება Materialized View-მა ClickHouse-ში მონაცემები გამოტოვოს ან, პირიქით, დუბლიოროდ გახდეს?

თქვენ ოდესმე შეხვედროდით ClickHouse `Too many parts` შეცდომას შეტანისას? როგორ გადაჭარით?

რომელი Python ბიბლიოთეკებით მუშაობდით?

გთხოვთ, მოგვიყევით მეტი მონაცემთა გადახრის შესახებ შარდებს შორის: როგორ განსაზღვრეს და როგორ გამოიყენეს შესაბამისი ფუნქცია/მექანიზმი?

შეგიძლიათ იცოდეთ ClickHouse-ის UDF (მომხმარებლის განსაზღვრული ფუნქციები), მუშაობდით მათთან?

როგორ გამოსწორდით მონაცემების გადახრა client_id-ის მიხედვით, როდესაც ერთი მომხმარებელი მნიშვნელოვნად მეტია დანარჩენებზე? რა ვარიანტები არსებობს?

რა პარამეტრებით ხართ გაცნობილი Distributed ძრავის in ClickHouse?

როგორ იმოქმედებდით Materialized View-ის ჯაჭვთან, რომელიც გადის ReplacingMergeTree-ის შუამავლობით, რათა სწორად შეავსოთ მონაცემები, რომლებიც უკვე არსებობდა ახალი MV-ის დაწყებამდე?

რომელი Airflow ვერსიით მუშაობდით?

მონაცემთა გაერთიანება რომელ ველებზე მოხდა და როგორ აღმოფხვრეს დუბლიკატები ვიტრინაში?

როგორ ორგანიზება გავაკეთოთ მონაცემების ჩატვირთვა ClickHouse-ში დიდ PostgreSQL-ის ცხრილში, სადაც მუდმივად მოდიან ახალი ჩანაწერები monotonically ზრდადი მთავარი გასაღვით?

გიცნობთ ReplicatedQueue-ს? გაქვთ მასთან მუშაობის გამოცდილება?