Google Next 2026 для інжынерыі даных: Looker, BigQuery і MCP-серверы
Што Google Cloud Next 2026 азначае для інжынерыі даных на Looker і BigQuery: агенты, семантычны пласт LookML, кіраваныя MCP-серверы і Knowledge Catalog.
Крыніцы: Google Next 2026: What’s New for Looker, BigQuery, Data Platforms and Agentic Analytics
Канферэнція Google Cloud Next 2026 у Лас-Вегасе працавала у масштабах, які пасуюць да самай маркі, з ключавымі прымовамі і сесіямі, распадзеленымі па вялічзенай арэне. Для тых, хто рэалізуе праекты на базе Looker чыра BigQuery, найболей значнымі былі сесіі па аналітыцы, інтэграцыі дадзеных і агентскай аналітыцы. Далейшы частка апранае анунсаванні, якія магчымае змяніць падход да адклекчэння такіх заданняў прыблізна за наступныя дванаццаць месцацоў, а таксама прыводзіць увагу да урокаў, выведзеных з размоваў з кліентамі, якія выявіліся корыстнейшымі за большасць новых спактаваў пра продукты.
Канцэпцыя: ад адпаведзення да дзеяння
Абшчая ідэя Google для платформ аналітыкі і дадзеных — пераход з "сістэмы інтэлігэнціі" да "сістэмы дзеяння". Першая — гэта рэактыўная BI, якая адпаведзае на запыткі. Другая — гэта сукупнасц праактыўных агентаў, якія сочыць за показнікамі, падсумоўваюць атрыбуты, якія знаходзяць, і дзейнуюць зарады бізнесу.
Нічога з гэтаго не ў новасці. Апавешчэнні, якія выклікаюцца падзеямі, і аўтаматызаваныя адпаведзі ў інструментах аналізу дадзэнняў для корпаратыўных аб’ектаў існуюць вясьмадзесят годзін. Тым не менш, паўторны акцэнт на гэтыя аспекты мае практычны эфект, адтаму што ён змінюе тое, што ўключаецца ў межы праекта развіцця Looker, запускаемага у 2026 годзе.
Для тых, хто піша опіс задач, выліваецца практычны наследак. Раней усім, што мяло быць выдана, былі справаздачы і панелі керування. Цяпер неабходна таксама розглядаць, хто чы ў што спрацоўвае дадзеныя (людзі чы агенты), якія запытанні агенты павінны рашаць самі, і хто сертыфікуе бізнес-правіла, на якія яны паслягаюць. Праекты, якія прыхоўваюць гэтыя аспекты, часта знову сталкваліся з імі пазней, пад час рэалізацыі, за вышэйшую цэну.
Agentic Data Cloud і яго тры ідэі
Галоўная прыемлівка была спрывачоўкай да тэмы Agentic Data Cloud — адпаведзі Гуглу на нясуварасць: інструменты, створаныя для таго, каб людзі разумелі даны, ніколі не былі прызначаныя для света, дзе штучныя інтэлектуальныя агенты самастойна працуюць з гэтымі данымі. Тры ідэі станавяць яго аднойчыну.
Агентам патрэбны значэнні разам з данымі. Намеравацца даўерыць моцнаму агенту роўнымнародны скупаку необработаных даных і спадзявацца, што ён сам разберэся ў бізнесе, — гэта дорогі рызык. Ён павінен выучыцца, што «чысты дохад» не включае дохады ад іншых джэроў, што певны показнік вырахоўваецца інакш у двух бізнес-падразеленнях, або што пункт у контракце змінюе спосаб перавозкі груза. Каталог знанняяў прызначаны для збору і стацыонарнага падтрымкі гэтых інстытуцыйных знанняяў, такім чынам кожны агент, які працуе з данымі, выйшае з аднаковага, стандартызаванага розумення.
Агенты должны дзеяць, а не толькі фармаваць інфармацыю. Прыклад з канферэнцыі: у звязку з ростам колькасці анульванняя замовленняў на панелі керування, агент зазначае гэты рост, аналізуе даны логістыкі і прыемкі, выявляе відпаведны центр распадзелу, прымечае пра неабходнасць змены маршруту і запускае агента для стазірання, каб адразу пабачыць, калі сітуацыя павярнёцца да нормы. Ніхто не мусіў прасіць.
Даны застаюцца там, дзе яны знаходзяцца. Платформы на базе воблака давно выкарыстоўваюць тэчку, калі ўсё павінна быць перанесенае ў адно месца, перш чым можна будзе адчуць яе цэннасць. У гэтым случае агенты можаць запытаць даны з любога месца, чы то ў Google Cloud, AWS, Azure, Snowflake, Databricks чы ў локальных сістэмах, без неабходнасці дорогай пачатковай міграцыі.
Looker як семантычны і эксперыэнцыйны слой
Конкрэтна, Agentic Data Cloud спаўнае BigQuery, Knowledge Catalog, Gemini і Looker; Looker выступае як слой для адображэння даных, а гэтыя чатыры інструмента працуюць як адна сістэма, а не як адзінаковыя продукты. Канверсацыйны аналіз, агенты для панелей керування, запускаемыя рабочыя працэсы і іншыя функцыі Looker — гэта тыя спосабы, якімі гэтая архітэктура даступае да корыстувачаў, і самэ гэтая точка, дзе люды відчуваюць разліку межаючы BI, якае толькі фіксуе даныя, і BI, якае ўжо дзеяе.
Новая версія Explore ідзе ўсё далей. Стары модэль выбірання поль і фільтраў заменяецца візуальным інтэрфейсам з можласцю ператасовкі элементаў, які больш прыемлівы для корыстувача, падобны да Google Search чы Google Docs. У ёй ўбудованы трое асістэнтав Gemini: адны для навігацыі за дапамогою нейтральнай мовы, другі для стварэння выразаў для Looker з звычайнай англійскай мовы, і трэці для выбірання прыдатнага тыпу дыяграмы для задання.
Для команд з доставкі ласка, гэта значыць менш часу, які паслягае на адказванне на запыткі корыстувачаў праз слой візуалізацыі, і больш часу, які паслягае на адбеджэнне якасці і сэмантычнай правільнасці коду LookML, адколькі асістэнты робяць выводы на адважанні таго, што заданае модэлем. Некачэвы сэмантычны слой дае некачэвыя адказы, пры чым гэта відбываецца у масштабе дыялогу.
Агенты дашборда зазвычай ў доступе. Дашборды больш не ўжо статычныя, адныя толькі для трансляцыі інфармацыі: корыстувачы можаць ставіць ўпыткі, прасіць пра падсумкі контэнту і змян, а таксама дакладна выясняць прычыны певных цыфр у ходзе дыялогу. Найяскравейшы прыклад на рэвэрсе ўжо існуе ў YouTube, дзе менеджэры партнераў запытваюць пра портфэлі создаўцоў на адной панелі дашборда Looker, якая аб’еднвае паданні з п’ятнаццаці разных джэрэл.
Автаматызаваныя працэйныя праграмы ператвараюць агентаў з пасыўных адпаведчыкаў у актыўных наглядчыкаў. Показнікі фіксуюцца цяпер усю ноч, і каманды абавешчаюцца як толькі перакрываецца паказнік. У бліжыней перспектыве плануецца, што агенты будуць самі складаць электранявісі або публікуваць паведамленні ў Slack. Для аналізу кампаній гэта мае большую цэнна, чым можа здавацца, і гэта тое, чаго кліянты не прасілі два гады тыму.
Іншыя аанунсаванні Looker таксама заслуговуюць на увагу:
- Агенты Looker унутрь Gemini Enterprise. Агенты, створаныя ў Looker, можна публікуваць у Gemini Enterprise і кераваць імі разам з іншымі агентамі для падпрыемства. Для кліянтав, якія інвестуюць у гэта рашэння, Looker стае часткай шырэй стратэгіі AI, а не самастоятэльным інструментам дакладнай аналітыкі.
Што вывучылі Yahoo і Virgin Media O2
Сесіі аналізу кантэксту разгавора ад Yahoo і Virgin Media O2 былі найцэннейшымі для тых, хто займаецца такой работай. Галоўны вынік: точнасць у значнай меры залежыць ад двух фактараў — «золатых запытанняў» і інструкцыйіяў агента, напісаных у фармаце YAML. Yahoo зазначыла лепшыя рэзультаты пасля перакідвання інструкцыйяў агента з фармата JSON у YAML. Пасля чаго яны перыяктувалі «золатыя запытання» і бізнес-глосарый у фармат LookML замест таго, каб заставіць іх там, дзе яны былі раней, што значна зменіла складнасць інструкцыйяў, адтолькі ўсё гэта цяпер выконваецца на адной семантычнай паўеразлі, а не на адной рукапіснай інфармацыі пра кантэкст.
Самы цікавы выказванне з заходу было самае падрабатванае: аналіз кантэксту разгавора пачынаецца з семантычнай паўеразлі, а не з ШЫ. Калі даны і модэль готавы, аналіз кантэксту разгавора стае практычна наступным крокам у ўзвышэнні якосці.
Практычным падчынным эфектам для команд являецца зміна падходу. Напісанне дзяўнаўгольных, рэтэльна настроеных заповедзей для агентаў заступаецца паўнейшым адгульненнем самага модэля, адтолькі што все, што размешчаецца ў LookML, ёсць доступным для кожнага агента і кожнага корыстніка, тады калі все, што размешчаецца ў заповедзі, служыць толькі однаму агенту і паступова стае безнадзейным.
У рэзультаце зменіўся і хорашы модэль LookML для аналізу канверсацый. Базовая версія цяпер включае абазаванні, апісанні, сінантымы і прымэты да кожнага поля, «золатыя» запыткі, ўбудованыя ў LookML, а таксама гласарый бізнес-тэрмінаў у фармаце YAML унутрь модэля. Інструкцыі для агентаў залішаюцца намерна простымі, адтолькі што семантычны слой віконвае большую частку работы. Наладжэнне агентаў Dashboard, запускаемых рабочых праграм і «золатых» запыткаў цяпер павінны ўхоўвацца ў базовыя ваколіцы будзь-якіх серйозных трэбаванняў Looker, а не ў спіску неабавязковых дадатковых элементаў.
Працоўны камплекс Data Studio вяртаецца
Looker Studio быў перайменаваны знова на Data Studio з шырэйшымі функцыяямі. Ён цяпер апрацоўвае тры відэры продуктав. Першы — гэта звычныы справаздача або панель керування, якія падаюць з BigQuery, прыемнікаў Google і партнерскіх SaaS-сервісаў, або з семантычнага шару Looker. Другі — гэта агент для аналізу, які быў створаны ў BigQuery і пасля таго опублікованы там. Трэці — гэта новая ідэя «даных-дзеянаў», па якой блокнеты Colab публікуюцца як інтэрактывныя прыемнікі.
Даныя-дзеянаў знаходзяцца між панеллю керування і цэлым прыемнікам. Яны ўжыткавы для кліентаў, якія выкарыстоўваюць Looker для оператыўнага справаздачнасцня, хочуць большай інтэрактыўнасці і не хочуць ствараць цэлы прыемнік з убудованымі функцыяямі.
Адзін з наследкав перэіменавання і новых можнасцей самаслужбы — інтэграваны «Studio in Looker», які раней называлі будучынёй фронтэнда Looker, стаў недоступны для арганізацыяў, якія яго не актываўалі, і ў планах ўсунуць яго 15 чэрвеня 2026 года.
BigQuery: агенты для інжынерыі дадзэнняў і кераваны сервер MCP
Значная частка прыкладоў з мінулага года перайшла у стан загальнай доступнасці. Гэта агенты для інжынерыі дадзэнняў і наукі пра дадзеныя, аналіз на основе дыялога ўнутрь BigQuery і яго API, BigQuery ADK, кераваны аддалены сервер MCP для BigQuery, адкрытыя інструменты MCP Toolbox, а таксама плагін, які фіксуе тэлеметрычныя даны пра работу агентаў.
Дзеяныя новейшыя элементы маюць большое значэнне, чым здаецца на першы погляд.
Масштабаванне рэсурсаў. BigQuery дадае вычынныя рэсурсы, калі агенты ў актыўным стане, і зніме іх, калі яны не працуюць, без неабяжнага ручнага налагоджэння. Частая працоўка ўжо ўжо ў спрацэ падаючых костаў аналізу дыялогаў у масштабе значна слабее.
Графыкі BigQuery. Натыўны механізм для апрацоўкі графаў без паслядоўных крокаў ETL, які можа масштабавацца да мільярдаў вузлаў і падтрымлівае стандарт ISO GQL. Яшчэ болей цікавым дадаткам ёсць функцыя Measures у BigQuery Graph, якая спаўнае метрыкі з картамі асоціяцый і дазволяе агентам аналізаваць залежнасці між рознымі элементамі.
Меры як расшырэнні процэса аналізу. Корыстны спосаб разлічэння двух віда мераў: меры LookML керуюць вычысленнямі, візначаючы, што значыць тая чы іншая метрыка, і гарантуючы аднаковы SQL для кожнага аналітыка і агента, які выкарыстоўвае Looker. Меры графа керуюць процэсам аналізу, размешчаючы тыя ж візначэнні метрык у графе з’яўленых адносоў, такіх як продукты, прадавцы, цэнтры і маршруты, тады агент можа з’ясаваць, чаму метрыка зменілася, праходзячы па адносах між факторамі, якія на яе вплываюць.
Службы міграцыі
Сэрвіс міграцыі BigQuery быў перайменаваны у Data Analytics Migration Services, і гэтыя змяны ў значным меры вплываюць на працэс міграцыі, таму всі, хто плануе перэйść з Snowflake, Cloudera чыя Databricks у 2026 годзе, должны перэацэніць свае рашэнні. Для Cloudera і Databricks працэс ацэнкі адбываецца автаматычна і дае план, у яком пераказаны задачы з оцэнкай аб’ёму загальных вітрачэнняў. SQL з Hive, Snowflake і іншых дыялектаў перакладаецца у GoogleSQL на рэвэлі мовы-кампіляра. Працэс міграцыі табліц з фарматаў Lakehouse, такіх як Iceberg, Parquet і Hive, адбываецца за дапамогою спецыяльных засобаў, а сэрвіс верыфікацыі працюе падчас самай міграцыі, оцінюючы точнасць для кожной табліцы і кожнага столбца. Паколькі API для міграцыі доступны праз MCP, такі інструмент, як Claude Code, можа кераваць усім працэсам міграцыі.
У пакуальніях службы быў сумяшаны рэзультат у працэі з складным перакладам SQL, а новая версія выглядае набагато сільней. Выдзеляецца панель адзначэння правільнасці, калі ўжо ёй даваецца віконваць вельмі большую частку ручных пераканальняў, якія гадыма затрымлівалі графікі міграцыі. Команды, якія раней планавалі, што аналітыкам патрэбны тыдні на ручны парабяроўкі колькасці радоў і значэнняў столбцоў, должны пераглянуць гэтыя прыбліжэнні.
Федэрацыя між хмарамі
У частцы федэрацыі каталог Databricks Unity Catalog на AWS S3 цяпер можа быць чытаны ў обох направленнях, а Snowflake Polaris і AWS Glue таксама можна чытаць з BigQuery. Усё грунтуецца на стандарцы каталога Apache Iceberg REST, таму BigQuery можа выконваць запыты да гэтых зовнішніх каталогаў без перадачы дадзэнняў.
Для кліянтов, які не можуць або не хочуць перайсці цалкам, падчынна стратэгія змініцца. У зменшчэнні на адказ пра тое, каб усё перайшло ў BigQuery, працэўніка стае такім: заліцьце даныя на месцы, даступаце да іх праз BigQuery, а зверху выкорыстоўваце Looker і Conversational Analytics. Компаніі Snowflake, якія інакш былі бы выключаны з практыкі аналітыкі, якая прывязана да GCP, атрымліваюць рэальную можлівасць, якая, верагодна, стане ступенем да цалкамейшых перайсцяў.
Урокі перайсця ад Target, Wells Fargo і Virgin Media O2
Група экспертаў з гэтых трох кампаній выявіла тэндэнцыі, якія багато хто выучыў ценай болю, але якія вартая памянуць знову.
Першыя, і найважлівейшыя правілы: спачатку перанесіце семантычны слой. Створыце слой Looker або BI на GCP, каб бізнес-выкарыстоўчыкі моглі адразу доступвацца да дадзэнняў, пакуль працы з іх перанесення ўсё ў ходзе, і заполніце прыгождыну за дапамогою тактычных заданняў на копіюванне, якія копіююць ключовыя наборы дадзэнняў у BigQuery. Virgin Media O2 падараваўся гэтам падходу праз шасць велікіх міграцый платформ, а Wells Fargo санкціонаваў гэты метод.
Іншыя патэрны:
- Зменшыце обсяг дадзэнняў прычыну міграцыі. AI можа знайсці невыкарыстоўваныя і дублікатныя дадзэнні з самага пачатку; адна з компаній у групе выявіла, што аднаўсотка 80% ўсіх ўсіх яе дадзэнняў была дублікатная.
- Спачатку перанесіце, а пасля — модэрнізуйце. Рэфактораванне падчас міграцыі неспакойна адлічвае часы выпання заданняў.
Компанія Target таксама запропанавала корысную концэпцыю — „іррацыянальныя цялі“: выбірайце цялі, якія немагчыма досягнуць, калі толькі платформа не будзе перабудована на аднойчыныя да AI методы. Такое падходжэнне перакідае дыскусію з пытанняў міграцыі на пытанні трансформацыі.
Кіт для дадзенневых агентаў
У прыёмнай версіі Data Agent Kit спаўнае пашырэнне VS Code з плагінамі для Gemini CLI, Cloud Code і Codex. Разам яны ствараюць комплект навыкаў і інструментаў MCP для работы з дадзеннямі у BigQuery: навыкі агентскага тыпу, серверы MCP, інструменты для доступу да BigQuery і плагіны для глыбокай налаштовкі VS Code. Самыя навыкі ўжо ёсць адкрытымі за кодам і можна яны адаптаваць.
Консалтынгавыя фірмы і команды кліянтаў, якія ужо ствараюць внутрашні інструменты для агентскай працы, должны серьёзна ўважна ўзяць іх пад розгляд. Па пачатковым аналізу, гэты комплект пакрывае аспекты інжынерыі на рэвэрсе BigQuery і дапамагае у болей шырокай організацыі працэсаў выдання рэшэнняў і іспользованні LookML, падходзячы да вялікі ўжо існуючых падходаў, якія базуюцься на навыках.
Каталог знанняў, ранейша Dataplex, як кантэкст агента
Dataplex цяпер называецца Knowledge Catalog і выступае як бэкэнд для кантэкстуальнай працы у робочых праграмах Google Cloud. Яго падтрымліваюць тры основныя элементы. Першы збірае метаданы з сервісаў Google, укладзеных у Looker, а таксама з каталагаў партнераў, такіх як Atlan, Collibra і SAP. Другі паўнейшае гэтыя метаданы, выкарыстоўваючы автаматызаванае стварэнне і бізнес-глосарый, які ужо знаходзіцца у этапы загальнага выпуску. Трэці прыменяе семантычны пошук за дапамогою Context API, які дазволяе агентам атрымліваць неабходную інфармацыю.
Найболей паучны прыклад практычнага выкарыстоўвання падаў Bloomberg Media. Іхній „Knowledge Gap Agent“ вучыцца на адмовах агентаў, выявляе месцы, дзе кантэкст дадзенаў некарэктны або відсутны, і пропануе змяны для Knowledge Catalog з метой ўтверджэння ў людзяў. Главны рэзультат: 102 прыміткі па выкарыстоўванні, створаныя автаматычна для двадцаты табліц MVP, паднялі точнасць агента для доступу да дадзенаў на 63%.
Для меншых праектаў Knowledge Catalog будзе працаваць у фоне. Для кліянтаў, які ствараюць агентаў для аналізу канверсацый у масштабе, калі інстытуцыянальныя знанні ўсё ўсё не зафіксаваныя там, дзе можа дасягнуць агент, гэта яе нехватка. Bloomberg назваў глыбінную прычыну гэтага явышча «праблемай у 42 долары», якая паўтараецца як у людзях-аналітыках, так і у AI-агентах: знанні, якія не задокументаваныя нідзе ў платформе дадзеных.
У ўзорце, які яны паказалі, младшы аналітык выбраў правыя табліцы, напісаў правільны SQL і застаўіў стандартную логіку расчытку чыстага доходу, але отрымаў некорэктную цыфру. Прадавець платэжных аперацый берае плату у розмярэ 42 долары за кожную суперчлівасць з кліентам, і гэтаю платой трэба ўзяць пад увагу пад час расчытку доходу. Гэтае правіле не было ні ў жадным схематызме, ні ў жадным потоку дадзеных, ні ў жадным доступным дакуменце. Яго хранілі на старой сторонцы Confluence з 2017 года, чыяй авар пакінуў компанію.
Чы не хватка семантычнага двігу?
Адзін з крытык, якія пачалі распространяцца пасля гэтаго, гласі, што Google усіяе сілы на роўні агентаў, тады калі яго семантычны і бізнес-кантэкст застаецца ступенява слабым. Па гэйму, Каталог знанняяў нагадвае агрэгатор метадаў, не маючы значнай часткі характэра справжнейа сістэмы керування падпрыемствамі, такой як Frontier ад OpenAI чы Foundry ад Palantir. Без сільнага семантычнага двайніка, які бы спаяў бізнес-значэнні з агентамі, нават прыгожыя інструменты рызыкуюць даўаць некарэктныя рэзультаты, галюцынаціі чы правільныя адпаведзі на неправільныя запытанні.
Большая частка тых дыягназаў застаецца актуальной, і семантычны слой мае большое значэнне ў свеце агентных сістэм, чым калі-небудзь у сістэмах у відэаформаце. Болей оптымістычны падход заключаецца ў тым, што семантычны слой LookML ужо падкрывае большасць задач, якія, як очаквалася, павінен выканаць корпоратыўны операцыйны сістэма. Ён усуняе проблему наявнасці калькольных версіяў правды, забезпечвае стандартызаваныя ваказанні па метрыках і служыць надзеяным сховішчам метрыкаў для асістэнтов, такіх як Claude, праз MCP Toolbox.
Тое, што на конферэнцыі Каталог знанняяў мало сказало пра інтэграцыю LookML, не значыць, што LookML не працуе. Праца ведзецца на адны слой ніжэй, чым яго шукаюць крытыкі.
Конкрэтныя доказы знаходзяцца ў задокументаваных найкрашчых практыках Google для налаштавання функцыі Conversational Analytics у Looker. Яны базуюцца на двух галоўных элементах: структуры, полях, аблікованнях, апісаннях і сінанімах у модэлі LookML, а таксама на адзінаковых значэннях полей, выбраных з дадзеных, пры чым кардынальнасць (колькісць унікальных значэнняў) вплывае на спосаб іх выкарыстоўвання.
Для атрымання адзінаковых значэнняў функцыя Conversational Analytics выкарыстоўвае давно існуючы метод API Looker model_fieldname_suggestions. Гэта той самы механізм, які відпавядае за падказкі фільтраў у выбірачы полей і фільтрах панелі керування, і які цяпер перадаецца як сігнал для модэлі. Тры існуючыя параметры LookML — suggestions, suggest_explore і suggest_dimension — такім чынам служаюць засобам для распрацоўшчыка, які керуе тым, якія значэння будуць ведамыя для функцыі Conversational Analytics.
Командам не трэба чакаць, пакуль продукт гэта зрабіць; тую ж ідэю можна стварыць вручную ў складзі BigQuery. Паралельна стандартнаму словніку дадзэнняў, які вытвараецца з INFORMATION_SCHEMA, можна падтрымваць кансэльнік у фармаце markdown, які ўваходзіць у склад асістэнта як спецыяльная функцыя і перыядычна генеруецца праз крок аналізу. У яму опісваецца кожны таблыцы з колькасцю роўнаў, дыяпазонамі дат, а таксама множынамі значэнняў і кардынальнасцямі катагарычных поль з высокай значымасцю, тады асістэнт знае, напрыклад, што таблыцы з паведамленнямі раздэляецца між iMessage, Slack, WhatsApp і іншымі у вядомых прыцэпах, а не проста здагадваецца.
Conversational Analytics цяпер выконвае адпрацоўку, эквівалентную той, што відбываецца на шары LookML, і ўніверсальна падходзіць да всіх корыстувачаў Looker. Возьмімо вымір city, заполнены выканкамі кліянтаў або операцыйнымі дадзеннямі. Сістэма бярэ прыклады яго унікальных значэнняў, такіх як Брайтан, Хоўв і Ландан, і дазволяе параметру кардынальнасці вялікі гэтыя значэнні будуць урахавленыя, калі корыстувачы ставяць запытанні.
Для распрацоўшчыкаў LookML ключовыя ўстановкі — гэтыя тры параметры, якія вікорыстоўваюцца так:
view: customer {
dimension: city {
label: "Customer City"
description: "The city associated with the customer's primary address. Most operational activity occurs in Brighton and Hove (UK head office) and London (UK secondary office)."
type: string
sql: ${TABLE}.customer_city ;;
# Hard-code a curated list of values rather than letting Looker
# run SELECT DISTINCT against a large table.
suggestions: ["Brighton", "Hove", "London", "Edinburgh", "Manchester"]
}
dimension: customer_segment {
label: "Customer Segment"
description: "Customer tier based on annual recurring revenue."
type: string
sql: ${TABLE}.segment ;;
# Pull suggestions from another view rather than scanning
# the much larger customer fact table.
suggest_explore: segments
suggest_dimension: segments.segment_name
}
}
У спалучанні з апісаннямі, сынанімамі і калькама золатых запыткаў, якія ўбудованы ў модэль, яны даюць семантычным шарам LookML самэ гэта, чаго хочуць крытыкі ад аперацыйнай сістэмы падпрыемства: адпаведны, кантролюемы бізнес-кантэкст для шара агентаў, з выбірам рэальных значэнняў з урахоўваннем кардынальнасці, пры чым усё гэта керуецца тым самым LookML, які відпавядае панелям керавання і інструментам аналізу.
Таму спрыяванне Каталогу знанняў і LookML разныя. Сэродзён LookML выглядае як адны з многіх вхідных элементаў у архітэктурэ Каталогу знанняў, і лёгка зрозумець, чаму гэта можа здавацца недастатнім. За наступныя дванаццац-вясемнаццац месцаў можна спакушацца, што гэта значна змяніцца, адколі у Google ёсць всі прычыны зробіць LookML найважлівейшым вхідным элементам каталогу, а не проста аднам з калькам.
Семантычный двыжок, які выклікаюць крытыкі, на самай працэўнае не відсутні, бо большая часць яго ужо ў LookML. Што застаецца нерашаным, так гэта тое, чы розробка Knowledge Catalog дастаеся до ролі шара бізнес-кантэксту, які будзе перадаваць значэння LookML у всій структуры агентных рашэнняў, чы ж іншы продукт выпляне гэту ролю. У будзь-якім случае, час, які вітрачаецца на правільную настройку LookML, вяртаецца у віглядзе практычных выгод.
Спадні матэрыялы
- Практычныя прыміткі: RAG ўмер. LLM Wiki, ідэя Andrej Karpathy – гэта тое, што будзе далей: Паследовны апіс практычных прымітак: RAG ўмер. LLM Wiki, ідэя Andrej Karpathy – гэта тое, што будзе далей: контракты, перакрыццяі і шаблоны коду для команд, якія рэалізуюць рашэння на базе RAG.