DATA LAKEHOUSE деген не
Қарапайым тілмен түсіндіремін — және неге бұл жай ғана «көл + қойма» емес
Автор: Александр Полоротов
Компания: Datanomix.pro
Оқу уақыты: ~15 мин
Сәлем, менің атым Александр Полоротов, datanomix.pro негізін қалаушылардың бірімін — және мен соңғы бірнеше жылда ірі бизнеске тағы бір деректер платформасы не үшін қажет екенін түсіндіріп жүрген адамдардың бірімін. Әрбір екінші әңгіме шамамен былай басталады: «Бізде Oracle, Hadoop, ELK, үш DWH және төрт data lake бар — бізге тағы бір нәрсе не үшін керек?» Және әр жолы мен сұхбаттасушының көзінен бірдей көзқарасты көремін — шаршау мен үміттің қоспасы.
Жақында бір банктің CTO-сы маған бір оқиға айтып берді. Олар екі жыл бойы «деректер көлін» (data lake) салған. Елеулі бюджет жұмсаған, 12 инженерден тұратын команда жинаған, жабдық сатып алған. Нәтижесі? Деректер ол жаққа құйылып жатыр — бірақ онда не жатқанын ешкім білмейді. Аналитиктер бұрынғысынша Oracle-ға барады. ML-инженерлер CSV-лерді қолмен жүктеп алады. Ал көл ақырындап батпаққа айналуда.
Спойлер: Data Lakehouse маркетологтар әдемі сөз ойлап тапқандықтан пайда болған жоқ. Ол data-инженерлер түнгі сағат 3-те пайплайндарды жөндеуден шаршағандықтан, ал бизнес «деректер ертең болады» дегенді естуден шаршағандықтан пайда болды. Егер сіз барлық деректерді S3-ке тастап, оны «көл» деп атау жеткілікті деп ойласаңыз — көңілі қалғандар клубына қош келдіңіз. Мұнда кофе және мағынасыздық сезімі беріледі.1-бөлім: Деректерді сақтаудың қысқаша және қайғылы тарихы
// 30 жыл бойы тербеліп келе жатқан маятник
Деректер индустриясында мені таң қалдыратын нәрсе: біз әр 10 жыл сайын бір идеяны қайта ойлап табамыз. Шынымен. Бұл суретке алыстан қараңыз — және сіз сызықтық прогрессті емес, екі шеткі нүктенің арасында тербеліп тұрған маятникті көресіз: «бәрін ретке келтірейік» және «бәрін бір үйіндіге тастайық, кейін түсінеміз».
1990-шы жылдар: Data Warehouse — каталогы бар элиталық қойма
Идея әдемі болды: компанияның барлық деректерін бір жерге жинау, тәртіп орнату, схемалар құру. Teradata, Oracle, IBM DB2 — бұлар деректер әлемінің Rolls-Royce-тары еді. Қымбат, салмақты және қызмет көрсетуде баяу.
Жұмыс істеді ме? Иә. Құрылымдалған деректер үшін — тамаша. Қаржылық есептер, сатылымдар, клиенттік база — бәрі таза, бәрі сөрелерде.
Мәселе? Екі жақты. Біріншіден, құны. Ірі банк үшін Teradata лицензиясы — бұл шағын стартаптың бюджеті. Екіншіден — икемсіздік. Жаңа деректер түрін қосқыңыз келе ме? Мархабат, өтінім толтырыңыз, 3 айдан кейін DBA схеманы жобалайды. Деректер бизнес жылдамдығымен түседі, ал қойма бюрократия жылдамдығымен өзгереді.
Және ең маңыздысы — жартылай құрылымдалған деректер (JSON, логтар, суреттер, видео) Data Warehouse-қа мүлдем сыймады. Физикалық емес — концептуалды түрде. Бұл мысықты аквариумға тығуға тырысқанмен бірдей: техникалық тұрғыдан мүмкін, бірақ бәрі бақытсыз болады.2010-шы жылдар: Data Lake — «бәрін таста, кейін түсінеміз»
Содан кейін Hadoop келді. Онымен бірге — қағаз жүзінде керемет көрінетін идея: қымбат қойма үшін неге төлеу керек? Барлық деректерді арзан үлестірілген қоймаға (HDFS, кейін S3) құя салайық. Құрылымдалған, жартылай құрылымдалған, құрылымдалмаған — бәрін бір үйіндіге. Кейін түсінеміз.
Не болғанын білесіз бе? «Кейін» ешқашан келмеді.
Gartner 2018 жылы есептеді: Data Lake жобаларының 60%-ы не сәтсіздікке ұшырады, не мәлімделген құндылықты бермеді. Деректер көлдері батпақтарға — data swamps-қа айналды. Деректер құйылды, бірақ каталогсыз, сапаны бақылаусыз, схемасыз. Нақты бір нәрсені табу бәрі бір-бірінің үстіне үйілген гараждан қажетті қорапты іздеумен бірдей болды.
Мен клиенттермен кездесулерде қолданатын метафора: Data Warehouse — бұл IKEA. Қымбат, бірақ бәрі каталог бойынша қойылған, көрсеткіштер мен бағалар бар. Data Lake — бұл гараж-сейл. Арзан, қазына кездесуі мүмкін, бірақ оны табу үшін — үш тонна қоқысты ақтару керек.2020-шы жылдар: Data Lakehouse — үшінші әрекет
Міне, біз осындамыз. Деректер индустриясы екі тәсілден де таяқ жеп, сұраққа келді: егер көлден арзан сақтауды алып, қоймадан тәртіпті қоссақ ше? Деректерді әрі-бері тасымалдамай, дәл сол жерде?
Бұл Data Lakehouse. Бірақ — және бұл маңызды — бұл жай ғана «көл + қойма = кәмпит үй» емес. Бұл деректермен жұмыс істеуге түбегейлі басқа көзқарас. Және оның неге маңызды екенін түсіну үшін, нақты ненің бұзылғанын анықтап алайық.
2-бөлім: Шын мәнінде не бұзылды
// мәселе деректерде емес — мәселе архитектурада
Мәселе деректердің көптігінде емес. Мәселе деректердің әртүрлі әлемдерде өмір сүруінде
2020-шы жылдарға қарай типтік enterprise-компания шамамен осылай көрінетін:
- Oracle / PostgreSQL — транзакциялық база, бизнестің негізі
- Teradata / Vertica / Snowflake — аналитика үшін DWH
- Hadoop / S3 — «қалғандары» үшін Data Lake
- Elasticsearch — іздеу және логтар үшін
- MongoDB — жартылай құрылымдалған деректер үшін
- Kafka — ағындық деректер үшін
- ML үшін тағы бір Feature Store
Жеті жүйе. Жеті команда. Жеті бюджет. Және — ең ауыры — бір деректердің жеті көшірмесі.
№1 Ауру: Деректердің қосарланған есебі
Бұл жай ғана сақтау құны мәселесі емес (бірақ ол да аз емес). Басты мәселе — сәйкессіздіктер. Бір деректер көл мен қойма арасында ETL-пайплайндар арқылы көшірілгенде, ерте ме, кеш пе сандар сәйкес келмей бастайды.
Міне нақты сценарий: CFO Power BI-да есепті ашады (DWH деректері), тоқсандық түсімді көреді. Маркетинг өз дашбордын ашады (Spark арқылы Data Lake деректері). Сандар сәйкес келмейді. Тергеу басталады. Data-инженерлер үш күн бойы жазбалардың қайда жоғалғанын іздейді. Табады: сәрсенбі түні пайплайн құлаған, 47 000 жол құйылмаған.
Мен мұндай сәйкессіздіктер қаржылық есептердің бір аптаға кешігуіне әкелгенін көрдім. Банкте. Сандарды күтіп отырған реттеушімен.№2 Ауру: ETL-тозақ
Anaconda зерттеуі бойынша (State of Data Science 2022), data-инженерлер жұмыс уақытының шамамен 40%-ын деректерді дайындауға, тазалауға және тасымалдауға жұмсайды. Талдауға емес. Модельдер құруға емес. Бір форматтан екіншісіне ауыстыруға.
Сонымен қатар ETL-пайплайндар — нәзік жаратылыстар. Олар дереккөз схемасының кез келген өзгеруінде, жүктемеде, кітапханалар жаңартылғанда бұзылады. Тәжірибелі әрбір data-инженер түнгі сағат 3-те «Pipeline failed» деген алерт келгендегі сезімді біледі. Және сіз таңертең бизнес жаңа деректерсіз қалатынын түсінесіз.
№3 Ауру: Бүгінгі шешімдер үшін кешегі деректер
Ең қауіпті мәселе. Деректердің классикалық жолы: дереккөз → Data Lake → ETL → Data Warehouse → BI-дашборд. Әр кезең кідіріс қосады. Деректер дашбордта пайда болған кезде, оларға бірнеше сағат, кейде тәулік өтіп кетеді.
Тоқсандық есеп үшін — жарайды. Нақты уақытта фродты анықтау үшін — апат. Ұсыныс жүйесі үшін — ақша жоғалту.
Сізде тоңазытқыш (warehouse) және қойма (lake) бар деп елестетіңіз. Әр жолы кешкі ас дайындау үшін алдымен қоймадан өнімдерді тоңазытқышқа тасып, сөрелерге қойып, содан кейін ғана дайындауды бастау керек. Ал дайындау кезінде өнімдердің жартысы балғын емес. Data Lakehouse — бұл қойманың өзі тоңазытқышқа айналған кез.3-бөлім: Data Lakehouse — шынайы көзқарас
// өнім емес, архитектуралық принцип
Бірден түсіну маңызды: Data Lakehouse — бұл сатып алып, орнатуға болатын нақты бағдарламалық жасақтама емес. Бұл архитектуралық тәсіл. «Микросервистер» сияқты — бұл өнім емес, жүйелерді құру тәсілі.
Lakehouse мәні үш қабатта:
- Арзан қойма — деректер объектілік қоймада жатыр (S3, MinIO, HDFS, Azure Blob). Data Lake-тегідей — ешқайда тасымалдамаймыз, арзан сақтаймыз.
- Метадеректер және тәртіп — файлдардың үстіне схеманы, ACID-транзакцияларды, нұсқалауды қамтамасыз ететін қабат қосылады. Data Warehouse-тағыдай — бірақ деректерді көшірмей.
- Есептеулер мен сақтауды бөлу — сұраныс қозғалтқышы (compute) қоймадан бөлек жұмыс істейді. Сол деректерге кез келген қозғалтқышты қосуға болады.
Бұл оқиғаның нағыз қаһарманы — Open Table Formats
Міне, ең қызығы осында. Егер сіз Data Lakehouse туралы басқа мақалаларды оқысаңыз, сізге әдемі архитектуралық схемалар салған шығар. Бірақ нағыз революция архитектурада емес, бір нақты технологияда болды: open table formats.
Apache Iceberg, Delta Lake, Apache Hudi — ойын ережесін шынымен өзгерткендер осылар. Бұл форматтар S3-тегі қарапайым файлдарға жетіспейтін нәрселерді қосты:
- ACID-транзакциялар — ешқандай «файл жартылай жазылды» жоқ
- Схема эволюциясы — кесте құрылымын қайта құрусыз өзгертуге болады
- Time travel — деректерді өткен кез келген сәтте сұрау мүмкіндігі
- Partition evolution — партициялау деректерді қайта жазусыз өзгереді
- Snapshot isolation — бір уақытта оқу және жазу, қақтығыссыз
Қатаң айтқанда, open table formats объектілік қоймадағы файлдар үйіндісін толыққанды дерекқорға айналдырды. Дерекқорсыз. Сиқыр сияқты естіледі, бірақ бұл жай ғана жақсы инжиниринг.
Аналогия: USB-C кабельдер әлемін қалай өзгерткені есіңізде ме? Бұрын әр құрылғының өз қосқышы болды: microUSB, Lightning, Mini-USB, меншікті порттар. USB-C — бұл бәріне арналған бір формат. Open table formats — бұл деректерге арналған USB-C. Кез келген қозғалтқышты қосуға болатын бір формат.Үш тәсілді салыстыру
| Критерий | Data Warehouse | Data Lake | Data Lakehouse |
|---|---|---|---|
| Деректер түрлері | Құрылымдалған | Кез келген | Кез келген |
| Сақтау құны | $$$ (SSD, проприетарные) | $ (S3/HDFS, open) | $ (S3/HDFS, open) |
| ACID-транзакциялар | Иә | Жоқ | Иә (Iceberg/Delta/Hudi) |
| ML/AI-жүктемелер | Нашар | Жақсы | Жақсы |
| BI/SQL-аналитика | Өте жақсы | Нашар | Жақсы — Өте жақсы |
| Деректер балғындығы | Кідіріс (ETL) | Real-time | Real-time |
| Vendor lock-in | Жоғары | Төмен | Төмен (open formats) |
| Governance/аудит | Жетілген | Әлсіз | Өсуде |
4-бөлім: Бес айқын емес артықшылық
// олар туралы әдетте үндемейді
Бірыңғай шындық нүктесі — сандар үшін корпоративтік соғыстардың соңы
Lakehouse-та деректер бір жерде өмір сүреді. Аналитик есеп құрады, ML-инженер модельді жаттықтырады, маркетолог дашбордты қарайды — бәрі деректердің бір физикалық көшірмесімен жұмыс істейді. Сәйкессіздіктер анықтамасы бойынша мүмкін емес.
Бұл техникалық дәлел емес — бұл ұйымдастырушылық. «Ал менде басқа сандар» тақырыбындағы жанжалдар саны нөлге дейін азаяды.Data-инженер ақыры түнде ұйықтайды
Аз жүйе = аз істен шығу нүктелері. Аз ETL-пайплайндар = аз түнгі алерттер. Аз деректер көшірмесі = аз рассинхронизация.
Менің тәжірибемде, Lakehouse-архитектураға көшу ETL-тапсырмалар санын 40-60%-ға қысқартады. Бұл data-инженерлер жұмыссыз қалады деген сөз емес — бұл олар ақыры өрт сөндірумен емес, инженериямен айналыса алады деген сөз.
Бөлек инфрақұрылымсыз AI/ML
Классикалық архитектурада ML үшін деректерді DWH-тан шығарып, түрлендіріп, Feature Store-ға жүктеп, содан кейін ғана модельге беру керек. Lakehouse-та ML-қозғалтқыш деректерді BI сияқты сол қоймадан тікелей оқиды.
Нәтиже: модель алдыңғы күнгі суретте емес, өзекті деректерде жаттығады. Fraud detection және ұсыныс жүйелері үшін — бұл «алаяқты ұстадық» және «екі күннен кейін байқадық» арасындағы айырмашылық.
Time travel — бәрі ұмытып кететін killer feature
Open table formats time travel қолдайды: деректерді өткен кез келген сәтте сұрау мүмкіндігі.
- Аудит: реттеуші «15 наурыз 14:00-дегі жағдайды көрсетіңіз» деп сұрайды — бір SQL-сұраныс
- Отладка: «Модель неге қателесе бастады?» — деректерді алдында және кейін салыстырамыз
- Compliance: банктер үшін — заң талабы
- Қателерді қайтару: бүлінген деректерді құйдыңыз ба? Секундтарда қайтару
Вендордан бостандық — және бұл ұран емес
Open table formats — бұл ашық стандарттар. Iceberg форматындағы деректерді Apache Doris, Spark, Trino, Flink, DuckDB, Snowflake — ондаған қозғалтқыштар оқи алады.
Сіз бір вендорға байланбағансыз. Сұраныс қозғалтқышы ұнамай ма? Деректерге тиіспей оны өзгертесіз. BI үшін бір қозғалтқыш, ML үшін басқасын қалайсыз ба? Мархабат. Деректер — сіздікі, сіздің қоймаңызда, ашық форматта.
Контекст үшін: Teradata-дан миграция — бұл әдетте 12-18 ай және сегіз таңбалы бюджет. Lakehouse-та қозғалтқыштар арасындағы миграция — бұл конфигті ауыстыру.5-бөлім: Бірақ нюанстар бар
// шектеулерге адал көзқарас
Бастапқы кіру қиындығы
Lakehouse-ты open-source компоненттерден жинау — бұл ДК-ні бөлшектерден жинау сияқты. Болады. Күшті. Бірақ құзыреттілікті талап етеді. Сізге қажет болады:
- Объектілік қойма (MinIO / S3 / HDFS)
- Open table format (Iceberg / Delta Lake)
- Сұраныс қозғалтқышы (Apache Doris, Trino, Spark)
- Метадеректер каталогы (Hive Metastore, Nessie)
- Governance құралдары (Apache Atlas, OpenMetadata)
Экожүйенің жетілуі
Apache Iceberg — жарайды, тез дамуда, 2026 жылға қарай де-факто стандартқа айналды. Бірақ айналасындағы экожүйе — governance, data quality, lineage — әлі қуып келеді.
Команда құзыреттілігі
Lakehouse storage, compute және data governance-ті түсінетін адамдарды талап етеді. Бұл классикалық DBA немесе ETL-әзірлеушіге қарағанда кеңірек T-shaped профиль.
Барлығына керек емес
Егер сізде PostgreSQL-де 10 ГБ деректер және Excel-де үш есеп болса — Data Lakehouse сізге керек емес. Шынымен. Бұл бір диванды тасымалдау үшін фура сатып алумен бірдей.
6-бөлім: Бұл кімге және қашан керек
// нақты профильдер
🏦 50+ ТБ деректері бар банк
Ағымдағы ауру: логтар — ELK-да, аналитика — Oracle Exadata-да, ML-модельдер (скоринг, антифрод) — бөлек кластерде. Үш жүйе, үш бюджет, үш команда.
Lakehouse-шешім: S3/MinIO-дағы бірыңғай қойма → Iceberg-кестелер → SQL-аналитика, толықмәтіндік іздеу және ML-фичалар үшін бір қозғалтқыш (Apache Doris / VeloDB).
Нәтиже: TCO-ны 40-60%-ға қысқарту, сағаттардың орнына секундтарда аудит, жаңа деректердегі ML-модельдер.
📡 Телеком-оператор
Ағымдағы ауру: нақты уақыттағы CDR, есеп беру үшін тарихи деректер, fraud detection лезде реакцияны талап етеді. Үш түрлі жүйе.
Lakehouse-шешім: ағындық ingestion (Kafka → Lakehouse) + тарихи аналитика + антифрод ML-модельдері — бәрі бір платформада.
Нәтиже: «бір тәуліктен кейін» орнына нақты уақытта фродты анықтау, реттеуші үшін бірыңғай дереккөз.
🛒 E-commerce
Ағымдағы ауру: ұсыныстар (ML) маркетинг есептерінен (BI) бөлек өмір сүреді, ал логтар мен observability — үшінші жүйеде. Маркетинг сандарға сенбейді.
Lakehouse-шешім: барлық деректер бір жерде. Ұсыныс моделі маркетингтік есептер құрылатын деректерде жаттығады.
Нәтиже: өзекті деректердегі ұсыныстар, маркетинг сандарға сенеді, инфрақұрылымдық бюджет — біреу.
🏛️ Мемлекеттік құрылым
Ағымдағы ауру: «Дербес деректер туралы» заң талаптары (Қазақстан — ҚР Заңы №94-V, Өзбекстан — ЎзР Қонуни №547), аудит, қолжетімділікті бақылау. Деректер ел аумағында сақталуы керек. Vendor lock-in — стратегиялық тәуекел.
Lakehouse-шешім: өз серверлеріндегі open-source стек (on-premise). Apache Iceberg + Apache Doris — бәрі ашық, бәрі бақылауда.
Нәтиже: деректерді толық бақылау, заңнамаға сәйкестік, батыс вендорларынан тәуелсіздік.
Формула: сізге Lakehouse керек пе?
Егер 5-тен кем дегенде 3-еуі — «иә» болса, байыпты ойлану керек:
- ☐ Деректер 1 ТБ-дан көп (және өсуде)
- ☐ Жүктеменің бір түрінен көп (BI + ML, немесе BI + іздеу)
- ☐ Бірнеше команда қиылысатын деректермен жұмыс істейді
- ☐ Data-команда бюджетінің >30%-ын деректерді тасымалдауға жұмсайсыз
- ☐ Аудитке, compliance немесе data governance-ке талаптар бар
Қорытынды, сусыз
Data Lakehouse деген не: Data Lake (арзан сақтау) және Data Warehouse (тәртіп пен транзакциялылық) артықшылықтарын жүйелер арасында деректерді көшірмей біріктіретін архитектуралық тәсіл.
Неге: бірыңғай шындық нүктесі, аз пайплайндар, жаңа деректер, бір платформада BI және ML, аудит үшін time travel, vendor lock-in-нен бостандық.
Қашан керек: егер деректер >1 ТБ болса, жүктемелердің бірнеше түрі, бірнеше команда, compliance талаптары болса.
Қашан керек ЕМЕС: егер деректер аз болса, бір команда, тапсырмалардың бір түрі болса және ағымдағы шешім жарап тұрса.
Әрі қарай не істеу керек: ағымдағы архитектура аудитінен бастаңыз. Әртүрлі жүйелерде бір деректердің қанша көшірмесі бар екенін санаңыз. Егер екіден көп болса — сізде Lakehouse үшін бизнес-кейс бар.
Жиі қойылатын сұрақтар
Data Lakehouse Data Warehouse-тан немен ерекшеленеді?
Data Warehouse құрылымдалған деректерді қымбат меншікті форматта қатаң схемамен сақтайды. Data Lakehouse кез келген деректерді арзан объектілік қоймада (S3) open table formats арқылы сақтайды, олар сол кепілдіктерді береді: ACID, схема, governance. Басты айырмашылық — Lakehouse деректерді көшіруді талап етпейді және бір вендорға байламайды.
Data Lakehouse Data Lake-тен немен ерекшеленеді?
Data Lake — бұл тәртіпсіз файлдар қоймасы: транзакциялар жоқ, схема жоқ, нұсқалау жоқ. Data Lakehouse сол файлдардың үстіне metadata layer (Iceberg, Delta, Hudi) қосады, ол «файлдар үйіндісін» ACID-транзакциялары, time travel және қолжетімділікті бақылауы бар толыққанды басқарылатын жүйеге айналдырады.
Бар DWH-ты тастау керек пе?
Жоқ. Lakehouse-қа көшу — бұл көбінесе революция емес, эволюция. Жаңа деректер мен жүктемелерден бастап, бар жүйелерді біртіндеп миграциялауға болады. Көптеген компаниялар біраз уақыт гибридті режимде жұмыс істейді.
Қандай open table format таңдау керек?
2026 жылға қарай Apache Iceberg де-факто стандартқа айналды: оны AWS, Google, Snowflake, Databricks, Apache Doris және ондаған басқа жүйелер қолдайды. Delta Lake — Databricks экожүйесіндегі күшті екінші нұсқа. Hudi — ауыр upsert бар арнайы сценарийлер үшін тауашалық шешім.
Lakehouse-қа көшу қанша тұрады?
Ауқымына байланысты. 5-10 ТБ деректерге арналған пилотты 2-3 инженерден тұратын командамен 2-4 аптада іске қосуға болады. Бірақ инфрақұрылымды үнемдеу әдетте инвестицияны бірінші жылы ақтайды.
LAKEHOUSE СІЗДІҢ ЖАҒДАЙЫҢЫЗДА ҚАЛАЙ ЖҰМЫС ІСТЕЙТІНІН ТҮСІНГІҢІЗ КЕЛЕ МЕ?
> Консультация тегін, міндеттемелер жоқ
./КОНСУЛЬТАЦИЯҒА_ТАПСЫРЫС_БЕРУ.shАрхитектура, қолдану сценарийлері, негізгі мүмкіндіктер. 5000+ компания production-да.
SuperSet, PowerBI, Tableau баяу ма? Sub-100ms, Auto Query Rewrite, тегін пилот.
MySQL Protocol, үш DAG паттерні, Stream Load. Job Scheduler vs Airflow.
Kafka -> Doris: standalone/distributed, SSL, DLQ, schema evolution және best practices.
Дереккөздер және қосымша оқу
- Armbrust, M. et al. "Lakehouse: A New Generation of Open Platforms" — Databricks-тің түпнұсқа мақаласы, 2021
- Apache Iceberg — құжаттама — стандартқа айналған open table format
- State of Data Science 2022 — Anaconda — data-мамандардың уақыты туралы зерттеу
- Zhamak Dehghani, "Data Mesh" — деректерді ұйымдастыруға балама көзқарас
- Ben Stancil, benn.substack.com — data-индустрия туралы ең адал блогтардың бірі