NGSIHDFSSink¶

コンテンツ :

• 機能性
  • NGSIEvent オブジェクトへの NGSI イベントのマッピング
  • HDFS データ構造への NGSIEvents のマッピング
    • HDFS パスの命名規則
    • Json 行ライクなストア
    • Json 列ライクなストア
    • CSV 行ライクなストア
    • CSV 列ライクなストア
    • Hive
  • 例
    • NGSIEvent
    • パス名
    • Json 行ライクなストア
    • Json 列ライクなストア
    • CSV 行ライクなストア
    • CSV 列ライクなストア
    • Hiveのストア
• 管理ガイド
  • 構成
  • ユースケース
  • 重要なメモ
    • 持続モード
    • バイナリ・バックエンド
    • バッチ処理
    • エンコーディング
• プログラマ・ガイド
  • NGSIHDFSSink クラス
  • OAuth2 認証
  • Kerberos 認証

機能性¶

com.iot.telefonica.cygnus.sinks.NGSIHDFSSink、または単なる NGSIHDFSSinkは、HDFS デプロイメント内で NGSI ライクのコンテキストデータ・イベントを維持するように設計されたシンクです。通常、このようなコンテキストデータは、Orion Context Broker インスタンスによって通知されますが、NGSI言語 を話す他のシステムである可能性があります。

データジェネレータとは無関係に、NGSI コンテキストデータは常に Cygnus ソースの内部オブジェクト NGSIEvent に変換されます。最終的には、これらのイベント内の情報を、Cygnus シンクの特定の HDFSデータ構造にマップする必要があります。

次のセクションでこれについて詳しく説明します。

トップ

NGSIEvent オブジェクトへの NGSI イベントのマッピング¶

コンテキストデータを含む、通知されたNGSI イベントは、NGSI データジェネレータまたはそれが永続化される最終的なバックエンドとは無関係に、NGSIEvent オブジェクト に変換されます。NGSIEvent は、各コンテキスト要素に対して作成されます。このようなイベントは、特定のヘッダと ContextElement オブジェクトを組み合わせたものです。

これは、[NGSIRestHandler](/ngsi_rest_handler.md) のおかげで、cygnus-ngsi Http のリスナー(Flume jergon のソース)で行われています。変換されると、データ (NGSIEvent オブジェクトとして)は、今後の消費のために内部チャネルに入れられます。次のセクションを参照してください。

トップ

HDFS データ構造への NGSIEvents のマッピング¶

HDFS は、大きなデータファイルを含むフォルダにデータを編成します。そのような構成は、NGSIEvent が永続化されるたびに NGSIHDFSSink によって利用されます。

トップ

HDFS パスの命名規則¶

NGSIHDFSSink で受け入れられるユニークなデータモデルはエンティティごとにあるため(詳細は構成セクションを参照してください)、HDFS フォルダは以下の通り :

/user/<hdfs_userame>/<fiware-service>/<fiware-servicePath>/<destination>

<hdfs_username> は HDFS スーパーユーザに関する設定パラメータであり、<fiware-service> および <fiware-servicePath> は Http ヘッダとして通知される、またはNGSIRestHandler ではデフォルトになる、通知された各エンティティに対して作成され、 <destination>は、NGSIEvent 内の notified_entities/grouped_entities ヘッダ値 (グループ化ルールを使用するかどうかに応じて、詳細は構成セクションを参照してください) です。

こでも、<destination> は、NGSIEvent 内のnotified_entities/grouped_entities ヘッダ値 (グループ化ルールを使用するかどうかに応じて、詳細は構成セクションを参照してください) です。

HDFS のフォルダとファイルは、許可された文字セットと、パスの最大長(255文字)に関する Unix の規則に従っていることを確認してください。これにより、enable_encoding構成パラメータによっては特定のエンコーディングが適用されます。

トップ

Json 行ライクなストア¶

HDFS ファイルにストアされている特定のデータに関して、file_format パラメータがjson-row (デフォルトのストアモード)に設定されている場合、通知されたデータは属性ごとにストアされ、それぞれの Json ドキュメントを構成します。各追加項目には、次のフィールドがあります :

