本文将对Looker进行更高层次的回顾和分析,并剖析它的功能与优缺点。 本文翻译自Holistic的产品博客,作者是其联合创始人兼首席设计师ThanhDinh。 Holistic是一家建立于2015年的国外BI厂商,在新加坡,越南,印尼等地设有办公室。今年上半年Looker被Google高价收购的消息漫天飞扬,却没有找到一篇中文文章介绍Looker产品本身,遂起了翻译本文之心。 原文意在对Looker及其优缺点进行全面分析。在流行的商业智能(BI)工具中,Looker以其创新的数据建模和探索方法而独树一帜。在这篇文章中,我们将对Looker进行更高层次的回顾和分析,它的功能以及它的优缺点。 汇总 Looker是一种创新产品,采用了独特的BI方法。Looker拥有自己的专有建模语言,称为LookML,这是Looker的强项,但有趣的是,这也成为了它的弱项。它提供了既可重用又可维护的数据建模层,但其陡峭的学习曲线使其比其他竞品更难上手。 Looker最适合经验丰富的数据团队。他们欣赏其独特的数据建模方法和其允许组织中的每个人自己对数据进行切片和切块(SDice)的功能。它还需要一个现有的数据仓库,对于已经建设完毕的数据团队来说更加友好。 随意跳到最感兴趣的部分,我们将在这里涵盖以下主题: 数据连接器(DataConnectors) 使用LookML数据建模 数据探索及可视化 下钻和钻透(DrilldownsandDrillthroughs) 数据混合(DataBlending) 数据交付和调度(DataDeliveryandScheduling) 使用Looker管理组织 访问控制和权限管理 数据准备功能 定价 结论 一、数据连接器 与其他任何BI工具一样,在Looker中,您需要立即设置与数据源的连接。作为基于SQL的BI工具,遗憾的是,Looker仅支持SQL数据库。从好的方面来说,它所支持的数据源列表相当不错,从常见的RDBMS(如Oracle,MicrosoftSQLServer)到晦涩的Denden和XtremeData。 可用的高级选项数量也令人印象深刻,其中包括最大连接数和连接池超时等选项。但是,最好将这些选项隐藏在“高级”复选框的后面,以使表单不太混乱和令人生畏。 二、使用LookML 一个能立即将Looker与其他选择区分开来的操作要求是:在任何数据可视化之前需要先花时间进行数据建模。对于Looker而言,这意味着首先要在LookML中学习并准备建模工作,作为对SQL数据库的抽象。 1。LookML概念 这是Looker文档中LookML的定义: LookML是一种用于描述SQL数据库中的维度,聚合,计算和数据关系的语言。 在Looker中最重要的概念是视图(Views),探索(Explores)和模型(Models),他们被直接建模在LookML中。 2。视图 在Looker中,视图是一组链接到物理表或派生表的字段。这些字段又分为两种类型:维度和度量(DMeasures)。你可以将维度视为数据库表中的列以及以这些列绘制的计算字段,将应用了SQL聚合(总和平均最小最大等)的列作为度量。(译者注:类似于数据采集和清洗) 3。探索 Looker称可查询的视图为探索。探索会声明与其他视图的关系(称为Joins),并用作查询的起点,或者在SQL术语中,它是FROM子句中引用的表的起点。(译者注:类似于数据计算和连接) 4。模型 Looker将模型称为数据库的自定义门户。本质上,它是一组相关的视图和探索,可以与业务用户共享以提供拖放式(DragandDrop)数据探索。(译者注:类似于设计报表的可视化) Looker的三步数据建模过程从定义视图开始,到利用表间关系将视图合并为探索,然后结合探索联结成模型来共享给业务方。 5。使用LookML定义视图,探索和模型 开发模式与生产模式 Looker在数据建模过程中区分开发模式和生产模式。开发模式允许您创建和编辑LookML项目,而生产模式允许企业用户浏览创建的LookML模型。当您只想完成事情时,将两种模式分开会使用户感到乏味。但是这样做的好处是,您可以在业务用户可用的内容和仍在开发的内容之间清楚地区分。 GIT集成 Git是一个分布式版本控制系统,程序员广泛使用它来管理源代码。Looker的独特之处在于,它迫使您使用Git来管理LookML项目。您可以在不具有Git集成的开发模式下使用Looker,但是如果要与业务用户共享并在生产模式下进行数据浏览,则必须设置Git。 对于Looker这种版本控制方法,意见两极分化。经验丰富的分析师将赞赏像Git这种版本控制系统的可维护性和灵活性。对于不熟悉Git的分析师,您将需要学习Git概念(例如提交,分支等),以充分了解整个工作流程。这涉及的学习曲线可能对带来普通用户本能性的强烈抵抗,搞不清为什么他们需要经过这么复杂的操作才能进行数据建模。 LOOKML编辑器 为了开始数据建模过程,Looker为您提供了一个基于Web的文本编辑器来开发LookML。 该编辑器具有代码编辑器期望的标准功能,例如自动完成功能,甚至在您遇到麻烦时甚至支持VimEmacs键绑定。快速帮助侧栏非常有用,因为否则您将需要不断查阅Looker的官方文档站点。 编辑的经验还不错,但是最糟糕的是漫长的反馈循环。与PowerBI等其他工具不同,在该工具中,您可以即时查看建模过程的每一步,而在Looker中,您需要真正了解自己在做什么:输入正确的规则,单击“验证”按钮,然后单击“保存”按钮,尝试使用创建的模型探索数据以进行验证,然后修改并重复。一路上任何错误的步骤都将需要您重新开始循环。根据我们的经验,与其他类似工具相比,此缺点是Looker数据建模产品中最薄弱的部分。 三、数据探索和可视化 一旦在LookML中定义了视图和探索,用户现在就可以开始在LookerExplore中进行自助式数据探索。为此,您可以从左侧栏中选择感兴趣的字段,然后单击“运行”按钮。定位按钮很简单,但不是很直观,因为您需要单击要定位的字段按钮再进行选择,而不是像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连接一样工作,甚至跨数据库也是如此。 为了使用它,您将需要使用探索来生成结果集。完成后,您可以从菜单中单击“合并结果”: 然后,您将需要添加另一个结果集(Looker将其称为查询)以将其合并到原始结果集中。 您可以添加多个查询以合并,但是您需要将一组查询作为主查询。 我认为合并结果与Looker进行数据建模的方式不合时宜,尽管如此,它仍使用户能够很好地处理常见的用例。 六、数据交付和调度 Looker提供了不错的数据交付内容,如下面的截图所示。您可以通过电子邮件,webhooks,AmazonS3或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设置时间表,以将数据从该模型具体化到您的数据库。您还可以设置其他选项,例如索引或实现频率。 但是,LookerPDT的选择非常有限,因为它没有像Holistics或dbt那样提供增量和依赖的实现。 十、定价 Looker不在其网站上提供公开定价,而是选择提供定制的定价模型。最终价格将取决于多个因素,包括总用户数,用户类型(查看器与编辑器),数据库连接以及部署规模。 根据第三方网站的数据,Looker的价格从3000500010人月起计,每位新用户每月额外收取50。这种类似于传统的企业定价结构,可能对熟悉基于SaaS可预测且透明定价模式的潜在客户并不具备吸引力。 十一、客户支持 我们在Looker的客户支持方面没有直接的经验,但是根据与部分Looker客户的评论和交谈,Looker的支持经验似乎反应迅速且很有帮助。 十二、总结 Looker的数据建模方法是独特的,创新的,但并非没有缺点。它的特点有两点: 它利用了现代数据仓库的功能,而不是构建自己的存储层,从而无需将数据加载到其专有引擎中。这提供了两个好处:完全访问行级原始数据,并且消除了管理加载刷新数据的麻烦,并向用户保证,查询数据时会更新数据。另一方面,这种方法是一把双刃剑,因为它意味着查询性能完全取决于基础数据仓库,并且从Looker用户的角度来看无法预测或标准化。 它使用LookML和Git集成意味着数据团队拥有一个集中的,版本控制的单一真实数据源来用于数据建模逻辑。这使得数据建模过程更加可维护和可重用。不利的一面是该语言陡峭的学习曲线和数据建模过程漫长的反馈回路。 总的来说,Looker是一种创新的BI产品,具有独特的数据建模方法。对于经验丰富的数据团队来说,这是一个很好的选择,他们需要复杂的数据建模需求,并且欣赏可维护性和可重用性。 这里是几个关键点: 它对LookML的使用提供了陡峭的学习曲线,但提供了可维护和可重用的数据建模层 一旦您熟悉LookML,Looker的向下钻取功能将非常强大且易于使用 Looker没有自己的存储层,而是依靠客户的数据仓库 从本质上讲,Looker是一个SQL查询构建器引擎,可将业务用户的拖放输入转换为SQL查询 Looker提供了高度灵活和复杂的访问控制和权限管理,从而简化了功能。 与其他工具相比,Looker的数据准备功能有限,因此将这项任务委托给其合作伙伴来提供这些功能。 译者注 这笔收购案中,Google应是看重了Looker的数据能力和客户能力,借此推广GoogleCloud业务。Looker的多云环境可以让GCP更好地切入,且能有机会撬动其他云厂商如AWS,Azure的蛋糕,这比收购那些只有GCP或者只用其他产品如Domo来说,预期的收益会大许多。 Forbes专栏作家PeterCohan,过去数年间采访了三次CEOFrankBien,也给出了他认为Google此次收购的4个原因: 数据分析是一块增长迅速的市场:2018年比2017年增长11。7,达到166B,并将在2022到达260B Looker比市场增长得更快:CEO给出的数据是YoY70 CEO是个前朋克摇滚者,不希望运营一家上市的大公司:这哥们从2003年至今做了4家被高价收购的公司 GoogleCloudCEO希望做出自己的业绩:促进云业务快速增长 目前来看,国内并没有类似的BI平台出现。现有的GrowingIO,神策更多是产品分析工具,BI要涉及到多数据源的整合。原因在于这块市场要滞后于其他ToB产品的发展。只有一批比较成熟的新企业服务产品出来,拥有相对稳定的数据规范,在这之上才能长出来一堆BI平台工具。目前这个趋势正在慢慢形成。 本文介绍Looker一些产品概念,在这之上,有些特性也颇有有趣。比如为了减少获取数据方面的难度,Looker设计了Block的概念,预置了一些常见的流程工具,帮助用户清洗和建立数据模型等。同时,还有Act概念,他能方便和其他tob产品联动,如Slack,Jira等等。 原文来源:Holistic的产品博客