Google Next 2026 dla inżynierii danych: Looker, BigQuery i serwery MCP

Google Cloud Next 2026 w Las Vegas odbył się w skali odpowiadającej renomie tej imprezy, z przemówieniami głównymi i sesjami tematycznymi rozproszonymi po ogromnej hali. Dla wszystkich, którzy realizują projekty z wykorzystaniem Looker lub BigQuery, najważniejsze okazały się sesje poświęcone analityce, integracji danych oraz analityce opartej na agentach. Dalej przedstawiono ogłoszenia, które powinny zmienić sposób planowania takich zadań w ciągu najbliższych dwunastu miesięcy, a także wnioski z rozmów z klientami, które okazały się bardziej przydatne niż większość wiadomości o produktach.

Kontekst: od odpowiadania do działania

Główny przekaz Google dotyczący platform analitycznych i do zarządzania danymi to przejście od „systemu inteligencji” do „systemu działania”. Pierwszy to reaktywna analityka biznesowa, która odpowiada na zadawane pytania. Drugi to zbiór proaktywnych agentów, które monitorują wskaźniki, podsumowują uzyskane informacje i podejmują działania dla firmy.

W istocie nic z tego nie jest nowością. Alarmy sterowane wydarzeniami oraz automatyczne odpowiedzi istnieją w zestawach narzędzi BI dla przedsiębiorstw od dwudziestu lat. Mimo to ponowne podkreślenie tego aspektu przynosi korzyści, ponieważ zmienia to, co powinno należeć do zakresu projektu realizowanego przy użyciu Looker w 2026 roku.

Powstaje z tego praktyczna konsekwencja dla wszystkich, którzy opracowują opis zadań. Wcześniej całością wyniku pracy były raporty i tablice kontrolne. Teraz rozmowa musi obejmować również to, kto lub co konsumuje dane (ludzie czy agenci), jakie pytania agenci powinni rozwiązywać samodzielnie oraz kto weryfikuje reguły biznesowe, od których ci agenci zależą. Projekty, które pomijają tę rozmowę, zazwyczaj odkrywają ją później, w trakcie realizacji, przy wyższych kosztach.

Agentic Data Cloud i jego trzy koncepcje

Kluczowym tematem przemówienia była Agentic Data Cloud – rozwiązanie Google na problem niespójności: narzędzia stworzone po to, by ludzie mogli rozumieć dane, nigdy nie były przeznaczone dla świata, w którym agenci AI działają na podstawie tych danych samodzielnie. Trzy koncepcje stanowią jego podstawę.

Agenci potrzebują informacji o znaczeniu danych. Skierowanie potężnego agenta na surowe dane i oczekiwanie, że sam rozwiąże problemy biznesowe, to drogie ryzyko. Agent musi nauczyć się, że „przychód netto” nie uwzględnia zysków, że pewna metryka jest obliczana inaczej w dwóch jednostkach biznesowych, lub że klauzula w umowie zmienia sposób dostawy towaru. Katalog wiedzy ma na celu przechowywanie i ciągłe aktualizowanie tej wiedzy instytucjonalnej, aby każdy agent pracujący z danymi wychodził od tej samej, spójnej informacji.

Agenci muszą działać, a nie tylko zgłaszać problemy. Przykład z konferencji: zamiast panelu kontrolnego pokazującego gwałtowny wzrost liczby anulowanych zamówień, agent zauważa ten wzrost, przeprowadza analizę przyczyn źródłowych na podstawie danych logistycznych i sprzedażowych, określa odpowiedni ośrodek dystrybucji, zaleca zmianę trasy dostawy i uruchamia agent monitorujący, aby sprawdzić, kiedy sytuacja się poprawi. Nikt nie musiał o to prosić.

Dane pozostają tam, gdzie są. Platformy chmurowe od dawna wymagają, aby wszystko zostało przeniesione w jedno miejsce, zanim pojawi się ich wartość. Tutaj agenci mogą wyszukiwać dane tam, gdzie się znajdują – czy to w Google Cloud, AWS, Azure, Snowflake, Databricks, czy w systemach lokalnych – bez konieczności kosztownej migracji na początku.

