DWH үшін Postgres пен ClickHouse: қашан қайсысын таңдау және енгізу

Коммерциялық DWH‑ты алмастыру қандай мәселені шешеді

Коммерциялық DWH жиі «өсу салығына» айналады. Деректер, пайдаланушылар және есептер көбейген сайын лицензиялар мен кеңею шығындары тез өседі. Соңында деректер моделінде өзгеріс енгізу немесе жаңа витриналар жасау — келісімдер, сатып алулар және техникалық терезелерді күтуге айналады, бизнеспен бірден жұмыс істеуге емес.

Ауыстыру әдетте open source үшін сәндіктен емес, бақылауды қайтару үшін қажет: компания деректерді қайда сақтауын, қалай масштабтауын, нені оңтайландыруын және нені төлеуін өзі шешкісі келеді — инфрақұрылым мен қолдауға емес, әр ядроға немесе қосымша модульге төлегісі келмейді.

Жаңа платформадан көбіне үш нәрсе күтіледі: аналитиканың болжамды жылдамдығы, түсініктілік (неліктен сұраныс жылдам немесе баяу екенін түсіну) және витриналарды дамытудағы икемділік. Тағы бір жиі себеп — тәуекелдерді төмендету: мерді өзгерту оңайрақ болсын және маңызды функция лицензиямен «жабық» болмауы керек.

Неліктен көбінде екі дерекқор жұбы таңдалады, біреу емес? Өйткені DWH‑та әдетте екі түрлі тапсырма болады. Біріншісі — деректерді жинап, тазалап, сәйкестендіріп, анықтамалар мен фактылар бойынша «шындықты» беру, мұнда транзакция мен шектеулер маңызды. Екіншісі — үлкен көлем бойынша ауыр аналитикалық есептерді тез есептеу, мұнда колонкалық сақтау мен тиімді агрегаттар қажет. Postgres пен ClickHouse осы рөлдерді бөлек жақсы жабады.

Күтуді бастапқыда оңайлату керек: ғажайып болмайды. Егер көздер «шулы», деректер иелері жоқ, метрикалар анықталмаған және жүктемелер сапа бақылаусыз өтсе, кез келген жұп да даулы сандар мен тұрақсыз өнімділік береді. Open source DWH тәртіп болғанда жеңіске жетеді: схема ережелері, витриналардың нұсқалануы, жүктемелерді мониторингі және өзгерістер процесі анық болса.

Postgres пен ClickHouse: рөлдерді оңай бөлу

Postgres + ClickHouse жұбы алдын ала рөлдер туралы келіссеңіз болжамды нәтиже береді. Осылайша бір СУБД‑ні бәрін бірден жасауға мәжбүрлемейсіз және жылдамдық пен сақтау құнындағы тосынсыйлар сирек болады.

Postgres әдетте «кіру аймағы» және ережелердің тұрған жері болады. Мұнда шикі деректерді (staging) жүктеу, типтерге келтіру, дубликаттарды тазалау, кілттерді тексеру, анықтамалардың тарихын жүргізу ыңғайлы. Ол транзакциялар, шектеулер және жаңартулар логикасы маңызды болған жерде жақсы.

ClickHouse аналитиканы алады: үлкен сканерлеулер, группировкалар, уақыт бойынша фильтрлер, кең факт кестелері және BI үшін жылдам есептер. Ол үшін деректер дайындалып, сұраныс кезінде көп жол оқуға ыңғайлы етіп орналастырылғаны оңай.

Типтік ағым осылай көрінеді: көздер (1С, CRM, биллинг, логтар) Postgres‑тегі staging‑ке түседі, онда нормализация және сапа бақылау өтеді, кейін фактылар мен витриналар құрылады да ClickHouse‑қа жүктеледі. BI мен аналитиктер негізінен ClickHouse‑тан оқиды, ал Postgres «басқару панелі» болып қалады: метадеректерді сақтайды және сандар қайдан алынғанын түсіндіруге көмектеседі.