• recvTimeTsUTC : タイムスタンプ(ミリ秒単位)
• recvTime : 人間が判読可能な形式のUTCタイムスタンプ(ISO 8601)
• fiwareServicePath : 通知された fiware-servicePath、または通知されない場合はデフォルトの設定済みパス
• entityId : 通知されたエンティティ ID
• entityType : 通知されたエンティティタイプ
• attrName : 通知された属性名
• attrType : 通知された属性タイプ
• attrValue : 最も単純な形式では、この値は単なる文字列ですが、Orion 0.11.0 以降、Json オブジェクトまたは Json 配列になる可能性があります
• attrMd : これには、Json の属性のメタデータ配列の文字列のシリアル化が含まれます。属性にメタデータがない場合、空の配列 []が挿入されます

トップ

Json 列ライクなストア¶

HDFS ファイルにストアされている特定のデータに関して、file_format パラメータがjson-column に設定されている場合、通知されたデータは属性ごとにストアされ、それぞれの Json ドキュメントを構成します。各追加項目には、次のフィールドがあります :

• recvTime : 人間が判読可能な形式の UTC タイムスタンプ (ISO 8601)
• fiwareServicePath 通知された パス、または デフォルトのパス
• entityId : 通知されたエンティティ ID
• entityType : 通知されたエンティティタイプ
• 通知された属性ごとに、属性として指定されたフィールドが考慮されます。このフィールドには、時間に沿って属性値が格納されます
• 通知された属性ごとに、属性名と _md の連結として指定されたフィールドが考慮されます。このフィールドには、属性のメタデータ値が時間とともにストアされます

トップ

CSV 行ライクなストア¶

Regarding the specific data stored within the HDFS file, if file_format parameter is set to csv-row then the notified data is stored attribute by attribute, composing a CSV record for each one of them. Each record contains the following fields:

• recvTimeTsUTC : タイムスタンプ(ミリ秒単位)
• recvTime : 人間が判読可能な形式のUTCタイムスタンプ(ISO 8601)
• fiwareServicePath : 通知された fiware-servicePath、または通知されない場合はデフォルトの設定済みパス
• entityId : 通知されたエンティティ ID
• entityType : 通知されたエンティティタイプ
• attrName : 通知された属性名
• attrType : 通知された属性タイプ
• attrValue : 最も単純な形式では、この値は単なる文字列ですが、Orion 0.11.0 以降、Json オブジェクトまたは Json 配列になる可能性があります
• attrMd : この場合、フィールドには実際のメタデータは含まれず、そのようなメタデータを格納する HDFS ファイルの名前が含まれます。これを行う理由は、メタデータが任意の長さの配列である可能性があるためです。配列内の各要素は、メタデータの名前、型、および値を含むメタデータファイル内の単一の行として永続化され、すべてが ',' フィールド区切り文字で区切られます。/user/<hdfs_userame>/<fiware-service>/<fiware-servicePath>/<destination>_<attrName>_<attrType>/<destination>_<attrName>_<attrType>.txt 下の各属性ごとにメタデータファイルがあります

トップ

CSV 列ライクなストア¶

HDFS ファイル内に格納されている特定のデータに関して、file_format パラメータがcsv-column に設定されている場合は、以下のフィールドを含む通知されたエンティティ全体に対して単一の CSV レコードが作成されます :

• recvTime : 人間が判読可能な形式のUTCタイムスタンプ(ISO 8601)
• fiwareServicePath: 通知されたパス、またはデフォルト・パス
• entityId : 通知されたエンティティ ID
• entityType : 通知されたエンティティタイプ
• 通知された属性ごとに、属性として指定されたフィールドが考慮されます。このフィールドには、時間に沿って属性値が格納されます
• 通知された属性ごとに、属性名と _md の連結として指定されたフィールドが考慮されます。このフィールドには、属性のメタデータ値が時間とともにストアされます

トップ

Hive¶

HDFS の永続化されたデータに関する特別な機能は、SQL のようなクエリ・システムである Hive を使用してそのデータを利用できることです。NGSIHDFSSink は、デフォルト・データベースの各永続エンティティに対して、Hive 外部テーブル (SQL テーブルに似ています) を自動的に作成します。このテーブルは <username>_<fiware-service>_<fiware-servicePath>_<destination>_[row|column] というテーブルの名前です。

各データ行に関するフィールドは、HDFS ファイルに追加された JSON ドキュメント/CSV レコードのフィールドと一致します。JSON の場合は、JSON serde を使用してデシリアル化されます。 CSV の場合、テーブル作成で指定された区切り文字フィールドによってデシリアライズされます。

