グループ化ルールを処理する方法

Question

割り当てられたCosmosスペースに何らかの注文を保存しようとしています。現在、私は、下図のようにデータを格納しています：TEMPORAL1は私のエンティティIDとPhysicalTestそれぞれのタイプを表し

.../webhdfs/v1/user/[ USERNAME ]/[ Fiware-Service ]/[ Fiware-ServicePath ]/TEMPORAL1_PhysicalTest/TEMPORAL1_PhysicalTest.txt 
.../webhdfs/v1/user/[ USERNAME ]/[ Fiware-Service ]/[ Fiware-ServicePath ]/TEMPORAL2_PhysicalTest/TEMPORAL2_PhysicalTest.txt 
.../webhdfs/v1/user/[ USERNAME ]/[ Fiware-Service ]/[ Fiware-ServicePath ]/TEMPORAL3_PhysicalTest/TEMPORAL3_PhysicalTest.txt 
.../webhdfs/v1/user/[ USERNAME ]/[ Fiware-Service ]/[ Fiware-ServicePath ]/TEMPORAL4_PhysicalTest/TEMPORAL4_PhysicalTest.txt 

。私はそれがルールをグループ化することによって対処することができ信じて

.../webhdfs/v1/user/[ USERNAME ]/[ Fiware-Service ]/[ Fiware-ServicePath ]/physicaltests/TEMPORAL1_PhysicalTest.txt 
.../webhdfs/v1/user/[ USERNAME ]/[ Fiware-Service ]/[ Fiware-ServicePath ]/physicaltests/TEMPORAL2_PhysicalTest.txt 
.../webhdfs/v1/user/[ USERNAME ]/[ Fiware-Service ]/[ Fiware-ServicePath ]/physicaltests/TEMPORAL3_PhysicalTest.txt 
.../webhdfs/v1/user/[ USERNAME ]/[ Fiware-Service ]/[ Fiware-ServicePath ]/physicaltests/TEMPORAL4_PhysicalTest.txt 

;：しかし、私は以下の（架空の）構造に基づいてデータを格納するために充当メカニズムを知って好きになるでしょう確かに。

そのような場合、私は最初に提示され、私は構造になってしまっているので、成功していない結果と以下のように私のgrouping_rules.confを解決しています

{ 
    "grouping_rules": [ 
     { 
      "id": 1, 
      "fields": [ 
       "entityType" 
      ], 
      "regex": "PhysicalTest.*", 
      "destination": "PhysicalTest", 
      "fiware_service_path": "/[ Fiware-Service ]/physicaltests" 
     } 
    ] 
} 

Answer 1

このような事を行うことができません。シグナスこのパターン（*）は、以下のデータを記憶らHDFSフォルダを：

/user/<username>/<service>/<service-path>/<entity-id>_<entity-type>/<entity-id>_<entity-type>.txt 

<entity-id>_<entity-type>/<entity-id>_<entity-type>.txt部分の構造は常に（通知またはマップをlater-説明-will）の意味で、変更することができないエンティティIDと（通知された、またはマッピングされている - 後で説明する）エンティティタイプがそれを構成するために使用される。このような構造体は、サブフォルダとファイルの両方にエンティティIDと型連結を複製することに注意してください。どうして？ Hadoopはファイルではなくディレクトリで動作するためです。したがって、単一のエンティティ分析を可能にするために、このような構造は、Cygnusで設計されました。

上記の構造は、Name Mappingsを使って変更することができます。これは、エンティティIDやエンティティタイプ（特に）を変更できる機能です。これは非常に強力な機能です。たとえば、「carのすべてのエンティティは自分のIDが自分の選択したIDにマッピングされていると見られます」ということです。つまり、すべてのエンティティが同じサブディレクトリ/ファイルに格納されます。

/user/<username>/<service>/<service-path>/<unique-entity-id>_<entity-type>/<unique-entity-id>_<entity-type>.txt 

これは、必要なものに最も近いものです。

何について言及していますか。Grouping Rulesあなたは言及していますか？彼らは名前マッピングの以前のものでした。彼らは、私たちは、エンティティのIDとタイプ（私たちは、「目的地」と呼ばれるものを）の全体の連結を変更することができ、それにもかかわらず、説明した構造も同様に維持された。

/user/<username>/<service>/<service-path>/<destination>/<destination>.txt 

グループのルールは、名前のマッピングの賛成でdeprecatedあります。

（*）また、service_as_namespace = trueを設定すると、<username>レベルを回避することができます。これは、FIWAREサービスが有効なHDFSユーザーと一致する場合に便利です。