Excel中的报告时间正在迅速用尽-用于呈现和分析信息的便捷工具的趋势在所有领域都可见。 我们已经在报告建筑物的数字化内部进行了很长时间的讨论，并选择了Tableau可视化和自助服务分析系统。 M. Video-Eldorado集团分析解决方案和报告部门负责人Alexander Bezugly谈到了建立战斗仪表板的经验和结果。我会马上说，并不是所有计划中的事情都可以实施，但是这次经历很有趣，希望对您也有帮助。 如果有人提出了如何做得更好的想法，我将非常感谢您的建议和想法。
关于我们遇到的和我们学到的东西的切入点。
我们从哪里开始
“ M. Video-Eldorado”具有完善的数据模型：具有所需存储深度的结构化信息以及大量固定格式的报告（有关详细信息，请参阅
本文 ）。 其中，分析师可以在Excel中创建数据透视表或格式化的邮件，或者在PowerPoint中为最终用户创建精美的演示文稿。
大约两年前，我们开始使用SAP Analysis（实际上是Excel的加载项-OLAP引擎上的数据透视表）而不是固定格式的报告来创建分析报告。 但是该工具无法满足所有用户的需求，其中大多数人继续使用分析师额外处理的信息。
我们的最终用户分为三类：
最高管理者 。 以清晰易懂的形式索取信息。
中层管理 ，高级用户。 对研究数据感兴趣并能够使用工具独立构建报告。 他们成为SAP Analysis中分析报告的主要用户。
大众用户 。 对数据的自我分析不感兴趣，请以Excel中的新闻通讯和数据透视表格式使用自由度有限的报表。
我们的想法是满足所有用户的需求，并为他们提供一个便捷的工具。 他们决定从高层管理人员入手。 他们需要方便的仪表板来分析关键业务成果。 因此，我们从Tableau入手，首先选择了两个领域：分析深度和广度有限的零售和在线销售，这将覆盖高层管理人员要求的大约80％的数据。
由于仪表板的用户是最高管理层，因此出现了产品的另一个附加KPI-响应速度。 没有人会等待20-30秒，直到数据更新。 导航必须在4-5秒内完成，最好立即进行锻炼。 we，我们未能实现这一目标。
这是我们的基本仪表板布局，如下所示：
关键思想是将左侧的19个主要KPI驱动程序组合起来，并在右侧显示其动态和主要属性的细分。 任务似乎并不复杂，可视化是合乎逻辑的并且可以理解，直到您进入细节为止。
细节1.数据量
该年度的主要销售表约占3亿行。 由于有必要反映上一年度和上一年度的动态，仅实际销售额的数据量就约为10亿行。 计划数据和在线销售单位的信息也分别存储。 因此，即使我们使用了SAP HANA内存数据库内存，查询中从当前存储中选择所有指标一周的查询速度仍约为15-20秒。 解决此问题的方法本身就是-额外的数据实现。 但是它也有陷阱，下面是关于它们的。
第2部分。非加性指标
我们有许多KPI与支票数量有关。 并且此指示符是行数（接收标头）的COUNT DISTINCT，并且根据所选属性显示不同的数量。 例如，应如何考虑该指标及其衍生工具：
为了确保计算的正确性，您可以：
- 在存储中即时进行此类指标的计算；
- 计算Tableau中的全部数据量，即 根据要求，在Tableau中，以检查位置的粒度提供所选过滤器的所有数据；
- 制作一个具体化的展示柜，在该展示柜中，将对所有变量的样品中的所有指标进行计算，从而得出不同的非累加结果。
显然，在示例中，UTE1和UTE2是表示产品层次结构的材料属性。 这不是一成不变的事情，因为它通过了公司内部的管理，因为 不同的产品组负责不同的经理。 当一组的所有层次都发生变化，相关性得到修订时，以及一组组从一个节点移动到另一组时，常数点也发生了变化，我们对该层次进行了许多全局修订。 在普通报告中，所有这些都是从物料的属性中即时考虑的，在实现此数据的情况下，有必要开发一种机制来跟踪这种变化并自动重载历史数据。 一项非常重要的任务。
细节3.数据比较
此项与上一项相似。 最重要的是，在分析公司时，习惯上与上一时期形成多个比较层次：
与上一期间的比较（每天，每周，每月）在此比较中，假设根据用户选择的时间段（例如一年中的第33周），我们必须在第32周之前显示动态，如果我们选择月份的数据（例如5月），则此比较将在4月之前显示动态。
与去年比较这里主要的警告是，按天和周比较时，您没有使用去年的同一天，即 您不能只将当前年份减去一年。 您必须观看星期几的比较。 相反，在比较月份时，您需要使用与去年完全相同的日历日。 leap年也有细微差别。 在源存储库中，所有信息都是按天分发的，没有单独的字段包含周，月，年。 因此，要在面板中获得完整的分析切片，有必要考虑一个周期（例如一周），而不是一个周期，而是四个星期，然后应将这些数据进行比较，以反映动态，偏差。 因此，这种在动态中进行比较的逻辑也可以在Tableau中或在店面一侧实现。 是的，我们当然在设计阶段就知道并考虑了这些细节，但是很难预测它们对最终仪表板性能的影响。
随着仪表板的引入，我们走了很长的敏捷之路。 我们的任务是为工作工具提供必要的数据，以便尽快进行测试。 因此，我们进行了冲刺，并从最小化当前存储方面的工作开始。
第1部分。Tableau中的信念
为了简化IT支持并快速实施更改，我们决定采用逻辑来计算非累加指标并比较Tableau中的过去期间。
阶段1.一切正常，没有改善窗帘。
此时，我们将Tableau连接到当前的店面，并决定查看如何在一年内计算支票数量。
结果：答案令人沮丧-20分钟。 网络数据蒸馏，Tableau负载高。 我们意识到，必须在HANA上实施具有非累加指标的逻辑。 这并没有给我们带来太大的恐惧，我们已经在BO和Analysis方面拥有类似的经验，并且能够在HANA中建立快速展示柜，以产生正确计算的非加性指标。 现在仍然可以在Tableau下对其进行调整。
阶段2。我们调整窗户，没有实现，一切都在进行中。
我们制作了一个单独的新展示柜，该展示柜可即时生成TABLEAU所需的数据。 总的来说，我们取得了很好的结果，我们将所有指标的形成时间从一周减少到了9-10秒。 我们真诚地希望在Tableau中，仪表板的响应时间在第一次打开时为20-30秒，然后由于缓存从10到12，这通常适合我们。
结果：首次打开仪表板：4-5分钟
任意点击：3-4分钟
没有人期望如此增加商店橱窗的工作量。
第2部分。浸泡在Tableau中
阶段1. Tableau性能分析和快速调整
我们开始分析Tableau在大多数时间上花费的时间。 为此，有一个很好的工具包，当然，还有Tableau。 我们确定的主要问题是Tableau构建的非常复杂的SQL查询。 它们主要与以下内容相关：
-数据转置。 由于Tableau没有用于转置数据集的工具，因此要使用所有KPI的详细视图来构建仪表板的左侧，我们必须创建一个案例表。 数据库中SQL查询的大小达到120,000个字符。
-时间段的选择。 在数据库级别进行这样的查询所花的时间比执行要长：
即 请求处理12秒+ 5秒执行。
我们决定简化Tableau端的计算逻辑，并将另一部分计算转移到店面和数据库级别。 带来了很好的效果。
首先，我们根据Wiki
Transpose-Wikipedia（免费百科全书）和
Elementary matrix-Wikipedia（免费百科全书）上描述的这种方法，在VIEW计算的最后阶段通过完全外部联接进行了
转置 。
也就是说，我们制作了一个调整表-转置矩阵（21x21），并将所有指标逐行细分。
那是：
它变成了：
数据库本身几乎不花时间进行自我转换。 一周内所有指标的要求都在大约10秒内完成。 但另一方面，在通过特定指标（即 对于显示动态和特定指标的详细细分的仪表板的右侧，展示柜在1-3秒之前就已经完成，因为 查询继续执行一个指标，现在数据库始终选择所有指标并过滤结果，然后再将结果返回到Tableau。
结果，仪表板的速度降低了近3倍。
结果：- 5秒-解析仪表板，可视化
- 15到20秒-准备在Tableau中执行预计算以编译查询
- 35-45秒-SQL查询的编译及其在Hana中的并行顺序执行
- 5秒-在Tableau中处理结果，排序，可视化的重新计算
- 当然，这样的结果并不适合该业务，因此我们继续进行优化。
阶段2。Tableau中的最小逻辑，完全实现
我们知道，不可能在可以运行10秒的商店窗口中建立具有几秒钟响应时间的仪表板，并且我们考虑了在数据库侧具体实现所需仪表板的数据的选项。 但面对上述全球性问题-非加性指标。 我们无法做到，因此在更改过滤器或扫描时，Tableau可以在不同的店面和针对不同产品层次结构计算的级别之间灵活切换（在示例中，三个不带UTE，UTE1和UTE2的查询形成不同的结果）。 因此，我们决定简化仪表板，放弃仪表板中的产品层次结构，并查看简化版本中的速度。
因此，在最后阶段，我们将一个单独的存储库放在一起，在其中存储了所有KPI。 在数据库方面，对此类存储库的任何请求都将在0.1-0.3秒内完成。 在仪表板中，我们得到以下结果：
首次开启：8-10秒
任意点击：6到7秒
Tableau花费的时间包括：
- 0.3秒 -解析仪表板并编译SQL查询
- 1.5-3秒 -在Hana中执行SQL查询以实现基本可视化（与第1点同时开始）
- 1.5-2秒 -呈现，重新计算可视化
- 1.3秒 -执行其他SQL查询以获取相关的过滤器值（品牌，部门，城市，商店），并解析结果
总结一下
在可视化方面，我们喜欢Tableau工具。 在原型设计阶段，我们检查了各种可视化元素，并在库中找到了所有这些元素，包括复杂的多级细分和多驱动程序瀑布。
在引入具有关键销售指标的仪表板后，我们遇到了无法克服的性能难题。 我们花了两个多月的时间，获得了一个功能上不完整的仪表板，其响应速度接近了允许的范围。 对于我自己，我们得出结论：
- Tableau不知道如何处理大量数据。 如果在原始数据模型中您有10 GB以上的数据（大约2亿X 50行），则仪表板会严重减慢速度-每次单击从10秒缩短至几分钟。 我们尝试了实时连接和提取。 工作速度是可比的。
- 使用多个存储（数据集）时的限制。 无法使用标准工具指示数据集的关系。 如果您使用解决方法来连接数据集，那么这将极大地影响性能。 在我们的案例中，我们考虑了在表示形式的每个所需部分中实现数据的选项，并在这些实现数据集上通过保存先前选择的过滤器进行切换-事实证明这在Tableau中是不可能做到的。
- 在Tableau中，无法创建动态参数。 您不能在实时连接期间使用用于过滤提取中的数据集的参数来填充数据集中的另一个选择的结果或另一个SQL查询的结果，而只能使用本机用户输入或常量。
- 与使用OLAP | PivotTable元素构建仪表板相关的限制。
在MSTR，SAP SAC，SAP Analysis中，如果将数据集添加到报表中，则默认情况下，报表上的所有对象都将相互连接。 在Tableau中不是，必须手动配置连接。 这可能更灵活，但是对于我们所有的仪表板，这是元素的强制性要求-因此，这是额外的人工成本。 此外，如果进行相关过滤器，例如，在过滤区域时，城市列表仅限于该区域的城市，您将立即收到对数据库的连续查询或提取，这显着降低了仪表板的速度。 - 功能限制。 无论是提取的内容，还是超过Live-connecta数据集的内容，您都无法进行批量转换。 这可以通过Tableau Prep完成，但这是一项额外的工作，并且是另一个需要研究和维护的工具。 例如，您不能转置数据，而是让它们加入您自己。 通过对必须通过case或if选择的各个列或字段进行转换而关闭的操作会生成非常复杂的SQL查询，在该查询中，数据库将大部分时间用于编译查询文本。 这些仪器的刚度必须在店面一级解决，这导致了更复杂的存储，额外的负载和转换。
我们没有结束Tableau。 但是，作为可用于构建工业仪表盘的工具以及可用于替换公司的整个公司报告系统并对其进行数字化的工具，Tableau不被考虑。
现在，我们正在另一个工具上积极开发类似的仪表板，与此同时，我们正在尝试修改Tableau中仪表板的体系结构，以进一步简化它。 如果社区感兴趣，我们将告诉您结果。
我们也正在等待您关于Tabeau如何基于如此大量的数据构建快速仪表板的想法或建议，因为我们还有一个网站，其中的数据比零售数据多得多。