嵌入式悲痛的五个阶段
因此，您想将数据呈现给您的客户... 但代价是什么？
当您考虑将数据呈现给您的客户时，您可能正在想象定制图表、颜色编码的指标和大量的空白。
虽然仪表盘能够向您的客户提供自助分析，但它们很少是完成这项工作的最佳工具。
本文向您展示了为什么从嵌入式仪表盘（或数据的任何预定义视图）开始往往会导致可维护性和可扩展性问题。
如果您已经确信，请查看您可以采取的嵌入方法，以避免给自己带来麻烦。
示例用例
假设您运营一个电子商务平台。您的分析师构建了一个仪表盘，您的团队可以在其中根据每个商户的数据（例如每次访问的客户数、随时间推移的交易量和平均客户评分）来查看每个商户的成功情况。
您计划将仪表盘嵌入到面向商户的应用程序中，以便您的商户可以利用这些指标和可视化来了解和发展他们的业务。
第 1 阶段：否认
人们每天都在使用您的仪表盘，因此您非常有信心它已经达到了高质量外部分析的标准。
在阅读交付客户分析的策略后，您决定结合单点登录 (SSO)、数据沙箱和白标，将您现有的仪表盘直接嵌入到面向商户的应用程序中。
第 2 阶段：愤怒
在推出第一个迭代版本几周后，您发现您的商户喜欢使用该仪表盘，以至于您的数据仓库无法完全扩展以满足他们的热情。
您的商户开始对仪表盘加载时间过长感到沮丧。您决定将仪表盘的数据源复制到更快的数据仓库，并且为了稳妥起见，您调整了实例数量。
第 3 阶段：讨价还价
仪表盘的功能请求开始涌入——似乎您的商户使用数据越多，他们对过滤器、透视和自定义计算的疑问就越多。
您的一些商户希望使用他们自己的收入计算方法。其他人对折线图与条形图的看法强烈。一小部分（但声音很大）人甚至根本不在乎图表——他们只想要一种获取去匿名化客户数据以运行个性化活动的方式。
第 4 阶段：沮丧
您意识到数据库中的表需要一些严肃的 SQL 魔法才能支持您的商户要求的最新仪表盘添加。
您的团队没有时间重构架构（他们正忙于维护现有视图），因此您开始编写自定义 SQL 脚本以满足您最重要的商户的需求。您的数据仓库变得杂乱无章，堆满了任意表。
即使您的产品团队尽力跟踪对更多数据和更多查看数据方式的请求，您曾经成功的内部仪表盘似乎也已变异成一个由数百个图块组成的怪胎。
当您最终有时间查看商户仪表盘的使用统计数据时，您伤心地得知您的商户只看过这些图块一次，如果看过的话。
第 5 阶段：接受
您很高兴地记得整个场景都是假设性的。当您反思您模拟的创伤时，您开始理解
- 人们通过以不同的方式查看数据来获得答案。
- 仪表盘请求（我可以获得数据的特定视图吗？）实际上是对自助服务数据的请求（我可以获得尽可能多的视图来回答我的问题吗？）。
- 您不应为了响应仪表盘请求而创建或更新表。
思维模式转变：从嵌入式仪表盘到嵌入式数据模型
开始嵌入的最佳方法是将您的数据模型视为最终产品（数据模型是指字段、表和关系的在您的数据仓库中的设计）。
如果您的数据模型对非工程师来说很容易查找、理解、修改和验证，您将使他们有信心和自主权以对他们最有意义的方式使用数据（并从处理临时仪表盘请求中解放您的时间）。
当然，您仍然希望避免创建全新的临时数据模型请求类别。现在您已经有了一些空闲时间，非常值得您花时间构建数据模型，这些模型不仅从工程角度进行了优化，而且还从产品设计的角度进行了优化。
延伸阅读
了解有关数据建模策略、设计和实施的更多信息
下一步：分析的推拉
如何培养一种使用数据来制定决策的文化。