著者について：モバイルクラウドデータベースであるApacheHBaseの開発者であるChenHaifengは、Apache HBase、RBF、およびApacheSparkに強い関心を持っています。
バックグラウンド
Apache HBaseは、ApacheHadoopエコシステムにおける大規模でスケーラブルな分散データストレージサービスです。また、NoSQLデータベースでもあります。これは、数百万の列を含む数十億のレコード行に対して、ランダムで一貫性の高いリアルタイムクエリを提供するように設計されています。デフォルトでは、HBaseデータはHDFSに保存され、HBaseは安定性とパフォーマンスを確保するためにHDFSに対して多くの最適化を行っています。ただし、HDFS自体の保守は決して容易ではなく、継続的な監視、運用保守、調整、容量拡張、ディザスタリカバリなどが必要であり、パブリッククラウド上にHDFSを構築するコストも非常に高くなります。コストを節約し、メンテナンスコストを削減するために、一部のユーザーはS3（または他のオブジェクトストレージ）を使用してHBaseデータを保存します。S3を使用すると、運用と保守の監視の手間が省け、ストレージとコンピューティングの分離が実現し、HBaseの拡張と縮小が容易になります。
ただし、オブジェクトストレージへのHBaseデータアクセスは簡単な作業ではありません。オブジェクトストレージは、それ自体の特性により機能とパフォーマンスが制限されます。データがオブジェクトストレージに書き込まれると、データオブジェクトを変更することはできません。一方、ファイルシステムのセマンティクスを使用してブロックストレージにアクセスすることには、当然の制限があります。HadoopのネイティブAWSクライアントを使用してオブジェクトストレージにアクセスする場合、ディレクトリの名前変更操作は、ファイルをコピーおよび削除するためにディレクトリ全体をトラバースし、パフォーマンスは非常に低くなります。さらに、名前変更操作は原子性の問題も引き起こします。つまり、元の名前変更操作はコピーと削除の2つの操作に分解され、極端な場合にはユーザーデータビューの不整合が発生しやすくなります。同様に、ディレクトリ内のすべてのファイルの合計サイズのクエリもあります。原則は、トラバーサルの反復を通じてディレクトリのすべてのファイル情報を順番に取得することです。ディレクトリに多数のサブディレクトリとファイルがある場合、ディレクトリ内のすべてのファイルの合計サイズのクエリはより複雑になり、パフォーマンスが低下します。
スキームの選択
多くのソリューション調査とコミュニティの問題追跡を経て、現在、クラウドHBaseデータアクセスオブジェクトストレージには3つのソリューションがあります。
1つ目は、HBaseがHadoopネイティブAWSクライアントを使用してオブジェクトストレージ、つまりS3AFileSystemにアクセスすることです。HBaseカーネルコードは、S3AFileSystemを使用するためにわずかな変更のみが必要です。このHBaseダイレクトドッキングオブジェクトストレージソリューションで解決する必要がある問題点は、ディレクトリの名前を変更することです。HBaseには、Hlogファイル管理、MemStoreフラッシュ、テーブル作成、リージョンの圧縮、およびリージョンの分割におけるディレクトリの名前変更が含まれます。コミュニティは、名前変更のパフォーマンスの問題のいくつかを解決するためにStoreFIleを最適化しました。ディレクトリ操作のパフォーマンスの問題を完全に解決するには、HBaseカーネルのソースコードを大幅に変更する必要があります。
2番目の解決策は、キャッシュアクセラレーションとしてAlluxioを導入することです。これにより、読み取りと書き込みのパフォーマンスが大幅に向上するだけでなく、ファイルメタデータ管理も導入され、ディレクトリ操作のパフォーマンス低下の問題が完全に解決されます。一見ハッピーエンドには、その背後に多くの制約があります。Alluxioがメモリのみを使用するように構成されている場合、ディレクトリ操作にかかる時間はミリ秒です。AlluxioのUFSが構成されている場合、Alluxioでのメタデータ操作には2つのステップがあります。最初のステップはAlluxioマスターの状態を変更することであり、2番目のステップはUFSに要求を送信することです。ご覧のとおり、メタデータ操作はまだアトミックではなく、操作の実行中または障害が発生したときの状態は予測できません。Alluxioは、ファイルの名前変更などのメタデータ操作をUFSに依存しており、これがコピーおよび削除操作になります。HBaseのデータはディスクに配置する必要があり、Alluxioはディレクトリ操作のパフォーマンスの問題を解決できません。
3番目のオプションは、HBaseとオブジェクトストレージの間にJuiceFS共有ファイルシステムを導入することです。JuiceFSを使用してデータを保存すると、データ自体がオブジェクトストレージ（モバイルクラウドEOSなど）に永続化され、対応するメタデータを必要に応じてRedis、MySQL、およびその他のデータベースに永続化できます。このソリューションでは、ディレクトリ操作はメタデータエンジンでオブジェクトストレージとの対話なしに完了し、操作時間はミリ秒レベルであるため、オブジェクトストレージへのHBaseデータアクセスの問題点を解決できます。ただし、JuiceFSカーネルはGo言語で記述されているため、後のパフォーマンス調整と定期的なメンテナンスに特定の課題が生じます。
上記の3つのソリューションの長所と短所を比較検討した後、JuiceFSは、オブジェクトストレージをサポートするクラウドHBaseのソリューションとして最終的に採用されました。以下は、クラウドHBaseでサポートされているオブジェクトストレージでのJuiceFSの実践とパフォーマンスの調整に焦点を当てています。
はじめに
まず、JuiceFSのアーキテクチャを紹介しましょう。JuiceFSは、JuiceFSメタデータサービスとオブジェクトストレージの2つの主要部分で構成されています。JuiceFS JavaSDKはHDFSAPIと完全に互換性があり、FUSEベースのクライアントマウントも提供し、POSIXと完全に互換性があります。ファイルシステムとして、JuiceFSはデータとそれに対応するメタデータを個別に処理し、データはオブジェクトストレージに保存され、メタデータはメタデータエンジンに保存されます。データストレージに関しては、JuiceFSは、ほぼすべてのパブリッククラウドオブジェクトストレージに加えて、OpenStack Swift、Ceph、MinIO、およびプライベートデプロイメントをサポートするその他のオープンソースオブジェクトストレージをサポートします。メタデータストレージに関しては、JuiceFSはマルチエンジン設計を採用しており、現在、メタデータサービスエンジンとしてRedis、TiKV、MySQL / MariaDB、PostgreSQL、SQLiteなどをサポートしています。
JuiceFSに保存されているファイルはすべて、固定サイズの「チャンク」に分割され、デフォルトのサイズ上限は64MiBです。各チャンクは1つ以上の「スライス」で構成されており、ファイルの書き込み方法によっては、スライスの長さは固定されていません。各スライスはさらに固定サイズの「ブロック」に分割され、デフォルトは4MiBです。最後に、これらのブロックはオブジェクトストアに保存されます。同時に、JuiceFSは、各ファイルとそのチャンク、スライス、ブロック、およびその他のメタデータ情報をメタデータエンジンに保存します。
JuiceFSを使用すると、ファイルは最終的にチャンク、スライス、ブロックに分割され、オブジェクトストレージに保存されます。したがって、JuiceFSに格納されているソースファイルはオブジェクトストレージプラットフォームで見つけることができず、バケットにはチャンクディレクトリと数値番号が付けられたディレクトリとファイルの束しかありません。
HBaseコンポーネントがJuiceFSを使用するには、次の構成が必要です。まず、コンパイルされたクライアントSDKをHBaseクラスパスに配置します。次に、次の表に示すように、JuiceFS関連の構成を構成ファイルcore-site.xmlに書き込みます。最後に、juicefsクライアントを使用してファイルシステムをフォーマットします。
| 構成項目 | デフォルト | 説明 |
|---|---|---|
| fs.jfs.impl | io.juicefs.JuiceFileSystem | 使用するストレージ実装を指定します。デフォルトはjfs：//です。 |
| fs.AbstractFileSystem.jfs.impl | io.juicefs.JuiceFS | |
| Juicefs.meta | 事前に作成されたJuiceFSファイルシステムのメタデータエンジンアドレスを指定します。 |
メタデータストレージに関しては、MySQLがメタデータストレージとして使用されます。formatfilesystemコマンドは次のとおりです。ファイルシステムをフォーマットするには、次の情報が必要であることがわかります。
--storage：モバイルクラウドEOSなどのストレージタイプを設定します。--bucket：オブジェクトストレージのエンドポイントアドレスを設定します。--access-key：オブジェクトストレージAPIアクセスキーアクセスキーIDを設定します。--secret-key：ObjectStorageAPIアクセスキーシークレットを設定します。
juicefs format --storage eos \
--bucket https://myjfs.eos-wuxi-1.cmecloud.cn \
--access-key ABCDEFGHIJKLMNopqXYZ \
--secret-key ZYXwvutsrqpoNMLkJiHgfeDCBA \
mysql://username:password@(ip:port)/database NAME
スキームの検証と最適化
Juicefsの使用方法を紹介した後、テストを開始します。テスト環境では、48コアと187Gメモリを備えたサーバーが選択されました。HBaseクラスターには、1つのHMaster、1つのRegionServer、および3つの動物園の飼育係がいます。マスタースレーブレプリケーションを備えた3ノードのMySQLは、メタデータエンジンで使用されます。オブジェクトストレージはモバイルクラウドオブジェクトストレージEOSを使用し、ネットワーク戦略はパブリックネットワークを採用しています。Juicefsは、チャンクサイズを64Mに、物理ストレージブロックサイズを4Mに、キャッシュなしで、MEM用に300Mに構成します。2セットのHBaseクラスターを構築しました。1つはモバイルクラウドオブジェクトストレージに直接配置されたHBaseで、もう1つはHBaseとモバイルクラウドオブジェクトストレージの間にJuicefsを導入したものです。シーケンシャル書き込みとランダム読み取りはHBaseクラスターの2つの主要業績評価指標であり、PEテストツールを使用してこれら2つの業績評価指標をテストします。テストの読み取りと書き込みのパフォーマンスを次の表に示します。
クラスター環境
| クラスター環境HBase-juicefs-EOS（行/秒） | クラスター環境HBase-EOS（行/秒） | |
|---|---|---|
| 順番に書く | 79465 | 33343 |
| ランダム読み取り | 6698 | 6476 |
テスト結果によると、Juicefsソリューションを使用すると、クラスターのシーケンシャル書き込みパフォーマンスは大幅に向上しますが、ランダム読み取りパフォーマンスは向上しません。その理由は、クライアントのメモリバッファに書き込むことで書き込み要求を返すことができるため、一般的に、JuiceFSの書き込みレイテンシは非常に短い（数十マイクロ秒）ためです。JuiceFSは、読み取り要求を処理するときに、通常、4Mブロックアライメント方式に従ってオブジェクトストレージを読み取り、特定の先読み機能を実現します。同時に、読み取られたデータは、後で使用するためにローカルキャッシュディレクトリに書き込まれます。シーケンシャル読み取りでは、事前に取得したデータに後続のリクエストでアクセスし、キャッシュヒット率が非常に高いため、オブジェクトストレージの読み取り性能も十分に活用できます。ただし、ランダム読み取り中、JuiceFSのプリキャッシング効率は高くありませんが、読み取りの増幅とローカルキャッシュの頻繁な書き込みおよび削除により、システムリソースの実際の使用率は低下します。
ランダム読み取りのパフォーマンスを向上させるために、2つの方向を考慮することができます。1つは、必要なデータをほぼ完全にキャッシュする効果を実現するために、キャッシュの全体的な容量を可能な限り増やすことです。大量のデータを使用するシナリオでは、この最適化の方向性は実現できません。もう1つの方向は、JuiceFSカーネルを深く育成し、データを読み取るロジックを最適化することです。
現在、私たちが行った最適化には次のものが含まれます。1）データ読み取りロジックを簡素化するために先読みメカニズムとキャッシュ機能をオフにします。2）ブロックデータ全体をできるだけキャッシュしないようにし、RangeHTTPリクエストデータをさらに使用します。 3）ブロックサイズを小さく設定します; 4）オブジェクトストレージの読み取りパフォーマンスを可能な限り向上させます。R＆D環境でテストした後、ランダム読み取りのパフォーマンスは、最適化後に約70％向上します。
以前のテスト作業と組み合わせて、基盤となるデータストレージシステムとしてオブジェクトストレージを使用した後、クラウドHBaseは、HDFSに保存されたデータと同じ読み取りおよび書き込みパフォーマンスを実現しますが、ユーザーはHDFSに保存されたデータの半分未満しか使用しません。オブジェクトストレージは、ケーキと足の両方を備えた研究開発手法です。
それが役に立ったら、私たちのプロジェクトJuicedata / JuiceFSに従ってください！（0ᴗ0✿）