IcCube 模式加载速度优化

Question

当我将大的 table 加载到 IcCube 架构中时，每秒提取的行数在来自同一数据库的不同 table 之间差异很大。不幸的是，我不知道如何优化它，因为我不知道这个速度取决于什么。

例如，我有一个包含 3 个不同 table 的模式，每个模式有超过 2000 万行。一个 tables 加载了 15.000 rows/s，另一个加载了 100.000 rows/s

是否有任何最佳实践，如何最大限度地提高速度？它是否取决于使用此 table 或其他东西的维数、度量数、计算度量数？不同的依赖性有多严重？

Answer 1

假设您谈论的是用于构建多维数据集的表的处理速度（事实上，您不太可能希望处理数百万行的维度）。

架构定义

确保没有模式备份被激活并且存储策略是默认的（即内存）。

维度处理

维度不应该像事实那么大，但可能就是这样。有一个约束可能会减慢它的速度 'Names unique in parent'。如果尺寸没有按需要加载那么快，只需将其删除。

事实处理

icCube 正在通过首先从底层数据源加载数据然后处理这些数据来构建事实（也称为度量组）。 LOADING 和 PROCESSING 可以同时发生，并且每一个都可以运行在多个线程中以加快速度（您可以在 icCube.xml 中查看更多详细信息：loadReadingThreadCount, loadProcessingThreadCount, ...).

最后，icCube 无法比从数据源交付数据更快地构建事实。因此，首先要检查的是数据源的速度（在您的情况下是 SQL 查询的速度）。

数据源速度

从 icCube v6.8 开始，配置 icCube.loadProcessingFactsMode = NONE 允许在不构建事实的情况下处理事实。这样，查看事实的模式统计信息，您将实际看到 SQL 查询的速度。为方便起见，请确保您使用以下方式一一加载事实：icCube.loadReadingThreadCount = 1。然后您可以查看每个事实的“加载详细信息”中的架构统计信息。例如，

  F : Cashflow.Facts
    Rows Count         : 100'000'000
    Rows/Sec           : 225'000

从结果来看，如果速度看起来很慢，您可以对 SQL 查询进行故障排除 and/or 如果速度远低于数据源的本机客户端的速度，请联系 icCube。

下一步是看看是否可以以相同的速度并行加载多个事实。由于您有 3 个事实，您可以尝试：

icCube.loadProcessingFactsMode = NONE
icCube.loadReadingThreadCount  = 3

再次检查生成的架构统计信息，看看数据源是否能够以您喜欢的速度传送数据。

icCube处理速度

一旦知道了数据源的实际速度和可以使用的并行负载数，就可以确定最佳的处理线程数；您可以从 2（开箱即用配置）开始：

icCube.loadProcessingFactsMode    = FULL
icCube.loadReadingThreadCount     = 3
icCube.loadProcessingThreadCount  = 2

并增加它，直到达到无法获得更多增益的极限；例如，我们有一个客户使用以下设置达到 600'000 行/秒：

icCube.loadReadingThreadCount     = 3
icCube.loadProcessingThreadCount  = 6

icCube在加工过程中主要是建立内部索引。速度主要取决于要索引的层次结构的数量（您可以在每个事实统计信息中看到它们）。统计数据中提供了一些额外信息：

  F : Cashflow.Facts
    Elapsed            : 58m14s
    - whole processing : 2h16m22s      -- greater than elapsed because of several threads of processing
    - resolve members  : 1h25m49s      -- from member "keys" to internal icCube members
    - index & columns  : 50m30s        -- mainly about building the index

    Page Lock Time     : 25.45s        -- the lower the better
    Page Lock Count    : 105258

    Cache Hit          : 8'135'974'783 -- the higher the better (used by resolve members above)
    Cache Miss         : 241'674'486

关于用于处理“解析成员”的缓存的更多信息：

RM. Cache Dim :    dim |     type |    nil |      prev |       hit |      miss
              : Stocks | LRU:2048 |      0 |   205'350 | 2'359'923 | 2'785'420
              :   ...

对于每个索引维度，您可以看到 'prev/hit/miss' 统计信息。最好的办法是在 'prev' 列中解析所有成员（使用上一行信息的快速缓存），然后在 'hit' 列中解析。当心高'miss'，因为根据您的尺寸，这可能会非常昂贵。

正在处理队列

您可以 grep 模式 'processing-queue' 的日志，它告诉您处理是否使可用资源饱和。如果队列已满，您可以增加处理线程的数量并再次检查队列并获得收益。理想情况下，队列应保持为空。

核心数

快速说明，loadReading/Processing ThreadCount 的数量应该低于可用内核的数量，因为处理受到很大 CPU/RAM 限制。

Java 垃圾收集器

您也可以在日志文件中使用 grep "GC" 来调查 GC 行为（暂停）。如果出现问题，您可以在启动 icCube 时使用以下 Java 选项增加 G1 的 RAM and/or 实验：-XX:+UseG1GC.

希望对您有所帮助。

IcCube 模式加载速度优化

IcCube schema load speed optimization

iccube