Neophyte
The custom table type may be your answer. I'd have to play with it to be sure.
If you haven't already requested it, I'd put in a feature request asking for what I call "metric families". Essentially you have one metric that can be collected via a variety of different DSs. All the DSs that collect that metric would belong to that metric family. All reporting (including dashboards, display in the resource tree, reports, basically everything) would group by metric family instead of DS. This would abstract away the actual collection method in favor of putting the metric at the forefront. For reference, CA did something like this with their CAPM product. This would allow displaying the metric "CPU" for any/all instances, within the same widget/report/etc. regardless of how it's collected. For example, you could have CPU for Cisco ASA, Cisco IOS, Palo Alto, Forcepoint, Juniper, Linux, Windows, SSH capable devices, and SNMP capable devices all in a single top-n graph. Another advantage of this is that logic could be built in to prefer one collection method over another (essentially a priority list of DSs) so that if a higher priority DS collects the data successfully, the lower priority DSs could be ignored. This would prevent duplicate polling for the same metric through different methods.