Тіпті аналитика ClickHouse‑та болса да, Postgres‑та көбіне анықтамалар мен олардың нұсқаларын (контрагенттер, филиалдар, тауарлар), жүктеу метадеректерін (не, қашан, қай көзден), тапсырмалар кестесі мен статустарын, сапа ережелері мен нәтижелерін және тексерістер мен аудитке арналған қызметтік кестелерді қалдырған дұрыс.

Қарапайым мысал: филиалдар желісі күнделікті сатуды жібереді. Postgres‑та файлдың немесе пакеттің алынғанын тіркеп, толықтықты (барлық филиал есеп берген бе) тексеріп, тауар кодтарын нормализациялайсыз. ClickHouse‑та сату фактыларын кең түрде сақтап, күндер, категориялар және аймақтар бойынша есептерді секундтар ішінде есептейсіз.

Деректер витриналары: қашан Postgres, қашан ClickHouse

Деректер витринасы — жай аналитиктерге арналған кесте емес. Бұл бизнес өнімі: нақты сұрақтарға жауап береді, иесі бар және жаңартылу кестесі бар.

Жақсы витрина әдетте шешімдерге қажет нәрсені ғана енгізеді, «барлығын сақтап қою» емес. Алдын ала өрістер мен метрикалардың анықтамаларын ("табыстың" не екенін, "активті клиент" қай негізде өлшенетінін), гранулярлығын (күн бойынша, чек бойынша, клиент бойынша) және қосылу кілттерін бекіту пайдалы. Қайдан алынатынын және жаңартылу режимін (инкремент немесе қайта есептеу) түсіну және негізгі сапа бақылауы: сомалар, бос өрістер және дубликаттарға тексерулер — маңызды.

Postgres ыңғайлырақ, егер витрина операциялық деректерге жақын өмір сүрсе немесе жиі ұсақ өзгерістерді талап етсе: жолдарды қосу, статустарды жаңарту, анықтамаларды сақтау, тұтастықты қолдау. Типтік мысал — "клиент анықтамасы + келісімнің ағымдағы статусы" витринасы, мұнда жазбалар күн ішінде бірнеше рет жаңарталуы мүмкін.

ClickHouse жиі жеңіске жетеді, егер витрина негізінен оқуға арналған болса: үлкен таңбалар, группировкалар, период бойынша есептер, сегменттерді салыстыру және "шеңберлер" бойынша есептер. Мысалы, жүз миллиондары бар чектер бойынша сату витринасы, негізгі жүктеме — күндер, дүкендер және категориялар бойынша агрегаттар.

Postgres пен ClickHouse жұбында қарапайым ереже жиі жұмыс істейді: анықтамалар мен "ағымдағы күй" Postgres‑та қалады, ал фактылар мен ауыр аналитика ClickHouse‑қа шығады.

Витриналармен асыра сілтеуге оңай. Онда оншақты ұқсас кестелер пайда болады, иесі жоқ, және ешкім қайсысының «дұрыс» екенін білмейді. Витриналарды өнім ретінде басқару: иесін тағайындау, витрина қандай сұрақтарға жауап беретініне сипаттама жазу, анықтамалар мен көздерді құжаттау, дубли біріктіру немесе жабу — әлдеқайда дұрыс. Өзгерістер чаттағы өтінішпен емес, анық процесс арқылы өтуі керек.

Агрегаттар мен предрасчеттер: қай жерде ең үлкен әсер береді

Агрегаттар — бұл алдын ала есептелген жиынтықтар: күн бойынша табыс, апта бойынша операция саны, филиалдар немесе өнімдер бойынша көрсеткіштер. Postgres + ClickHouse жұбында олар жиі ең үлкен тиімділікті береді, өйткені пайдаланушы сұраныстарынан ең қымбат группировкаларды алып тастайды.

