歴史的に、政府部門はより不活性です。なぜなら、各ステップをより長く調整することが慣習的であるからです。 ほとんどの職員自身が過度の熱意なしにITプロジェクトを認識しています。 状態構造には通常、新しいものに対する強い抵抗はありませんが、特に新しいソリューションを導入した結果に関心のある「機関車」を見つけることは難しいことがわかりました。 その結果、実装の進行が遅くなり、外部からは、顧客はこのプロジェクトまたはそのプロジェクトをまったく必要としないように思われ始めています。
しかし、これらすべてにより、近年、国有企業のITに対する態度は根本的に変化しました。 電子政府プログラムの下で、政府機関は、情報システムの使用は、少なくとも避けられないことを認識しました。 そして、開発の準備ができている比較的若いマネージャーが非常に重要な先例を取っている世代の変化-政府機関は、サポートと開発を確実にするために顧客側でプロジェクトに参加できる人々を持っています。
ゴサムには何が必要ですか？
企業が必要なものとその数を明確に知っている場合、政府機関はそのような知識を自慢できません。 同時に、部門のニーズは、原則として、当初の予想よりもはるかに広いです。 たとえば、実践が示しているように、第3バージョン（SMEV 3.x）の省庁間相互作用のシステムに切り替えると、顧客は新しいモジュールを導入するだけでなく、SMEV 2.xとの後方互換性を提供するフォーマットコンバーターと、追加の決定。 このようなことは、国有企業のプロジェクトで発生します。これには、インテグレーターの統合アプローチとすべてに対する準備が必要です。
政府機関がSAPやOracleなどの業界大手のソリューションを広く使用しているという事実にもかかわらず、これらのプラットフォームの安定性にもかかわらず、最近優先順位が変わっています。 サポートのコストはますます重要になり、輸入代替のコースは勢いを増し続けています。 たとえば、以前に大規模な分析プロジェクトにIBM Cognos TM1およびOracle Hyperion EssBase OLAPエンジンを使用する予定だった場合、今日、為替レートの変更により、そのようなソリューションは予定予算に含まれなくなりました。 その結果、Polymatika社の製品など、価値のある国内ソリューションが見つかりました。 このシステムはOLAPキューブデータをRAMに配置するため、分析は最大速度で実行され、中央およびGPUのコアを使用して標準サーバーで数十億件のレコードを処理できます。
しかし、市場には必要なレベルのロシア製品は非常に少なく、あらゆる応用分野から遠く離れて、価値のある代替品を見つけることは可能です。 したがって、政府機関は、オープンソースプラットフォームに基づいたカスタム開発、および外国のサプライヤーからのシステムの保証されたサポートに対して前向きな姿勢を持っています。 もちろん、ここには完全な自律性はありません。ベンダーに依存する代わりに、開発者に依存しています。 顧客は、誰がシステムをサポートおよび開発するのだろうと考え始めますか？ そのため、同じ企業が政府の顧客の請負業者として最もよく機能します。新しいプロジェクトを立ち上げるとき、正当な信頼は主要な議論の1つです。
上記のすべてを考慮すると、政府機関の情報システムはパズルのようなものであり、その組み立てには箱入りのカスタム製品、オープンプラットフォーム、および商用ソリューションの使用が必要です。 高品質の統合が存在する場合、このようなアプローチにより、特定の製品の閉鎖を回避し、開発やサポートが疑わしい場合は新しい「パーツ」を追加してパズルを交換する機会を残します。
政府のニーズ
1つの機関ではなく、複数の機関を同時にカバーする複雑な情報空間の状態構造の形成により、新世代の分析ソリューションを使用するための前提条件が作成されました。 たとえば、第3バージョンのMEELには、公共サービスの提供の量と質に関する統計を電子形式および部門間相互作用で収集する分析モジュールも含まれています。 現在、地域のMFCと金融機関の両方を含む、増え続けるSMEVユーザーを背景に、相互作用の量は指数関数的に増加しています。 大量のデータは、それらを使用できる追加のツールを導入する可能性をすべて開きます。 膨大なデータセットは分析の機会を切り開き、新しいITツールの使用は州の実際のニーズによって決まります。 すべてが利益を上げてコストを削減することを目的とする営利団体とは異なり、政府機関はわずかに異なるタスクを持ち、主なものは次のとおりです。
- 規制報告の形成-各政府部門は、厳密に定義された形式で報告を提供します。 手動モードでは、このようなレポートの準備により数日間、部門の作業が麻痺します。分析システムを使用すると、この問題をできる限り明確かつ迅速に解決できます。 たとえば、自動化されたFIUシステムは、300以上の異なるレポートを準備します。
- レジスタの維持-近年のほとんどの部門は、1つまたは別のレジストリを維持するように指示されています。 そのため、「Roskomandzor」は禁止サイトの登録を保持し、そのクローンを発見し、FIUは保険会社と保険契約者の登録を保持しています。 このようなレジストリの関連性を追跡することは、BIシステムにとってほぼ理想的なタスクです。
- モバイル分析-さまざまな組織の部門の責任者が、タブレットにある運用指標を操作するのに便利であることがわかりました。 政府機関の場合、全体的なプロセスを監視することに加えて、この機会は当局に必要なレベルの個人的な保護を与えます。当局の「カーペットの上」では、どんな質問にも迅速に答えられるからです。
連邦データ
これらの問題を解決するには、大規模なデータウェアハウスやそれらを操作するための特別なツールなどの特別なテクノロジーを使用する必要があります。 連邦政府部門は、最大50 TB以上のデータベースを使用しています。 たとえば、FIUのAIS-2 IAPの分析データウェアハウスには、次の特性があります。
- 最大200 Tbの推定容量。
- 1500人以上のユーザーと、最大6000人の接続が見込まれます。
- さまざまな類型の17のデータソース。その一部は地理的に分散しています。
- 2000を超えるエンティティ（テーブル）。
- 約10,000個のエンティティ属性。
- 約300のインジケータと500のデータモデル測定。
- データモデルの15,000以上の属性。
分散バージョンでそのようなシステムの動作を確保するために（結局、データは異なる地域に格納されます。つまり、多くのソースは地理的に分散したプラットフォームで動作します）、Ralph KimballとBill Inmonによるデータウェアハウスを作成する古典的なアプローチを使用しました。
3つのストレージレイヤーが作成され、単一のBIレイヤーで補完されています
1.データ準備レイヤーは、ソースデータが保存されるSRCと、データを結合およびクリーニングするアルゴリズムを使用するステージングの2つのレベルで構成されます。 分散状態システムでは、参照情報が常に同種ではないため、これが必要です。 具体的な例：85の各地域のディレクトリは少なくとも少しですが、それらは異なります。
2.詳細データの層は、データストレージを直接提供します。 それに直接アクセスすることはできませんが、顧客にとって重要な情報が絶えず更新されるのはその中にあります。 詳細レイヤーは、情報の観点から見た組織の主題活動の全体像です。 例：擬人化会計（SPU）システムでは、すべての被保険者に関する情報が保存され、保険料管理（DIA）システムでは、保険契約者からの支払いに関するデータがあります。 さらに、被保険者が退職すると、彼のデータは連邦の年金受給者データベース（FBDP）に入力されます。 各オブジェクトのこれらすべてのデータの統合は、詳細データレイヤーで正確に実行されます。 このために、データの深刻な変更と変換、異なるシステム間の関係の構築があります。
3.データマートは、要求に応じて情報を提供します。 個々のショーケースは詳細レイヤーのさまざまな部分から取得した情報を提供できるため、これはかなり複雑なレイヤーです。 実際、さまざまなメトリックまたはデータサンプルの表示を提供するのはデータマートです。 すでにウィンドウを介して、ビジネスロジック（BI）レイヤーへの接続が作成されています。 たとえば、ユーザーが特定のインジケーターの値を確認したい場合、BIシステムのグラフィカルインターフェイスでボタンを押すと、データはすぐにストアフロントから取得されます。これは既にリクエストに対応しているためです。 今年退職した人々に関する情報が地域全体で収集された場合、事前に定義された基準に従って、地区ごと、または年金の規模ごとのウィンドウで既にプレゼンテーションが行われます。
運用上の特徴
政府部門で使用される大規模な情報システムは、データソースの変更などのトラブルにも対処する必要があります。データソースの変更は、そのような規模で時間の経過とともに必然的に発生します。 システム自体のロジック、クエリの特性、データ表現の変更は排除されません。 したがって、州構造の大規模な情報システムを作成するプロジェクトでは、変化する要件と条件に徐々に適応する必要があります。
さらに、ストレージのサイズとデータモデルの複雑さにより、さまざまな種類の情報ロードの可能性を探す必要があります。 完全かつ増分の両方でなければなりません。 たとえば、特定のモジュールの実装後、ほとんどの場合、一部のデータセグメントを完全にロードしてから、非同期モードでそれらを調整および補完する必要があります。
最後に、組織および経済システムとそのストレージの最も興味深い機能は、データの履歴性をサポートすることです。 エラーを修正したり、機能しなかった通信チャネルを再開した場合、データがさかのぼって変更される可能性があることは誰にとっても秘密ではありません。 ただし、レポートを作成するには、「特定の日付」の更新されたデータと情報の両方が必要になる場合があります。 実践が示しているように、このような機能をサポートするには、追加のストレージリソースを割り当て、トポロジの設計を調整する必要があります。 異なるバージョンを保存することに加えて、時間とデータのタイムスタンプをすべてのフィールドにバインドする必要があることを考慮してください。これは、BIシステムから要求するときにも考慮する必要があります。
並列クエリ処理
十分なパフォーマンスを実現し、複雑なトポロジの分散ストレージのさまざまな問題に対処するために、実際には、IBM Netezzaなどの非同期大規模並列マルチプロセッサMPPシステムを使用します。 この場合、膨大な量のデータが地理的に分散したクラスターのノードに配置され、各分析要求は多数のサーバーノードで並行して処理できます。 次の投稿で、MPPのアーキテクチャとその機能について説明します。