当前位置：主页 > 查看内容

Call Caching 用法详解 - 批量计算

发布时间：2021-09-20 00:00| 有 位朋友查看

简介：背景 Cromwell 的 Call Caching 功能如何开启和关闭？ 在一些场景下，提交工作流时不想使用 Call Caching，需要无条件执行，该如何设置？ 工作流重新提交后，有一些 task 预期不需要重新执行，但依然执行了，Call Caching 疑似没有生效，怎么查看原因？ 本篇……

背景

  • Cromwell 的 Call Caching 功能如何开启和关闭？
  • 在一些场景下，提交工作流时不想使用 Call Caching，需要无条件执行，该如何设置？
  • 工作流重新提交后，有一些 task 预期不需要重新执行，但依然执行了，Call Caching 疑似没有生效，怎么查看原因？

本篇文档将对 Call Caching 的使用做一个详细的介绍，包括功能的开启和关闭、如何通过查看元数据的方式，确认 Call Caching 未生效的原因等。

Call Caching 设置

配置文件中设置全局 Call Caching 开关状态

如果要使用 Cromwell 的 Call Caching 功能，需要在 Server 的配置文件中设置：

  1. call-caching {
  2.   # Allows re-use of existing results for jobs you have already run
  3.   # (default: false)
  4.   enabled = true
  5.   # Whether to invalidate a cache result forever if we cannot reuse them. Disable this if you expect some cache copies
  6.   # to fail for external reasons which should not invalidate the cache (e.g. auth differences between users):
  7.   # (default: true)
  8.   invalidate-bad-cache-results = true
  9. }

call-caching.enabled 是 Call Caching 功能的开关，可以按照自己的需求开启和关闭。

在 Option 中设置单个 Workflow 是否使用 Call Caching

在 Call Caching 功能全局开启的状态下，提交工作流时，可以通过携带如下两个 option 选项设置本次执行是否使用 Call Caching:

  1. {
  2.     "write_to_cache": true,
  3.     "read_from_cache": true
  4. }
  • write_to_cache: 表示本次 workflow 执行结果是否写入 Cache，实际上就是是否给后面的工作流复用。默认是 true。
  • read_from_cache: 表示本次 workflow 执行是否从 Cache 中读取之前的结果，也就是是否复用以前的结果，默认是 true，如果设置为 false，表示本次执行不使用 Call Caching，强制执行。

查看元数据

工作流执行时，每一个 task 的每一个 call（对应批量计算的一个作业）都会有 metadata，记录了这个步骤的运行过程，当然也包括 Call Caching 的详细信息，通过下面的命令可以查询一个工作流的 metadata:

  1. widdler query -m [WorkflowId]

