Hadoop から RIP & REPLACE なしで移行することは可能です — その方法は次のとおりです

HDFS から MinIO などの最新のオブジェクト ストレージへの移行を検討して当社に訪れるお客様の数に、私たちはいまだに驚いています。私たちは、今では誰もが移行を済ませていると思っていましたが、毎週、移行を決定した大手の高度な技術を持つ組織と話をしています。

こうした話し合いでは、移行後も維持したいインフラストラクチャの要素が見つかることがよくあります。HDFS エコシステムから生まれたフレームワークやソフトウェアには、多くの開発者の支持を得ており、最新のデータ スタックでも依然として活用されています。実際、HDFS エコシステムから多くの優れた成果が生まれていると私たちはよく言っています。根本的な問題は、ビッグ データ時代から生まれたツールやサービスではなく、ストレージとコンピューティングが密接に結合していることにあります。

このブログ投稿では、価値のあるツールやサービスを削除したり置き換えたりすることなく、移行を行う方法に焦点を当てます。現実には、インフラストラクチャを最新化しないと、組織に必要な AI/ML の進歩を実現することはできませんが、そのためにすべてを捨てる必要はありません。

Spark と Hive によるストレージとコンピューティングの分離

すでにいくつかの完全な移行戦略場合によっては、これが前進への道となります。ただし、HDFS 実装を最新化する別の方法を見てみましょう。

これアーキテクチャにはKubernetesの管理が含まれますアパッチスパークデータ処理には Spark と Apache Hive コンテナを使用します。Hive は YARN を使用するのに対し、Spark は MinIO とネイティブに統合されます。MinIO はステートフル コンテナでオブジェクト ストレージを処理し、このアーキテクチャではデータの分離にマルチテナント構成に依存します。

アーキテクチャの概要:

• コンピューティング ノード: Kubernetes は、コンピューティング ノード上のステートレス Apache Spark および Apache Hive コンテナーを効率的に管理し、最適なリソース使用率と動的なスケーリングを保証します。

  
  

• ストレージ層: MinIO消失訂正符号BitRot Protection により、ドライブの最大半数が失われても回復可能となり、Hadoop で必要な各データ ブロックの 3 つのコピーを維持する必要がなくなります。

  
  

• アクセス レイヤー: MinIO オブジェクト ストレージへのすべてのアクセスは S3 API を通じて統合され、保存されたデータと対話するためのシームレスなインターフェイスが提供されます。

  
  

• セキュリティ レイヤー:データ セキュリティは最も重要です。MinIO はオブジェクトごとのキーを使用してすべてのデータを暗号化し、不正アクセスに対する強力な保護を実現します。

  
  

• アイデンティティ管理: MinIO Enterprise は、WSO2、Keycloak、Okta、Ping Identity などのアイデンティティ プロバイダーと完全に統合され、アプリケーションまたはユーザーの認証を可能にします。

  
  

完全に近代化された Hadoop の代替品であり、これにより組織は、Hive、YARN、および最新のデータ スタックのほぼすべてであるオブジェクト ストレージと統合できるその他の Hadoop エコシステム データ製品を維持できます。

アクセス層における相互運用性

S3a は、Hadoop からの移行を目指すアプリケーションにとって不可欠なエンドポイントであり、Hadoop エコシステム内のさまざまなアプリケーションとの互換性を提供します。2006 年以降、S3 互換のオブジェクト ストレージ バックエンドは、Hadoop エコシステム内の多数のデータ プラットフォームにデフォルト機能としてシームレスに統合されてきました。この統合は、新興技術に S3 クライアント実装が組み込まれたことに遡ります。

すべての Hadoop 関連プラットフォームでは、 hadoop-awsモジュールとaws-java-sdk-bundleの採用が標準的な方法であり、S3 API の堅牢なサポートが保証されています。この標準化されたアプローチにより、HDFS および S3 ストレージ バックエンドからのアプリケーションのスムーズな移行が容易になります。適切なプロトコルを指定するだけで、開発者は Hadoop から最新のオブジェクト ストレージにアプリケーションを簡単に切り替えることができます。S3 のプロトコル スキームは s3a:// で示され、HDFS の場合は hdfs:// で示されます。

移行のメリット

Hadoop から最新のオブジェクト ストレージに移行するメリットについては、長々と語ることができます。この記事を読んでいる方は、Hadoop などのレガシー プラットフォームから移行しなければ、AI やその他の最新のデータ製品の進歩は実現できない可能性が高いことをすでに大体ご存知でしょう。その理由は、パフォーマンスとスケールにあります。