Looker jako warstwa semantyczna i warstwa doświadczenia użytkownika

W praktyce Agentic Data Cloud łączy BigQuery, Knowledge Catalog, Gemini i Looker, przy czym Looker pełni rolę warstwy interfejsu, a te cztery elementy działają jako jeden system, a nie oddzielne produkty. Analiza konwersacyjna, agenci dashboardów, uruchamiane procesy i inne nowości Lookera to sposoby, w jakie ta architektura dociera do użytkowników – to właśnie tutaj ludzie odczuwają różnicę pomiędzy BI, które tylko raportuje, a BI, które działa.

Nowy Explore idzie jeszcze dalej. Stary model wybierania pól i filtrów ustępuje miejsca wizualnemu interfejsowi typu „przeciągnij i upuść”, podobnemu do Google Search lub Google Docs. W jego ramach znajdują się trzej asystenci Gemini: jeden do nawigacji za pomocą języka naturalnego, jeden do tworzenia wyrażeń Lookera na podstawie zwykłego języka angielskiego oraz jeden do wyboru odpowiedniego typu wykresu do danego pytania.

Dla zespołów dostawczych oznacza to mniej czasu poświęcanego na indywidualne wsparcie użytkowników przy pracy z warstwą wizualizacji oraz więcej czasu na zapewnienie jakości i semantycznej poprawności w LookML, ponieważ asystenci wyciągają wnioski na podstawie tego, co zdefiniował model. Niedbale zaprojektowana warstwa semantyczna przyniesie niedbale sformułowane odpowiedzi, tym razem w skali rozmowy.

Agenci dashboardów są obecnie powszechnie dostępni. Dashboardy przestają być statycznymi, jedynie do transmisji artefaktami – użytkownicy mogą je kwestionować, prosić o streszczenia treści i zmian, a także zgłębiać powody podanych liczb w trakcie rozmowy. Najlepszym przykładem na poziomie przedsiębiorstw jest YouTube, gdzie menedżerowie partnerów sprawdzają portfele twórców na podstawie piętnastu połączonych źródeł danych, wszystko to z wyglądu zwykłego dashboardu Looker.

Uruchamiane automatycznie procesy przekształcają agentów z pasywnych odbiorców informacji w proaktywnych monitorów. Wskaźniki są śledzone przez całą dobę, a zespoły otrzymują powiadomienia w momencie przekroczenia ustalonego progu. W krótkoterminowej strategii rozwoju przewidziano agenty, które same komponują e-maile lub publikują wpisy w Slacku. Dla analiz operacyjnych jest to bardziej wartościowe, niż się wydaje, i stanowi rodzaj żądania, którego klienci nie formułowali jeszcze dwa lata temu.

Inne ogłoszenia dotyczące Lookera również zasługują na wzmiankę:

• Agenci Lookera w Gemini Enterprise. Agenci stworzone w Looker mogą być publikowane w Gemini Enterprise i zarządzane razem z innymi agentami korporacyjnymi. Dla klientów inwestujących w to rozwiązanie Looker staje się częścią szerszej strategii AI, a nie samodzielnym narzędziem analitycznym.
• Conversational Analytics API, teraz GA. Zawiera wbudowaną integrację z SDK Looker, możliwość wgrania w iframe oraz implementację referencyjną opartą na oprogramowaniu otwartym. Zespoły, które wdrażają analizę konwersacyjną we własnych aplikacjach, mają wreszcie dostęp do obsługiwanej metody, a rozmowy, które zostały przerwane, ponieważ API znajdowało się jeszcze w wersji wstępnej, mogą zostać wznowione.
• LookML Agent dla VS Code (wersja wstępna). Rozszerzenie obejmujące cały cykl życia LookML, począwszy od języka naturalnego.
• Looker MCP jako standard otwarty. Istnieje zarządzany serwer MCP obok opcji opartych na oprogramowaniu otwartym dostępnych za pośrednictwem MCP Toolbox. Połączenie Looker z asystentami takimi jak Claude umożliwia analizę między różnymi źródłami danych oraz rozumowanie oparte na agentach, wykraczające poza możliwości samodzielnego zarządzania danymi przez Looker.
• Integracje z rdzenną warstwą semantyczną. Looker potrafi bezpośrednio odczytywać definicje grafów w BigQuery oraz widoki semantyczne w Snowflake, dzięki czemu logika semantyczna już obecna w BigQuery nie musi być ponownie budowana w LookML.
• Agenty do wielokrotnej eksploracji. Jeden agent może korzystać jednocześnie z maksymalnie pięciu eksploracji. Rozwiązanie Yahoo łączy dane z dziedzin HR, finansów, wyszukiwania i obsługi klienta w pojedynczych agentach na kilku instancjach Looker.