Агрегаттар ең қажет болатын жағдай — бірдей есептер жиі іске қосылады және бастапқы кестелер тез өседі. Мысалы, басшылар әр таңертең филиалдар бойынша кеше, апта және ай қорытындыларын көреді. Миллиардтаған жолды әр уақытта группировкалау тез қозғалтқыш болса да үлкен ресурстарды талап етеді және шыңдарда баяулауға әкеледі.

Жиі сұраныс сирек немесе деректер шағын болса, on‑the‑fly есептеу ақылға қонымды. Онда предрасчет қосымша витринаға айналып, оны қолдау мен түсіндіру қосымша ауыртпалық болады.

Предрасчеттерді мәңгілік ауыртпалыққа айналдырмау үшін инкременталдық қайта есептеуді ойластырыңыз. Барлық тарихты емес, тек жаңа кезеңді қайта есептеңіз. Көп жағдайда деректер күн бойынша жүреді, және әр күн тек кәмелетке жеткенше ғана (мысалы, кеше + кіші «хвост») қайта есептеледі.

Жұмыс балансы мынадай қарапайым ережелерге негізделсін: ең танымал 3–5 есепке арналған агрегаттар жасаңыз, нақты қолданылатын детализацияны сақтаңыз (күн, филиал, өнім), көрсеткіш формулаларын бекітіңіз, және деректер түзетілетін болса артқа қарай қысқа мерзімді қайта есептеу аймағын қосыңыз.

Агрегаттар неғұрлым көп болса, жылдамдық соғұрлым жоғары, бірақ қолдаудың құны да өседі. Аз, бірақ түсінікті және үнемі қолданылатын агрегаттар жақсы.

Аналитикалық сұраныстар: не жылдам, не баяу болатынын қалай анықтау

Postgres + ClickHouse жұбы сұраныстар сипатын алдын ала түсінгенде жақсы жұмыс істейді. Сыртында ұқсас көрінетін екі есеп әр түрлі мінез көрсете алады: бірі секундтарда есептеледі, екіншісі диск немесе желіге тіреліп қалады.

ClickHouse әдетте көптеген жолдарды оқып, нәтижені тез есептеу қажет болғанда жақсы болады. Типтік қолданулар: уақыт бойынша фильтрлер (күн, апта, ай), сатулар немесе оқиғалар бойынша топтар, воронкалар (қадам 1 -> қадам 2 -> қадам 3), бірінші әрекет күндері бойынша когорттық талдау. Оның күші — колонкалық агрегаттар мен үлкен сканерлеулер.

Postgres болжамдырақ болып келеді нүктелік сұраныстар мен кішігірім біріктірулер үшін. Мысалы, клиент карточкасын ашқанда 5–20 қатынасты жазбаны тарту немесе бірнеше шағын анықтаманы фактыларға қосу қажет болса, және деректер көлемі орташа болса.

Қолданбалы таңдау ережесі:

• ClickHouse: көп жолдарды оқу, кішкентай нәтиже қайтару, көп GROUP BY/COUNT/SUM периодтар бойынша.
• Postgres: кілттер бойынша нүктелік фильтрлер, жиі шағын JOIN, транзакциялық тексерулер мен түзетулер.
• Абай болу керек: алдын ала ойластырылмаған кілт пен деректер тәртібі жоқ үлкен кестелерді JOIN ету.
• Абай болу керек: агрегация орнына күрделі жолдық бизнес‑логика қолданатын сұраныстар.
• Әрдайым алдын ала: BI пайдаланушылар шынайы қандай өрістермен сүзетінін тексеріңіз.

Коммерциялық DWH‑тан көшіру кезінде ең қауіпті үлгі — әдеттегі ауыр JOIN‑дарды шикі үлкен кестелерге дәл көшіру. ClickHouse‑та бұл жиі ұзақ оқу және аралық нәтижелерді үлкейтуге әкеледі. Шешім — модельді өзгерту: тар факті кестелер, қажетті кілттерді бірге сақтау және анықтамаларды компактты ұстау.