在元数据信息中找到对应的 task 的详细信息，比如：

  1. {
  2.     "callRoot": "oss://gene-test/cromwell_test/GATK4_VariantDiscovery_pipeline_hg38/53cfd3fc-e9d5-4431-83ec-be6c51ab9365/call-HaplotypeCaller/shard-10",
  3.     "inputs": {
  4.         "gatk_path": "/gatk/gatk",
  5.         "ref_fasta": "oss://genomics-public-data-shanghai/broad-references/hg38/v0/Homo_sapiens_assembly38.fasta",
  6.         "cluster_config": "OnDemand ecs.sn2ne.xlarge img-ubuntu-vpc",
  7.         "input_bam_index": "oss://gene-test/cromwell_test/GATK4_VariantDiscovery_pipeline_hg38/cf55a2d1-572c-4490-8edf-07656802a79b/call-GatherBamFiles/NA12878.hg38.ready.bam.bai",
  8.         "output_filename": "NA12878.hg38.vcf.gz",
  9.         "contamination": null,
  10.         "ref_fasta_index": "oss://genomics-public-data-shanghai/broad-references/hg38/v0/Homo_sapiens_assembly38.fasta.fai",
  11.         "ref_dict": "oss://genomics-public-data-shanghai/broad-references/hg38/v0/Homo_sapiens_assembly38.dict",
  12.         "interval_list": "/home/data/GATK_human_genome_resource_bundle/hg38_from_GCP/hg38_wgs_scattered_calling_intervals/temp_0047_of_50/scattered.interval_list",
  13.         "input_bam": "oss://gene-test/cromwell_test/GATK4_VariantDiscovery_pipeline_hg38/cf55a2d1-572c-4490-8edf-07656802a79b/call-GatherBamFiles/NA12878.hg38.ready.bam.bam",
  14.         "docker_image": "registry.cn-shanghai.aliyuncs.com/wgs_poc/poc:4.0.10.1"
  15.     },
  16.     "returnCode": 0,
  17.     "callCaching": {
  18.         "allowResultReuse": true,
  19.         "hashes": {
  20.             "output expression": {
  21.                 "File output_vcf_index": "A162250CB6F52CC32CB75F5C5793E8BB",
  22.                 "File output_vcf": "7FD061EEA1D3C63912D7B5FB1F3C5218"
  23.             },
  24.             "runtime attribute": {
  25.                 "userData": "N/A",
  26.                 "docker": "F323AFFA030FBB5B352C60BD7D615255",
  27.                 "failOnStderr": "68934A3E9455FA72420237EB05902327",
  28.                 "imageId": "N/A",
  29.                 "continueOnReturnCode": "CFCD208495D565EF66E7DFF9F98764DA"
  30.             },
  31.             "output count": "C81E728D9D4C2F636F067F89CC14862C",
  32.             "input count": "D3D9446802A44259755D38E6D163E820",
  33.             "command template": "9104DF40289AB292A52C2A753FBF58D2",
  34.             "input": {
  35.                 "File interval_list": "04dc2cb895d13a40657d5e2aa7d31e8c",
  36.                 "String output_filename": "2B77B986117FC94D088273AD4D592964",
  37.                 "File ref_fasta": "9A513FB0533F04ED87AE9CB6281DC19B-400",
  38.                 "File input_bam_index": "D7CA83047E1B6B8269DF095F637621FE-1",
  39.                 "String gatk_path": "EB83BBB666B0660B076106408FFC0A9B",
  40.                 "String docker_image": "0981A914F6271269D58AA49FD18A6C13",
  41.                 "String cluster_config": "B4563EC1789E5EB82B3076D362E6D88F",
  42.                 "File ref_dict": "3884C62EB0E53FA92459ED9BFF133AE6",
  43.                 "File input_bam": "9C0AC9A52F5640AA06A0EBCE6A97DF51-301",
  44.                 "File ref_fasta_index": "F76371B113734A56CDE236BC0372DE0A"
  45.             },
  46.             "backend name": "AE9178757DD2A29CF80C1F5B9F34882E"
  47.         },
  48.         "effectiveCallCachingMode": "ReadAndWriteCache",
  49.         "hit": false,
  50.         "result": "Cache Miss"
  51.     },
  52.     "stderr": "oss://gene-test/cromwell_test/GATK4_VariantDiscovery_pipeline_hg38/53cfd3fc-e9d5-4431-83ec-be6c51ab9365/call-HaplotypeCaller/shard-10/stderr",
  53.     "shardIndex": 10,
  54.     "stdout": "oss://gene-test/cromwell_test/GATK4_VariantDiscovery_pipeline_hg38/53cfd3fc-e9d5-4431-83ec-be6c51ab9365/call-HaplotypeCaller/shard-10/stdout",
  55.     "outputs": {
  56.         "output_vcf": "oss://gene-test/cromwell_test/GATK4_VariantDiscovery_pipeline_hg38/53cfd3fc-e9d5-4431-83ec-be6c51ab9365/call-HaplotypeCaller/shard-10/NA12878.hg38.vcf.gz",
  57.         "output_vcf_index": "oss://gene-test/cromwell_test/GATK4_VariantDiscovery_pipeline_hg38/53cfd3fc-e9d5-4431-83ec-be6c51ab9365/call-HaplotypeCaller/shard-10/NA12878.hg38.vcf.gz.tbi"
  58.     },
  59.     "commandLine": "set -e\n\n  /gatk/gatk --java-options \"-Xmx4g -Xmx4g\" \\\n    HaplotypeCaller \\\n    -R /cromwell_inputs/73a7571e/Homo_sapiens_assembly38.fasta \\\n    -I /cromwell_inputs/02f1b5ca/NA12878.hg38.ready.bam.bam \\\n    -L /home/data/GATK_human_genome_resource_bundle/hg38_from_GCP/hg38_wgs_scattered_calling_intervals/temp_0047_of_50/scattered.interval_list \\\n    -O NA12878.hg38.vcf.gz \\\n    -contamination 0",
  60.     "attempt": 1,
  61.     "jobId": "job-000000005DB051A800006F970001CAC8",
  62.     "start": "2019-10-25T02:38:03.522Z",
  63.     "backendStatus": "Finished",
  64.     "runtimeAttributes": {
  65.         "cluster": "Right(AutoClusterConfiguration(OnDemand,ecs.sn2ne.xlarge,img-ubuntu-vpc,None,None,None))",
  66.         "continueOnReturnCode": "0",
  67.         "failOnStderr": "false",
  68.         "vpc": "BcsVpcConfiguration(Some(10.20.200.0/24),Some(vpc-uf61zj30k0ebuen0xi7ci))",
  69.         "mounts": "BcsInputMount(Right(nas://10.20.66.4:/data/ali_yun_test/),Left(/home/data),true)",
  70.         "docker": "BcsDockerWithoutPath(registry.cn-shanghai.aliyuncs.com/wgs_poc/poc:4.0.10.1)",
  71.         "autoReleaseJob": "false",
  72.         "maxRetries": "0"
  73.     },
  74.     "executionStatus": "Done",
  75.     "end": "2019-10-25T03:22:23.481Z",
  76.     "executionEvents": [
  77.         {
  78.             "endTime": "2019-10-25T03:22:21.626Z",
  79.             "description": "RunningJob",
  80.             "startTime": "2019-10-25T02:38:03.645Z"
  81.         },
  82.         {
  83.             "endTime": "2019-10-25T03:22:22.481Z",
  84.             "description": "UpdatingCallCache",
  85.             "startTime": "2019-10-25T03:22:21.626Z"
  86.         },
  87.         {
  88.             "endTime": "2019-10-25T02:38:03.645Z",
  89.             "description": "CallCacheReading",
  90.             "startTime": "2019-10-25T02:38:03.643Z"
  91.         },
  92.         {
  93.             "endTime": "2019-10-25T02:38:03.522Z",
  94.             "description": "Pending",
  95.             "startTime": "2019-10-25T02:38:03.522Z"
  96.         },
  97.         {
  98.             "endTime": "2019-10-25T02:38:03.542Z",
  99.             "description": "WaitingForValueStore",
  100.             "startTime": "2019-10-25T02:38:03.542Z"
  101.         },
  102.         {
  103.             "endTime": "2019-10-25T03:22:23.481Z",
  104.             "description": "UpdatingJobStore",
  105.             "startTime": "2019-10-25T03:22:22.481Z"
  106.         },
  107.         {
  108.             "endTime": "2019-10-25T02:38:03.643Z",
  109.             "description": "PreparingJob",
  110.             "startTime": "2019-10-25T02:38:03.542Z"
  111.         },
  112.         {
  113.             "endTime": "2019-10-25T02:38:03.542Z",
  114.             "description": "RequestingExecutionToken",
  115.             "startTime": "2019-10-25T02:38:03.522Z"
  116.         }
  117.     ],
  118.     "backend": "BCS"
  119. }

