时间: 2021-08-03 09:04:23 人气: 10 评论: 0
本文将对 Looker 进行更高层次的回顾和分析，并剖析它的功能与优缺点。
本文翻译自 Holistic 的产品博客，作者是其联合创始人兼首席设计师 Thanh Dinh。
Holistic 是一家建立于 2015 年的国外 BI 厂商，在新加坡，越南，印尼等地设有办公室。今年上半年 Looker 被 Google高价收购的消息漫天飞扬，却没有找到一篇中文文章介绍 Looker 产品本身，遂起了翻译本文之心。
原文意在对 Looker 及其优缺点进行全面分析。在流行的商业智能（BI）工具中，Looker 以其创新的数据建模和探索方法而独树一帜。在这篇文章中，我们将对 Looker 进行更高层次的回顾和分析，它的功能以及它的优缺点。
汇总
Looker 是一种创新产品，采用了独特的 BI 方法。Looker 拥有自己的专有建模语言，称为 LookML，这是 Looker 的强项，但有趣的是，这也成为了它的弱项。它提供了既可重用又可维护的数据建模层，但其陡峭的学习曲线使其比其他竞品更难上手。
Looker 最适合经验丰富的数据团队。他们欣赏其独特的数据建模方法和其允许组织中的每个人自己对数据进行切**和切块（Slice&Dice）的功能。它还需要一个现有的数据仓库，对于已经建设完毕的数据团队来说更加友好。
随意跳到最感兴趣的部分，我们将在这里涵盖以下主题：
与其他任何 BI 工具一样，在 Looker 中，您需要立即设置与数据源的连接。作为基于 SQL 的 BI 工具，遗憾的是，Looker 仅支持 SQL 数据库。从好的方面来说，它所支持的数据源列表相当不错，从常见的RDBMS（如Oracle，Microsoft SQL Server）到晦涩的 Denden 和 XtremeData。
可用的高级选项数量也令人印象深刻，其中包括最大连接数和连接池**时等选项。但是，最好将这些选项隐藏在“高级”复选框的后面，以使表单不太混乱和令人生畏。
一个能立即将 Looker 与其他选择区分开来的操作要求是：在任何数据可视化之前需要先花时间进行数据建模。对于 Looker 而言，这意味着首先要在 LookML 中学习并准备建模工作，作为对 SQL 数据库的抽象。
这是 Looker 文档中 LookML 的定义：
LookML 是一种用于描述 SQL 数据库中的维度，聚合，计算和数据关系的语言。
在Looker 中最重要的概念是视图（Views），探索（Explores）和模型（Models） ，他们被直接建模在 LookML 中。
在 Looker 中， 视图是一组链接到物理表或派生表的字段。这些字段又分为两种类型：维度和度量（Dimensions & Measures）。你可以将维度视为数据库表中的列以及以这些列绘制的计算字段，将应用了 SQL 聚合（总和/平均/最小/最大/等）的列作为度量。（译者注：类似于数据采集和清洗）
Looker 称可查询的「视图」为「探索」。「探索」**声明与其他视图的关系（称为 Joins），并用作查询的起点，或者在 SQL 术语中，它是 FROM子 句中引用的表的起点。（译者注：类似于数据计算和连接）
Looker 将「模型」称为数据库的自定义门户。本质上，它是一组相关的视图和探索，可以与业务用户共享以提供拖放式（Drag-and-Drop）数据探索。（译者注：类似于设计报表的可视化）
Looker 的三步数据建模过程从定义视图开始，到利用表间关系将视图合并为探索，然后结合探索联结成模型来共享给业务方。
开发模式与生产模式
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 服务器发送数据结果。
您甚至可以使用“高级”选项创建自定义警报，仅在结果集为空或自上次运行以来结果发生更改时才发送结果集。
使用 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 个原因：
">
目前来看，国内并没有类似的BI平台出现。现有的 GrowingIO，神策更多是产品分析工具，BI 要涉及到多数据源的整合。原因在于这块市场要滞后于其他ToB产品的发展。只有一批比较成熟的新企业服务产品出来，拥有相对稳定的数据规范，在这之上才能长出来一堆BI平台工具。目前这个趋势正在慢慢形成。
本文介绍 Looker 一些产品概念，在这之上，有些特性也颇有有趣。比如为了减少获取数据方面的难度，Looker设计了Block的概念，预置了一些常见的流程工具，帮助用户清洗和建立数据模型等。同时，还有Act 概念，他能方便和其他tob产品联动，如Slack，Jira等等。
原文来源：Holistic 的产品博客
原文作者：Holistic联合创始人兼首席设计师 Thanh Dinh
编译作者：陈新涛，微信公众号：三生万数（ID: ourStone），现任转转数据负责人，曾任美团外卖首任数据产品经理。
本文由 @陈新涛 翻译发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