Болжамсыздықтан аулақ болу үшін енгізу алдында нақты сұраныстарды жинаңыз: BI‑дан логтарды шығарып, 10–20 ең маңызды есепті сұраңыз, сүзгілерді (арнайы уақыт бойынша) және күтілетін жауап уақытын бекітіңіз. Содан кейін оларды тестілік көлемде іске қосып, не ClickHouse‑та есептеген дұрыс, а қайсысын Postgres‑та қалдыру керек екенін шешіңіз.

Дискілер, жад және желі талаптары: болжамсыз есептеу қалай жасауға болады

Postgres пен ClickHouse жұбы үшін аппараттық есептеулерді «қазір қанша дерек» емес, тапсырмалардан бастап есептеңіз. DWH көлемі әдетте бірнеше қабаттан өсе береді: шикі (staging), витриналар және агрегаттар, плюс ретеншн және бэкаптар.

Қарапайым шамалау:

• Шикі: орташа жолдың өлшемі x күндік жол саны x сақтау күндері.
• Витриналар: жиі шикіден 20–80% (нормализация мен дубликаттарға байланысты).
• Агрегаттар: әдетте 5–30%, бірақ барлық жағдайға арналған предрасчеттер витриналардан да үлкен болуы мүмкін.
• Қызметтік: Postgres‑тағы индекстер мен WAL, ClickHouse‑тағы бөліктер мен merge (көбінесе +20–50%).
• Өсу: кем дегенде +30% және бэкапқа орын бөлек.

Дисктің көлемі маңызды, бірақ жылдамдық жиі одан да маңызды. Сыну нүктелері — Postgres‑тағы WAL және индекстер, сондай‑ақ ClickHouse‑тағы фондық слияниялар мен енгізулер. Егер диск баяу болса, жүктеу барысында сұраныстардың «тісумен» баяулайтыны байқалады. Мұндай таршылықтарда тез SSD/NVMe және әртүрлі рөлдерге бөлек дисктер үлкен ұтым береді.

Желі жүктемелер, репликация, таратылған сұраныстар мен бэкаптар басталған кезде күтпеген жерден мәселе туғызады. Көбінесе тек "Күндегі ГБ" есептеліп, шыңдар ұмытылады: түнгі догрузкалар, витриналарды қайта есептеу және Postgres пен ClickHouse арасында деректер тасымалы. Егер желі тар болса, жүктеу ұзарып, түнгі есептеу терезі жұмыс уақытын жей бастайды.

Жад пен CPU да шектеулі болуы мүмкін. ClickHouse‑та группировкалар, сортировкалар және JOIN‑дар кенеттен жад тұтынуды өсіреді. Postgres‑та кэш, work_mem және параллелизм маңызды. CPU күрделі агрегаттарда және жоғары бәсекелестік болғанда шектеледі.

Практика қарапайым: резерв қалдырыңыз және пилотта өлшеңіз. Шынайы сұраныстармен жүктеу жылдамдығын, витриналарды қайта есептеу уақытын, сұраныс кешігулерін (merge, vacuum фонында), репликация мен бэкапқа желінің қорын, сондай‑ақ деректер 3–5 есе өскен кездегі деградацияны тексеріңіз.

Егер пилотты «шынайы» серверлерде жасасаңыз, нәтижелер нақтырақ болады, кездейсоқ виртуалкадағы тесттен гөрі. Мысалы, on‑prem сценарийінде S200 Series деңгейіндегі стойкалардан бастап есептеулер жүргізуге болады — GSE.kz тәжірибесі осындай.

Деректер және пайплайндар: алғашқы жүктеуге дейін не ойластыру керек

DWH‑тағы көп проблемалар Postgres не ClickHouse таңдауынан емес, деректерді қалай келісетініңізден басталады. Алғашқы жүктеуге дейін негізгі ережелер бекітілмесе, әрі қарай есептердегі сәйкессіздіктерді шешіп, витриналарды қайта-қайта өзгерте бересіз.

