PDF可视化系统延迟
热图是一种独特而强大的可视化延迟数据的方法。然而，解释结果一直是一个持续的挑战。
Brendan Gregg，Oracle
当 I/O 延迟以可视化热图的形式呈现时，会涌现出一些有趣而美观的模式。这些模式提供了对系统实际运行情况以及最终用户应用程序体验到的延迟类型的深入了解。在这些模式中看到的许多特征仍未被理解，但到目前为止，它们的分析正在揭示以前未知的系统性行为。
延迟简介
延迟是等待所花费的时间。当应用程序请求的同步组件引起延迟时，它会对性能产生直接影响。这使得解释很简单——延迟越高，性能越差。对于许多其他常用于性能分析的统计类型，例如利用率、IOPS（每秒 I/O）和吞吐量，这种简单的解释是不可能的。这些统计数据通常更适合容量规划和理解工作负载的性质。然而，对于识别性能问题，理解延迟至关重要。
对于从应用程序服务器测量的应用程序协议，延迟可以指从收到请求到发送完成的时间——例如，Web 服务器响应 HTTP GET 请求或文件服务器响应 NFS（网络文件系统）操作的时间。这种测量对于性能分析非常重要，因为客户端和最终用户通常在这段时间内处于等待状态。
对于磁盘等资源组件，延迟可以指发送 I/O 请求和接收完成中断之间的时间间隔。高磁盘延迟通常转化为应用程序性能问题，但并非总是如此：文件系统可能会定期将脏缓存数据刷新到磁盘；然而，I/O 对于应用程序是异步的。例如，Oracle Solaris ZFS 文件系统定期将事务组刷新到磁盘，导致平均磁盘延迟出现峰值。这并不反映 ZFS 用户体验到的文件系统延迟，因为平均磁盘延迟包括来自事务刷新的异步写入。（如果分别观察读取和写入延迟，这种误解会在某种程度上得到缓解，因为事务刷新仅影响写入延迟。）
虽然检查延迟是可取的，但从历史上看，对于某些组件来说，直接测量延迟一直很困难甚至不可能。例如，检查服务器端的应用程序级延迟可能涉及检测应用程序或检查网络数据包捕获并将请求与响应关联起来。然而，随着 DTrace,1 的引入，在生产系统中甚至实时地在任意点测量延迟已成为可能。
延迟热图
鉴于能够在任意感兴趣的点跟踪延迟，问题就变成了对这些数据进行有效的可视化呈现。繁忙的系统每秒可能处理数十万个 I/O 事件，每个事件都提供完成时间和 I/O 延迟。一种方法是将数据汇总为每秒的平均延迟和最大延迟，这可以以折线图的形式呈现。虽然这允许随时间检查平均延迟，但无法识别该延迟的实际组成或分布（如果提供最大值的话，也只能识别最大值）。
为了检查随时间的分布，可以使用热图等可视化方法。热图在系统可观察性工具中的使用并不频繁，但偶尔会出现用于映射磁盘 I/O 的访问模式。这方面的一个例子是 taztool (1995)，它显示了一个热图，x 轴表示时间，y 轴表示磁盘 I/O 偏移量，通过可视化磁盘 I/O 的位置，可以识别随机和顺序磁盘 I/O 模式。5
为了可视化延迟随时间的分布，可以创建一个热图，x 轴表示时间，y 轴表示延迟。热图是一个彩色阴影像素矩阵，其中每个像素代表特定的时间和延迟范围。在该时间和延迟范围内发生的 I/O 量由像素的颜色深浅表示：颜色越深表示 I/O 越多，颜色越浅表示 I/O 越少。除了显示延迟分布外，热图还通过查找具有最高延迟的像素以及颜色最深区域的像素来传达有关最大延迟和平均延迟的详细信息。
为了使延迟热图最有效，每个像素代表的时间和延迟范围应足够大，以便允许多个 I/O 操作落入其中。这允许选择较深的阴影，并观察不同阴影显示出的模式。如果范围太小，许多像素可能只代表一个 I/O，并且热图的大部分区域可能以相同的颜色阴影显示；这也可能降低相邻像素被着色的可能性，并且热图可能看起来更像散点图。
可以将从浅到深的可能颜色阴影范围应用于生成的每个热图。这可以线性应用：将 I/O 最多的像素分配为最深的颜色，所有其他像素都赋予从最深 I/O 计数缩放的阴影。这种方法的缺点是重要的细节可能会显得模糊不清。偏离常态的延迟尤其值得检查，尤其是高延迟的发生。由于这些可能只占工作负载的一小部分——可能不到 1%——颜色阴影可能非常浅且难以看到。可以改为应用伪彩色调色板来突出这些细微的细节，但权衡之处在于，颜色阴影随后不能用于衡量像素之间相对的 I/O 计数。
热图可视化的一个特殊优势是能够看到异常值。对于延迟热图，这些可能是偶尔发生的具有特别高延迟的 I/O 操作，这可能会导致严重的性能问题。如果自动选择 y 轴刻度来显示所有数据，则异常值很容易被识别为热图顶部的偶尔出现的像素。这也带来了一个问题：单个高延迟 I/O 将重新缩放 y 轴，从而压缩大部分数据。如果需要，可以消除异常值，以便可以详细检查大部分 I/O。一种自动方法可以是根据需要从显示中删除一定百分比（例如，0.1%）的最高延迟 I/O。
为了生成延迟热图，需要收集每个 I/O 事件的数据：完成时间和 I/O 延迟。然后将这些数据分组到热图的时间/延迟像素中，并根据像素的 I/O 计数对像素进行着色。如果保留了原始 I/O 事件数据，则可以为任何时间和延迟范围以及不同分辨率重新生成热图。这方面的一个问题是数据的大小：繁忙的生产系统每秒可能处理数十万个 I/O 事件。长时间（例如几天或几周）持续收集这些数据可能会变得令人望而却步——无论是对于所需的存储空间还是处理和生成热图的时间而言。一种解决方案是将这些数据汇总到足够高的时间和延迟分辨率，并保存汇总后的数据。在显示热图时，这些摘要将重新采样到所需的分辨率。
热图详解
延迟热图是作为名为 Analytics 的系统可观察性工具的一部分实现的。该实现允许实时查看它们，并以一秒的粒度持续记录数据以供以后查看。DTrace 使这一切成为可能并达到最佳效果，DTrace 能够在内核中跟踪和汇总数据到足够的分辨率，并将这些摘要每秒返回到用户空间。然后，用户空间软件重新采样汇总的数据以生成热图。
图 1 中的热图是 Analytics 的示例屏幕截图，显示了 NFS 读取工作负载的延迟分布以及在使用额外的基于闪存的缓存层时对 NFS 延迟的影响。此缓存层在 19:31:38 启用，该时间在此屏幕截图中已居中于 x 轴。详细解释此热图将展示这种可视化对于理解这些系统组件的作用及其对交付的 NFS 延迟的影响是多么有效。
在此屏幕截图中，热图左侧显示了一个面板，用于显示平均 IOPS 计数。“范围平均值：”和“每秒 8494 次操作”在面板的上方和下方显示可见时间范围（x 轴）的平均 NFS I/O 每秒。面板内是延迟范围的平均值，第一个显示 0 到 333 微秒之间的平均 2,006 NFS IOPS。这些延迟范围中的每一个都对应于热图上的一行像素。
对于 19:31:38 之前的时间，系统从两个位置之一提供 NFS 读取：基于 DRAM 的缓存或磁盘存储。如果请求的 I/O 不在 DRAM 缓存中，则会改为从磁盘检索。在热图中，可以看到两个级别的延迟。这些延迟对应于
- DRAM 命中，在热图底部显示为深色线
- 磁盘命中，显示为从 2 毫秒及以上的延迟阴影云
这是预期的。DRAM 命中具有非常低的延迟，并显示在最低延迟像素中。此像素表示 0 到 333 微秒之间的延迟，这是当前显示的热图的分辨率限制。由于记录的数据具有更高的分辨率，因此可以使用不同的垂直比例重新绘制此热图以显示更精细的细节。通过放大到较低的延迟，发现 DRAM 命中主要在 0 到 21 微秒的范围内。2
磁盘命中的延迟分布范围很广，从大约 2 毫秒到显示的热图顶部 10 毫秒。磁盘 I/O 的返回延迟包括旋转、寻道和总线 I/O 传输时间。由于磁盘是以随机 I/O 模式访问的，仅旋转延迟就可能高达 8.3 毫秒，即这些磁盘上完成一次完整旋转的时间。这种旋转延迟被认为是热图中看到的大部分随机模式的原因。
19:31:38 之前的热图还识别出一个 I/O 不太频繁的延迟范围：在 DRAM 命中和磁盘命中之间，从 334 微秒到大约 2 毫秒的较浅的条带。ZFS6 中的混合存储池4 通过添加基于闪存的缓存层解决了此延迟差距。闪存比 DRAM 慢，但比磁盘快，并以 SSD（固态磁盘）的形式集成到此 NFS 服务器中。然后，NFS 读取可以从以下三个位置之一提供服务，优先级顺序为：基于 DRAM 的缓存、基于闪存的缓存或磁盘存储。
启用基于闪存的缓存发生在 19:31:38，之后可以看到三个级别的延迟
- DRAM 命中，在热图底部显示为深色线
- SSD 命中，延迟小于约 2 毫秒
- 磁盘命中，由于添加了额外的缓存层，因此变得更浅，因为到达磁盘的请求减少了
此热图表明，基于闪存的缓存降低了原本将从磁盘提供的 I/O 的延迟。所有三个系统组件都被可视化，包括它们的延迟范围和该范围内延迟的分布。它还表明，磁盘 I/O 仍然发生，尽管速率降低了。这些都是热图可视化提供的有用信息。想象一下，如果改为以平均延迟的折线图形式呈现此数据：唯一可见的信息将是在启用缓存时平均延迟略有降低（由于平均延迟将主要受大量 DRAM 命中的影响，因此降低幅度很小）。
大多数热图都像这个一样容易理解。接下来是我们发现的意想不到的热图，它们展示了有趣的模式，但尚未完全理解。
冰湖
工作负载和目标很简单：单个客户端具有单个线程，对 NFS 共享执行顺序同步 8 KB 写入。NFS 服务器具有 22 个 7,200 RPM 的磁盘，这些磁盘是 ZFS 条带化池的一部分。
由于这些是同步写入，因此只有在数据写入到稳定存储后，NFS 请求才能完成。此测试未使用基于闪存的日志设备，因此预计延迟会很高，因为数据必须写入到 7,200 RPM 的磁盘。
您可能期望延迟在 0 到 10 毫秒之间随机分布，并且热图显示为白噪声。实际结果如图 2 所示。
与随机分布相反，延迟在随时间上升和下降的各个级别聚集在一起，从而产生一种称为冰湖的模式中的线条。这是出乎意料的，尤其是考虑到工作负载的简单性。
仅从平均延迟或最大延迟无法识别此行为——想象一下将 y 轴信息压缩为单个折线图。即使在检查每个 I/O 事件时，例如通过使用基于 DTrace 的 iosnoop 工具在磁盘级别进行跟踪，也难以识别此行为，因为数据量巨大（数千行输出）。
理解此模式的第一步是检查 22 个磁盘中的每一个是否贡献了不同的线条。图 3 显示了来自单个磁盘的磁盘 I/O 延迟，这证实了每个磁盘都在为该模式贡献线条。
点击此处查看更高分辨率的图像
下一步是调查为什么有些线条增加而有些线条减少。增加可能是由于应用程序与磁盘旋转同步请求 I/O，并且 ZFS 沿磁盘上的磁道写入扇区，从而在每次 I/O 时增加磁盘旋转延迟（尽管这无法解释为什么某些磁盘的延迟会增加而其他磁盘的延迟会减少）。
为了简化问题，使用单磁盘池重复了测试。图 4 显示，大多数 NFS 延迟在 7.86 毫秒到 8.20 毫秒之间，这接近 7,200 RPM 磁盘的 8.33 毫秒旋转速度。检查了磁盘 I/O 偏移量（同时使用 Analytics 和 iosnoop），结果表明 ZFS 在磁盘上顺序写入 8 KB I/O。NFS 延迟较小的原因可能是客户端和网络延迟：一旦一个 I/O 完成，磁盘在将 NFS 完成发送到客户端时会继续旋转；客户端处理它，请求下一次写入，然后向磁盘请求下一次写入。当这一切发生时，磁盘已经旋转了一点，因此不需要完整旋转即可写出下一个偏移量。这将解释热图中显示的大部分 I/O；然而，顶部线条的原因仍然未知（它显示每秒平均一个 I/O，延迟从 9.29 毫秒到 9.64 毫秒，并且通过 Analytics 使用的伪彩色调色板清晰可见）。
ZFS 通过写入 ZIL（ZFS intent 日志）来处理同步写入，这些日志稍后将被分组并作为 TXG（事务组）刷新到磁盘。ZIL 预计会按顺序写入，因此热图也符合预期（除了顶部的线条）。对于双磁盘条带化池，情况会有所不同，因为 ZFS 将在每个磁盘上都有一个 ZIL，并以轮询方式写入它们。对此进行了测试，图 5 显示了双磁盘池上的结果 NFS 延迟以及池中每个磁盘的磁盘 I/O 延迟。现在可以推测延迟增加和减少的原因：当一个磁盘上的延迟增加时，另一个磁盘继续旋转，并且在发出请求时具有相应的较小延迟。图 2 中的热图是这种情况的扩展，使用了 22 个磁盘而不是两个。
最初出现斜坡的原因仍未确定。磁盘正在写入稳步增加的偏移量，预计该偏移量将以顺序方式放置在磁盘磁道上（磁盘实际如何处理它取决于磁盘）。如果旋转的起点是固定的，则每次写入的旋转延迟都会随着磁盘旋转更远以达到增加的偏移量而稳步增加（直到达到完整旋转）。然而，起点不是固定的；相反，它是前一次 I/O 的终点，其中包括起始偏移量和 I/O 大小。由于每个偏移量增量和 I/O 大小相同，因此下一次 I/O 的旋转延迟也应相同。与单磁盘池分析一样，斜坡实际上可能是磁盘继续旋转时客户端和网络延迟的结果。斜坡变化的原因也是未知的，如图 5 中 20:10:00 到 20:10:45 之间所示。
此工作负载在其他存储配置（例如镜像、单奇偶校验和双奇偶校验 RAID）上进行了测试。图 6 显示了此工作负载在 22 个磁盘的镜像池上的情况。在这里，ZIL 在成对的磁盘之间进行镜像，并且只有当镜像两侧都存在 ZIL 时，才认为对稳定存储的写入完成；因此，NFS I/O 延迟来自该对中最慢的磁盘。这使得热图偏向于更高的延迟。在单奇偶校验和双奇偶校验 RAID 上也看到了类似且更大的影响（此处未包含其热图屏幕截图）。
总结一下我们对冰湖的了解：线条来自单个磁盘，磁盘对会导致延迟增加和减少。导致此模式的延迟随时间变化的实际原因尚未确定；导致增加/减少速率变化的原因（图 5 中看到的斜率变化）也是未知的；并且，单磁盘池中看到的较高延迟线（图 4）也尚未理解。以这种方式可视化延迟显然提出了比答案更多的问题。
彩虹翼龙
与冰湖一样，彩虹翼龙是另一个简单的工作负载，它产生了令人惊讶的复杂模式。这次在具有 48 个磁盘（分布在两个 JBOD（只是一堆磁盘）机箱中）的系统上检查磁盘 I/O 延迟。执行本地工作负载以通过以顺序 128 KB 读取逐个添加磁盘来研究 I/O 总线吞吐量，同时在吞吐量图中寻找拐点。预计对于使用的 I/O 大小，延迟将是一致的，并显示为一条窄线，随着 I/O 子系统总线（包括 HyperTransport、PCIe 和 SAS）上的争用增加，延迟可能会略有增加。当其中一条总线达到饱和时，预计延迟会更急剧地增加。因此，仅预期有两个特征：延迟一致的逐渐增加，以及稍后由于争用而导致延迟变得不太一致的急剧增加。
图 7 显示了此测试的吞吐量图和延迟热图。 每两秒向工作负载添加一个新磁盘，并且可以在 17:55 看到磁盘吞吐量图中的拐点。找到此拐点是此实验的最初目的；然而，引人注目的是延迟热图。我们将其命名为彩虹翼龙。
磁盘 I/O 字节图（彩虹）显示了三个特征：初始上升，然后是斜率减小，然后是衰减。通过将磁盘图与热图对应起来，可以看到热图中的特征在特定磁盘计数时出现。热图显示以下特征。
“喙”出现在磁盘 1 到磁盘 8 之间。两级延迟的原因尚不完全清楚，但一项实验提供了一个线索：如果重复读取相同的数据以确保磁盘缓存命中，则只会看到一条低延迟线。当按顺序读取这些磁盘时，会出现双线模式，这表明第二条线是用于磁盘缓存未命中的。使用标准工具进一步分析这一点很困难：可以跟踪到磁盘的输入及其返回的延迟，但无法了解磁盘内部结构，例如磁盘数据控制器的操作。
当添加第九个磁盘时，“喙”变成了“头部”。磁盘使用两条 SAS 电缆连接，每条电缆 x4 端口，总共提供八个 SAS 端口。访问第九个磁盘可能会导致 SAS 控制器中这些端口上的争用以及相应的随机延迟模式。当磁盘使用单条 x4 SAS 电缆连接时，“喙”到“头部”的过渡发生在第五个磁盘。
在磁盘 9 和磁盘 12 之间的头部顶部形成一个“凸起”，显示延迟略有增加。原因尚不确定，但可能来自 SAS 端口的争用增加。形成磁盘 13 和磁盘 14 处的“颈部”的延迟降低的原因也不得而知。
大约在磁盘 15 和磁盘 20 之间是“翅膀”。延迟的突然增加导致磁盘吞吐量图中的拐点。这种争用的来源尚不清楚，尽管另一个使用单条 x4 SAS 电缆连接到单个 JBOD 的磁盘扩展实验产生了无翼翼龙。
从大约磁盘 20 开始，当磁盘继续添加时，延迟继续上升并变得不太一致。预计这是 SAS 控制器卡上的 PCIe-gen1 总线争用。
所有这些特征都通过热图可见，但对于形成输入的单个 I/O 事件来说是完全未知的：它们仅提供完成时间和 I/O 延迟，而磁盘计数却增加了。热图已从此数据中对 I/O 子系统进行成像，显示了被怀疑是磁盘缓存、SAS 端口和 PCIe 总线的组件。
总结一下彩虹翼龙：准确了解的信息很少，还需要进行更多的调查。但这确实表明了简单的可视化可以变得多么深入。
延迟级别
对于彩虹翼龙，通过步进顺序磁盘读取工作负载来测试 I/O 总线吞吐量。这在具有更强大的 I/O 子系统的不同系统上重复进行，发现来自所有可用磁盘的顺序磁盘读取无法达到 I/O 总线饱和（没有拐点）。为了查看是否可以找到限制，工作负载更改为从每个磁盘重复读取相同的 128 KB，以便每个磁盘只能通过从其缓存返回来提供更高的吞吐量。结果如图 8 所示。
在 15:39 到 15:40 之间达到了拐点，尽管在磁盘字节图中很难看到。此时，出现了一个延迟增加的级别；稍后，还有另一个级别（在此屏幕截图中已选择）。在各个点，似乎延迟级别已提升到更高的级别。这是最近发现的，到目前为止尚不清楚。此处提供它是延迟热图挖掘出的意外细节的另一个示例。
对 JBOD 大喊大叫
虽然不如之前的示例那样美观，但下一个热图背后的故事已经获得了一些恶名，值得包含在内，以强调这是一个识别问题的延迟热图。
该系统包括几个具有数十个磁盘的 JBOD，并且正在执行流式写入工作负载。我发现，如果我尽可能大声地对着 JBOD 大喊大叫，磁盘会返回具有极高延迟的 I/O。图 9 显示了来自此不寻常测试的热图。
热图显示了两个延迟峰值，分别对应于我的每次喊叫。我们将此发现录制下来并上传到 YouTube，我在其中将这种效应描述为磁盘振动。3 此后有人建议，由于喊叫的音量，最好将其描述为冲击效应，而不是振动。
热图中显示的受影响的磁盘 I/O 具有非常高的延迟——超过一秒。如果改为跟踪平均延迟，则在同时执行超过 8,000 个更快 I/O 事件的系统上，几个高延迟 I/O 事件可能会被淹没。从这次经验中得到的教训是延迟热图能够多么出色地识别这种扰动。
其他应用
前面的示例显示了部署 ZFS 文件系统（通过 NFS 访问）的系统的延迟热图。延迟热图也适用于其他本地和远程文件系统类型（例如，UFS、HFS+、CIFS），在这些类型中，可以以类似的方式识别和解释特征。例如，在 Solaris 上部署的 UFS（Unix 文件系统）执行一个名为fsflush定期将脏数据写入磁盘。这可以更新分布在磁盘上的 UFS 柱面组块，从而导致由寻道和旋转延迟引起的高延迟 I/O。在旧版本的 Solaris 上，写入间隔为五秒 (tune_t_fsflushr)，因此在磁盘 I/O 的延迟热图上，这可能很容易识别，表现为间隔五秒的高延迟突发。
除了延迟之外，热图可视化还可以应用于其他指标。I/O 大小可以可视化为 y 轴上具有大小（字节）的热图，从而可以识别任何特别大或小的 I/O，这两者都因不同的原因而有趣。I/O 位置可以可视化为 y 轴上具有偏移量的热图（如前所述），从而可以识别随机或顺序 I/O。
组件的利用率也可以可视化为热图，显示各个组件的百分比利用率，而不是显示所有组件的平均百分比利用率。利用率可以显示在 y 轴上，并且该利用率下的组件数量可以由热图像素的颜色显示。这对于检查磁盘和 CPU 利用率，以检查负载在这些组件之间如何平衡特别有用。较深颜色的紧密分组表示负载均衡，而较浅像素的云表示负载不均衡。
异常值也很有趣：利用率为 100% 的单个 CPU 可能在热图顶部显示为一条浅线，这通常是软件可伸缩性问题（单线程执行）的结果。利用率为 100% 的单个磁盘也很有趣，可能是磁盘故障的结果。这无法仅使用平均值或最大值来识别：最大值无法区分利用率为 100% 的单个磁盘和利用率为 100% 的多个磁盘，这在正常的负载突发期间可能会发生。
此处提到的所有热图都在 Analytics 中实现。与 I/O 延迟热图一起，利用率热图被证明对于快速识别性能问题特别有用。
结论
将延迟呈现为热图是一种有效的方法，可以识别否则可能会被遗漏的细微特征，例如在检查每秒平均延迟或最大延迟时。尽管本文中显示的许多特征尚不清楚，但既然已知它们的存在，我们就可以研究它们并在一段时间后正确识别它们。一些热图，例如彩虹翼龙，也是简单的可视化可以变得多么深入和美观的有趣示例。
问
致谢
感谢 Bryan Cantrill 开发 Analytics，包括此处看到的热图功能，并共同发明了 DTrace，本文基于 DTrace。
参考文献
1. Cantrill, B. 2006. Hidden in plain sight. 4(1): 26-36; https://queue.org.cn/detail.
2. Gregg, B. 2009 (Feb. 6). DRAM latency; http://blogs.sun.com/brendan/
3. Gregg, B. 2008. Shouting in the Datacenter; http://www.youtube.com/watch?
4. Leventhal, A. 2008. Flash storage today. 6(4): 24-30; https://queue.org.cn/detail.
5. taztool; http://www.solarisinternals.
6. ZFS; http://en.wikipedia.org/wiki/
喜欢它，讨厌它？请告诉我们
Brendan Gregg 是 Oracle 的首席软件工程师，他在 Fishworks 高级开发团队从事性能分析和可观察性工作。他还是 DTraceToolkit 的创建者，并且是 Solaris Performance and Tools （Prentice Hall）的合著者。
© 2010, Oracle 和/或其附属公司。保留所有权利。
最初发表于 Queue 第 8 卷，第 5 期—
在 数字图书馆 中评论本文
更多相关文章
David Crandall, Noah Snavely - 使用互联网照片集对人和地点进行建模
本文介绍了我们如何使用在线照片集来重建关于世界及其居民在全球和本地范围内的信息。这项工作得益于社交内容共享网站的显着增长，这些网站创建了大量的用户生成视觉数据在线集合。仅 Flickr.com 目前就托管了超过 60 亿张由超过 4000 万独立用户拍摄的图像，而 Facebook.com 表示其每天增长近 2.5 亿张照片。
Jeffrey Heer, Ben Shneiderman - 用于视觉分析的交互式动态
数字数据规模和可用性的不断提高为公共政策、科学发现、商业策略甚至我们的个人生活提供了非凡的资源。然而，为了充分利用这些数据，用户必须能够理解它：追寻问题、发现感兴趣的模式并识别（并可能纠正）错误。与数据管理系统和统计算法相结合，分析需要针对数据中发现的集群、趋势和异常值进行特定领域意义的情境化人类判断。
Robert DeLine, Gina Venolia, Kael Rowan - 使用代码地图进行软件开发
为了更好地理解专业软件开发人员如何使用代码的可视化表示，我们采访了微软的九位开发人员，以确定常见场景，然后调查了 400 多名开发人员，以更深入地了解这些场景。
Jeffrey Heer, Michael Bostock, Vadim Ogievetsky - 可视化动物园导览
感谢传感、网络和数据管理方面的进步，我们的社会正以惊人的速度产生数字信息。根据一项估计，仅在 2010 年，我们将生成 1200 艾字节——相当于美国国会图书馆内容的 6000 万倍。在这数据洪流中，蕴藏着关于我们如何开展业务、管理政府和个人生活的丰富有价值的信息。为了充分利用这些信息，我们必须找到有意义地探索、关联和交流数据的方法。
© 版权所有。