Co nauczyły się Yahoo i Virgin Media O2

Sesje analityki konwersacyjnej z Yahoo i Virgin Media O2 okazały się najcenniejsze dla osób zajmujących się tą pracą. Główne ustalenie: dokładność zależy przede wszystkim od dwóch czynników – „złotych zapytań” oraz instrukcji dla agentów napisanych w formacie YAML. Yahoo zaobserwowało lepsze wyniki po przeniesieniu instrukcji agentów z formatu JSON na YAML. Następnie przeniosły one „złote zapytania” oraz glosariusz biznesowy do formatu LookML zamiast przechowywać je gdzie indziej, co znacznie obniżyło złożoność instrukcji, ponieważ model teraz wyciąga wnioski na podstawie warstwy semantycznej, a nie ręcznie napisanego kontekstu.

Własny podsumowanie Yahoo było najczęściej cytowanym stwierdzeniem z tego wydarzenia: analityka konwersacyjna zaczyna się od warstwy semantycznej, a nie od sztucznej inteligencji. Gdy dane i model są gotowe, analityka konwersacyjna stanowi niemal następny krok w rozwoju.

Praktycznym rozwiązaniem dla zespołów jest zmiana podejścia. Zamiast pisać długie, starannie skonfigurowane instrukcje dla agentów, lepiej wzbogacać sam model, ponieważ wszystko, co znajduje się w LookML, jest dostępne dla każdego agenta i każdego użytkownika, natomiast informacje umieszczone w instrukcjach służą tylko jednemu agentowi i stopniowo tracą na aktualności.

W rezultacie zmienił się również standardowy model LookML do analizy konwersacji. Bazowy model obejmuje teraz etykiety, opisy, synonimy oraz komentarze do każdego pola, wbudowane w LookML zapytania wzorcowe oraz słownik terminologiczny w formacie YAML wewnątrz modelu. Instrukcje dla agentów są celowo proste, ponieważ ciężką pracę wykonuje warstwa semantyczna. Konfiguracja agentów Dashboard, uruchamianych procesów i zapytań wzorcowych powinna teraz stanowić element podstawowych wymagań w przypadku każdego poważnego projektu z użyciem Looker, a nie być tylko opcją dodatkową.

Data Studio wraca

Looker Studio zostało ponownie przemianowane na Data Studio o szerszym zakresie działania. Teraz obsługuje trzy rodzaje artefaktów. Pierwszym z nich są znane raporty lub tablice kontrolne, dostarczane z BigQuery, połączeń SaaS firmy Google i jej partnerów lub warstwy semantycznej Looker. Drugim jest agent analityczny umożliwiający rozmowę, stworzony w BigQuery i następnie tam opublikowany. Trzecim jest nowa koncepcja „aplikacji danych”, w której notatniki Colab są publikowane jako interaktywne aplikacje.

Aplikacje danych znajdują się pomiędzy tablicą kontrolną a pełną aplikacją. Są one przydatne dla klientów, którzy polegają na Looker do raportowania operacyjnego, pragną większej interaktywności i woleliby uniknąć tworzenia pełnej aplikacji wbudowanej.

