JindoCube在E-MapReduce 3.24.0及之后版本中可用。本文主要介绍E-MapReduce JindoCube的安装、部署和使用等。

前提条件

已创建表或者视图。

概述

JindoCube是E-MapReduce Spark支持的高级特性，通过预计算加速数据处理，实现十倍甚至百倍的性能提升。您可以将任意View表示的数据进行持久化，持久化的数据可以保存在HDFS或OSS等任意Spark支持的DataSource中。EMR Spark自动发现可用的已持久化数据，并优化执行计划，对用户完全透明。JindoCube主要用于查询模式相对比较固定的业务场景，通过提前设计JindoCube，对数据进行预计算和预组织，从而加速业务查询的速度，常见的使用场景包括MOLAP多维分析、报表生成、数据Dashboard和跨集群数据同步等。

JindoCube的安装与部署

JindoCube作为EMR Spark组件的高级特性，所有使用EMR Spark提交的Dataset、DataFrame API、SQL任务，均可以基于JindoCube进行加速，无须额外的组件部署与维护。

  1. UI页面展示。
    JindoCube主要通过Spark的UI页面进行管理，包括JindoCube的创建、删除和更新等。通过UI创建JindoCube完成后，即可自动用于该集群所有Spark任务的查询加速。通过spark.sql.cache.tab.display参数可以控制是否在Spark UI页面展示JindoCube的Tab，可以通过EMR控制台在Spark服务中配置相关参数，或者在Spark提交命令中指定参数值，该参数默认值为false。Spark_UI

    JindoCube还提供了spark.sql.cache.useDatabase参数，可以针对业务方向，按不同的业务建立database，把需要建cache的view放在这个database中。对于分区表JindoCube还提供了spark.sql.cache.cacheByPartition参数，可指定cache使用分区字段进行存储。

    参数 说明 示例值
    spark.sql.cache.tab.display 显示Cube Mangament页面。 true
    spark.sql.cache.useDatabase cube存储数据库。 db1,db2,dbn
    spark.sql.cache.cacheByPartition 按照分区字段存储cube。 true
  2. 优化查询。

    spark.sql.cache.queryRewrite用于控制是否允许使用JindoCube中的Cache数据加速Spark查询任务，用户可以在集群、session、SQL等层面使用该配置，默认值为true。

JindoCube的使用

  1. 创建JindoCube。
    1. 通过阿里云账号登录阿里云 E-MapReduce 控制台。
    2. 单击集群管理页签。
    3. 单击待操作集群所在行的集群ID。
    4. 单击左侧导航栏的访问链接与端口。
    5. 在公网访问链接页面，单击YARN UI所在行的链接，进入Knox代理的YARN UI页面。

      Knox相关使用说明请参见Knox。

    6. 单击User为spark，Name为Thrift JDBC/ODBC Server所在行的ApplicationMaster。
    7. 单击最上面的Cube Management页签。
    8. 单击New Cache。
      用户可以选择某一个表或视图，单击action中的链接继续创建Cache。可以选择的Cache类型分为两类：
      • Raw Cache：某一个表或者视图的raw cache，表示将对应表或视图代表的表数据按照指定的方式持久化。

        在创建Raw Cache时，用户需要指定如下信息：

        参数 描述 是否必选
        Cache Name 指定Cache的名字，支持字母、数字、连接号（–）和下划线（_）的组合。 必选
        Column Selector 选择需要Cache哪些列的数据。 必选
        Rewrite 是否允许该Cache被用作后续查询的执行计划优化。 必选
        Provider Cache数据的存储格式，支持JSON、PARQUET、ORC等所有Spark支持的数据格式。 必选
        Partition Columns Cache数据的分区字段。 可选
        ZOrder Columns ZOrder是一种支持多列排序的方法，Cache数据按照ZOrder字段排序后，对于基于ZOrder字段过滤的查询会有更好的加速效果。 可选
      • Cube Cache：基于某一个表或者视图的原始数据，按照用户指定的方式构建cube，并将cube数据持久化。

        在创建Cube Cache时，用户需要指定如下信息：

        参数 描述 是否必选
        Cache Name 指定Cache的名字，支持字母、数字、连接号（–）和下划线（_）的组合。 必选
        Dimension Selector 选择构建Cube时的维度字段。 必选
        Measure Selector 选择构建Cube时的measure字段和measure预计算函数。 必选
        Rewrite 是否允许该Cache被用作后续查询的执行计划优化。 必选
        Provider Cache数据的存储格式，支持JSON、PARQUET、ORC等所有Spark支持的数据格式。 必选
        Partition Columns Cache数据的分区字段。 可选
        ZOrder Columns ZOrder是一种支持多列排序的方法，Cache数据按照ZOrder字段排序后，对于基于ZOrder字段过滤的查询会有更好的加速效果。 可选
        cube_cache

        JindoCube通过用户指定的Dimension和Measure信息来构建Cube，对于上图的示例，创建的Cube Cache可以用SQL表示为：

        SELECT c_city, c_nation, c_region, MAX(lo_quantity), SUM(lo_tax)
