Apache Kylin 4.0は、ビルドエンジンとしてSparkを使用し、ストレージとしてParquetを使用するため、クラウドでの展開とスケーリングが容易になります。ただし、ローカルディスクを使用するHDFSと比較すると、クラウドでオブジェクトストレージを使用すると、互換性とパフォーマンスの問題が発生する可能性があります。このような問題に直面した今日、JuiceFSに最適化されたソリューションをお届けします。Kylin 4.0の強力なクエリエンジンとJuiceFSの効率的なローカルキャッシュにより、互換性とパフォーマンスの面でWin-Winの状況を実現できます。詳細については、KylinとJuicedataが共同で作成したこの優れた記事をご覧ください。
Apache Kylinとは何ですか？
Apache Kylinは、超大規模データ用に設計されたオープンソースの分散分析エンジンであり、Hadoop / SparkでSQLクエリインターフェイスと多次元オンライン分析（OLAP）機能を提供します。元々はeBayによって開発され、Apache SoftwareFoundationに貢献しました。大量のデータに直面しても、Kylinは1秒未満のクエリ応答を実現できます。
【ApacheKylinアーキテクチャ図】
Kylinは、超高性能クエリエンジンとして、HiveやKafkaなどのさまざまなデータソースをダウンロードし、TableauやSupersetなどのさまざまなBIシステムに接続できます。また、さまざまなアプリケーション統合用のJDBC / ODBC / RESTAPIも提供します。オープンソース以来、KylinはMeituan、Xiaomi、58.com、Shell Search、Huawei、Autohome、Ctrip、Tongcheng、Vivo、Yahoo Japan、OLX Groupなどで広く使用されており、毎日の訪問数は数万に上ります。数千万の範囲で、ほとんどのクエリは1〜3秒以内に完了できます。
製品/ビジネス側があなたを見つけて、数十億または数千億のレコードに対して柔軟な要約クエリを実行する必要があると言った場合、応答は速く、同時実行性は高く、リソース使用量は低くなければなりません。アプリケーション開発をサポートするために、また、SQL構文を完全にサポートし、BIをシームレスに統合できるため、ApacheKylinが最適です。
Kylinの中心的なアイデアは事前計算です。これは、指定されたディメンションとインジケーターに基づいてすべての可能なクエリ結果（つまり、キューブ、多次元キューブ）を計算し、時間のスペースを使用して、固定クエリモードでOLAPクエリを高速化します。ディメンションの各組み合わせはキューボイドと呼ばれ、すべてのキューボイドのコレクションはキューブです。すべての次元で構成されるキューボイドはベースキューボイドと呼ばれ、他のキューボイドはベースキューボイドから集約できます。Kylinは、クエリを実行すると、条件を満たす最適なCuboidを自動的に選択します。ユーザーの元のテーブルから計算する場合と比較して、Cuboidからデータを取得して計算すると、スキャンされるデータと計算の量を大幅に減らすことができます。
【4次元キューブの例】
Kylinは、誕生当初からストレージエンジンとしてHBaseを選択しました。これは、基本的にクエリパフォーマンスの要件を満たしていますが、HBaseの運用と保守の複雑さ、クエリノードのシングルポイントの問題など、HBaseソリューションに基づく一連の問題点があり、HBaseは純粋な列型ストレージIOの効率ではありません。より高い。Apache Kylin v4は、Parquet + Sparkの組み合わせを採用し、コンピューティングとストレージを分離するHBaseを使用しなくなりました。これは主要なアーキテクチャのアップグレードであり、クラウドネイティブテクノロジーのトレンドにより適合しています。
クラウドでのParquetの課題に関するKylin
以前と比較して、新世代のKylin 4に基づいて、ユーザーはクラウド上に高性能で低TCOのデータ分析サービスを迅速かつ簡単に展開できます。コンピューティングとストレージの分離、およびアーキテクチャの複雑さの軽減により、Kylinはクラウドでのデータ分析に最適な選択肢の1つになっています。ただし、クラウド上のオブジェクトストレージに基づいて抽象化されたファイルシステムと従来のHDFSの大きな違いにより、データの局所性、オブジェクトストレージAPI呼び出しの頻度の制限、データ移動操作の一貫性の難しさなど、注意が必要な一連の問題が発生します。保証などは、Kylinの構築とクエリにいくつかの安定性とパフォーマンスの課題をもたらします。ネイティブHDFSの優れたパフォーマンスエクスペリエンスを軽減し、さらには達成する方法については、いくつかの成功したソリューションを見ることができます。JuiceFSはその1つです。
JuiceFSとは何ですか？
JuiceFSは、クラウドネイティブ環境向けに設計された分散ファイルシステムです。POSIXおよびHDFSと完全に互換性があり、ビッグデータ、機械学習トレーニング、Kubernetes共有ストレージ、および大規模なデータアーカイブ管理シナリオに適しています。世界中のすべてのパブリッククラウドサービスプロバイダーをサポートし、フルマネージドサービスを提供します。お客様は運用や保守に投資する必要がなく、100PBの容量まで拡張できる弾力性のあるスケーラブルなファイルシステムをすぐに利用できます。
以下のアーキテクチャ図に示されているように、JuiceFSは、Ceph、MinIO、Swiftなどのオープンソースオブジェクトストレージだけでなく、さまざまなパブリッククラウドオブジェクトストレージ製品をすでにサポートしています。FUSEクライアントはLinuxとmacOSで提供され、ネイティブクライアントはWindowsシステムでも提供されます。どちらもJuiceFSファイルシステムをシステムにマウントでき、エクスペリエンスはローカルディスクとまったく同じです。Hadoop環境でJavaSDKを提供すると、エクスペリエンスはHDFSと同じになります。JuiceFSのメタデータサービスは、すべてのパブリッククラウドにフルマネージドサービスを展開しています。顧客が自分でサービスを維持する必要はなく、学習と使用のしきい値は非常に低くなっています。
【JuiceFSアーキテクチャ図】
KylinとJuiceFSを一緒に使用する必要があるのはなぜですか？
顧客がパブリッククラウドでKylinを使用していて、オブジェクトストレージにデータを保存したい場合、次の2つの問題が発生します。
最初の問題は互換性です。KylinはデフォルトでHDFSとAmazonS3をサポートし、他のパブリッククラウドも「S3互換」オブジェクトストレージを提供します。ただし、実際のテストでは、AWSとAzureに加えて、他のパブリッククラウドオブジェクトが見つかりました。ストレージには互換性がありません。たとえば、OSSに基づいてAlibaba CloudでKylinを実行すると、Alibaba Cloud EMRとCDHに基づいた自作のクラスターであるかどうかに関係なく、キューブの構築段階で失敗します。
2番目の問題はパフォーマンスです。ユーザーの観点から、ビッグデータシナリオでHDFSからオブジェクトストレージに切り替えると、パフォーマンスの低下が感じられます。パフォーマンスの低下にはいくつかの理由があります。
1.ネットワークオーバーヘッドの増加：ストレージにHDFSを使用すると、データの局所性が特徴になります。オブジェクトストレージに切り替えた後、すべてのデータ送信がネットワークを通過するため、一定量のオーバーヘッドが増加し、パフォーマンスが低下します。
2.メタデータのパフォーマンスの低下：キューブの構築プロセス中に、多くのファイルメタデータ操作、特にリストと名前の変更があります。オブジェクトストレージでのこれら2つの操作のパフォーマンスは、HDFSと比較して非常に低く、ジョブ全体の時間が消費されます。増加すると、パフォーマンスが低下します。
3.読み取り増幅によるパフォーマンスの低下：KylinのデータがParquetファイル形式に変更された場合、データを照会するときにParquetファイル全体を読み取る必要がないことが多く、ヘッダーまたはフッターのみを読み取る必要があります。これには、適切なストレージシステムが必要です。オブジェクトストレージの欠点であるランダム読み取り機能は、読み取りの増幅を引き起こし、クエリタスク全体のI / Oを増加させ、パフォーマンスの低下を引き起こします。
JuiceFSは、ビッグデータシナリオでの互換性とパフォーマンスの問題を完全に解決できます。その方法について説明しましょう。
まず、互換性について説明します。JuiceFSのメタデータサービスはJava SDKを提供します。その機能は、HDFSのJava SDKと同等です。HDFSのすべてのファイルインターフェイスAPIのインターフェイスを実装します。動作は、HDFSをサポートしている限り、HDFSとの一貫性が保証されます。すべてのコンピューティングエンジンは、互換性の問題なしにJuiceFSを使用できます。さらに、JuiceFSは世界中のすべてのパブリッククラウドサービスをサポートし、一貫したエクスペリエンスを提供します。ユーザーは、さまざまなクラウドベンダーのオブジェクトストレージの違いを気にする必要がなくなります。
次に、パフォーマンスについて説明し、JuiceFSが上記の3つの側面によって引き起こされるパフォーマンスの低下をどのように解決するかを説明します。
1. JuiceFSを使用するコンピューティングクラスターは、ストレージとコンピューティングの分離アーキテクチャでもあります。HDFSのデータローカリティ機能も失われますが、JuiceFSはクライアントにデータキャッシュ機能を提供します。JuiceFSから読み取られたすべてのデータは、クライアントが配置されているノードに自動的にキャッシュされます（仮想マシンまたはコンテナのローカルストレージでは、次にこのデータにアクセスしたときに、ローカルストレージから直接読み取られ、ネットワークを経由しなくなります。ビッグデータのクエリと分析のシナリオでは、通常、データにホットスポットがあります。JuiceFSキャッシュのサポートにより、パフォーマンスを大幅に向上させることができます（以下のテスト結果を参照）。また、キャッシュの管理、有効期限、および一貫性について懸念する場合があります。JuiceFSには、別の記事に値する処理メカニズムの完全なセットがあり、この記事は拡張されません。
2.メタデータのパフォーマンス。JuiceFSには独自の独立したメタデータサービスがあります。リスト操作と名前変更操作はすべてJuiceFSメタデータによって応答されます。パフォーマンスはオブジェクトストレージよりも数十倍高速で、HDFSと比較して50％以上向上しています。詳細についてはJuiceFSを参照してください。テストケース。
3. JuiceFSキャッシュは、ランダム読み取りの遅延を効果的に削減し、読み取り増幅を削減できます。ParquetおよびORCデータ形式に基づくクエリ分析シナリオでは、明らかにパフォーマンス上の利点があります。
要約すると、JuiceFSは、Hadoopエコロジカル製品の完全な互換性サポートを提供しながら、HDFSと同等のパフォーマンスを得ることができます。さらに重要なことに、顧客が使用するパブリッククラウドに関係なく、JuiceFSを使用して一貫したエクスペリエンスを得ることができます。
パフォーマンスの比較
上記では、ParquetとJuiceFSでKylinを一緒に使用する利点について説明しました。パフォーマンステストの結果を見てみましょう。
前述のように、OSSに基づくキューブ構築には互換性の問題があり、キューブを正しく構築できません。ただし、JuiceFSで構築されたCubeデータをOSSにコピーしてQueryを実行することは可能であるため、TPC- H10GBデータセットに基づいてQuery1からQuery22をテストしました。JuiceFSは合計実行時間でOSSよりも高速です。それは38％です。
•JuiceFSは70,423msを使用します
•OSSは113,670msを使用します
次の表に、すべてのテストクエリの詳細なテスト環境構成と実行時間を示します。
マシン構成
CDH 5.16を使用して、AlibabaCloud上にクラスターを構築します。詳細な構成とソフトウェアバージョンは次のとおりです。
すべてのテストクエリの実行時間
総括する
Kylin 4.0では、コンピューティングとストレージに別個のアーキテクチャが導入されているため、クラウドでのKylinの展開とスケーリングが容易になります。ただし、ローカルディスクを使用するHDFSと比較すると、クラウド上のオブジェクトストレージにはドッキングの開発と互換性に問題があります。一方で、パフォーマンスは低下します。KylinでJuiceFSを使用すると、すべてのパブリッククラウドに特別な適応を行うことなく、EMRまたは自己構築Hadoopクラスターでのビッグデータ計算にクラウドストレージサービスを使用できます。JuiceFSを使用すると、クラスターはストレージとコンピューティングの分離アーキテクチャを実現しながら、効率的なローカルキャッシングを通じて各ネットワークIOのコストを削減できます。Parquet形式ベースのクエリ分析シナリオでは、ランダム読み取りの遅延を効果的に削減し、読み取り増幅を削減できます。 、HDFSに近いパフォーマンスを得る。テストシナリオでは、JuiceFSを使用すると、オブジェクトストレージを直接使用する場合と比較してパフォーマンスが38％向上します。
パブリッククラウドでKylinを使用してデータ分析要件を完了し、オブジェクトストレージを使用したストレージにJuiceFSを使用する場合は、互換性とパフォーマンスの面でWin-Winの状況を実現できます。