Jedną z konsekwencji zmiany wizerunku marki oraz wprowadzenia nowego rozwiązania typu self-service jest to, że zintegrowane rozwiązanie „Studio in Looker”, kiedyś przedstawiane jako przyszłość interfejsu użytkownika Looker, nie jest dostępne dla organizacji, które go nie włączyły, a jego wycofanie planowane jest na 15 czerwca 2026 roku.

BigQuery: agenci do inżynierii danych i zarządzany serwer MCP

Znaczna część wersji wstępnych z zeszłego roku przeszła do fazy powszechnej dostępności. Obejmuje to agenty do inżynierii danych i nauki o danych, analizę konwersacyjną w ramach BigQuery i jego API, BigQuery ADK, zarządzany zdalny serwer MCP dla BigQuery, otwarte narzędzie MCP Toolbox oraz wtyczkę, która zbiera dane telemetryczne dotyczące wydajności agentów.

Część nowszych rozwiązań ma większe znaczenie, niż na pierwszy rzut oka się wydaje.

Skalowanie dynamiczne. BigQuery dodaje zasoby obliczeniowe, gdy agenci są aktywni, a usuwa je, gdy są nieaktywni, bez konieczności ręcznej regulacji rozmiaru. Powszechny zarzut dotyczący kosztów analityki konwersacyjnej w skali znacznie słabnie.

BigQuery Graphs. Natywny silnik grafowy bez kroku ETL, zdolny do skalowania do miliardów węzłów oraz obsługujący standard ISO GQL. Najciekawszym dodatkiem jest funkcja Measures w BigQuery Graphs, która łączy kontrolowane metryki z mapowaniem relacji i umożliwia agentom analizowanie zależności wieloetapowych.

Mierzenia jako rozszerzenia rozumowania. Praktyczny sposób na odróżnienie tych dwóch rodzajów mierzeń: mierzenia LookML kontrolują obliczenia, określając znaczenie metryki i gwarantując spójny SQL dla każdego analityka i agenta korzystającego z Lookera. Mierzenia grafowe kontrolują proces rozumowania, umieszczając te same definicje metryk w grafie połączonych elementów, takich jak produkty, dostawcy, węzły i trasy, dzięki czemu agent może sprawdzić, dlaczego metryka uległa zmianie, śledząc związki pomiędzy czynnikami wpływającymi na nią.

Usługi migracyjne

Służba migracji BigQuery została przemianowana na Data Analytics Migration Services, a zmiany są znaczne, dlatego wszyscy, którzy planują przeniesienie się z Snowflake, Cloudera lub Databricks w 2026 roku, powinni to ponownie przeanalizować. W przypadku Cloudera i Databricks ocena odbywa się automatycznie i generuje plan zawierający listę zadań z szacunkami całkowitego kosztu posiadania. SQL z Hive, Snowflake oraz innych dialektów jest tłumaczony na GoogleSQL na poziomie kompilatora. Migracja typu lakehouse obsługuje tabele w formatach Iceberg, Parquet i Hive, a usługa walidacji działająca w czasie rzeczywistym ocenia dokładność tabel i kolumn pojedynczo. Ponieważ API do migracji są dostępne przez MCP, narzędzie takie jak Claude Code może koordynować cały proces migracji.

Wcześniejsze wersje usługi wykazywały zróżnicowane wyniki w przekładaniu złożonych zapytań SQL, natomiast nowa generacja wydaje się znacznie silniejsza. Wyjątkiem jest panel walidacji, który przejmuje dużą część ręcznych sprawdzeń, które od lat opóźniały harmonogram migracji. Zespoły, które wcześniej planowały tygodnie pracy analityków zajmujących się ręcznym porównywaniem liczby wierszy i wartości kolumn, powinny ponownie przeanalizować te szacunki.

Federacja między chmurami