FROM lineorder_flatten
GROUP BY c_city, c_nation, c_region;

        JindoCube计算Cube的最细粒度维度组合，在优化使用更粗粒度的维度组合的查询时，基于Spark强大的现场计算能力，通过重聚合实现。在定义Cube Cache时，必须使用JindoCube支持的预计算函数。JindoCube支持的预计算函数和其对应的聚合函数类型如下：

        聚合函数类型 预计算函数
        COUNT COUNT
        SUM SUM
        MAX MAX
        MIN MIN
        AVG COUNT，SUM
        COUNT（DISTINCT ） PRE_COUNT_DISTINCT
        APPROX_COUNT_DISTINCT PRE_APPROX_COUNT_DISTINCT

        在Cube Management页面，展示所有的Cache列表。单击Detail进入Cache的详细页面，在Cache详细页会展示Cache的详细信息、包括基本信息、Cache数据分区信息、构建Cache信息以及构建历史信息等。

  2. 构建JindoCube。

    创建JindoCube Cache只是进行元数据操作，Cache表示的数据并未持久化，需要继续构建Cache，从而持久化Cache数据到HDFS或OSS等存储中。此外Cache对应的源表数据可能会新增或者更新，需要更新Cache中的数据从而保持一致。JindoCube支持两类构建操作：

    • Build Cache。

      通过Build Cache链接，用户可以主动触发一次构建操作，构建页面相关信息如下：

      build_Cache

      在构建JindoCube的Cache时，相关用户选项如下：

      参数 描述
      Save Mode

      支持Overwrite和Append两种模式。

      • Overwrite：会覆盖之前曾经构建的Cache数据。
      • Append：会新增数据到Cache中。
      Optional Filter

      用户可以选择额外的过滤条件，在构建时，将该Cache表示的数据过滤后再持久化。

      • Column：过滤字段。
      • Filter Type：过滤类型，支持固定值和范围值两种。
        • Fixed Values：指定过滤值，可以多个，以“,”分隔。
        • Range Values：指定范围值的最小和最大值，最大值可以为空，过滤条件包含最小值，不包含最大值。

      上图中构建任务想要构建lineorder_flatten视图的Raw Cache数据，要写入Cache中的数据可以使用如下SQL表示：

      SELECT * FROM lineorder_flatten