トップ

例¶

NGSIEvent¶

以下の NGSIEvent が通知された NGSI コンテキストデータから作成されたと仮定します。以下のコードは実体データ形式ではなくオブジェクト表現です :

ngsi-event={
    headers={
         content-type=application/json,
         timestamp=1429535775,
         transactionId=1429535775-308-0000000000,
         correlationId=1429535775-308-0000000000,
         fiware-service=vehicles,
         fiware-servicepath=/4wheels,
         <grouping_rules_interceptor_headers>,
         <name_mappings_interceptor_headers>
    },
    body={
        entityId=car1,
        entityType=car,
        attributes=[
            {
                attrName=speed,
                attrType=float,
                attrValue=112.9
            },
            {
                attrName=oil_level,
                attrType=float,
                attrValue=74.6
            }
        ]
    }
}

トップ

パス名¶

構成パラメータとして、hdfs_username=myuser と service_as_namespace=false を祖想定すると、NGSIHDFSSink はこのファイル内のデータを本体内に保持します (古いエンコーディング) :

$ hadoop fs -cat /user/myuser/vehicles/4wheels/car1_car/car1_car.txt

新しいエンコーディングを使用 :

$ hadoop fs -cat /user/myuser/vehicles/4wheels/car1xffffcar/car1xffffcar.txt

トップ

新しいエンコーディングを使用 :¶

上記のファイルには、1つの属性ごとに1組の Json ドキュメントが追加されています :

{"recvTimeTs":"1429535775","recvTime":"2015-04-20T12:13:22.41.124Z","fiwareServicePath":"4wheels","entityId":"car1","entityType":"car","attrName":"speed","attrType":"float","attrValue":"112.9","attrMd":[]}
{"recvTimeTs":"1429535775","recvTime":"2015-04-20T12:13:22.41.124Z","fiwareServicePath":"4wheels","entityId":"car1","entityType":"car","attrName":"oil_level","attrType":"float","attrValue":"74.6","attrMd":[]}

トップ

Json 列ライクなストア¶

上記のファイルには、すべての属性を含む単一の Json ドキュメントが追加されます :

{"recvTime":"2015-04-20T12:13:22.41.124Z","fiwareServicePath":"4wheels","entityId":"car1","entityType":"car","speed":"112.9","speed_md":[],"oil_level":"74.6","oil_level_md":[]}

トップ

CSV 行ライクなストア¶

CSV レコードのペアが属性ごとに1つ、上記のファイルに追加されます :

1429535775,2015-04-20T12:13:22.41.124Z,4wheels,car1,car,speed,float,112.9,hdfs:///user/myuser/vehicles/4wheels/car1_car_speed_float/car1_car_speed_float.txt
1429535775,2015-04-20T12:13:22.41.124Z,4wheels,car1,car,oil_level,float,74.6,hdfs:///user/myuser/vehicles/4wheels/car1_car_oil_level_float/car1_car_oil_level_float.txt

上記の例のメタデータが空であるにもかかわらず、とにかくメタデータ・ファイルが作成されることに注意してください。

この場合、speed 属性のメタデータは、例えば :

[
   {"name": "manufacturer", "type": "string", "value": "acme"},
   {"name": "installation_year", "type": "integer", "value": 2014}
]

そして、hdfs:///user/myuser/vehicles/4wheels/car1_car_speed_float/car1_car_speed_float.txt ファイルの内容は次のようになります :

1429535775,manufacturer,string,acme
1429535775,installation_year,integer,2014

トップ

CSV 列ライクなストア¶

単一の CSV レコードがすべての属性を含む上記のファイルに追加されます :

2015-04-20T12:13:22.41.124Z,112.9,4wheels,car1,car,hdfs:///user/myuser/vehicles/4wheels/car1_car_speed_float/car1_car_speed_float.txt,74.6,hdfs:///user/myuser/vehicles/4wheels/car1_car_oil_level_float/car1_car_oil_level_float.txt}

上記の例のメタデータが空であるにもかかわらず、とにかくメタデータファイルが作成されることに注意してください。

この場合、speed 属性のメタデータは、例えば :

[
   {"name": "manufacturer", "type": "string", "value": "acme"},
   {"name": "installation_year", "type": "integer", "value": 2014}
]