Бастапқыда схеманың арқауын анықтаңыз. Тұрақты кілттер қажет (атау, статус немесе филиалдан тәуелсіз), ортақ справочниктер және уақытқа қатысты ережелер. Мысалы, "күн" деген не: дерек көзінің уақыт белдеуіне қарай ма, орталық офис уақытын қолданамыз ба, әлде UTC па? Тіпті "кешегі күннің табысы" көрсеткіші әртүрлі жүйелерде күндерді басқаша бөлсе өзгеруі мүмкін.

Алдын ала бекітуге тиіс нәрселер

• Біртұтас идентификаторлар: клиент, келісім, өткізу нүктесі, құрылғы.
• Жалпы анықтамалар (ұйымдар, филиалдар, статустар) және олардың иелері.
• Уақыт келісімдері: уақыт белдеуі, күнтізбе, "бизнес‑күн", жабылу кешігіп келуі.
• Міндеттер шекарасы: қайсысы дерек көзінде есептеледі, қайсысы ETL/ELT‑те, қайсысы витринада.
• Өзгерістер ережелері: артқа түзетулер қалай өңделеді.

Содан соң жүктеу режимін шешіңіз: batch немесе near real‑time. "Шамамен онлайн" жиі өзінен қалаған секілді көрінеді, бірақ шынайы қажет тек шектеулі витриналар үшін (кезек мониторингі, fraud‑сигналдар, оперативті KPI). Қаржылық және басқарушылық есептеулер үшін әдетте сағат сайын немесе күнделікті пакет жүктеу жеткілікті болады: сапа мен тұрақтылықты осылай оңай бақылауға болады.

Сапа бақылауын пайплайнға кірістіру керек, оны кейін қолмен түзетуге қалдырмаңыз. Минимальді жиынтық: кілттер бойынша дубликаттар, міндетті өрістердің бос қалуы, келіп кешігу, көзбен салыстыру (кемінде сомалар мен есептер бойынша).

Есептеулер логикасы және бақылау

Показатель формулаларын нұсқалау керек: кім формуланы өзгертті, қашан, қандай даталар үшін әрекет етеді. Трансформация коды мен схема миграциясын бірге сақтап, өзгерістерді релиз ретінде шығару пайдалы тәжірибе.

Бақылауды бірінші күннен бастап орнатыңыз: жүктеу уақыты, көлемдер, қате саны, кешігіп келетін деректер үлесі, негізгі сұраныстар орындалу уақыты. Сонда істен шығулар тез көрініп, емес, басшыға есеп қажет болған кезде ғана байқалмайды.

Postgres + ClickHouse жұбын енгізудің кезеңдері

Бұл жұбты бірден «үлкен миграция» сияқты емес, қысқа, тексерілетін қадамдар сериясы ретінде енгізген дұрыс. Осылайша тарлықтарды (диск, желі, деректер моделі) ерте көруге болады және жүйені «көзбен» емес, нақты өлшемдерге салмайсыз.

Бастысы — нақты анықтау: бірінші күнде қандай есептер мен метрикалар жұмыс істеуі керек және қандай кешігу қабылданады (5 минут, сағат, тәулік). Тек есептер тізімін емес, типтік сүзгілерді де бекітіңіз: филиал бойынша, менеджер бойынша, период бойынша, өнім бойынша. Олардың өзі агрегаттардың қажеттілігін және партициялауды анықтайды.

Сосын деректерді көздер бойынша жіктеңіз: қайдан келеді, қаншалықты жиі жаңартылады, не маңызды (мысалы, қаржылық операциялар), қай жерде «кістьі» оқиғалар болуы мүмкін. Бұл жүктеу, дедупликация және сапа бақылау ережелерін бірден береді.

Жұмыс тәртібі әдетте мынадай:

1. Басты есептер тізімі мен сәттілік критерийлерін бекіту: жауап уақыты, жаңарту жаңалығы, дәлдік.
2. Көздер мен жаңартулар сипаттамасын жазу: кесте, кесте көлемдері, қай өрістер артқа түзетілетін болуы мүмкін.
3. Қабаттарды және иелерді таңдау: staging — шикі деректер, core — келісілген субъектілер, marts — витриналар және жауапты тұлғаларды тағайындау.
4. Бір доменде пилот жасау (мысалы, сату): витринаны Postgres‑та жинап, ауыр есептер мен топтауларды ClickHouse‑қа шығарып, тарлықтарды өлшеу.
5. Витриналарды кезек бойынша көшіру және ескі DWH бөліктерін сөндірудан бұрын параллель тексеру жүргізу.

Пилотта үш нәрсені өлшеңіз: жүктеу жылдамдығы, типтік сұраныстардың жауап уақыты және түзетулер келгенде қайта есептеудің «шығыны». Егер есептер филиал желісі бойынша жиі күні/қалаларға бөлінсе, уақытқа бөлініп және тарату кілттері алдын ала тексерілген болсын. Әйтпесе ClickHouse демода жылдам көрініп, нақты өмірде баяу болады.

Аяқтау кезеңі — ауыстыру жоспары: параллель есептеу периоды, негізгі метрикаларды салыстыру және өндірісте айырмашылық шықса қайтару жоспары.

Енгізу кезінде жиі болатын қателіктер және оларды болдырмау

Ең жиі қате — барлық деректерді бір үлкен кестеге салып, «аналитиктер өзі шешсін» деп қою. Соңында ешқандай анық витриналар мен жауапты тұлғалар болмайды, әр жаңа есеп қолмен жасалады және қай нәтисе дұрыс деген дау шығады.

Екінші тұзақ — тым ерте предрасчеттер жасау. Команда алдын ала оншақты предрасчет жасайды "барлық жағдайға" деп, бірақ кейін оның жартысы қолданылмайтын шығады. Бұл предрасчеттер ұзақ жаңартылып, жүктеу терезін бұзады. Қарапайым ереже: агрегат нақты бизнес сұрағына жауап беруі тиіс және оның иесі болуы керек.

Есептердің бұзылуына жиі себеп болатындар

Уақыт пен уақыт белдеулері айрықша проблема. Бір жүйеде уақыт локальді белдеуде, басқасында UTC‑та, ал витрина «көптеп келгендей» болса, күн бойынша есептер секіре бастайды. Мысалы, филиалдар локальді уақытпен күнді 20:00‑да жабады, аналитикада кейбір сатулар келесі күнге өтіп қалуы мүмкін.

Жаңарту стратегиясы да ойланбастан қойылса қауіпті. Postgres нүктелік жаңартуларға және анықтамаларға жақсы сәйкес келеді, ал ClickHouse‑та жиі жолдарды апдейттеу қымбат және сұраныстарды тежейді. ClickHouse‑қа енгізуді көбіне қосулар және партицияларды қайта есептеу түрінде жасаған дұрыс; түзетулер партициялар бойынша қайта есептелсін, тұрақсыз көптеген кіші жөндеулер арқылы емес.

Практикада қателіктерді болдырмау

Іске қоспас бұрын базалық ережелерге келісіңіз: әр витринаның иесі мен метрикалардың сипаттамасы бар, уақыт біркелкі сақталады (жиі UTC), локальді уақыт бөлек көрсетілген, жаңарту жоспары анық (қайсысы толық қайта есептеледі, қайсысы инкременталды, қайда кешігулер рұқсат етілген), жүктеу мен сапаны мониторингтеу орнатылған (жаңалық, сомалар бойынша тексерулер, аномалиялар) және әр өзгерістен кейін салыстырылатын «алтын» есеп бар.

Егер DWH‑ты филиалдары бар ұйымға енгізсеңіз, бір витринасынан бастаңыз (мысалы, күндік сату бойынша), оны тұрақты етіп шығарғаннан кейін ғана басқа домендерге таратыңыз. Жүйелік интеграция жобаларында (GSE.kz секілді) дәл витриналар тәртібі, уақыт пен сапа бақылауы жиі ең үлкен әсер береді, барлық нәрсені бірден "жылдамдату" әрекетінен гөрі.

