ON-PREMISE · DATA WAREHOUSE · BI + AI

Дата агуулах, дээр нь BI ба AI

Байгууллагын үйл ажиллагааны системүүдээс өдөр бүр татаж, цэвэрлэж, бизнесийн хэлээр загварчилсан нэг агуулах. Дээр нь дашбоард, сэрэмжлүүлэг, асуувал хариулдаг AI. Дотоод серверт, нээлттэй эх технологиор, хоёр аналистын багаар авч явах боломжтой.

Хэрэгжүүлэх төлөвлөгөө Давхаргын бүтэц

Үйл ажиллагааны системэх сурвалж On-premiseбайршил 6–8 долоо хоногэхний ажиллах дашбоард $0лицензийн зардал

01 · ТОДОРХОЙЛОЛТ

Дата агуулах гэж юу вэ?

Тайлан гаргахын тулд баригдсан, тусдаа ажилладаг өгөгдлийн сан. Эх системийн хуулбар биш — асуулт хариулахаар дахин зохион байгуулагдсан хэлбэр.

Нэг газар

Бүх эх сурвалж нэгддэг

Нягтлан бодох бүртгэл, санхүү, агуулах, борлуулалт, Excel, гараар хөтөлдөг лавлах — бүгд нэг санд, нэг цагийн бүсэд, нэг нэршилтэйгээр. «Аль файл нь хамгийн сүүлийнх вэ» гэдэг асуулт алга болно.

Түүхтэй

Өчигдрийн үнэн хадгалагдана

Үйл ажиллагааны систем нь одоо-г хадгалдаг: үнэ өөрчлөгдвөл хуучин нь дарагдана. Агуулах нь өөрчлөлт бүрийг үлдээдэг тул «өнгөрсөн сард ямар үнээр зарсан бэ» гэдэг хариулттай.

Тусдаа

Эх системийг удаашруулахгүй

Аналистын хүнд query нь нягтлангийн системд хүрэхгүй. Агуулах өөрийн сервер дээр, өөрийн ачаалалтай — тэр хоёр хэзээ ч хоорондоо өрсөлдөхгүй.

Тодорхойлолттой

Нэг үзүүлэлт — нэг томьёо

«Борлуулалт» гэж юу вэ гэдэг нь кодод бичигдсэн, хүн бүрийн Excel дээр биш. Хоёр хэлтэс өөр тоо авчрах нөхцөл нь ингэж арилдаг.

Энэ нь эх системийн нөөц биш. Нөөцлөлт нь сэргээхэд зориулагдсан; агуулах нь асуухад зориулагдсан.

Энэ нь дашбоардын хэрэгсэл биш. Metabase бол дээр нь тавигдах цонх; агуулахгүй бол тэр цонх шууд эх систем рүү харна.

Энэ нь «том дата» биш. Байгууллагын хэмжээний дата PostgreSQL дээр багтана. Асуудал нь эзлэхүүн биш, тодорхойлолт.

Дата агуулахын төслүүд технологиос болж унадаггүй. «Борлуулалт» гэж юуг хэлэх вэ гэдэг дээр хоёр хэлтэс өөр өөр ойлголттой байснаас унадаг. Тиймээс эхний алхам сервер захиалах ч биш, tool сонгох ч биш — 10–15 үзүүлэлтээ томьёо, эх сурвалж, эзэмшигчтэй нь бичгээр тодорхойлох.

02 · АРХИТЕКТУР

Давхарга бүр нэг ажилтай

Өгөгдөл доороос дээшээ урсана. Давхарга бүр өөрийн ганц асуултад хариулна.

Эх сурвалж

Нягтлан бодох бүртгэл, санхүү, агуулах, борлуулалтын систем, Excel файл, гараар хөтөлдөг лавлах хүснэгт.

MSSQLPostgresOracleExcel

Ingestion — татаж авах

Эх системийн read replica-аас өдөр бүр зөвхөн шинэчлэгдсэн мөрийг татна. Ажиллаж байгаа production DB-д шууд хэзээ ч ханддаггүй.

dltAirbyte OSS

Raw — хөндөөгүй хуулбар

Эх системээс ирсэн чигээрээ, зөвхөн нэмэгдэнэ. Ачаалсан огноог тэмдэглэнэ. Гараар хэзээ ч засахгүй.

schema-per-sourceappend-only

Staging — цэвэрлэгээ

Төрөл тааруулах, нэр стандартчлах, давхардал арилгах, NULL зохицуулах. Бизнес логик энд орохгүй.

dbt modelsdbt tests

Mart — бизнесийн загвар

Star schema: fact_sales, dim_customer, dim_product, dim_date. Аналист шууд уншиж чадах нэршил.

dbt modelsSQL