そして、hdfs:///user/myuser/vehicles/4wheels/car1_car_speed_float/car1_car_speed_float.txt ファイルの内容は次のようになります :

1429535775,manufacturer,string,acme
1429535775,installation_year,integer,2014

トップ

Hive のストア¶

Hive に対して、json-row, json-column, csv-row および csv-column モード内のテーブルの内容は、それぞれ、以下のとおりです :

$ hive
hive> select * from myuser_vehicles_4wheels_car1_car_row;
OK
1429535775  2015-04-20T12:13:22.41.124Z 4wheels car1    car speed       float   112.9   []
1429535775  2015-04-20T12:13:22.41.124Z 4wheels car1    car oil_level   float   74.6    []
hive> select * from myuser_vehicles_4wheels_car1_car_column;
2015-04-20T12:13:22.41.124Z     4wheels car1    car 112.9   []  74.6    []
hive> select * from myuser_vehicles_4wheels_car1_car_row;
OK
1429535775  2015-04-20T12:13:22.41.124Z 4wheels car1    car speed       float   112.9   hdfs:///user/myuser/vehicles/4wheels/car1_car_speed_float/car1_car_speed_float.txt
1429535775  2015-04-20T12:13:22.41.124Z car1    car oil_level   float   74.6    hdfs:///user/myuser/vehicles/4wheels/car1_car_oil_level_float/car1_car_oil_level_float.txt
hive> select * from myuser_vehicles_4wheels_car1_car_column;
2015-04-20T12:13:22.41.124Z     4wheels car1    car 112.9   hdfs:///user/myuser/vehicles/4wheels/car1_car_speed_float/car1_car_speed_float.txt  74.6    hdfs:///user/myuser/vehicles/4wheels/car1_car_oil_level_float/car1_car_oil_level_float.txt

注 : hive は、データをローカルにクエリするための Hive CLI です。

トップ

管理ガイド¶

構成¶

NGSIHDFSSinkは、 次のパラメータによって構成されます :

パラメータ	必須	デフォルト値	コメント
type	yes	N/A	com.telefonica.iot.cygnus.sinks.NGSIHDFSSink である必要があります
channel	yes	N/A
enable_encoding	no	false	true または false。true は新しいエンコーディングを適用し、false は古いエンコーディングを適用します
enable_grouping	no	false	true または false。詳細については、このリンクをチェックしてください
enable_name_mappings	no	false	true または false。詳細については、このリンクをチェックしてください
enable_lowercase	no	false	true または false
data_model	no	dm-by-entity	構成されていなくても、常に dm-by-entity です
file_format	no	json-row	json-row, json-column, csv-row または json-column のいずれかになります
backend.impl	no	rest	rest は、HDFS とやりとりするときに WebHDFS/HttpFS ベースの実装が使用される場合。または、 binary は、HDFS とやりとりするときに Hadoop API ベースの実装が使用されている場合
backend.max_conns	no	500	Http ベースの HDFS バックエンドに許可される最大接続数。バイナリバックエンド実装を使用している場合は無視されます
backend.max_conns_per_route	no	100	Http ベースの HDFS バックエンドに許可されているルートごとの最大接続数。バイナリバックエンド実装を使用している場合は無視されます
hdfs_host	no	localhost	HDFS ネームノードが実行される FQDN/IPアドレス、またはHDFS HA ネームノードが実行される FQDN/IP アドレスのコンマ区切りリスト
hdfs_port	no	14000	HttpFS (rest) を使用する場合は14000、WebHDFS (rest) を使用する場合は50070、Hadoop API (binary) を使用する場合は8020
hdfs_username	yes	N/A	service_as_namespace=false の場合、HDFS の既存のユーザでなければなりません。service_as_namespace=true の場合、HDFS のスーパーユーザでなければなりません
hdfs_password	yes	N/A	上記 hdfs_username のパスワード。これは Hive 認証にのみ必要です
oauth2_token	yes	N/A	HDFS 認証に必要な OAuth2 トークン
service_as_namespace	no	false	true に設定されている場合は、fiware-service またはデフォルト・パスが、hdfs_username の代わりに、HDFS 名前空間として代わりに使用されます。この場合は HDFS スーパーユーザである必要があります
csv_separator	no	,
batch_size	no	1	永続化の前に蓄積されたイベントの数
batch_timeout	no	30	バッチがそのまま永続化される前に構築される秒数
batch_ttl	no	10	バッチを永続化できない場合のリトライ回数。リトライしない場合は 0、無限にリトライする場合は -1 を使用してください。無限のTTL(非常に大きいものでさえ)がすべてのシンクのチャネル容量を非常に素早く消費するかもしれないと考えてください
batch_retry_intervals	no	5000	永続化されていないバッチに関するリトライが行われるコンマ区切りの間隔(ミリ秒単位)のリスト。最初のリトライは、最初の値と同じ数ミリ秒後に実行され、2回目の再試行は2番目の値の後に完了します。batch_ttl が間隔の数より大きい場合、最後の間隔が繰り返されます
hive	no	true	true または false
hive.server_version	no	2	リモート Hive サーバが HiveServer1 を実行している場合は、1 または リモート Hive サーバが HiveServer2を実行している場合は、2
hive.host	no	ローカルホスト
hive.port	no	10000
hive.db_type	no	default-db	default-db または namespace-db。hive.db_type=default-db の場合、デフォルトのHiveデータベースが使用されます。hive.db_type=namespace-db とservice_as_namespace=false の場合、hdfs_username が Hive データベースとして使用されます。hive.db_type=namespace-db と service_as_namespace=true の場合、通知された fiware-service は Hive データベースとして使用されます
krb5_auth	no	false	true または false
krb5_user	yes	empty	krb5_auth=false の場合は無視され、それ以外の場合は必須です
krb5_password	yes	empty	krb5_auth=false の場合は無視され、それ以外の場合は必須です
krb5_login_conf_file	no	/usr/cygnus/conf/krb5_login.conf	krb5_auth=false の場合は無視されます
krb5_conf_file	no	/usr/cygnus/conf/krb5.conf	krb5_auth=false の場合は無視されます