WHERE s_region == 'ASIA' OR s_region == 'AMERICA';

      单击Submit，提交构建任务，返回到Cache详细页面，对应的构建任务会提交到Spark集群中执行，在Build Information中可以看到当前是否正在构建Cache的信息。在Cache构建完成后，可以在Build History中看到相关的信息。

      说明 Cache数据由Spark任务写到一个指定目录中，和普通的Spark写表或者写目录一样，对于Parquet、Json、ORC等数据格式，并发构建同一个Cache可能导致Cache数据不准确，不可用，应避免这种情况。如果无法避免并发构建、更新Cache，可以考虑使用delta等支持并发写的数据格式。
    • Trigger Period Build。

      定期更新功能可以方便用户设置自动更新Cache的策略，保持Cache数据和源表数据的一致。相关页面如下：

      Trigger_Period_build

      定期更新的相关用户选项如下：

      参数 描述
      Save Mode
      支持Overwrite和Append两种模式。
      • Overwrite：会覆盖之前曾经构建的Cache数据。
      • Append：会新增数据到Cache中。
      Trigger Strategy
      触发策略，设置触发构建任务的开始时间和间隔时间。
      • Start At：通过时间控件选择或者手工输入第一次触发构建任务的时间点，日期格式为yyyy-MM-dd hh:mm:ss。
      • Period：设置触发构建任务的间隔时间。
      Optional Step
      设置每次触发构建任务的数据筛选条件，通过指定时间类型的字段，配合触发策略中的间隔时间，可以实现按照时间间隔增量的更新Cache。如果不选择，每次全量更新Cache。
      • Step By：选择增量更新字段类型，只支持时间类型字段，包括Long类型的timestamp字段，以及指定dateformat信息的String类型字段。
      • Column Name：增量更新字段名称。

      在Cache详细页面中，可以看到当前设置的定期更新策略，用户可以随时通过Cancel Period Build取消定期更新。所有触发的构建任务信息在完成后也可以在Build History列表中看到。

      说明
      • 定期更新任务是Spark集群级别的，相关设置保存在SparkContext中，并由Spark Driver定期触发，当Spark集群关闭后，定期更新任务也随之关闭。
      • 当前Spark集群所有的构建任务完成后，都会展示在Build History列表中，包含开始/结束时间、SaveMode、构建条件，任务最终状态等。Build History也是Spark集群级别的信息，当Spark集群关闭后，相关信息也随之释放。
  3. 管理JindoCube。

    创建和构建JindoCube的Cache数据后，通过Cube Management的UI页面，可以对JindoCube的Cache数据进行进一步的管理。

    • 删除cache。

      在JindoCube Cache列表页面，可以通过action列的Drop删除对应Cache，删除成功后，Cache的相关元数据和存储数据都会被清理。

      Drop_table
    • 开启或关闭Cache优化。

      JindoCube支持在Cache级别，设置是否允许用于Spark查询的优化，在Cache的详细页面，您可以通过基本信息中的Enabled或Disabled，启用或者停用该Cache，控制是否允许该Cache用于查询加速。

      enable_disable
    • 删除分区数据。

      如果Cache的数据是按照分区存储的，当确认某些分区数据不再需要时，删除这些分区数据可以节省大量存储空间。在Cache的详细页面，分区Cache的相关分区会通过列表展示，用户可以通过Delete删除特定分区的数据。

      Delete
      说明 在删除Cache分区数据之前，请谨慎确认，确保该分区数据不会被使用。如果用户的查询经过优化需要用到该Cache被删除的分区数据，会导致错误的查询结果。
  4. 查询优化。

    目前JindoCube支持基于View的查询优化，当用户使用某个视图创建了Raw Cache或者Cube Cache后，后续的查询使用到了该视图，EMR Spark会在满足逻辑语义的前提下，尝试使用Cache重写查询的执行计划，新的执行计划直接访问Cache数据，从而加速查询速度。以如下场景为例，lineorder_flatten视图是将lineorder和其他维度表关联之后的大宽表视图，其相关定义如下：

    lineorder_define

    基于lineorder_flatten视图简单查询的执行计划如下：

    check_lineorder

    在为line order_flatten视图创建Raw Cache并构建完成后，执行相同查询，EMR Spark会自动使用Cache数据优化执行计划，优化后的执行计划如下：

    lineorder_flatten_after

    可以看到，优化后的执行计划省去了lineorder_flatten视图的所有计算逻辑，直接访问HDFS中Cache的数据。

注意事项

  1. JindoCube并不保证Cache数据和源表数据的一致性，而是需要用户通过手工触发或者设置定期策略触发更新任务同步Cache中的数据，用户需要根据查询对于数据一致性的需求，触发Cache的更新任务。
  2. 在对查询的执行计划进行优化的时候，JindoCube根据视图的元数据判断是否可以使用Cache优化查询的执行计划。优化后，如果Cache的数据不完整，可能会影响查询结果的完整性或正确性。可能导致Cache数据不完整的情况包括：用户在Cache详情页主动删除查询需要的Cache Partition数据，构建、更新Cache时指定的过滤条件过滤掉了查询需要的数据，查询需要的数据还未及时更新到Cache等。