Semantic layer — үзүүлэлтийн тодорхойлолт

KPI бүрийн томьёо ганц газар. BI ба AI хоёул эндээс уншина. AI-ийн нарийвчлалын түлхүүр энэ давхарга.

Cube CorePostgres-wire SQL API

Хэрэглэгчийн давхарга

Дашбоард, тайлан, AI чат, сэрэмжлүүлэг, экспорт.

MetabaseAI chatEmail alert

Давхарга алгасахыг хориглоно. BI хэрэгсэл Raw давхаргаас шууд уншиж болохгүй. Энэ ганц дүрэм л системийг хоёр жилийн дараа ч ойлгомжтой байлгана.

Оркестраци — Dagster / cron Засаглал — тест · git · нөөцлөлт · хандалт

03 · СОНГОЛТ

Бүгд нээлттэй эх

Лицензийн төлбөр $0. Бодит зардал бол техник хангамж ба цалин.

Давхарга	Сонголт	Хувилбар	Яагаад
Агуулах DB	PostgreSQL 18	ClickHouse	Багийнхан аль хэдийн мэддэг. Байгууллагын хэмжээний дата (<500 GB) дээр хангалттай хурдан. Дашбоардын query 10 сек давах, эсвэл 1 TB давахад ClickHouse руу шилжинэ.
Ingestion	dlt	Airbyte OSS	Python сан — тусдаа сервер шаардахгүй, код нь git-д орно. Airbyte нь UI-тай ч 4–8 GB RAM нэмж иднэ.
Хувиргалт	dbt-core	—	Энэ дээр буулт хийхгүй. Зөвхөн SQL бичнэ, гэхдээ тест, баримтжуулалт, lineage, хувилбарын хяналт дагалдана.
Оркестраци	cron → Dagster	Airflow	Эхний 2 сар `cron + dbt run` хангалттай. Pipeline 10-аас олон болоход Dagster руу шилжинэ.
BI	Metabase	Apache Superset	Контейнер асаснаас эхний дашбоард хүртэл ~10 минут; техникийн бус хүн өөрөө асуулт үүсгэнэ. Мөр түвшний эрх үнэгүй хэрэгтэй бол Superset.
Semantic layer	Cube Core	dbt MetricFlow	Cube Core (Apache 2.0) нь Postgres протоколоор SQL API гаргадаг тул Metabase түүнийг ердийн DB мэт хардаг. MetricFlow-ийн хөдөлгүүр үнэгүй ч BI холбох API нь зөвхөн төлбөртэй dbt Cloud дээр.
ML	statsforecast · LightGBM	Prophet	Таамгийг Python-оор бодоод үр дүнг `mart_forecast_*` хүснэгтэд буцааж бичнэ — BI дээр бодит гүйцэтгэлийн хажууд харагдана.
Код хадгалалт	Gitea	GitLab CE	dbt код, dlt скрипт, тохиргоо бүгд git-д. 1 GB RAM-д ажиллана. Энэгүйгээр 6 сарын дараа хэн юу өөрчилснийг мэдэхээ болино.

Phase 1–2 · эхлэл

1 сервер

8–16 vCPU · 64 GB RAM · 2 TB NVMe (RAID 1). Docker Compose дээр Postgres, dbt, Metabase, Gitea бүгд нэг машин дээр. Ubuntu Server LTS.

Phase 3+ · өргөтгөл

2 сервер + нөөцлөлт

DWH сервер — зөвхөн Postgres. App сервер — Metabase, Dagster, Gitea. NAS эсвэл tape — өдөр тутмын нөөц, өөр байранд.

Зөвхөн локал LLM-д

GPU сервер

48–96 GB VRAM. 48 GB-д 30B загвар зөвхөн quantized хэлбэрээр багтана. Заавал биш — §04-ийн шийдвэрээс хамаарна.

Анхаар. 2026 оны DDR5 ECC санах ойн хомсдолоос болж серверийн RAM жилийн өмнөхөөс ~2 дахин үнэтэй болсон — 2025 оны үнээр төсөвлөж болохгүй. Нэг хүн цагийнхаа 60–70%-ийг өгвөл энэ төлөвлөгөө биелнэ; хэн ч бүтэн эзэнгүй бол төсөл гурав дахь сард зогсоно.

04 · AI ДАВХАРГА

Цэвэр агуулахгүйгээр утгагүй

Хамгийн түгээмэл алдаа: цэвэрлэгээгүй дата дээр AI чат тавьж, итгэлтэй өнгөөр буруу тоо хэлүүлэх. Тиймээс L4 mart болон L5 semantic layer бэлэн болтол AI-д гар хүрэхгүй.

84–90%

Шууд text-to-SQL — загвар schema-г уншаад өөрөө SQL бичих.