構成例は、次のとおりです :

cygnus-ngsi.sinks = hdfs-sink
cygnus-ngsi.channels = hdfs-channel
...
cygnus-ngsi.sinks.hdfs-sink.type = com.telefonica.iot.cygnus.sinks.NGSIHDFSSink
cygnus-ngsi.sinks.hdfs-sink.channel = hdfs-channel
cygnus-ngsi.sinks.hdfs-sink.enable_encoding = false
cygnus-ngsi.sinks.hdfs-sink.enable_grouping = false
cygnus-ngsi.sinks.hdfs-sink.enable_lowercase = false
cygnus-ngsi.sinks.hdfs-sink.enable_name_mappings = false
cygnus-ngsi.sinks.hdfs-sink.data_model = dm-by-entity
cygnus-ngsi.sinks.hdfs-sink.file_format = json-column
cygnus-ngsi.sinks.hdfs-sink.backend.impl = rest
cygnus-ngsi.sinks.hdfs-sink.backend.max_conns = 500
cygnus-ngsi.sinks.hdfs-sink.backend.max_conns_per_route = 100
cygnus-ngsi.sinks.hdfs-sink.hdfs_host = 192.168.80.34
cygnus-ngsi.sinks.hdfs-sink.hdfs_port = 14000
cygnus-ngsi.sinks.hdfs-sink.hdfs_username = myuser
cygnus-ngsi.sinks.hdfs-sink.hdfs_password = mypassword
cygnus-ngsi.sinks.hdfs-sink.oauth2_token = mytoken
cygnus-ngsi.sinks.hdfs-sink.service_as_namespace = false
cygnus-ngsi.sinks.hdfs-sink.batch_size = 100
cygnus-ngsi.sinks.hdfs-sink.batch_timeout = 30
cygnus-ngsi.sinks.hdfs-sink.batch_ttl = 10
cygnus-ngsi.sinks.hdfs-sink.batch_retry_intervals = 5000
cygnus-ngsi.sinks.hdfs-sink.hive = false
cygnus-ngsi.sinks.hdfs-sink.krb5_auth = false

トップ

ユースケース¶

中長期的に成長する JSON または CSV ベースのドキュメント・ストレージを、将来のトレンド探索のためのテラバイトの推定サイズで、時間の持続的な行動のパターンなどに沿って、探している場合は、NGSIHDFSSink を使用してください。

短期間の履歴、ダッシュボードやチャート作成のユーザーインターフェースに必要なものは、MongoDB, STH Comet, MySQL (Cygnus も同様のシンクを提供します) などのバックエンドが適しています。