Jeśli chodzi o federację, katalog Databricks Unity Catalog na AWS S3 można teraz odczytywać w obu kierunkach, a Snowflake Polaris oraz AWS Glue mogą być odczytywane również z BigQuery. Wszystko opiera się na standardzie katalogu REST Apache Iceberg, dzięki czemu BigQuery może bezpośrednio wysyłać zapytania do tych zewnętrznych katalogów bez konieczności przenoszenia danych.

Dla klientów, którzy nie mogą lub nie chcą przeprowadzić pełnej migracji, strategia się zmienia. Zamiast nalegać na przeniesienie wszystkiego do BigQuery, oferta brzmi: pozostaw dane na miejscu, uzyskuj do nich dostęp przez BigQuery, a na wierzchu zastosuj Looker oraz Conversational Analytics. Firmy Snowflake, które w przeciwnym razie zostałyby wykluczone z podejścia analitycznego opartego wyłącznie na GCP, otrzymują prawdziwą opcję, która prawdopodobnie stanie się kamieniem milowym na drodze do pełniejszych migracji.

Lekcje z migracji od Target, Wells Fargo i Virgin Media O2

Panel z udziałem tych trzech firm ujawnił wzorce, których wielu nauczyło się boleśnie, ale które warto powtórzyć.

Pierwsza i najważniejsza zasada: najpierw przenieś warstwę semantyczną. Utwórz warstwę Looker lub BI w GCP, aby użytkownicy biznesowi mogli uzyskać dostęp do danych, podczas gdy przenoszenie danych jest jeszcze w trakcie, a lukę wypełnij zadańiami replikacji taktycznej, które kopiują kluczowe zbiory danych do BigQuery. Virgin Media O2 udało się to osiągnąć dzięki sześciu dużym migracjom platform, a Wells Fargo zaaprobowało taki podejście.

Inne wzorce:

• Zmniejsz rozmiar danych przed migracją. Sztuczna inteligencja może z góry wykryć nieużywane i duplikowane dane; jedna z firm biorących udział w badaniu stwierdziła, że ponad 80% jej danych było duplikatem.
• Najpierw przenieś infrastrukturę, a dopiero potem ją zmodernizuj. Refaktoryzacja w trakcie migracji nieprzewidywalnie wydłuża terminy realizacji.
• Buduj strukturę zarządzania od pierwszego dnia. Umowy dotyczące danych, glosariusz biznesowy oraz zasady jakości danych powinny być częścią programu migracji, ponieważ ich wprowadzenie później często kończy się niepowodzeniem, gdy okno polityczne się zamyka.
• Zacznij od małych kroków w zakresie umów dotyczących danych. Wybierz określony obszar, stwórz czyste umowy pomiędzy dostawcą a odbiorcą dla tego przypadku i użyj ich jako modelu tego, jak powinno wyglądać dobre rozwiązanie, zanim przystąpisz do skalowania.

Target zaproponował również przydatne określenie – „irracjonalne cele”: wybieraj cele, których nie da się osiągnąć, chyba że platforma zostanie przebudowana wokół metod typowych dla sztucznej inteligencji. Dzięki temu dyskusja przesuwa się z kwestii migracji na kwestie transformacji.

Data Agent Kit

W wersji wstępnej Data Agent Kit łączy rozszerzenie VS Code z pluginami dla Gemini CLI, Cloud Code i Codex. Razem tworzą one zestaw umiejętności oraz narzędzi MCP przeznaczonych do zadań związanych z danymi w BigQuery: umiejętności agentowe, serwery MCP, narzędzia do połączenia się z BigQuery oraz pluginy umożliwiające głęboką personalizację VS Code. Same umiejętności są otwarte source i mogą być modyfikowane.

Konsultingi oraz zespoły klientów, które już tworzą wewnętrzne narzędzia do realizacji zadań agentowych, powinny je dokładnie przeanalizować. Z wstępnej oceny wynika, że rozwiązanie to obejmuje aspekty inżynieryjne związane z BigQuery i uzupełnia szersze mechanizmy organizacji procesów realizacji zadań oraz technologię LookML, pasując do już stosowanych podejść opartych na umiejętnościach.