現代のワークロードでは、処理されるデータの量や現在要求されているタスクの複雑さに対抗するために、優れたパフォーマンスが必要であることは間違いありません。パフォーマンスが単なる虚栄心のベンチマークではなく、厳しい要件である場合、Hadoopの代替候補の分野は劇的に減少する。

移行を推進するもう1つの要素は、クラウドネイティブのスケールです。クラウドの概念が物理的な場所ではなく、運用モデルたった 1 つの .yaml ファイルから、数分でデータ スタック全体をデプロイするといったことが可能になります。実装が非常に速いため、Hadoop エンジニアなら誰でも椅子から転げ落ちるでしょう。

このコンセプトの重要な要素は、ベンダーロックインからの解放から得られる経済的メリットです。これにより、組織は特定のワークロードに対してクラス最高のオプションを選択できます。言うまでもなく、データを保護するために3つの別々のコピーを維持する必要がなくなります。これは、アクティブ-アクティブレプリケーション将来を見据えた技術に投資することは、通常、インフラ整備に携わる優秀な専門家を見つけて採用することが容易になることを意味します。人々はビジネスを前進させる仕事に就きたいと考えており、それを実現するのにこれほど適したものはほとんどありません。 データこれらの要素を組み合わせることで、より高速で低コストなだけでなく、今日および将来のデータ主導のニーズに適したデータ スタックが実現します。

はじめる

アーキテクチャの詳細に進む前に、いくつかのコンポーネントを稼働させる必要があります。Hadoop から移行するには、当然、まず Hadoop をインストールしておく必要があります。この体験をシミュレートしたい場合は、Hadoop の Hortonworks ディストリビューションをこちら からセットアップして、このチュートリアルを開始できます。

それ以外の場合は、次のインストール手順から始めることができます。

1. Ambariの設定:次に、 Ambariをインストールするは、YARN を自動的に構成することでサービスの管理を簡素化します。Ambari は、Hadoop エコシステム内のサービスを管理し、すべてをスムーズに実行するためのユーザーフレンドリーなダッシュボードを提供します。

   
   

2. Apache Sparkをインストールします。Sparkは大規模データの処理に不可欠です。 標準インストールSpark を起動して実行するための手順。

   
   

3. MinIO をインストールします。環境に応じて、2 つのインストール方法から選択できます。 クベネフィットまたはヘルムチャート。

   
   

これらの要素を正常にインストールしたら、SparkとHiveをHDFSの代わりにMinIOを使用するように構成できます。Ambari UI http://<ambari-server>:8080/に移動し、デフォルトの資格情報を使用してログインします。 username: admin, password: admin 、

Ambari で、サービス、HDFS、構成パネルの順に移動します (下のスクリーンショットを参照)。このセクションでは、HDFS ではなく MinIO で S3a を使用するように Ambari を構成します。

下にスクロールして、 Custom core-siteに移動します。ここで S3a を構成します。

 sudo pip install yq alias kv-pairify='yq ".configuration[]" | jq ".[]" | jq -r ".name + \"=\" + .value"'

ここからの構成は、インフラストラクチャによって異なります。ただし、以下は、 core-site.xmlで、12 ノードで実行される MinIO と 1.2TiB のメモリを使用して S3a を構成する方法を表しています。

 cat ${HADOOP_CONF_DIR}/core-site.xml | kv-pairify | grep "mapred" mapred.maxthreads.generate.mapoutput=2 # Num threads to write map outputs mapred.maxthreads.partition.closer=0 # Asynchronous map flushers mapreduce.fileoutputcommitter.algorithm.version=2 # Use the latest committer version mapreduce.job.reduce.slowstart.completedmaps=0.99 # 99% map, then reduce mapreduce.reduce.shuffle.input.buffer.percent=0.9 # Min % buffer in RAM mapreduce.reduce.shuffle.merge.percent=0.9 # Minimum % merges in RAM mapreduce.reduce.speculative=false # Disable speculation for reducing mapreduce.task.io.sort.factor=999 # Threshold before writing to drive mapreduce.task.sort.spill.percent=0.9 # Minimum % before spilling to drive

この移行パターンに関するドキュメントを確認することで、検討できる最適化がかなりあります。 ここまた、S3のHadoopのドキュメントにも記載されています。 ここそしてここ。