在上面的元数据中，有一项 callCaching，主要记录了如下信息：

  • allowResultReuse：是否允许其他工作流复用。
    • 如果当前工作流设置了不允许写入 Cache，则不可以复用
    • 如果当前工作流设置了允许写入 Cache，则只有任务执行成功，才允许复用
  • hashes：当前任务的输入、输出、运行时等参数的 hash 记录，用于比对两次运行条件是否一样。
  • effectiveCallCachingMode：Call Caching 的模式，比如是否从 Cache 中读取，或者是否写入 Cache 等。
  • hit：当前任务在 Cache 是否命中。
  • result：当前任务在 Cache 中命中的详情，比如哪个工作流的哪个 task 的哪个 shard。

综合上面的解释，我们看到实例中的这个 call, 是 GATK4_VariantDiscovery_pipeline_hg38 这个工作流的 HaplotypeCaller 这个 task 的10号 shard，Call Cache 情况如下：

  • 未在 Cache 中命中，完整的执行了一次
  • 执行成功，可以允许后的流程复用

Call Caching 未生效问题排查

如果遇到不符合预期的 task，可以通过如下步骤排查原因：

  • 查看当前 workflow 重新执行的 task 的 Call Caching 元数据
    • 如果当前 task 的 Call Caching 的模式是不使用Cache（可能是提交作业时设置了不使用 Call Caching 的选项），则不会去利用之前的结果，确实会强制重新执行，是符合预期的
    • 如果当前 task 未命中 Cache，则需要查看之前的 workflow, 进一步确认未命中的原因
  • 查看之前的 workflow 的 task 的 CalCaching 元数据，确认之前的 task 是否执行成功，是否可以复用
    • 如果之前的 task 的 不允许复用，可能是执行失败了，或者虽然执行成功，但 Cache 模式设置的不写入 Cache，即不允许复用
    • 如果之前的 task 允许复用，但未命中，则需要比较两次的 hash 记录，可能是由于 Call Caching 相关的参数变化引起的

本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！
上一篇：配置反向解析_云解析服务 DNS_快速入门 下一篇：没有了

推荐图文

  • 周排行
  • 月排行
  • 总排行

随机推荐