トップ

重要なメモ¶

永続化モード¶

同じ数の属性が通知されるとは限りません。これは、NGSI のような送信者へのサブスクリプションに依存します。 通知された属性ごとに固定の8フィールドの行(fixed 8-fields rows)がアップデートされるため、*-row の永続化モードでは問題ありません。 それにもかかわらず、*-column モードはフィールドの長さが異なる複数行の影響を受ける可能性があります。 したがって、*-column モードは、サブスクリプションが最後の通知以降に更新されなかった場合、常に同じ属性、イベントを送信するように設計されている場合にのみ推奨されます。

トップ

バイナリ・バックエンド¶

HDFS バイナリ・バックエンドの現在の実装は、認証メカニズムをサポートしていません。

望ましい認証方法は、FIWARE の標準である OAuth2 ですが、バイナリ・バックエンドがアクセスするリモート RPC サーバでは現在サポートされていません。

有効な認証メカニズムは Kerberos と Hadoop Delegation Token ですが、いずれも使用されておらず、バックエンドは cygnus ユーザ( Cygnusを実行しているユーザ)が偽装するためには単にユーザ名 (hdfs_username 内に設定されているもの) が必要です。

したがって、マルチユーザー環境でこのバックエンドを使用することは推奨されません。少なくとも、ユーザーがユーザ名を指定するだけで他のユーザを偽装する可能性はありません。

fiware-cosmos プロジェクトのコンテキストで、Hadoop RPC メカニズムに OAuth2 サポートを追加する際の問題があります。

トップ

バッチ処理¶

プログラマ・ガイドで説明したように、NGSIHDFSSink は、内部 Flume チャネルからイベントを収集するための組み込みのメカニズムを提供する NGSISink を拡張します。このメカニズムにより、拡張クラスは、最終的なバックエンドにおけるこのような一連のイベントの永続化の詳細のみを処理することができます。

バッチのメカニズムに関して重要なことは、インサートの数が大幅に減少するため、シンクの性能を大幅に向上させることです。例を見てみましょう。100個の NGSIEvent を一組としましょう。最良の場合、これらのイベントはすべて同じエンティティに関係します。つまり、その中のすべてのデータが同じ HDFS ファイルに保持されます。イベントを1つずつ処理する場合は、HDFS への書き込みは100回必要です。それにもかかわらず、この例では、1つのインサートのみが必要です。明らかに、すべてのイベントが常に同じユニークなエンティティを考慮するとは限らず、多くのエンティティがバッチ内に関与する可能性があります。しかし、これは問題ではありません。イベントのいくつかのサブバッチがバッチ内に作成されるため、最終的な出力先 HDFS ファイルごとに1つのサブバッチが作成されるためです。 最悪の場合、100のエンティティは100種類のエンティティ(100種類の HDFS デスティネーション)になりますが、これは通常のシナリオではありません。したがって、1バッチあたり10〜15個のサブバッチが現実的であると仮定すると、10〜15個のインサートのみを用いたイベントアプローチによるイベントの100個のインサートを置き換えます。

バッチ処理メカニズムは、新しいデータが到着しないときにシンクがバッチ構築の待ち状態にとどまるのを防ぐために蓄積タイムアウトを追加します。 そのようなタイムアウトに達すると、バッチはそのまま維持されます。

永続化されていないバッチのリトライに関しては、2つのパラメータが使用されます。一方は、Cygnus がイベントを確実にドロップする前にリトライする回数を指定して、Time-To-Live(TTL) を使用します。もう一方は、リトライ間隔のリストを構成することができます。そのようなリストは最初のリトライ間隔を定義し、次に2番目のリトライ間隔を定義します。TTLがリストの長さより大きい場合、最後のリトライ間隔が必要な回数繰り返されます。

デフォルトで、NGSIHDFSSink は、設定されたバッチサイズは１で、バッチ蓄積タイムアウトは30秒です。それにもかかわらず、上で説明したように、パフォーマンス目的で少なくともバッチサイズを増やすことを強くお勧めします。どのような最適な値ですか？バッチのサイズは、イベントが得られているチャネルのトランザクションサイズに密接に関連しています(最初のものが2番目のものより大きいことは意味がありません)。また、推定されたサブバッチの数にも依存します。累積タイムアウトは、最終ストレージに新しいデータを出力する頻度に依存します。イベントのバッチとその適切なサイジングについての深い議論は、パフォーマンスのドキュメントで見つけることができます。