Санал болгож буй зам 98–100%

Semantic layer дундуур — загвар зөвхөн тодорхойлсон үзүүлэлтийг дуудна.

~15%

Text-to-SQL үнэмшилтэй харагдах буруу хариу өгөх магадлал — алдаа нь чимээгүй.

Гол ялгаа нь нарийвчлал биш, алдах хэлбэр. Semantic layer алдвал «ийм үзүүлэлт алга» гэж ил хэлнэ. Text-to-SQL алдвал зөв харагдах тоо буцаана — хүн үүнийг удирдлагын хуралд аваачина.

LLM-ИЙН БАЙРШИЛ

On-prem-ийн гол шийдвэр

Хувилбар А

API + зөвхөн metadata

Гадаад загвар руу зөвхөн хүснэгтийн бүтэц, багана, үзүүлэлтийн тодорхойлолт явна. Бодит мөр гадагшилахгүй, SQL нь дотоод серверт ажиллана. Хамгийн хямд, хамгийн нарийвчлалтай.

Хувилбар Б

Бүрэн локал загвар

Qwen / Llama ангиллын 30B загвар GPU сервер дээр. Юу ч гадагш гарахгүй. Нарийвчлал доогуур, GPU-д $5–7k, тохируулга удаан. Банк, төрийн байгууллагад л зайлшгүй.

Хувилбар В

Холимог

Мөр датад хүрэх алхмыг локал загвараар, зөвхөн schema хардаг алхмыг API-аар. Хамгийн уян хатан ч хамгийн олон эд анги — багийн чадавх бэхжсэн хойно.

Дараалал. Аномали илрүүлэлт (хамгийн хялбар) → semantic layer дээрх асуулт-хариулт → таамаглал ба churn (хамгийн хүнд). ML-ээр бүү эхэл: өдөр тутмын KPI цуваа дээр STL задаргаа + robust z-score хангалттай.

05 · ТӨЛӨВЛӨГӨӨ

Үе шат бүр ажиллаж байгаа зүйл гаргана

Хугацаа нь ойролцоо; дуусгах шалгуур нь тодорхой.

Phase 02–4 долоо хоног

Тодорхойлолт ба бэлтгэл

10–15 KPI-г томьёо, эх сурвалж, эзэмшигчтэй нь бичих
Эх системийн хүснэгтийн бүртгэл, эзлэхүүн, өсөлтийн хурд хэмжих
Эх систем дээр read replica тохируулах эсвэл шөнийн цонх тохирох
Сервер захиалах, Ubuntu + Docker бэлдэх, Gitea босгох

Дуусмагц Гарын үсэгтэй KPI баримт бичиг, ажиллаж байгаа сервер, хоосон git repo.

Phase 14–8 долоо хоног

Эхний урсгал, эхний дашбоард

dlt-ээр 5–8 гол хүснэгтийг өдөр бүр Raw давхаргад татах
dbt: staging загварууд + эхний 3 mart (борлуулалт, харилцагч, бараа)
Metabase суулгаж, Phase 0-д сонгосон гар тайланг орлуулах дашбоард
cron дээр өдөр тутмын ажиллагаа, амжилтгүй болвол имэйл

Дуусмагц Өмнө нь 1–2 хүн-өдөр иддэг байсан нэг тайлан өглөө бүр өөрөө шинэчлэгддэг болсон. Энэ мөч төслийн үлдсэн төсвийг шийднэ.

Phase 22–3 сар

Найдвартай байдал ба өргөтгөл

dbt тест 30+ (uniqueness, not-null, relationship, тоон хязгаар)
Түүх хадгалах загвар (SCD2) — үнэ, ангилал өөрчлөгдөх лавлахуудад
Incremental ачаалалт — бүтэн дахин ачаалалтаас салах
Нөөцлөлт + сэргээх дасгал, хандалтын эрхийн бүтэц

Дуусмагц Өдөр бүр бүх тест ногоон, гар оролцоо тэг, аль ч тоо хаанаас гарсныг lineage-аар харуулж чадна.

Phase 31–2 сар

Semantic layer ба сэрэмжлүүлэг

KPI-уудыг Cube Core дээр нэг удаа тодорхойлж, Metabase-ийг Cube-ийн SQL API руу холбох
5–10 үзүүлэлт дээр аномали илрүүлэлт, босго тохируулга
Имэйл / Slack сэрэмжлүүлэг, хүлээн авагч бүрт эзэмшигч

Дуусмагц Нэг үзүүлэлт нэг л газар тодорхойлогдсон; сэрэмжлүүлгийн худал дохио 20%-иас доош.

Phase 42–3 сар

AI чат ба таамаглал

