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