Katalog wiedzy, wcześniej Dataplex, jako kontekst agenta

Dataplex to teraz Knowledge Catalog, przeznaczony jako backend kontekstowy dla zautomatyzowanych procesów w Google Cloud. Jego funkcjonowanie opiera się na trzech filarach. Pierwszy z nich gromadzi metadane z usług Google, w tym Looker, oraz z katalogów partnerów takich jak Atlan, Collibra i SAP. Drugi wzbogaca te metadane poprzez automatyczną generację treści oraz użycie glosariusza biznesowego, który już wszedł do fazy produkcyjnej. Trzeci zapewnia wyszukiwanie semantyczne dzięki API Context, za pomocą którego agenci mogą uzyskać potrzebne im informacje.

Najbardziej pouczającym przykładem jest projekt realizowany przez Bloomberg Media. Ich „Knowledge Gap Agent” uczy się na błędach agentów, wykrywa miejsca, gdzie kontekst danych jest błędny lub brakuje, i proponuje aktualizacje do Knowledge Catalog w celu weryfikacji przez ludzi. Główny efekt: automatyczna generacja 102 notatek dotyczących użycia w dwudziestu tabelach MVP, co zwiększyło dokładność agenta obsługującego dostęp do danych o 63%.

W przypadku mniejszych zadań Knowledge Catalog będzie działał w tle. Dla klientów tworzących agentów analitycznych w skali przemysłowej, których wiedza instytucjonalna nie została jeszcze skodyfikowana w miejscach dostępnych dla agentów, stanowi on kluczowy element brakujący w takich rozwiązaniach. Bloomberg nazwał ten podstawowy problem „problemem 42 dolarów”, który dotyka zarówno analityków ludzkich, jak i agentów AI: wiedza, która nie jest udokumentowana nigdzie w platformie danych.

W przykładzie przedstawionym przez autorów, młodszy analityk wybrał odpowiednie tabele, napisał poprawny kod SQL i zastosował standardową logikę obliczania przychodów, a mimo to uzyskał błędną wartość. Dostawca usług płatniczych pobiera opłatę 42 dolary za każdą spór z klientem, a ta opłata musi zostać dodana do obliczeń przychodów. Zasada ta nie znajdowała się ani w żadnym schemacie, ani w żadnym procesie, ani w żadnym dostępnym dokumencie. Istniała jedynie na stronie w Confluence z 2017 roku, której autor odszedł z firmy.

Czy brakuje silnika semantycznego?

Jedna z krytyk pojawiających się później mówi, że Google skupia się wyłącznie na warstwie agentów, podczas gdy jego kontekst semantyczny i biznesowy pozostaje stosunkowo słaby. Z tego punktu widzenia Katalog Wiedzy przypomina agregator metadanych, bez cech prawdziwego systemu operacyjnego dla przedsiębiorstw, takiego jak Frontier od OpenAI czy Foundry od Palantir. Bez silnego silnika semantycznego łączącego znaczenie biznesowe z agentami, nawet zaawansowane narzędzia niosą ryzyko błędnych wyników, halucynacji lub udzielenia poprawnej odpowiedzi na niewłaściwe pytanie.

Większość tych stwierdzeń pozostaje aktualna, a warstwa semantyczna ma większe znaczenie w świecie opartym na agentach niż kiedykolwiek w środowisku opartym na panelach kontrolnych. Bardziej optymistyczna interpretacja jest taka, że warstwa semantyczna LookML już obejmuje większość zadań związanych z kontekstem biznesowym, które powinien wykonywać system operacyjny przedsiębiorstwa. Rozwiązuje ona problem wielu wersji prawdy, dostarcza zdefiniowanych metryk i służy jako zaufane źródło metryk dla asystentów takich jak Claude za pośrednictwem MCP Toolbox.