LLM байршлын шийдвэр — мэдээллийн аюулгүй байдлын журмын зөвшөөрөл
Semantic layer дээр суурилсан асуулт-хариулт, 20 сорилын багц
Борлуулалтын таамаг → mart_forecast_sales → дашбоард дээр гүйцэтгэлийн хажууд
Churn загвар (харилцагчийн 24+ сарын түүх байгаа бол)

Дуусмагц Сорилын 20 асуултад 100% зөв хариулна; таамаг нь улирлын baseline-ыг тодорхой давсан.

06 · СЭРЭМЖ

Төсөл унагаадаг найман зүйл

Урьдчилан мэдэж байвал зайлсхийж болно.

Tool-оос эхлэх

Үзүүлэлтээ тодорхойлохоос өмнө технологи сонгох. Гурван сарын дараа «энэ тоо яагаад санхүүгийнхтэй таарахгүй байна вэ» гэсэн асуултаас гарч чадахгүй.

Ажиллаж байгаа системд шууд хандах

Аналистын хүнд query нь нягтлан, санхүүгийн системийг удаашруулна. Нэг удаа тохиолдвол IT хэлтэс хаалгыг бүрмөсөн хаана. Replica эсвэл шөнийн цонх заавал.

«Хэрэг болж магадгүй» гэж бүгдийг татах

300 хүснэгт татсан ч 12 нь л хэрэглэгдэнэ. Үлдсэн нь зөвхөн диск, засвар үйлчилгээ иднэ. Асуултаас ухраад хэрэгцээт хүснэгтээ ол.

Тестгүй pipeline

Итгэл нэг л удаа буруу тоо гарахад алдагдана, буцаад сэргэдэггүй. dbt тест бол нэмэлт биш, суурь.

Цэвэр агуулахгүйгээр AI

Эмх замбараагүй дата дээрх AI бол хамгийн үнэтэй буруу хариултын машин. Дараалал: mart → тест → semantic layer → AI.

Эзэнгүй дашбоард

Дашбоард бүрд нэр бүхий эзэмшигч байх. Зургаан сар хэн ч нээгээгүй дашбоардыг устга — тэдгээр нь буруу тоогоор эргэлдэж хор хийнэ.

Git-гүй, нөөцгүй

Серверийн дискэн дээр л байгаа SQL код бол цаг хугацааны бөмбөг. Сэргээж үзээгүй нөөц ч мөн адил — сэргээж үзээгүй нөөц бол нөөц биш.

Бүтэн дахин ачаалалт

Эхэндээ 5 минут, жилийн дараа 6 цаг. Phase 2-т заавал incremental болго — дараа нь хийхэд илүү үнэтэй.

07 · ЭХЛЭЛ

Эхний 30 хоног

Маргаашаас эхлэх дараалал. Эхний долоо хоногт нэг ч мөр код бичихгүй — бичих ёстой зүйл нь тодорхойлолт.

1 дэх 7 хоног

KPI-ийн семинар

Санхүү, борлуулалт, үйл ажиллагааны хүмүүсийг нэг өрөөнд оруулж, 10–15 үзүүлэлтийг томьёотой нь бич. Санал зөрсөн газрыг тэмдэглэ — тэр яг л агуулах шийдэх ёстой асуудал.
1 дэх 7 хоног

Гар тайлангийн аудит

Одоо хэн, ямар тайланг, хэдэн цагаар гаргадгийг бүртгэ. Хамгийн их цаг иддэгийг Phase 1-ийн бай болго.
2 дах 7 хоног

Эх системийн бүтцийг ухах

Хэрэгтэй 5–8 хүснэгтийг ол, мөрийн тоо, өсөлт, updated_at-ийг шалга. IT-тэй read replica-ийн талаар ярь.
2 дах 7 хоног

Сервер захиалах

16 vCPU / 64 GB / 2 TB NVMe. Хүргэлт ихэвчлэн 2–4 долоо хоног — эрт эхэл.
3 дах 7 хоног

Laptop дээр прототип

Docker дээр Postgres + dbt + Metabase босгож, эх системийн нэг хүснэгтийн CSV экспортоор бүтэн замыг туршиж үз. Нэг өдрийн ажил, олон эргэлзээг арилгана.
4 дэх 7 хоног

Сервер тохируулах

Ubuntu, Docker Compose, Gitea, Postgres, өдөр тутмын pg_dump. Эхний dlt урсгалыг ганц хүснэгт дээр ажиллуулж, Raw давхаргад буулга.
4 дэх 7 хоног

Багийн үүрэг тодорхойлох

Аль аналист dbt эзэмших, хэн Metabase-ийн эзэн болох. Долоо хоног бүрийн 30 минутын демо тогтоо — үзүүлэх зүйлгүй долоо хоног бол дохио.