Apache Kylin は、多くのデータ サイエンティストのニーズを満たす優れたツールのようです。また、非常に複雑なシステムでもあります。まったく同じ目標を念頭に置いて、クエリの待ち時間が短い多次元 OLAP キューブという社内ソリューションを開発しています。多くの問題の中で、私が今最も懸念しているのは、耐障害性に関するものです。受信トランザクション データが大量にある場合、キューブを段階的に更新する必要があります。一部の立方体は、年スケールの時間ディメンション値を持つものなど、長期間にわたって更新されます。このような長い期間にわたって、複雑なシステムの一部は確実に機能しなくなります。システムは、すべての生のトランザクション レコードが立方体に正確に 1 回だけ集約されることをどのように保証するのでしょうか? 各ピースには独自のフォールト トレランス メカニズムがありますが、そうではありません。つまり、自動的に一緒にプレイするということです。簡単にするために、すべての入力データは別のプロセスによって HDFS に保存され、自発的または強制的な中断から任意の方法で「再生」できると仮定できます。Kylin のフォールト トレランスに関する考慮事項は何ですか、それとも実際には問題ではありませんか?
2 に答える
2
データ障害とシステム障害があります。
データ フォールト トレランス: Kylin はキューブをセグメントに分割し、キューブ全体に影響を与えることなく個々のセグメントを再構築できます。たとえば、新しい日単位のセグメントが日単位で作成され、週末に週単位のセグメントにマージされるとします。週単位のセグメントは月単位のセグメントなどにマージされます。1 週間以内にデータ エラー (または何らかの変更) が発生した場合、1 日のセグメントのみを再構築する必要があります。さらに遡ってデータを変更するには、週単位または月単位のセグメントを再構築する必要があります。
セグメント戦略は完全にカスタマイズ可能であるため、データ エラー許容度とクエリ パフォーマンスのバランスを取ることができます。セグメントが多いほど、データの変更に対する耐性が高くなりますが、クエリごとに実行するスキャンも多くなります。Kylin は RESTful API を提供します。外部スケジューリング システムは API を呼び出して、セグメントのビルドとマージをトリガーできます。
キューブはまだオンラインであり、セグメントの一部が再構築中の場合でもクエリを処理できます。
システムのフォールト トレランス: Kylin は、ほとんどのシステムの冗長性とフォールト トレランスを Hadoop と HBase に依存しています。それに加えて、Kylin のすべてのビルド ステップは冪等です。つまり、副作用なしで失敗したステップを安全に再試行できます。これにより、ビルド プロセスが何回失敗して再試行されても、最終的な正確性が保証されます。
(私は Apache Kylin の共同作成者であり、コミッターでもあります。:-)
于 2015-03-30T05:19:00.847 に答える
1
注: 私は Apache Kylin の共同作成者であり、コミッターです。
Fault Tolerance ポイントは非常に優れたポイントであり、非常に大きなデータセットがある場合に実際に尋ねられることがあります。計算を最初からやり直すには、膨大なコンピューティング リソース、ネットワーク トラフィック、および時間が必要になります。
しかし、製品の観点からは、正確な結果とリソースのどちらがより重要かという問題があります。トランザクション データの場合は正確な数の方が重要だと思いますが、動作データの場合は問題ないはずです。ビジネス ニーズに応えるために Kylin を活用するのは、どのような場合かによって異なります。
このアイデアをバックログに入れ、後で明確な手がかりがあれば、Kylin dev メーリング リストを更新します。
ありがとう。
于 2015-03-25T01:40:30.200 に答える