Fiware-cygnus のドキュメントには、Apache Flume に基づいていることが記載されています。ただし、ネイティブの Flume シンクを使用して、Orion Context Broker からのイベントを永続化できるかどうかは明確ではありません。これは、ほとんど (または理想的にはゼロ) コーディングで簡単に実行できるものですか? そうでない場合は、その理由 (および、これが今後サポートされるかどうか) を知ることをお勧めします。ありがとう!
1 に答える
ネイティブの Flume シンクを構成するだけで使用できます。Cygnus では構成管理に関して何も変更されていないため、Orion のようなシンクまたはネイティブのシンクを構成できます。
それでも、Orion のようなシンクとネイティブの Flume シンクには違いがあります。
1 つ目は、Orion のようなシンクが関連データを特定の構造で保存し、Flume ネイティブ シンクが通知された生データを保存することです。つまり、次のような Json ベースの通知を受け取った場合:
{
"subscriptionId" : "51c0ac9ed714fb3b37d7d5a8",
"originator" : "localhost",
"contextResponses" : [
{
"contextElement" : {
"attributes" : [
{
"name" : "speed",
"type" : "float",
"value" : "112.9",
"metadatas": []
},
{
"name" : "oil_level",
"type" : "float",
"value" : "74.6",
"metadatas": []
}
],
"type" : "car",
"isPattern" : "false",
"id" : "car1"
},
"statusCode" : {
"code" : "200",
"reasonPhrase" : "OK"
}
]
}
OrionHDFSSink は次のようなものを保存します。
{"recvTimeTs":"1429535775","recvTime":"2015-04-20T12:13:22.41.124Z","fiware-servicePath":"4wheels","entityId":"car1","entityType":"car","attrName":"speed","attrType":"float","attrValue":"112.9","attrMd":[]}
ただし、ネイティブ HDFS シンク (またはその他のシンク) は、通知された json 全体を保持します。
2 番目の主な違いは、通知された fiware-service と fiware-servicePath の処理です。Cygnus のシンクは、通知されたデータを特定のデータ構造 (フォルダー、データベース、テーブル、リソース、キューなど) にマップするために、これらの値を処理できます。これは、マルチテナンシーの目的にとって非常に重要です。
第 3 に、Cygnus は、CKAN、STH、MongoDB、MySQL、DynamoDB など、ネイティブの Flume でカバーされていないストレージ用のシンクを追加します。
他にも多くの違いがあります。
- グループ化ルールの使用。
- 管理インターフェース。
- 公式の FIWARE のメカニズムである OAuth2 認証。
- ...