設定に満足したら、すべてを再起動します。

また、Spark2 構成パネルに移動する必要があります。

Custom spark-defaultsまでスクロールし、MinIO で構成するために次のプロパティを追加します。

 spark.hadoop.fs.s3a.access.key minio spark.hadoop.fs.s3a.secret.key minio123 spark.hadoop.fs.s3a.path.style.access true spark.hadoop.fs.s3a.block.size 512M spark.hadoop.fs.s3a.buffer.dir ${hadoop.tmp.dir}/s3a spark.hadoop.fs.s3a.committer.magic.enabled false spark.hadoop.fs.s3a.committer.name directory spark.hadoop.fs.s3a.committer.staging.abort.pending.uploads true spark.hadoop.fs.s3a.committer.staging.conflict-mode append spark.hadoop.fs.s3a.committer.staging.tmp.path /tmp/staging spark.hadoop.fs.s3a.committer.staging.unique-filenames true spark.hadoop.fs.s3a.committer.threads 2048 # number of threads writing to MinIO spark.hadoop.fs.s3a.connection.establish.timeout 5000 spark.hadoop.fs.s3a.connection.maximum 8192 # maximum number of concurrent conns spark.hadoop.fs.s3a.connection.ssl.enabled false spark.hadoop.fs.s3a.connection.timeout 200000 spark.hadoop.fs.s3a.endpoint http://minio:9000 spark.hadoop.fs.s3a.fast.upload.active.blocks 2048 # number of parallel uploads spark.hadoop.fs.s3a.fast.upload.buffer disk # use disk as the buffer for uploads spark.hadoop.fs.s3a.fast.upload true # turn on fast upload mode spark.hadoop.fs.s3a.impl org.apache.hadoop.spark.hadoop.fs.s3a.S3AFileSystem spark.hadoop.fs.s3a.max.total.tasks 2048 # maximum number of parallel tasks spark.hadoop.fs.s3a.multipart.size 512M # size of each multipart chunk spark.hadoop.fs.s3a.multipart.threshold 512M # size before using multipart uploads spark.hadoop.fs.s3a.socket.recv.buffer 65536 # read socket buffer hint spark.hadoop.fs.s3a.socket.send.buffer 65536 # write socket buffer hint spark.hadoop.fs.s3a.threads.max 2048 # maximum number of threads for S3A

設定の変更が適用されたら、すべてを再起動します。

Hive パネルに移動して構成を完了します。

Custom hive-siteまでスクロールし、次のプロパティを追加します。

 hive.blobstore.use.blobstore.as.scratchdir=true hive.exec.input.listing.max.threads=50 hive.load.dynamic.partitions.thread=25 hive.metastore.fshandler.threads=50 hive.mv.files.threads=40 mapreduce.input.fileinputformat.list-status.num-threads=50

詳細な設定情報については、 ここ構成の変更が完了したら、すべてを再起動します。

これで、統合をテストできるようになりました。

自分で探検する

このブログ記事では、既存のシステムを完全に見直すことなく Hadoop から移行するための最新のアプローチについて説明しました。Kubernetes を活用して Apache Spark と Apache Hive を管理し、ステートフル オブジェクト ストレージに MinIO を統合することで、組織は動的なスケーリングと効率的なリソース使用をサポートするバランスの取れたアーキテクチャを実現できます。このセットアップにより、データ処理環境の機能を維持するだけでなく強化し、より堅牢で将来にも対応できるようになります。

MinIO を使用すると、コモディティ ハードウェアで高いパフォーマンスを提供し、消失訂正符号 (Hadoop のデータ レプリケーションの冗長性を排除) によってコストを削減し、ベンダー ロックインや Cassandra ベースのメタデータ ストアの必要性などの制限を回避するストレージ ソリューションのメリットが得られます。これらの利点は、既存のデータ システムのコア要素を破棄せずに高度な AI/ML ワークロードを活用したいと考えている組織にとって非常に重要です。

組織の独自のニーズに合わせてこの移行戦略をどのようにカスタマイズできるかについて、より詳しい議論や具体的なガイダンスが必要な場合は、お気軽にお問い合わせください。[email protected] のメールまたはコミュニティでお問い合わせください。スラックチャネルを通じて、当社はお客様がデータ インフラストラクチャへの投資を最大限に活用できるようお手伝いします。