作者|LiorGavish翻译|，或BI团队的新客户模型，是数据团队为公司增加价值的最有效方式之一。然而，开发外部数据产品有点不同：虽然增值更容易，但也更难。这是一个不同的举措，需要您的团队养成新习惯。同时，开发外部数据产品是一种新的思维方式，需要更高的协调性、纪律性和严谨性。这并不是说它不能由同一个团队完成，或者您的内部数据消费者无法获得与外部客户相同水平的服务。餐厅销售点供应商Toast的数据工程经理NoahAbramson最近谈到了他们在这方面的经验：“对我们来说，一个重要的价值是为我们的客户提供业务洞察力。餐厅，随着时间的推移，他们的表现如何？他们昨天的销售额是多少？谁是他们的主要客户？与我们的餐厅客户互动是数据平台团队的工作……我们说我们的客户是Toast员工。我们尽量让它们都可以访问尽可能多的数据。我们的团队服务所有内部数据访问，从产品到营销到客户支持再到硬件运营。”在观察平台构建内部数据产品和外部数据产品。在这篇文章中，我们总结了这些经验教训，并描述了数据团队如何成功推出外部数据通过了解将数据产品与构建内部产品区分开来的5个关键维度来了解数据产品，包括：开发将指导决策制定。什么是外部数据产品？有哪些数据应用示例？它们如何影响您的决策制定？外部数据产品是面向或影响客户的任何数据资产。这些可以包括客户账单中使用的数据集流程到完全独立的数据密集型应用程序，具有自己的客户操作界面系统。目前最热门的数据趋势之一是公司创建数据应用程序或在其SaaS产品中添加额外的层以帮助客户分析数据，例如上述Toast公司。Snowflake有一个有用的列表，包含五种常见类型的数据应用程序类型（完整参考架构）：客户360：需要完整了解客户关系的营销或销售自动化。物联网：对来自物联网设备和传感器的大量时间序列数据进行近乎实时的分析。应用程序健康和安全分析：通过分析大量日志数据识别潜在的安全威胁并监控应用程序健康状况。机器学习(ML)和数据科学：训练和部署机器学习模型以构建预测应用程序，例如推荐引擎。嵌入式分析：在应用程序内提供品牌分析和可视化。然而，外部数据产品不需要是完全内置的应用程序，也不需要集成到主要的SaaS产品中。例如，蒙特卡洛就不是这种情况。我们是一个数据密集型SaaS应用程序，可在UI中进行监控、警报和提供线索。客户还可以在UI中看到洞察报告，并可以选择使用Snowflake数据共享在他们自己的Snowflake环境中进行集成。在后一种情况下，我们只是为客户提供构建块，以进一步定制他们想要如何可视化或与其他数据结合的方式。全面了解数据应用程序或外部数据产品是什么很重要，因为这使团队能够确保更严格，最好是在工程之外。这些问题很重要：我们有哪些外部数据产品，它们是什么类型？他们在为谁服务？有哪些用例？他们是否满足了这些期望？我们如何衡量它？我们是否有合适的工具和流程？从以下五个维度来评估外部数据产品也很重要。架构与内部产品一样，外部数据产品可以利用各种数据云服务作为其平台的基础，包括数据湖或数据仓库。但是，许多人会利用像Snowflake这样的解决方案，因为它优化了大规模存储和查询关系数据的方式。这可能是您的团队第一次讨论多租户架构。在服务外部客户时，这是一个很大的变化和决策点。Snowflake在利用数据仓库作为产品基础时描述了三种多租户设计选项：多租户表：将租户集中在一个共享对象中，使租户能够有效地共享计算和其他资源。每个租户的对象：将租户隔离到同一帐户内的单独表、模式、数据库和存储库中。每个租户的帐户：将租户隔离到单独的Snowflake帐户中。每个选项都有优点和缺点，但总的来说，选择取决于需要更有效地扩展的内容——共享计算/存储或基于角色的数据访问。大多数内部产品在同一家公司内交付，并遵守相同的公司内部政策和法规。例如，如果营销团队的数据资产与法律团队的数据资产位于同一仓库中，他们就不会感到不安。但外部客户可能更关心。当然，您可以在堆栈中做出其他架构选择来减轻这些权衡。例如，MonteCarlo利用Snowflake的MTT多租户架构，使用令牌化等行业最佳实践在逻辑上分离客户数据。此外，我们使用混合架构，其中数据收集器嵌入到客户的环境中（但通常并不总是作为他们自己的虚拟私有云）。这意味着数据永远不会离开其环境。PII和敏感数据是抽象的，我们提取的是非敏感日志和评估其数据系统健康状况所需的指标聚合。架构决策过程的另一部分，类似于内部数据产品，是理解用例和工作负载。频率、规模和所需的时间表是什么？客户是否会在设定的时间接收数据、能够按需查询数据、实时访问数据，还是三者兼而有之？正如我们之前提到的，了解工作负载对于做出具有成本效益的架构选择非常有帮助。但是，与外部产品不同的是，可能需要支持更多种类的用例。在构建MonteCarlo时，我们不仅要考虑我们的关键任务生产工作负载，还要考虑我们的内部团队如何访问这些面向外部的数据。在这种情况下，内部分析和数据科学研究是作为我们机器学习驱动的异常监视器开发的一部分进行的。用户期望假设您有一个用户通常可以信任的数据产品，可以帮助回答他们的一些问题。数据每天刷新，仪表板具有可点击的元素，他们可以在其中向下钻取详细信息。这对于某些内部用户来说可能就足够了。他们可以比没有仪表板时更好地完成工作。另一方面，您的外部用户很生气。他们想要信任您的产品并希望它实时回答他们的所有问题。他们为什么不应该生气？毕竟，他们是在为您的产品付费，他们本可以选择竞争对手的产品。当数据就是产品时，数据质量就是产品质量。这个简单的事实就是为什么我们的数据观察平台的一些最热心的采用者正在利用它来支持他们的数据应用程序。例如，多渠道数字广告提供商Choozle在推出大规模平台升级以实现一流数据可靠性时采用了数据观察功能。“如果没有这样的工具，我们可能会监控最终结果的表格，但这可能会隐藏很多问题，”Choozle首席技术官AdamWoods说。广告活动中的一小段相关内容，但运行该广告活动的广告商会看到。有了【数据可观察性】，我们不需要妥协。我们可以监控所有3500个表。当数据面向客户或为面向客户的应用程序提供动力时，质量差甚至会损坏产品。例如，创建具有相同主键的重复对象的数据问题实际上导致了Netflix的中断。在规模和速度上，外部客户永远不想等待数据，他们想要更多的数据维度，以便他们可以切片和缝合到他们想要的内容。例如，我们的一位金融服务客户不仅关心数据新鲜度，还关心数据延迟，换句话说，即在支持查询的同时近乎实时地加载和更新数据的能力。Snowflake数据共享和Snowpipe可以帮助减少数据延迟。Blackboard解决了他们的延迟挑战，并通过使用Snowpipe从S3连续批量加载数据，使ETL工作负载的运行速度比以前快400倍。缩放数据维度也有助于差异化。再次以Choozle为例，根据Adam的升级平台：Snowflake允许我们将所有信息提供给我们的用户。例如，我们可以显示前20个邮政编码的广告活动效果，现在广告商可以根据需要访问美国所有30,000个邮政编码的数据。最后，当涉及到数据安全和隐私时，您的外部数据产品可能不仅需要在理论上说明PII，还需要通过SOCII等行业标准实际证明有效的安全控制。投资回报率绝大多数数据团队都没有根据硬投资回报率进行评估。事实上，具有讽刺意味的是，根据数据平台产品管理总监BrandonBeidel的说法，在绩效方面往往缺乏指标，RedVentures最初就是这种情况。下一层是衡量绩效。系统性能如何？如果有很多问题，那么也许我们没有以有效的方式构建我们的系统。或者，它可以告诉我们在哪里优化我们的时间和资源……拥有记录还可以使数据团队评估从“我认为团队做得好/不好”的感觉演变为更多基于数据的内容。内部数据产品也是如此。通常，成绩是临时的，“由于我们的新客户数据平台，我们的ROAS增加了3倍”，而不是根据生产成本或每个用户的成本来衡量。当您构建外部数据产品时，这种好运就消失了。产品经理需要了解如何定价，并且必须（在某个时候）有利可图。他们需要知道构建产品的启动成本，以及每个组件在维修时的成本（商品成本）。这对于尚未为其数据产品构建内部计费模型的数据团队来说是一个挑战，这些模型可以根据使用规模区分、跟踪和计费客户。自助“啊哈！”你说，“我们的团队已经允许内部用户使用自助服务，这并不是什么新鲜事。“这可能是真的，但自助服务和可用性的门槛也提高了。您的外部客户不能总是向您询问有关数据的问题，也不知道您是如何得出该客户流失概率的：”5sheets3.5inthefrowingface”。数据产品不能是一个黑盒子，你需要展示你的工作。UI必须是直观的，相关性必须是即时的，上下文必须是显而易见的。在构建内部数据时进行迭代当涉及到产品时，随着业务利益相关者收集、构建和迭代需求，最初通常很慢。之后，团队往往会启动并运行并继续下一个项目。数据会有补丁和修复停机时间，或者也许是为了满足内部SLA，但一般来说，你不会每个季度都重构这些仪表板。如前所述，付费客户有更高的期望，他们有更多的反馈。但是，你需要知道它即将推出并为它。吐司，例如，我它非常注重其流程的效率：“我们不仅倾听业务需求并大力支持它们，而且我们还在内部寻找并解决可扩展性问题，”Toast数据工程师AngieDelatorre说。“如果一项工作过去需要一个小时，现在需要三个小时，我们总是需要回头看看这些实例，这也会影响我们的OKR。在扩展操作方面，Snowflake产品管理总监ChrisChild建议：首先，将所有数据以最高保真度放在一个地方。只需将原始数据放在那里。其次，提出可重复的管道，将数据提供给数据分析师。你不想每次都想回到原始数据在你所做的一切中。前Uber数据产品经理AtulGupte讨论了在迭代数据产品时理解它的重要性：如何确定产品路线图的优先级，以及你需要为谁（通常是工程师）构建和设计（日常平台用户），包括分析师）。虽然这篇博客读起来像是一份你不应该构建外部数据产品的原因列表，但我希望它有助于揭开与这项艰巨但值得努力相关的内容的神秘面纱。挑战之谜。你不会构建性能在第一个冲刺中创建外部数据应用程序（没有人这样做），但我鼓励您构建、发布、迭代、冲洗和重复。原文链接：https://dzone.com/articles/why-building-an-external-data-product-is-so-hard译者介绍翟可，社区编辑，目前在杭州从事软件研发，并做过电子商务、征信等系统，享受分享知识的过程，丰富你的生活。