To, że na konferencji Katalog Wiedzy niewiele mówił o integracji z LookML, nie oznacza, że LookML jest bezczynny. Prace odbywają się na poziomie niżej niż ten, na którym szukają ich krytycy.

Bezpośrednim dowodem są udokumentowane najlepsze praktyki Google dotyczące konfiguracji Conversational Analytics w Looker. Opierają się one na dwóch głównych źródłach informacji: strukturze, polach, etykietach, opisach i synonimach w modelu LookML oraz odrębnych wartościach pól pobranych z danych, przy czym kardynalność (liczba unikalnych wartości) wpływa na sposób wykorzystania tych wartości.

Aby pobrać te odrębne wartości, Conversational Analytics korzysta z długo istniejącej metody API Looker model_fieldname_suggestions. Jest to ten sam mechanizm, który służy do sugestii filtrów w wybieraczu pól i filtrach na dashboardach, teraz wykorzystywany jako sygnał wskazujący modelowi, jakie wartości są istotne. Trzy istniejące parametry LookML, suggestions, suggest_explore oraz suggest_dimension, pełnią zatem podwójną funkcję – służą zarówno do konfiguracji, jak i do sterowania tym, jakie wartości są znane Conversational Analytics.

Zespoły nie muszą czekać, aż produkt to zrobi; tę samą koncepcję można zrealizować ręcznie w magazynie BigQuery. Obok standardowego słownika danych pochodzącego z INFORMATION_SCHEMA można utrzymywać przewodnik w formacie markdown, dostępny dla asystenta jako umiejętność i regularnie regenerowany poprzez krok profilowania. Przewodnik ten opisuje każdą tabelę, podając liczbę wierszy, zakresy dat oraz zbiory wartości i kardynalności poli kategorycznych o wysokim znaczeniu, dzięki czemu asystent wie na przykład, że tabela z wiadomościami jest rozdzielona pomiędzy iMessage, Slack, WhatsApp i inne w znanych proporcjach, zamiast zgadywać.

Conversational Analytics realizuje teraz to samo na poziomie LookML, dostosowane dla wszystkich użytkowników Lookera. Weźmy wymiar city wypełniony danymi klientów lub operacyjnymi. System pobierze jego unikalne wartości, takie jak Brighton, Hove i Londyn, a kardynalność określi, w jakim stopniu każda z tych wartości powinna być uwzględniana podczas zadawania pytań przez użytkowników.

Dla programisty LookML kluczowe są te trzy parametry, których używa się w następujący sposób:

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
  }
}

W połączeniu z opisami, synonimami oraz kilkoma kluczowymi zapytaniami wbudowanymi w model, zapewniają one warstwę semantyczną LookML dokładnie to, czego oczekują krytycy od systemu operacyjnego przedsiębiorstwa: ugruntowany, kontrolowany kontekst biznesowy dla warstwy agentów, wraz z próbkowaniem rzeczywistych wartości uwzględniającym kardynalność, wszystko to oparte na tym samym LookML znajdującym się za panelami sterowania i narzędziami analitycznymi.

Dlatego interpretacja Katalogu Wiedzy w porównaniu z LookML jest inna. Obecnie LookML wygląda jak jeden z wielu elementów we strukturze Katalogu Wiedzy, i łatwo zrozumieć, dlaczego może to wydawać się niewystarczające. W ciągu najbliższych dwunastu do osiemnastu miesięcy można się spodziewać znacznych zmian, ponieważ Google ma wszelkie powody, by uczynić z LookML najważniejszy element katalogu, a nie tylko jeden z wielu.

Ten silnik semantyczny, o który proszą krytycy, tak naprawdę nie jest brakujący, ponieważ większa jego część już istnieje w LookML. Pozostaje nierozstrzygnięte, czy Knowledge Catalog rozwinie się w warstwę kontekstu biznesowego, która przenosi znaczenie LookML przez całą architekturę agentic, czy też inny produkt zajmie tę rolę. W obu przypadkach czas poświęcony na poprawne użycie LookML jest czasem, który się zwraca.