本文将對 Looker 進行更高層次的回顧和分析,并剖析它的功能與優缺點。
本文翻譯自 Holistic 的産品博客,作者是其聯合創始人兼首席設計師 Thanh Dinh。
Holistic 是一家建立于 2015 年的國外 BI 廠商,在新加坡,越南,印尼等地設有辦公室。今年上半年 Looker 被 Google高價收購的消息漫天飛揚,卻沒有找到一篇中文文章介紹 Looker 産品本身,遂起了翻譯本文之心。
原文意在對 Looker 及其優缺點進行全面分析。在流行的商業智能(BI)工具中,Looker 以其創新的數據建模和探索方法而獨樹一幟。在這篇文章中,我們将對 Looker 進行更高層次的回顧和分析,它的功能以及它的優缺點。
彙總
Looker 是一種創新産品,采用了獨特的 BI 方法。Looker 擁有自己的專有建模語言,稱為 LookML,這是 Looker 的強項,但有趣的是,這也成為了它的弱項。它提供了既可重用又可維護的數據建模層,但其陡峭的學習曲線使其比其他競品更難上手。
Looker 最适合經驗豐富的數據團隊。他們欣賞其獨特的數據建模方法和其允許組織中的每個人自己對數據進行切片和切塊(Slice&Dice)的功能。它還需要一個現有的數據倉庫,對于已經建設完畢的數據團隊來說更加友好。
随意跳到最感興趣的部分,我們将在這裡涵蓋以下主題:
一、數據連接器
- 數據連接器(Data Connectors)
- 使用LookML數據建模
- 數據探索及可視化
- 下鑽和鑽透(Drilldowns and Drill-throughs)
- 數據混合(Data Blending)
- 數據交付和調度(Data Delivery and Scheduling)
- 使用Looker管理組織
- 訪問控制和權限管理
- 數據準備功能
- 定價
- 結論
與其他任何 BI 工具一樣,在 Looker 中,您需要立即設置與數據源的連接。作為基于 SQL 的 BI 工具,遺憾的是,Looker 僅支持 SQL 數據庫。從好的方面來說,它所支持的數據源列表相當不錯,從常見的RDBMS(如Oracle,Microsoft SQL Server)到晦澀的 Denden 和 XtremeData。
可用的高級選項數量也令人印象深刻,其中包括最大連接數和連接池超時等選項。但是,最好将這些選項隐藏在“高級”複選框的後面,以使表單不太混亂和令人生畏。
二、使用LookML
一個能立即将 Looker 與其他選擇區分開來的操作要求是:在任何數據可視化之前需要先花時間進行數據建模。對于 Looker 而言,這意味着首先要在 LookML 中學習并準備建模工作,作為對 SQL 數據庫的抽象。
1. LookML 概念
這是 Looker 文檔中 LookML 的定義:
LookML 是一種用于描述 SQL 數據庫中的維度,聚合,計算和數據關系的語言。
在Looker 中最重要的概念是視圖(Views),探索(Explores)和模型(Models) ,他們被直接建模在 LookML 中。
2. 視圖
在 Looker 中, 視圖是一組鍊接到物理表或派生表的字段。這些字段又分為兩種類型:維度和度量(Dimensions & Measures)。你可以将維度視為數據庫表中的列以及以這些列繪制的計算字段,将應用了 SQL 聚合(總和/平均/最小/最大/等)的列作為度量。(譯者注:類似于數據采集和清洗)
3. 探索
Looker 稱可查詢的「視圖」為「探索」。「探索」會聲明與其他視圖的關系(稱為 Joins),并用作查詢的起點,或者在 SQL 術語中,它是 FROM子 句中引用的表的起點。(譯者注:類似于數據計算和連接)
4. 模型
Looker 将「模型」稱為數據庫的自定義門戶。本質上,它是一組相關的視圖和探索,可以與業務用戶共享以提供拖放式(Drag-and-Drop)數據探索。(譯者注:類似于設計報表的可視化)
Looker 的三步數據建模過程從定義視圖開始,到利用表間關系将視圖合并為探索,然後結合探索聯結成模型來共享給業務方。
5. 使用 LookML 定義視圖,探索和模型
開發模式與生産模式
Looker 在數據建模過程中區分開發模式和生産模式。開發模式允許您創建和編輯LookML 項目,而生産模式允許企業用戶浏覽創建的 LookML 模型。當您隻想完成事情時,将兩種模式分開會使用戶感到乏味。但是這樣做的好處是,您可以在業務用戶可用的内容和仍在開發的内容之間清楚地區分。
Git集成
Git 是一個分布式版本控制系統,程序員廣泛使用它來管理源代碼。Looker 的獨特之處在于,它迫使您使用 Git 來管理 LookML 項目。您可以在不具有 Git 集成的開發模式下使用 Looker,但是如果要與業務用戶共享并在生産模式下進行數據浏覽,則必須設置 Git。
對于 Looker 這種版本控制方法,意見兩極分化。經驗豐富的分析師将贊賞像 Git 這種版本控制系統的可維護性和靈活性。對于不熟悉 Git 的分析師,您将需要學習Git 概念(例如提交,分支等),以充分了解整個工作流程。這涉及的學習曲線可能對帶來普通用戶本能性的強烈抵抗,搞不清為什麼他們需要經過這麼複雜的操作才能進行數據建模。
LOOKML編輯器
為了開始數據建模過程,Looker 為您提供了一個基于 Web 的文本編輯器來開發LookML。
該編輯器具有代碼編輯器期望的标準功能,例如自動完成功能,甚至在您遇到麻煩時甚至支持 Vim/Emacs 鍵綁定。快速幫助側欄非常有用,因為否則您将需要不斷查閱 Looker 的官方文檔站點。
編輯的經驗還不錯,但是最糟糕的是漫長的反饋循環。與 PowerBI 等其他工具不同,在該工具中,您可以即時查看建模過程的每一步,而在 Looker 中,您需要真正了解自己在做什麼:輸入正确的規則,單擊“驗證”按鈕,然後單擊“保存”按鈕,嘗試使用創建的模型探索數據以進行驗證,然後修改并重複。一路上任何錯誤的步驟都将需要您重新開始循環。根據我們的經驗,與其他類似工具相比,此缺點是 Looker 數據建模産品中最薄弱的部分。
三、數據探索和可視化一旦在 LookML 中定義了視圖和探索,用戶現在就可以開始在 Looker Explore 中進行自助式數據探索。為此,您可以從左側欄中選擇感興趣的字段,然後單擊“ 運行” 按鈕。「定位」按鈕很簡單,但不是很直觀,因為您需要單擊要定位的字段按鈕再進行選擇,而不是像 Excel 中那樣将字段拖到列/行框中。
使用 Looker 的數據浏覽功能一段時間後,您将開始意識到實際上是在運行 SQL 查詢構建器。Looker 使用您的輸入并将其與基礎視圖/探索設置預先結合起來,以生成并執行最終的 SQL 查詢,以将數據返回給您。
使用 Looker 進行數據可視化時,您會注意到的第一件事是,每次更改内容時都需要手動單擊“運行”按鈕。這是 Looker 工作方式的結果:隻要您更改數據可視化配置,便會生成一個新的SQL查詢。當您熟悉其他提供即時反饋而不必重新運行查詢的BI工具時,你會發現Looker 的設計雖然合乎邏輯但是很煩人。
在可視化方面,Looker 的産品尚可使用,但不能與 Tableau 甚至 PowerBI 或QlikView 之類的産品相匹配。它通過标準自定義支持大約15種不同類型的圖表,例如調色闆,系列類型(折線,面積,散布等)和其他常見的可疑對象。
探索完成後,您可以将單個探索保存到 Looker 所謂的 Look,或将一組 Looks 保存到儀表闆。
四、鑽取和鑽透
與 Looker 中的幾乎所有其他内容一樣,您需要使用 LookML 定義鑽取。熟悉Looker的工作方式後,它非常直觀。(譯者注:鑽取指的是根據維度的下級維度或關聯維度下鑽,鑽透則是連接到相關的報表或其他可視化形式)
您設置了一組字段,當您對某個特定維度或度量進行深入鑽取時,這些字段将公開。
現在,當選擇“訂購商品計數”度量時,您可以在該字段下鑽取。
例如,當您單擊圖表中的列時,将鑽取相應的度量“訂單項計數”,并觸發其鑽取字段(“産品ID”和“産品名稱”),并返回新的結果集:
單擊在“從這裡浏覽”中,将為您提供一個新的浏覽窗口,其中預先選擇了“産品ID”和“産品名稱”:
從上面的示例中,我們可以看到由于其強大的數據建模層,Looker 的向下鑽取很容易設置并提供流暢直觀的用戶體驗。
五、數據混合Looker 通過「合并結果」的概念支持數據混合。它像結果集之間的 SQL 連接一樣工作,甚至跨數據庫也是如此。
為了使用它,您将需要使用「探索」來生成結果集。完成後,您可以從菜單中單擊“合并結果…”:
然後,您将需要添加另一個結果集(Looke r将其稱為「查詢」)以将其合并到原始結果集中。
您可以添加多個查詢以合并,但是您需要将一組查詢作為主查詢。
我認為合并結果與 Looker 進行數據建模的方式不合時宜,盡管如此,它仍使用戶能夠很好地處理常見的用例。
六、數據交付和調度Looker 提供了不錯的數據交付内容,如下面的截圖所示。您可以通過電子郵件,webhooks,Amazon S3 或 SFTP 服務器發送數據結果。
您甚至可以使用“高級”選項創建自定義警報,僅在結果集為空或自上次運行以來結果發生更改時才發送結果集。
七、使用 Looker 管理組織
使用 BI 工具一段時間後,随着您開始擁有龐大的外觀和儀表闆,事情變得越來越難管理。為了簡化管理,Looker 提供了一項稱為“空間”的功能。基本上,“空間”是一個允許您存儲外觀和儀表闆的容器。一個空間也可以包含其他空間,從而可以創建類似于文件系統工作方式的分層文件夾結構。
空間也用于權限和訪問控制,這将在下一節中詳細介紹。
八、訪問控制和權限管理與其他 BI 工具相比,Looker 具有一組相當健壯和完善的功能來支持訪問控制和權限管理。Looker 有 3 種訪問類型:
- 内容訪問:控制訪問和管理 Spaces 的權限
- 數據訪問:控制用戶可以查看哪些數據。這通過對過濾器的限制完成
- 功能訪問:控制用戶可以在 Looker 中執行的操作類型。這通過創建具有特定權限的自定義角色并将這些角色分配給特定用戶來完成
對于具有現有身份驗證基礎結構的公司,Looker 還集成了LDAP和SAML。我們還沒有機會進行嘗試,但是如果您的組織已經使用這些技術進行身份驗證,那當然是一個加分點。
從 Looker 的訪問控制和權限管理設計中,我們可以清楚地看到,Looker 的目标是針對具有複雜需求的企業客戶,因為它的系統似乎對較小的組織來說有點高射炮打蚊子的意思。
九、數據準備功能Looker 不提供數據準備功能,而是依靠其合作夥伴(如 Stitch 或 Alooma)提供數據準備/數據管道功能。盡管如此,Looker 還是有一種稱為持久派生表(PDT)的東西,可以用于某些數據準備用例。
當您想要通過在數據庫中實例化一些數據來簡單地加快查詢速度時,PDT足夠好并且可以正常工作。它的工作方式如下:首先,直接從 SQL 或通過将 Look 保存到 LookML 來設置派生模型。然後,為 Looker 設置時間表,以将數據從該模型具體化到您的數據庫。您還可以設置其他選項,例如索引或實現頻率。
但是,Looker PDT的選擇非常有限,因為它沒有像 Holistics 或 dbt 那樣提供增量和依賴的實現。
十、定價Looker 不在其網站上提供公開定價,而是選擇提供定制的定價模型。最終價格将取決于多個因素,包括總用戶數,用戶類型(查看器與編輯器),數據庫連接以及部署規模。
根據第三方網站的數據,Looker 的價格從 $3000- $5000/10人/月起計,每位新用戶每月額外收取 $50。這種類似于傳統的企業定價結構,可能對熟悉基于SaaS 可預測且透明定價模式的潛在客戶并不具備吸引力。
十一、客戶支持我們在 Looker 的客戶支持方面沒有直接的經驗,但是根據與部分Looker客戶的評論和交談,Looker的支持經驗似乎反應迅速且很有幫助。
十二、總結Looker 的數據建模方法是獨特的,創新的,但并非沒有缺點。它的特點有兩點:
它利用了現代數據倉庫的功能,而不是構建自己的存儲層,從而無需将數據加載到其專有引擎中。這提供了兩個好處:完全訪問行級原始數據,并且消除了管理加載/刷新數據的麻煩,并向用戶保證,查詢數據時會更新數據。另一方面,這種方法是一把雙刃劍,因為它意味着查詢性能完全取決于基礎數據倉庫,并且從Looker 用戶的角度來看無法預測或标準化。
它使用 LookML 和 Git 集成意味着數據團隊擁有一個集中的,版本控制的單一真實數據源來用于數據建模邏輯。這使得數據建模過程更加可維護和可重用。不利的一面是該語言陡峭的學習曲線和數據建模過程漫長的反饋回路。
總的來說,Looker是一種創新的BI産品,具有獨特的數據建模方法。對于經驗豐富的數據團隊來說,這是一個很好的選擇,他們需要複雜的數據建模需求,并且欣賞可維護性和可重用性。
這裡是幾個關鍵點:
它對LookML的使用提供了陡峭的學習曲線,但提供了可維護和可重用的數據建模層
一旦您熟悉LookML,Looker的向下鑽取功能将非常強大且易于使用
Looker 沒有自己的存儲層 ,而是依靠客戶的數據倉庫
從本質上講,Looker是一個 SQL查詢構建器引擎 ,可将業務用戶的拖放輸入轉換為SQL查詢
Looker提供了高度靈活和複雜的訪問控制和權限管理,從而簡化了功能。
與其他工具相比,Looker的數據準備功能有限,因此将這項任務委托給其合作夥伴來提供這些功能。
譯者注這筆收購案中,Google 應是看重了 Looker 的數據能力和客戶能力,借此推廣 Google Cloud 業務。Looker的多雲環境可以讓GCP更好地切入,且能有機會撬動其他雲廠商如 AWS,Azure的蛋糕,這比收購那些隻有GCP或者隻用其他産品如 Domo來說,預期的收益會大許多。 Forbes 專欄作家 Peter Cohan ,過去數年間采訪了三次 CEO Frank Bien ,也給出了他認為 Google 此次收購的 4 個原因:
數據分析是一塊增長迅速的市場:2018 年比 2017 年增長 11.7%,達到 $166B,并将在 2022 到達 $260B Looker 比市場增長得更快:CEO 給出的數據是 YoY 70% CEO是個前朋克搖滾者,不希望運營一家上市的大公司:這哥們從 2003 年至今做了 4 家被高價收購的公司 Google Cloud CEO 希望做出自己的業績:促進雲業務快速增長 目前來看,國内并沒有類似的BI平台出現。現有的 GrowingIO,神策更多是産品分析工具,BI 要涉及到多數據源的整合。原因在于這塊市場要滞後于其他ToB産品的發展。隻有一批比較成熟的新企業服務産品出來,擁有相對穩定的數據規範,在這之上才能長出來一堆BI平台工具。目前這個趨勢正在慢慢形成。
本文介紹 Looker 一些産品概念,在這之上,有些特性也頗有有趣。比如為了減少獲取數據方面的難度,Looker設計了Block的概念,預置了一些常見的流程工具,幫助用戶清洗和建立數據模型等。同時,還有Act 概念,他能方便和其他tob産品聯動,如Slack,Jira等等。
原文來源:Holistic 的産品博客
原文作者:Holistic聯合創始人兼首席設計師 Thanh Dinh
編譯作者:陳新濤,三生萬數(ID: ourStone),現任轉轉數據負責人,曾任美團外賣首任數據産品經理。
本文由 @陳新濤 翻譯發布于人人都是産品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!