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

Есть намеки?

Спасибо

2 ответа

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

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

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

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

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

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

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

Например, давайте рассмотрим сущность, называемую "автомобиль", с атрибутами "скорость", "местоположение" и "уровень масла". Затем вы можете сказать "уведомлять Cygnus при каждом изменении скорости, но отправлять только значение скорости. Но в то же время вы можете сказать" уведомлять Cygnus при каждом изменении уровня масла, а также отправлять все значения атрибута ". Если машина начинает движение, и меняется только скорость и местоположение, но не уровень масла, тогда Cygnus будет уведомлен только об обновлении скорости, у которого нет никаких шансов узнать о других атрибутах в любое время.

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

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

Другие вопросы по тегам