Өнімге шығару алдындағы қысқа чек‑лист

Өнімге шығар алдында ең бастысы — жүйенің мәні мен шекаралары туралы келісімге келу. Тіпті күшті Postgres + ClickHouse жұбы әр түрлі командалар бір метриканы әр түрлі есептесе немесе қай жерде деректерді іздеу керектігін білмесе, тез-ақ «қаралып» қалады.

Есептерден бастаңыз. Нақты пайдаланатын негізгі дашбордтар мен шығару тізімін жасаңыз: қаржылық қорытындылар, сату, қор қалдығы, SLA, филиалдарға түсетін жүктеме. Әр элемент бойынша метрикалардың анықтамасын бекітіңіз (мысалы, «табыстылық» — төлем бойынша ма әлде жөнелту бойынша ма; «активті клиент» — соңғы 30 күн бе әлде календарлық ай ма) және бұл өзгерістерді растайтын иені анықтаңыз.

Содан соң қабаттық архитектураны тексеріңіз: шикі деректер қайда, витриналар қайда, агрегаттар қайда сақталатынын айқындаңыз. Әр өрістің қайсысы бірден «шын дерек қайнар көзі» екенін білу қажет. Жиі қате — витрина Postgres‑та кенеттен «жылдам» түрде әртүрлі жерлерден дерек тарта бастайды, ал айдан кейін ешкім сандарды қайталай алмайды.

Арнайы ретеншн мен сақтау ережелерін әр қабат бойынша бекітіңіз. Қатты жағдай — шикіні қайта ойнау үшін ұзақ сақтау, витриналарды бизнес қажеттілікке сай сақтау, агрегаттарды есептерді жылдамдату үшін сақтау. Алдын ала мерзімдер анықталмаса, дискілер күтпеген жерден таусылып, тазалау есептерді бұзуы мүмкін.

Деректер сапасы мен жүктемелерді бақылауды тексеріңіз: толықтық, дубликаттар және метрикалардың «секіру» үшін тексерулер бар ма; жүктеу кешігуі мен көлемнің кенет өсуі үшін ескерту бар ма; қай кесте және қай қадам істен шыққанын тез табуға мүмкіндік бар ма.

Соңында — пилотпен өлшеу. Шынайы, шектеулі деректер жиынтығында қабаттар бойынша диск өсімін, компоненттер арасындағы желі трафигін, типтік сұраныстардың уақытын және агрегаттарды қайта есептеу уақытын өлшеңіз. Егер нәтижелер күткендегіден әлдеқайда нашар болса, бұл әдетте витринаның гранулярлығын, партициялау схемасын немесе предрасчет стратегиясын өзгерту керектігін білдіреді, аппаратты «кездейсоқ» қосу емес.

Мысал сценарий: филиал желісі үшін есеп

Мысалы, 30–100 филиалы бар желіні елестетіңіз. Күн сайын басшылыққа бірдей көрсеткіштер қажет: табыс, чек саны, орташа чек, негізгі тауарлар тізімі, апта бойынша динамика. Көздер әртүрлі: касса, CRM, қойма, филиал және номенклатура анықтамалары. Деректер кейде кеш келеді, артқа түзетулер болады — қайтарулар мен статустар өзгереді.

Postgres пен ClickHouse жұбында рөлдерді бөлу ыңғайлы. Postgres staging пен анықтамаларды (филиалдар, категориялар, менеджерлер, топтау ережелері) сақтайды — сапаны бақылау, анықтамаларды нұсқалау және тексерулер осында оңай. ClickHouse дайын есептік витриналарды сақтайды, оқу мен агрегаттың жылдамдығы маңызды.

Осындай жағдайға практикалық агрегаттар жиынтығы — филиал және категория бойынша күндік сату, топтар үшін бөлек тауар бойынша күндік агрегат. Осылайша "кеше vs өткен жыл" немесе "аймақ бойынша топ‑20 категория" сияқты есептер миллиондаған чек жолдарын қайта есептемей, шағын кестелерден тез оқылады.

