注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
FAQ
オブジェクトタイプが OSv2 にインデックス化されたことを確認するにはどうすればよいですか？
Ontology Manager アプリケーションには、Funnel パイプライン内の各ジョブのステータスを示す専用のパイプライングラフがあります。グラフ内の Object Storage v2 ノードに緑色のチェックマークが表示されている場合は、インデックス化が完了し、OSv2 からオブジェクトタイプをクエリできる状態になっています。
以前に Object Storage v1（Phonograph）への登録に成功したにもかかわらず、インデックス化ジョブが失敗することがあるのはなぜですか？
OSv1 と OSv2 では、データの検証に若干の違いがあります。
OSv1 は、基盤となる分散ドキュメントストアおよび検索エンジンと密結合しているため、その動作は一般的に基盤となるデータストアの動作によって決まります。OSv2 では、オントロジーに取り込まれるデータの品質を確保し、OSv1 と比較してシステム全体の動作をより決定論的にし、より把握しやすくするために、より厳格な検証を行います。
そのため、以前は OSv1 で受け入れられていたインデックス化パイプラインの一部で、OSv2 を使用すると検証エラーが発生することがあります。このような破壊的変更の詳細な一覧については、OSv1 と OSv2 間のオントロジーの破壊的変更に関するドキュメントを参照してください。
ジョブの1つが失敗しましたが、再試行すれば成功する可能性があります。再ビルドをトリガーするにはどうすればよいですか？
OSv2 は、ジョブの再試行を含め、ジョブに関するすべてを管理します。ジョブを再ビルドすることで解消する可能性がある一時的なエラーによってジョブが失敗した場合、OSv2 は約5分後に自動的にジョブを再試行します。OSv2 がジョブの失敗を回復不能と判断した場合（たとえば、データ形式が無効な場合）は、新しいデータが利用可能になったときにのみ自動的に再試行します。オブジェクトタイプが制限付きビューのデータソースに基づいている場合は、データまたはポリシーが変更されるとジョブがトリガーされます。
インデックス化できるデータのサイズに制限はありますか？
インデックスのサイズは、主に、そのオブジェクトタイプのインデックス化先となるオブジェクトデータベースのストレージ容量によって制限されます。たとえば、OSv2 データストアでは、検索ノードのディスク容量がこれに該当します。
ディスク容量が不足している場合、インデックス化ジョブは成功せず、Ontology Manager アプリケーションのパイプライングラフに根本的な問題が報告されます。ディスク容量のエラーが発生した場合は、Palantir の担当者にお問い合わせください。
ストリーミングデータソースを持つオブジェクトタイプに大規模な履歴データをバックフィルできますか？
ストリーミングデータソースに基づいているオブジェクトタイプの同期には、内部ストリームの作成とインデックス化という2つのフェーズがあります。ストリーミングのインデックス化ジョブでは、Spark を使用してストリーミング履歴データの初期処理を大幅に並列化するため、Funnel バッチパイプラインと同程度のインデックス化の低遅延を実現します。このインデックス化の低遅延は、ライブのオントロジーデータに対するユーザー編集と同程度です。通常、制約となるのは内部ストリームの作成です。この処理では、ストリーミングインフラストラクチャを使用してデータソースをレコード単位で処理します。
オントロジーへのストリーミングで期待される低遅延はどの程度ですか？
Funnel ストリーミングパイプラインで最も時間がかかるのは、「exactly once」のストリーミング整合性を実現するための Flink のチェックポイント処理です。デフォルトのチェックポイント頻度は1秒に1回であるため、入力ストリームにデータが到着してからオントロジーにインデックス化されるまでの低遅延を左右する主な要因となります。頻度を減らしたり、チェックポイント処理を完全に取り除いたりすることで、コスト、パフォーマンス、低遅延のトレードオフを評価する実験を継続的に行っています。
必要に応じて動作を設定するには、Palantir サポートにお問い合わせください。
オントロジーへのストリーミングで期待されるスループットはどの程度ですか？
Object Storage v2 オブジェクトデータベースへのインデックス化スループットは、オブジェクトタイプあたり 2 MB/s に制限されています。より高いインデックス化スループットが必要な場合は、Palantir サポートにお問い合わせください。
オントロジーでストリームデータソースを使用する場合、オブジェクトの重複排除に使用するタイムスタンプを指定できますか？
いいえ。Funnel ストリーミングパイプラインは、インデックス化時に入力ストリームの順序を保持します。データは順序どおりにストリームに書き込む必要があります。これは、上流のストリーミングパイプラインで、イベントのタイムスタンプに基づいてデータをウィンドウ化し、データがハッシュパーティション分割されるように主キーを指定することで実現できます。
オントロジーのストリーミングは変更データキャプチャ（CDC）ワークフローに対応していますか？
Funnel ストリーミングパイプラインは、作成、更新、削除のワークフローに対応しています。削除メタデータの設定方法については、変更データキャプチャのドキュメントを参照してください。
ストリームデータソースを使用する場合、部分的な行をオントロジーに書き込めますか？オブジェクト全体を指定する代わりに、一度にいくつかのプロパティを更新できますか？
現時点ではできません。オブジェクト全体の確定は、上流のパイプラインで行う必要があります。規模の問題により、ステートフルストリーミングでこの問題を解決できない場合は、Palantir サポートにお問い合わせください。
オントロジーのストリーミングを多対多のリンクタイプに使用できますか？
はい、対応しています。ストリーミングデータソースを持つオントロジーのタイプの設定方法について、詳しくはこちらを参照してください。
Object Storage v2 以外のオブジェクトデータベース（たとえば、実体化や Automate）はストリーミングに対応していますか？
オントロジーのストリーミングに現在対応しているのは、Object Storage v2 オブジェクトデータベースのみです。ほかのオブジェクトデータベースでこの機能が必要な場合は、Palantir サポートにお問い合わせください。
ストリームデータソースを持つオブジェクトタイプは実体化に対応していますか？
いいえ。ストリームデータソースを持つオブジェクトタイプはユーザー編集に対応していないため、実体化されたデータセットはストリーム内のアーカイブデータセットと変わりません。現在のアーキテクチャでは、データセット内で重複排除されたビューを提供できません。
Funnel ストリーミングパイプラインが常に実行されています。キャンセルするにはどうすればよいですか？
ユーザーは Funnel ストリーミングパイプラインをキャンセルできません。本番環境のオブジェクトタイプには高可用性が必要なため、Funnel はストリームを常に稼働状態に保持します。この構成では、プロトタイプ作成時に不要なコストが発生する可能性があります。これがユースケースで大きな障害となる場合は、Palantir サポートにお問い合わせください。あるいは、プロトタイプ作成段階では、オブジェクトタイプをバッチのオブジェクトタイプに切り替えてみることもできます。
ダウンタイムなしでストリームデータソースを別のストリームに切り替えるにはどうすればよいですか？
Funnel ストリーミングパイプラインには、新しいストリームに切り替える前に、パイプラインが置き換え先のストリームに対して「最新」の状態になっているかを判断するヒューリスティックがあります。次の手順で、データソースの参照先を別のストリームまたはストリームの別のブランチに変更できます。
- 新しいロジックを別のストリーム（または別のブランチ）で実行します。
- すべての履歴レコードの処理が完了するまで待つなど、新しいストリームのリプレイが完了するまで待ちます。
- オブジェクトタイプの入力データソースを新しいストリームに変更します。
- Funnel ストリーミングパイプラインは、新しいストリームの置き換え先パイプラインが完全にインデックス化されるまで、元のストリームでライブパイプラインを保持します。
- Funnel の切り替えが完了したら、元のストリームを停止できます。
意図しない結果につながる可能性がある、よくある間違いにはどのようなものがありますか？
- データが想定と異なる場合は、入力ストリームが想定どおりの順序になっていることを確認してください。
- Funnel ストリーミングパイプラインは、Funnel バッチパイプラインと同じ検証を実行します。ただし、ストリーミングパイプラインでは、ストリーム処理を一時停止できないため、ユーザーのトランスフォームでエラーをスローする仕組みがありません。そのため、無効なレコードは破棄されます。
オントロジーのストリーミングのコストはいくらですか？
Funnel ストリーミングパイプラインのコンピュートは、通常のストリーミングリソースと同じ方法で計算されます。ストリーミングリソースのコストの詳細については、ストリーミングのコンピュート使用量のドキュメントを参照してください。
保持ウィンドウはどのように機能しますか？
保持ウィンドウは当初、ベータ版リリース中にデータサイズを制限する仕組みとして開発されました。そのため、ベストエフォートでのみ実装されています。つまり、保持ウィンドウ内のオブジェクトはクエリできますが、保持ウィンドウ外のオブジェクトは最終的に削除されます。たとえば、保持ウィンドウが2週間に設定されていて、ストリームデータソースのオブジェクトが入力ストリームによって最後に更新されたのが3週間前である場合、そのオブジェクトはオブジェクトタイプから削除される可能性があります。ただし、そのオブジェクトがオントロジーにさらに何日も残る可能性もあり、特定の期間内に削除されることは保証されません。
現在、オントロジーから古いデータを「クリーンアップ」する仕組みは、デフォルトで2週間ごとに実行されるパイプラインの置換です。置換時には、Funnel ストリーミングパイプラインが保持ウィンドウの開始時点からストリームを再生し、それによって古いオブジェクトをオントロジーから削除します。古いオブジェクトをより頻繁に削除する必要がある場合は、Palantir サポートにお問い合わせください。
保持ウィンドウが設定されていない場合、入力ストリームソースのすべてのデータがオントロジーに取り込まれます。
ストリームソースがバッチでインデックス化されたり、重複エラーで失敗したりするのはなぜですか？
Ontology Managerでは、入力データソースを常にストリームとして明示的に指定する必要があります。これは、ストリーミングデータソースを持つオブジェクトタイプと、ストリームを元にしている制限付きビューの両方に適用されます。指定しない場合、データソースは標準の Funnel バッチパイプラインとしてインデックス化されます。詳細については、ストリーミングオブジェクトタイプを設定するドキュメントを参照してください。
オントロジー関数を使用して、ストリーミングデータソースを持つオブジェクトタイプをクエリできますか？
はい、オントロジーのクエリは、ストリーミングオブジェクトタイプとバッチオブジェクトタイプで同じように機能します。