Tableau 能否用于面向客户的 SaaS Web 应用程序？

Question

我希望有人可以帮助我回答几个有关 Tableau 的问题。我对该平台不太熟悉，但我有一个客户正在寻找一个报告/分析/数据可视化平台，他们可以将其用于许多内部应用程序（用于他们的员工）和外部应用程序（面向客户的互联网登录）应用程序。

驱动因素是他们的每个内部团队都使用了许多不同的技术，例如 SSRS、Crystal、自定义 ASP.NET 控件（Kendo/Telerik 等），但现在他们有机会选择一个可以服务的通用平台面向企业和面向客户的解决方案的大部分/所有未来报告和数据可视化需求。

他们正在寻找一个平台，该平台提供从具有基本过滤器/排序/组的简单网格，一直到具有数据切片和切块的丰富图表和临时报告的所有功能。

他们不会总是在这些应用程序中创建仪表板，因为它们是面向客户的，但他们可能希望为内部（内部网）应用程序提供仪表板。他们肯定希望能够构建真正的内部 BI 仪表板，以报告来自所有客户的所有这些在线应用程序的数据，他们向这些客户提供 SaaS/面向客户的 Web 应用程序。

我们的主要关注点之一是数据的安全性，因为其中一些面向客户的 Web 应用是多租户的，因此我们需要确保始终按客户端租户 ID 过滤数据。此外，我们有一个非常定制的安全模型，具有数据驱动的角色、可能会阻止显示某些类型的数据（例如 SSN、薪水等）的权限等。

Tableau 是否适合此模型，是否可以满足大部分/所有这些要求，还是更适合内部数据？

Answer 1

通过设置一个反向代理来前端您的多租户 Web 应用程序应该是完全可能的。有一个document 介绍如何使用带/不带 SSL 的 Tableau 将 Apache 设置为反向代理。

我熟悉如何将 Apache 配置为反向代理，因此这里是 Apache Web server 中有关如何设置反向代理规则的详细信息。

可能有一些关于 IIS/Nginx 前端的文档，所以你应该自己做一些谷歌搜索。

您需要通过将来自外部防火墙的访问限制为只读页面以及内部用户可以访问所有页面来强化您的网络服务器配置。既然您提到允许外部用户访问只读页面，我假设当用户选择使用过滤器时，来自外部请求的所有请求将只有 GET 请求和一些 PUT/POST 请求。所以你可以block external users from any request except GET。允许应用过滤器和分组的页面应该例外。

在您的 mutitenant 应用程序中，请确保您通过向外界公开的 apache 服务器 url 引用 tableau URL。如果使用任何未在 apache 中配置的 url，用户将收到拒绝访问错误。您需要为外部用户创建一个对画面页面具有只读访问权限的角色。要解决多用户问题，您需要设置 cookie 或其他东西来识别租户以及类似的东西来识别用户。要过滤 SSN 和更多信息，您可以使用过滤内容的 mod_proxy_html。您还可以使用mod_security module of Apache 阻止 SSN 和信用卡号。

参考文献：

• Configuring Apache Server as Proxy with Tableau
• Apache mod Proxy documentation
• Blocking POST requests
• mod_security FAQs

Answer 2

您的大部分问题都是肯定的 - 只需一点小字。

首先请记住，Tableau 主要用于可视化数据，因此它非常适合发布只读交互式数据视图。如果您希望允许最终用户编辑数据，则必须通过另一种方式进行。幸运的是，Tableau JavaScript API 让您可以使用自定义 Javascript 代码与 Tableau 密切交互。因此，如果您的需求主要是关于可视化，但希望能够触发一些自定义代码来修改您的某些应用程序中的数据，那么您应该没问题。但 Tableau 通常不是为创建自定义 CRUD 应用而设计的。

Tableau Server 的伟大之处在于，许多人可以学习使用它并发布自己的可视化 - 即使他们不知道如何编程。这并不意味着他们会第一次获得可视化设计奖，或者如果他们想要获得良好的性能，他们不应该学习有关数据库如何工作的知识。但这确实意味着最了解他们的数据的人可以学习设计和发布自己的可视化，而无需在积压队列中等待三个月，这样一个 IT 人员就可以更改按钮的颜色或添加字段。让优秀的系统、数据库和可视化人员来帮助培训、组织数据、设置治理和安全规则、优化等仍然是件好事，但业务用户可以学习成为能够控制其信息呈现方式的人.这是一件好事。

安全问题有几个变化的部分，通常 Tableau 会给出很好的答案，具体取决于您要完成的任务。 Tableau Server 确实支持使用站点的多租户。有相当灵活的权限和组策略系统。它可以使用 SAML 进行身份验证，并具有多种功能，可提供对特定用户/租户的访问权限。它几乎适用于所有数据库，在某些情况下，您可以将安全措施推送到数据库服务器——例如 SQL 服务器。有一个受信任的票证功能，您可以将一些授权决定推迟到另一个服务器，例如门户网站服务器。当 Tableau 可视化嵌入到其他网页时很有用。

可以开箱即用地支持大多数安全用例，但目前在 Tableau Server 中实施一些复杂的自定义访问控制情况非常棘手。您列出的所有声音都没有超出正常泳道，但了解您的安全模型是否过于复杂的唯一方法是深入了解细节。希望他们会为想要扩展它的用户发布一个自定义访问控制 API。

Answer 3

由于 Tableau public 也是基于 Tableau，我假设您可以使用自己的 Tableau 基础架构将仪表板公开。

Answer 4

总体而言，您肯定可以使用 Tableau 构建面向客户的仪表板。您可以快速构建和部署它们，正如其他人所提到的，您可以使用 Javascript API 对它们进行 iFrame，您可以自定义其中的大部分内容。但它并没有为用户交互提供完全的灵活性，如果您使用其他技术，您可以做到这一点。其他选项包括手动编码框架，然后使用图表应用程序。 对于简单的仪表板，如果您已经购买了核心许可证，那么 Tableau 将是显而易见的选择。但纵观行业的发展情况，Tableau 将无法满足所有需求。 如果使用 Tableau 1. 构建图表/表格/可视化是一种超级简单、高效的方式。 2. 您可以向客户公开低粒度数据，因为 Tableau 的专有列式数据库引擎，您可以通过仪表板潜在地公开数百万条记录。 3.可以使用Tableau的安全和访问控制机制。 4. 正如其他用户提到的，您可以使用可信票务机制轻松与其他应用程序（门户网站等）集成。

Tableau 方法面临的挑战。 1. 如果您有迟到的交易（在互联网世界中，几天后将点击标记为欺诈是很常​​见的）和迟到的交易，您必须完全刷新数据提取，这意味着如果您显示 13 个月的数据，你一直在刷新它。现在有了大数据，企业一直需要所有数据，这意味着您最终将在一天中提取数百万条记录。 2. 用户交互的灵活性非常小，例如菜单、下拉菜单等。您必须使用 Tableau 提供的功能。 3. 如果您在同一个仪表板页面上有多个图表，那么下载底层数据的用户友好方式不那么好。 4. 许多其他挑战，在仪表板页面上布置可视化，因为没有简单的方法来控制画布与像素控制、空白等。

在分析您的用例之后，您应该非常小心，在您投资 Tableau 之前，它是否是正确的产品。

Tableau 的主要功能来自其用于数据可视化/探索的桌面工具，而不是来自预构建的仪表板。 祝你好运。