Жаңартуларды барлықты қайта есептемей ұйымдастырған дұрыс. Жалпы тәсіл: күнделікті жаңа деректер жүктеледі және тек соңғы N күн (мысалы, 7–14 күн) қайта есептеледі, өйткені дәл осы жерде ең жиі түзетулер мен қайтарулар келеді. Қалған тарих тұрақты деп есептеліп, өзгертілмейді.

Пилотта тек жылдам графикті емес, нәтижелердің қайталанбасын тексеріңіз: 5–10 типтік сұраудың мерзімі (филиал, аймақ, категория, топтар), күнделікті жүктеу және соңғы N күнді қайта есептеу уақыты, бірнеше басшы бір уақытта сұраныс жібергендегі мінез, егер жүктеу кешігіп жатса жедел «догоняние» қаншалықты жылдам болады және қате шыққанда оны есеп жібермей тұрып қалай анықтайсыз.

Егер инфрақұрылым on‑prem жоспарланып жатса, ClickHouse қайда орналасатынын және тез диск пен тұрақты желі қажеттілігін алдын ала қарастырыңыз, және 24/7 қолдау кімде болатынын анықтаңыз. Қазақстанда мұндай проекттер жиі жергілікті серверлерде және жергілікті сервиспен жасалады — мұнда GSE.kz сияқты жүйелік интегратор тәжірибесі пайдалы болуы мүмкін.

Келесі қадамдар: пилот, инфрақұрылым және қолдау

Postgres + ClickHouse жұбы «тағы бір аяқталмаған DWH» болмауы үшін нақты пилотпен бастаңыз — қазіргі кезде ең ауыртатын шынайы есептерді алыңыз: қай кестелер оқылады, қандай сүзгілер қолданылады, қай есептер минуттармен күтуге әкеледі.

Пилот үшін 1–2 домен таңдаңыз (мысалы, сату және қорлар немесе қаржы және төлемдер) және деректерді 3–6 айға дейін алыңыз. Осылай қай витриналарды Postgres‑та ұстау, ал қай ауыр агрегаттарды және ұзақ аналитикалық сұраныстарды ClickHouse‑қа беруге болатыны тез айқын болады.

Бастапқыда минимум SLA туралы келісіңіз, әйтпесе "жылдам" ұғымы әркімде әртүрлі болады. Екі көрсеткіш жеткілікті: деректер жаңартылу кешігі (мысалы, 15 минут сайын немесе күн сайын) және негізгі есептердің жауап уақыты (мысалы, типтік сүзгілер бойынша 5 секундтан артық емес).

Одан кейін инфрақұрылым мен эксплуатацияны жоспарлаңыз. Капацитетті "қазір" үшін емес, 12–24 айға өсіммен есептеңіз: деректер өсімі, пайдаланушылар саны, жаңа витриналар. ClickHouse жиі дискіге (жылдамдық пен көлем) және түйіндер арасындағы желіге тіреледі, Postgres — жазба IOPS пен сенімді бэкапқа.

2–6 аптаға практикалық жұмыс жоспары:

• 20–30 шынайы сұранысты жинау және витриналарға енгізілуі тиіс өрістер тізімін жасау.
• Жаңарту кешігі мен есептердің жауап уақыты бойынша SLA бекіту.
• 12–24 айға деректер өсімін шамалау және дискіге, жадқа резерв қалдыру.
• Жауаптыларды тағайындау: витриналар иесі, деректер сапасына жауапты, рұқсаттарды беретін адам.
• Негізгі эксплуатацияны орнату: мониторинг, бэкаптар, қалпына келтіру тесті, регламенттердің кестесі.

Егер командада интеграция мен дежурствоға адам жетпесе, сыртқы серіктес қосу мағыналы. Мысалы, GSE.kz өндірістік және жүйелік интегратор ретінде серверлерді таңдау, инфрақұрылым құру және тәулік бойы қолдау ұйымдастыруда көмектесе алады.