Как обращаться с правилами группировки

Question

Я пытаюсь сохранить порядок в пространстве Космоса. В настоящее время я хранение данных, как показано ниже:

.../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 

Где TEMPORAL1 представляет мои Entities идентификаторы и PhysicalTest соответствующего типа. Однако, я хотел бы знать, присваиваемой механизм для хранения данных на основе ниже (гипотетические) структуры:

.../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

Такая вещь не может быть сделано. Cygnus хранит данные аль 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-) идентификатор объекта и (уведомление или сопоставление - будет объяснено позже) - тип объекта будет использоваться для его составления. Обратите внимание, что такая структура реплицирует идентификатор объекта и тип конкатенации как во вложенной папке, так и в файле. Зачем? Поскольку Hadoop работает с каталогами, а не файлами. Таким образом, для того, чтобы разрешить анализ одного объекта, такая структурированная конструкция была разработана в Cygnus.

Считается, что вышеуказанную структуру можно изменить с помощью Name Mappings, функции, которая позволяет вам изменять идентификатор объекта и/или тип объекта (среди прочих). Это очень мощная функция, так как вы можете сказать, например: «все объекты типа автомобиля будут видеть, что их идентификаторы сопоставлены с одним идентификатором моего выбора», что означает, что все объекты будут храниться в том же подкаталоге/файле:

/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 в пользу имя отображений.

(*) В противном случае вы можете избежать уровня <username>, если вы сконфигурируете service_as_namespace = true. Это полезно, если ваша служба FIWARE соответствует действительному пользователю HDFS:

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