トップ

エンコーディング¶

バージョン1.2.0(含む)まで、Cygnus は非常に単純なエンコーディングを適用しました：

• 英数字以外の文字はすべてアンダースコア(_)で置き換えられました
• アンダースコアは連結文字としても使用されていました
• FIWARE service paths内のスラッシュ(/)は無視されます

バージョン1.3.0(含む)から、Cygnus は HDFS データ構造に合わせたこの特定のエンコーディングを適用します :

• 英数字はエンコードされません
• 数字はエンコードされません
• 等号文字 (=)は、xffff としてエンコードされます
• x 文字と Unicode で構成されるユーザ定義の文字列は、Unicode の後に xx としてエンコードされます
• スラッシュ文字 (/) は、x002f としてエンコードされます
• その他の文字はすべてエンコードされません
• xffff は、連結文字として使用されます

将来、古いエンコーディングは非推奨になりますが、構成セクションで説明したように、enable_encoding パラメータを使用してエンコーディングタイプを切り替えることは可能です。

トップ

プログラマ・ガイド¶

NGSIHDFSSink クラス¶

他の NGSI ライクのシンクと同様に NGSIHDFSSink は、NGSISink ベースを拡張します。拡張されるメソッドは次のとおりです :

void persistBatch(Batch batch) throws Exception;

Batch には 通知されたコンテキストデータイベントを解析した結果である NGSIEvent オブジェクトのセットが含まれます。バッチ内のデータは宛先別に分類され、最終的に宛先はデータが保存される HDFS ファイルを指定します。したがって、HDFSBackend 実装 (binary または rest) のおかげで、各宛先は、永続化される宛先データ・ストリングを構成するために反復されます。

public void start();

HDFSBackend の実装が作成されます。起動するシーケンスは NGSICKANSink() (コンストラクタ)、configure() および、start() であるため、start() メソッドではなくコンストラクタで行う必要があります。

public void configure(Context);

上記のような完全な構成が、与えられた Context インスタンスから読み取られます。

トップ

OAuth2 認証¶

OAuth2 は、認証のためのオープン・スタンダードである OAuth プロトコルの進化です。OAuth を使用すると、クライアント・アプリケーションは、リソース所有者に代わって特定のサーバ・リソースにアクセスし、資格情報をサービスと共有せずに最高の方法でアクセスすることができます。これは、いくつかのセキュリティ情報、すなわちアクセス・トークンの発行を担当する信​​頼できる認証サービスのために働きます。一度要求されると、アクセストークンはサービス・リクエストに添付され、サーバは、アクセス(認証)を要求するユーザの有効性と、このユーザに対するリソース自体の可用性(認可)を認可サービスに尋ねることができます。

OAuth2 の詳細なアーキテクチャはここにありますが、簡単に言えば、FIWARE は Identity Manager GE(Keyrock の実装)とアクセス制御(AuthZForce implementation) の実装)によって上記の概念を実装しています。この2つのイネーブラーの結合は、FIWARE の OAuth2ベースの認可サービスに準拠しています :

• アクセストークンは Identity Manager に要求されます。Identity Manager は、トークンが受信されると、認証のために最終サービスからリクエストされます。このサービスに依頼して、リクエストの背後にある本当のFIWARE ユーザが誰であるかを発見するだけでなく、そのユーザが自分が誰であるかを完全に確信していることを確認してください
• 同時に、Identity Manager は認証の目的でアクセス制御に依存します。アクセストークンは、ユーザの実際の身元に加えて、要求されたリソースに応じた役割を与えます。アクセス制御は、ユーザの役割に基づいてすべてのリソースにアクセスできるユーザに関するポリシーのリストを所有しています

Cygnus にとって重要なのは、HDFS (ビッグ)データにネイティブの WebHDFS RESTful API を介してアクセスできるためです。そして、それは上記のメカニズムで保護されるかもしれません。その場合、単にアクセストークンを要求し、cygnus-ngsi.sinks.hdfs-sink.oauth2_token パラメータを使用して設定に追加します。

アクセストークンを取得するには、OAuth2 トークンプロバイダに対して次の要求を行います。FIWARE Lab では、これは cosmos.lab.fi-ware.org:13000 です :

