Data Panda brengt de data uit je CRM, ERP, webshop en boekhouding samen in één warehouse, en je Looker LookML-project zit erbovenop als semantische laag. Dashboards, Looks en embedded views lezen één definitie van omzet, en de git-historiek toont wie ze heeft aangepast.
Looker is in januari 2012 opgericht in Santa Cruz door Lloyd Tabb en Ben Porterfield, gebouwd rond LookML: een modelleertaal die dimensies, measures en joins in versiebeheerde bestanden zet in plaats van in losse rapporten. Google nam het bedrijf over in februari 2020 (aangekondigd in juni 2019, $2,6 miljard) en schoof het bij Google Cloud in als de gemodelleerde, enterprise-kant van het BI-aanbod. Looker Studio is de aparte gratis dashboardingtool uit dezelfde Google-familie; de twee producten delen hun naam maar niet de LookML-laag of de developer-workflow.
Het platform bestaat uit de Looker IDE om LookML te schrijven, de webapp voor Explores, Looks en dashboards, geplande leveringen naar mail en Slack, en een embedded SDK voor klant-analytics. Het koppelt aan zo'n 40 databanken, met BigQuery, Snowflake, Redshift en Postgres als de typische landingsplek. De kracht is dat één LookML-project de bron van waarheid wordt voor hoe een metric is berekend, met branches, pull requests en een historiek van wie wat heeft veranderd. De zwakte is dezelfde die Power BI- en Tableau-pagina's raakt: als het warehouse eronder een puinhoop is, neemt elke Explore die puinhoop over en loopt de BigQuery-slot-rekening mee op. Wij cureren het warehouse zodat de LookML-laag declaratief blijft en de compute-kost in budget blijft.
Eén LookML-project op een gecureerd warehouse, dat elke Explore, Look en dashboard voedt.
Gecureerde warehouse-tabellen en persistent derived tables in plaats van dashboards die live joins afvuren.
De AI-functies van Looker en Gemini in Looker antwoorden vanuit LookML, niet vanuit ruwe tabellen.
Embedded Looker-views en de interne dashboards lezen hetzelfde warehouse en dezelfde LookML.
Een lijst van concrete rapporten, automatisaties en AI-toepassingen die we op Looker-data hebben gebouwd. Kies er een die bij je situatie past.
Waarom geeft dezelfde measure verschillende cijfers over onze Looker-dashboards?
Bijna altijd omdat twee LookML-branches uit de pas lopen, of omdat de ene Explore een ruwe brontabel leest en de andere een gecureerde versie. Met één warehouse dat één LookML-project voedt, staat een measure één keer in een view-bestand en geeft elke Explore die ze gebruikt hetzelfde antwoord. De git-historiek toont dan wanneer en waarom ze laatst werd aangepast.
Onze BigQuery-rekening is gesprongen sinds Looker is uitgerold. Hoe krijgen we ze terug in de hand?
Looker rekent BigQuery-slots aan voor elke Explore-query en elke PDT-rebuild, dus een model dat bij elke klik live brontabellen joint, telt snel op. De zware joins in gecureerde warehouse-tabellen zetten betekent dat Explores smalle, geïndexeerde marts lezen in plaats van joins opnieuw te draaien, en PDT-refresh loopt op een schema dat je zelf bepaalt. Slot-gebruik volgt dan dashboard-gebruik in plaats van onverwacht verkeer.
Hoe houden we onze embedded klant-dashboards in lijn met de Looker van het interne team?
Hetzelfde warehouse, hetzelfde LookML-project, andere Explores en andere toegangscontrole. Klant-embeds lezen row-level gefilterde views op dezelfde gecureerde feiten die het interne team gebruikt, zodat een wijziging aan een metric meteen op beide plekken landt. Het alternatief, een apart model voor het embedded product, is waar de twee verhalen uit elkaar lopen en de klant een ander cijfer ziet dan support.
Finance krijgt een Looker-model waar omzet, marge en debiteuren één definitie dragen die teruggaat op de boekhouding. De board pack en de analist-Explore tonen hetzelfde cijfer, en een wijziging aan een measure laat een git-diff achter, zodat het volgende kwartaal niet start met een discussie over wie wat heeft veranderd.
Sales ziet pipeline, winrate en forecast in één Explore die Salesforce of HubSpot koppelt aan billing en productgebruik. Dezelfde cijfers gaan van het dashboard naar de embedded view in het klantportaal, zodat interne QBR's en klantgerichte scorecards elkaar niet tegenspreken.
Operationele leads zien doorlooptijd, SLA en cost-to-serve vanuit hetzelfde warehouse dat finance leest, en BigQuery-slotgebruik wordt voorspelbaar in plaats van een maandelijkse verrassing. Looker-planningen en PDT-refresh landen naast de warehouse-loads, niet op de live bronsystemen.
Je houdt de rapporteringstool die je al hebt. Wij koppelen hem aan het warehouse waar je Looker-data staat.
OAuth-authenticatie. Standaard read-only. Wij tekenen een DPA en je admin houdt de sleutels.
Data stroomt naar je warehouse op het schema dat jij kiest. Bijna real-time of 's nachts, aan jou. Jij bent eigenaar.
We bouwen het eerste dashboard, de eerste workflow of AI-toepassing samen met jou, en geven de sleutels over. Of we blijven erbij voor doorlopende levering.
Wij zetten de basis op. Jouw team bouwt erop verder.
Beste match Teams die al een BI-analist of data engineer in huis hebben en zelf willen bouwen.
Wij bouwen het geheel, van A tot Z.
Beste match Teams zonder BI- of dev-capaciteit in huis. Jij zegt wat je nodig hebt en wij leveren het.
Jij. Ze komt in jouw warehouse terecht, op jouw cloud-account. Wij verkopen ze niet door en aggregeren ze niet. Stop je met ons, dan blijft het warehouse van jou en blijft het draaien.
Bijna real-time voor de meeste operationele systemen. Voor zwaardere bronnen plannen we per uur of per nacht. Je kiest op basis van wat de rapporten nodig hebben.
Nee. Heb je er geen, dan helpen we je er een kiezen en zetten we het op als deel van de eerste levering. Gangbare startpunten zijn Snowflake, Microsoft Fabric of een kleine Postgres-start.
Twee verschillende producten van Google. Looker (oorspronkelijk in 2012 opgericht, in 2020 overgenomen door Google) is de gemodelleerde, betalende enterprise-BI met de LookML semantische laag, de developer-workflow en embedded analytics. Looker Studio is de gratis self-service dashboarding-tool, vroeger Data Studio, zonder LookML. Deze pagina gaat over Looker. Beide kunnen lezen op het warehouse dat Data Panda bouwt, vaak zelfs naast elkaar.
Nee. Looker koppelt aan zo'n 40 databanken, met BigQuery, Snowflake, Redshift, Postgres en andere als gangbare landingsplek. BigQuery past het meest natuurlijk sinds de Google-overname, en we gebruiken het regelmatig voor de BE/NL-mid-market, maar het LookML-model zelf is databank-agnostisch. De keuze van warehouse staat los van de keuze van BI-tool.
Jullie team beheert de LookML, in jullie git-repo, met jullie branching-model. Wij leveren de gecureerde warehouse-views en dimensies waar LookML uit leest, plus de afspraken om ze netjes in LookML in te bouwen zodat de developer-flow zuiver blijft. De meeste BE/NL-klanten houden een analist of data engineer in-huis als LookML-onderhouder zodra het model staat.
We bekijken je Looker-opzet en de systemen eromheen. Samen kiezen we wat we als eerste bouwen.