Cygnus 0.7.1 не создает таблицы (MySQL и HDFS)

Я установил (из исходного кода) cygnus 0.7.1, и после его настройки (приемники MySQL и HDFS) я могу запустить его без проблем. Когда я подписываю cygnus на контекст orion, он получает информацию нормально, но есть проблема с MySQL и HDFS. Это журнал:

15/03/17 13:58:52 INFO handlers.OrionRestHandler: Starting transaction (1426597123-891-0000000000)
15/03/17 13:58:52 INFO handlers.OrionRestHandler: Received data ({  "subscriptionId" : "5508250c1860a36e55240c84",  "originator" : "localhost",  "contextResponses" : [    {      "contextElement" : {        "type" : "ubk-temp",        "isPattern" : "false",        "id" : "ubk:temp:1",        "attributes" : [          {            "name" : "temperature",            "type" : "float",            "value" : "11"          }        ]      },      "statusCode" : {        "code" : "200",        "reasonPhrase" : "OK"      }    }  ]})
15/03/17 13:58:52 INFO handlers.OrionRestHandler: Event put in the channel (id=1549700267, ttl=10)
15/03/17 13:58:52 INFO sinks.OrionSink: Event got from the channel (id=1549700267, headers={fiware-servicepath=ubktemp, destination=ubk_temp_1_ubk-temp, content-type=application/json, fiware-service=ubikwa, ttl=10, transactionId=1426597123-891-0000000000, timestamp=1426597132511}, bodyLength=462)
15/03/17 13:58:52 INFO sinks.OrionSink: Event got from the channel (id=1549700267, headers={fiware-servicepath=ubktemp, destination=ubk_temp_1_ubk-temp, content-type=application/json, fiware-service=ubikwa, ttl=10, transactionId=1426597123-891-0000000000, timestamp=1426597132511}, bodyLength=462)
15/03/17 13:58:52 INFO sinks.OrionMySQLSink: [mysql-sink] Persisting data at OrionMySQLSink. Database: ubikwa, Table: ubktemp_ubk_temp_1_ubk-temp, Timestamp: 2015-03-17T13:58:52.511, Data (attrs): {temperature=11}, (metadata): {temperature_md=[]}
15/03/17 13:58:53 INFO sinks.OrionHDFSSink: [hdfs-sink] Persisting data at OrionHDFSSink. HDFS file (ubikwa/ubktemp/ubk_temp_1_ubk-temp/ubk_temp_1_ubk-temp.txt), Data ({"recvTime":"2015-03-17T13:58:52.511","temperature":"11", "temperature_md":[]})
15/03/17 13:58:53 WARN sinks.OrionSink: Bad context data (Table 'ubikwa.ubktemp_ubk_temp_1_ubk-temp' doesn't exist)
15/03/17 13:58:53 INFO sinks.OrionSink: Finishing transaction (1426597123-891-0000000000)

Приемник MySQL не вызывает никаких ошибок, но таблицы не создаются. И приемник HDFS, похоже, не может создавать файлы. Ранее я устанавливал Cygnus 0.6, и он работал с той же конфигурацией.

Изменить:

Вот моя конфигурация:

cygnusagent.sources = http-source
cygnusagent.sinks = hdfs-sink mysql-sink
cygnusagent.channels = hdfs-channel mysql-channel

#=============================================
# source configuration
# channel name where to write the notification events
cygnusagent.sources.http-source.channels = hdfs-channel mysql-channel
# source class, must not be changed
cygnusagent.sources.http-source.type = org.apache.flume.source.http.HTTPSource
# listening port the Flume source will use for receiving incoming notifications
cygnusagent.sources.http-source.port = 5050
# Flume handler that will parse the notifications, must not be changed
cygnusagent.sources.http-source.handler = es.tid.fiware.fiwareconnectors.cygnus.handlers.OrionRestHandler
# URL target
cygnusagent.sources.http-source.handler.notification_target = /notify
# Default service (service semantic depends on the persistence sink)
cygnusagent.sources.http-source.handler.default_service = ubikwa
# Default service path (service path semantic depends on the persistence sink)
cygnusagent.sources.http-source.handler.default_service_path = ubktemp
# Number of channel re-injection retries before a Flume event is definitely discarded (-1 means infinite retries)
cygnusagent.sources.http-source.handler.events_ttl = 10
# Source interceptors, do not change
cygnusagent.sources.http-source.interceptors = ts de
# Timestamp interceptor, do not change
cygnusagent.sources.http-source.interceptors.ts.type = timestamp
# Destination extractor interceptor, do not change
cygnusagent.sources.http-source.interceptors.de.type = es.tid.fiware.fiwareconnectors.cygnus.interceptors.DestinationExtractor$Builder
# Matching table for the destination extractor interceptor, put the right absolute path to the file if necessary
# See the doc/design/interceptors document for more details
cygnusagent.sources.http-source.interceptors.de.matching_table = /opt/cygnus/conf/matching_table.conf

# ============================================
# OrionHDFSSink configuration
# channel name from where to read notification events
cygnusagent.sinks.hdfs-sink.channel = hdfs-channel
# sink class, must not be changed
cygnusagent.sinks.hdfs-sink.type = es.tid.fiware.fiwareconnectors.cygnus.sinks.OrionHDFSSink
# Comma-separated list of FQDN/IP address regarding the Cosmos Namenode endpoints
# If you are using Kerberos authentication, then the usage of FQDNs instead of IP addresses is mandatory
cygnusagent.sinks.hdfs-sink.cosmos_host = 130.206.80.46
# port of the Cosmos service listening for persistence operations; 14000 for httpfs, 50070 for webhdfs and free choice for inifinty
cygnusagent.sinks.hdfs-sink.cosmos_port = 14000
# default username allowed to write in HDFS
cygnusagent.sinks.hdfs-sink.cosmos_default_username = ***
# default password for the default username
cygnusagent.sinks.hdfs-sink.cosmos_default_password = ***
# HDFS backend type (webhdfs, httpfs or infinity)
cygnusagent.sinks.hdfs-sink.hdfs_api = httpfs
# how the attributes are stored, either per row either per column (row, column)
cygnusagent.sinks.hdfs-sink.attr_persistence = column
# Hive FQDN/IP address of the Hive server
cygnusagent.sinks.hdfs-sink.hive_host = 130.206.80.46
# Hive port for Hive external table provisioning
cygnusagent.sinks.hdfs-sink.hive_port = 10000
# Kerberos-based authentication enabling
cygnusagent.sinks.hdfs-sink.krb5_auth = false
# Kerberos username
cygnusagent.sinks.hdfs-sink.krb5_auth.krb5_user = krb5_username
# Kerberos password
cygnusagent.sinks.hdfs-sink.krb5_auth.krb5_password = xxxxxxxxxxxxx
# Kerberos login file
cygnusagent.sinks.hdfs-sink.krb5_auth.krb5_login_conf_file = /usr/cygnus/conf/krb5_login.conf
# Kerberos configuration file
cygnusagent.sinks.hdfs-sink.krb5_auth.krb5_conf_file = /usr/cygnus/conf/krb5.conf

# ============================================
# OrionMySQLSink configuration
# channel name from where to read notification events
cygnusagent.sinks.mysql-sink.channel = mysql-channel
# sink class, must not be changed
cygnusagent.sinks.mysql-sink.type = es.tid.fiware.fiwareconnectors.cygnus.sinks.OrionMySQLSink
# the FQDN/IP address where the MySQL server runs
cygnusagent.sinks.mysql-sink.mysql_host = 127.0.0.1
# the port where the MySQL server listes for incomming connections
cygnusagent.sinks.mysql-sink.mysql_port = 3306
# a valid user in the MySQL server
cygnusagent.sinks.mysql-sink.mysql_username = ***
# password for the user above
cygnusagent.sinks.mysql-sink.mysql_password = ***
# how the attributes are stored, either per row either per column (row, column)
cygnusagent.sinks.mysql-sink.attr_persistence = column

#=============================================
# hdfs-channel configuration
# channel type (must not be changed)
cygnusagent.channels.hdfs-channel.type = memory
# capacity of the channel
cygnusagent.channels.hdfs-channel.capacity = 1000
# amount of bytes that can be sent per transaction
cygnusagent.channels.hdfs-channel.transactionCapacity = 100

#=============================================
# mysql-channel configuration
# channel type (must not be changed)
cygnusagent.channels.mysql-channel.type = memory
# capacity of the channel
cygnusagent.channels.mysql-channel.capacity = 1000
# amount of bytes that can be sent per transaction
cygnusagent.channels.mysql-channel.transactionCapacity = 100

Любые подсказки?

Спасибо


fiware fiware-cygnus
person Ignacio Martin    schedule 17.03.2015    source источник
comment
Можете ли вы вставить свою конфигурацию, пожалуйста? Некоторые параметры появлялись/исчезали от версии к другой.   -  person frb    schedule 18.03.2015
comment
Я отредактировал исходное сообщение с моим файлом конфигурации. Спасибо.   -  person Ignacio Martin    schedule 19.03.2015

Ответы (2)


arrow_upward
2
arrow_downward

Я считаю, что это потому, что вы используете параметр column в своей конфигурации для OrionMySQLSink.

# how the attributes are stored, either per row either per column (row, column)
cygnusagent.sinks.mysql-sink.attr_persistence = column

В документации указано, что при использовании column база данных и таблицы должны быть созданы до запуска cygnus. При использовании row все 8 строк будут созданы автоматически перед первой вставкой.

В таблицах мы можем найти два варианта:

Фиксированные строки из 8 полей, как обычно: recvTimeTs, recvTime, entityId, entityType, attrName, attrType, attrValue и attrMd. Эти таблицы (и базы данных) создаются во время выполнения, если таблица не существовала до вставки строки. Что касается attrValue, в простейшей форме это значение представляет собой просто строку, но, начиная с Orion 0.11.0, это может быть объект Json или массив Json. Что касается attrMd, он содержит строковую сериализацию массива метаданных для атрибута в Json (если у атрибута нет метаданных, вставляется пустой массив []), два столбца для каждого атрибута сущности (один для значения, другой для метаданные), плюс дополнительный столбец о времени приема данных (recv_time). Таблицы такого типа (и базы данных) должны быть подготовлены до выполнения Cygnus, потому что каждый объект может иметь разное количество атрибутов, а уведомления должны обеспечивать уведомление о значении каждого атрибута.

Поведение коннектора в отношении внутреннего представления данных регулируется параметром конфигурации attr_persistence, значениями которого могут быть строка или столбец.

person petark    schedule 11.04.2015

arrow_upward
2
arrow_downward

Как предлагает Petark, «режим столбца» не создает таблицы автоматически, и это должно быть предварительно подготовлено вами. Почему? Причина в том, что в зависимости от подписки, которую вы сделали на Orion CB для отправки уведомлений в Cygnus, такое уведомление может иногда включать в себя несколько обновлений атрибутов, иногда набор других очень разных атрибутов и т. д.

Например, давайте рассмотрим объект под названием «автомобиль» с атрибутами «скорость», «местоположение» и «уровень масла». Тогда вы можете сказать: «уведомлять Cygnus каждый раз, когда изменяется скорость, но отправлять только значение скорости. Но в то же время вы можете сказать: «уведомлять Cygnus каждый раз, когда изменяется уровень масла, а также отправлять все значения атрибута». Если автомобиль начинает двигаться, и меняются только скорость и местоположение, но не уровень масла, тогда Лебедь будет уведомлен только об обновлениях скорости, у которого нет возможности узнать об остальных атрибутах в любой момент.

Таким образом, если вы хотите, чтобы строки данных имели все 3 атрибута, вам нужно подготовить таблицу самостоятельно. Кстати, наличие таких примеров подписки приведет к большому количеству строк «значение скорости, нуль, нуль» в ваших таблицах.

Отличие от «режима строки» заключается в том, что независимо от количества уведомляемых атрибутов для каждого уведомляемого атрибута будет добавлена ​​новая строка, имеющая все строки одного и того же формата (entityId,entitytType,attrName,attrType,attrValue,attrMd) ; эти форматы могут быть автоматически предоставлены Cygnus.

person frb    schedule 15.04.2015