$ curl -X POST "http://computing.cosmos.lab.fiware.org:13000/cosmos-auth/v1/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=password&username=frb@tid.es&password=xxxxxxxx”
{"access_token": "qjHPUcnW6leYAqr3Xw34DWLQlja0Ix", "token_type": "Bearer", "expires_in": 3600, "refresh_token": “V2Wlk7aFCnElKlW9BOmRzGhBtqgR2z"}

お分かりのように、FIWARE Lab の資格情報は、パスワードベースの認可タイプの形式でペイロードに必要です。これはあなたがそれらを与える必要がある唯一の時間になります。

トップ

Kerberos 認証¶

Hadoop 分散ファイルシステム (HDFS)は、WebHDFS というREST API を使用してリモート管理できます。この API は、セキュリティなしで使用できます。このユーザの HDFS スペースにアクセスするには有効な HDFS ユーザ名を知っていれば十分です。または、Kerberos インフラストラクチャを使用してユーザを認証できます。

Kerberos は MIT によって作成された認証プロトコルであり、現在のバージョンは5です。これは対称鍵暗号方式と信頼できるサードパーティの Kerberos サーバ自体に基づいています。このプロトコルは、認証サーバ(AS)を認証するのと同じくらい簡単です。これは、最終的な client-to-server チケットを取得するために使用できるチケット許可チケット(TGT)を使用して、ユーザーを Key Distribution Center(KDC)に転送します。このチケットは、双方向でサービスサーバーに対して認証目的で使用できます。

SPNEGO は、セキュリティ技術の選択を交渉するために使用されるメカニズムです。SPNEGO により、クライアントとサーバの両方が認証技術として Kerberos の使用をネゴシエートできます。

Kerberos 5 クライアントがインストールされ、ユーザーが Kerberos インフラストラクチャのプリンシパルとして既に存在する場合、コマンドラインから HDFS の Kerberos 認証を簡単に実行できます。次に、有効なチケットを取得し、curl で --negotiate オプションを使用します。

$ kinit <USER>
Password for <USER>@<REALM>:
$ curl -i --negotiate -u:<USER> "http://<HOST>:<PORT>/webhdfs/v1/<PATH>?op=..."

それにもかかわらず、Cygnus はこのプロセスを自動化する必要があります。設定の仕方を見てみましょう。

トップ

conf/cygnus.conf¶

このファイルは、配布された conf/cugnus.conf.template から構築できます。NGSIHDFSSink 設定のこの部分を適切に編集します。

# Kerberos-based authentication enabling
cygnus-ngsi.sinks.hdfs-sink.krb5_auth = true
# Kerberos username
cygnus-ngsi.sinks.hdfs-sink.krb5_auth.krb5_user = krb5_username
# Kerberos password
cygnus-ngsi.sinks.hdfs-sink.krb5_auth.krb5_password = xxxxxxxxxxxxx
# Kerberos login file
cygnus-ngsi.sinks.hdfs-sink.krb5_auth.krb5_login_file = /usr/cygnus/conf/krb5_login.conf
# Kerberos configuration file
cygnus-ngsi.sinks.hdfs-sink.krb5_auth.krb5_conf_file = /usr/cygnus/conf/krb5.conf

つまり、Kerberos 認証を有効にするかどうかを開始します。次に、すでに登録されている Kerberos プリンシパルとそのパスワードを使用してユーザーを構成します。最後に、2つの特別な Kerberos ファイルの場所を指定します。

トップ

conf/krb5_login.conf¶

変更してはならない次の行が含まれています。したがって、配布されたファイルはテンプレートではなく、最終的なものです。

cygnus_krb5_login {
    com.sun.security.auth.module.Krb5LoginModule required doNotPrompt=false debug=true useTicketCache=false;
};

トップ

conf/krb5.conf¶

このファイルは、配布された conf/krb5.conf.template から構築できます。EXAMPLE.COM を Kerberos 領域(これはあなたのドメインと同じですが、大文字で、example.com の領域は EXAMPLE.COMです)で置き換え、Kerberos Key Distribution Center(KDC) と Kerberos 管理/認証サーバを構成することで、適切に編集します。それらを知るためにネットワーク管理者に尋ねてください。

[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]
 EXAMPLE.COM = {
  kdc = kdc.example.com
  admin_server = admin_server.example.com
 }

[domain_realms]
 .example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM

トップ