第22回［最終回］ まとめと本連載で解説できなかったこと | gihyo.jp
連載を終えて 本連載では、これまで21回に渡り、HadoopやSparkなどのソフトウェアを並列データ処理系と称して、前半においてはおもに当該処理系のアーキテクチャやデータ処理方法の原理を説明し、後半においては当該処理系の実装における技術的特徴を概観してきました。 前半では、いくつかの教科書や古い文献をベースに説明をしましたが、近年の発展が著しいと考えられている並列データ処理系においても、過去に深く研究された技術の組み合わせや応用である場合が多いことを感じていただけたかと思います。技術全般において言えることですが、最先端の技術を理解するには、基礎を丁寧に押さえることが最も重要だと思います。多くの参考文献を載せましたので、このような技術に興味がある方や今回を機に興味をもった方は、さらに理解を深めていっていただけると幸いです。 また、後半においては、近年の並列データ処理系が、過去の技術を基礎と
第20回 Sparkの設計と実装［1］～登場の背景とデータ処理の特徴 | gihyo.jp
はじめに 今回から2回に渡って、並列データ処理系のひとつであるSparkについて解説します。まずはじめに、Sparkの開発が始められた経緯を紹介し、次にSparkの特徴を説明します。 Sparkが登場した背景 Sparkは、Hadoop MapReduceと同様に、複数の計算機を用いてデータ処理を行う並列データ処理系です。2009年に、カリフォルニア大学バークレー校のAMPLabにて、Matei Zaharia氏を中心として開発が始まりました。Sparkの開発が始まった当時、世の中にはすでにHadoopが存在しており、高い耐障害性を有しかつスケーラブルな並列データ処理を、コモディティな計算機を用いて行うことは一般的になりつつありました。しかし、Hadoop MapReduceは必ずしも個々の計算機のメモリを効率的に活用する設計ではありませんでした。 Hadoop MapReduceは、ジョ
第19回 Impalaの設計と実装［3］ | gihyo.jp
はじめに 今回は、ImpalaにおけるI/Oの高速化技法について説明します。 前回説明したように、Impalaの実行エンジンは可能な限りメモリ上で処理をすることでアドホッククエリのレイテンシを下げ、スループットを向上させる、という設計方針で開発されています。 しかし、データはストレージ（二次記憶装置）に格納されているため、当然、ストレージへのI/Oを回避することはできません。また、Impalaは実行時に十分なメモリを確保するべく、データをメモリ上に保持（キャッシュ）しないため、クエリを実行するたびにデータをストレージから読み出すことを前提として設計されています[1]。 今回は、このようなユースケースを考慮しつつ、高速・高効率なアドホッククエリを実行するためのI/O処理方式とデータレイアウトについて解説します。 Short-Circuit Local ReadsによるI/Oの高効率化 Sh
第18回 Impalaの設計と実装［2］ | gihyo.jp
はじめに 今回は、ImpalaのSQL処理の高速化において重要な役割を占めるクエリ処理について説明します。 Impalaのクエリ処理の特徴 Impalaは、MapReduceやSparkをはじめとする既存の手続き型のデータ処理エンジンを使用せず、アドホックなSQLクエリの処理の高効率化に焦点を置いた設計と実装が特徴です。たとえば、結合方法を見てみると、MapやReduceもしくはMapReduceジョブなどのブロッキングオペレータ（第16回）を組み合わせていく処理エンジンにおいては、Impalaにおけるパイプライン結合処理などを実現することは必ずしも容易ではありません（第8回「Impala／Prestoにおける結合処理」）。 また、MapReduceやSparkでは中間データをディスクに書き込むことにより高い耐障害性を実現しますが、Impalaでは耐障害性を多少犠牲にしてメモリ上で処理
第17回 Impalaの設計と実装［1］ | gihyo.jp
はじめに 今回から3回に渡って、Hadoop上で動作するデータ処理ソフトウェアの1つであるApache Impala（incubating)（以下、Impala）について、以下の流れで説明していきます。 Impala概要（今回） クエリ実行時の並列化の仕組み（第18回） I/O処理における高速化の仕組み（第19回） Impalaの特徴のすべてをお伝えできるわけではありませんが、Impalaの速度に対する取り組みについて参考になれば幸いです。 今回は、Impalaが開発されるに至った背景や特徴、および動作の概要までを紹介していきます。 Impala開発の背景 これまでの連載内でも触れられてきましたが、ImpalaはHadoop上でSQL（正確にはHive Query Language／HiveQL）を高速に処理するために開発された並列データ処理系です。Impala以前から、SQLを実行するH
第16回 並列データ処理系 Apache Tez | gihyo.jp
はじめに 今回は、Apache Hadoop上で動作する並列データ処理系Apache Tezについて解説します。 MapReduceの制約 本連載第13回で述べたように、Hadoop MapReduceは、MapとReduceからなる単純なインタフェースを有し、多くのデータ処理を記述できる汎用的な並列データ処理系（フレームワーク）である反面、その単純さによりいくつかの性能的な課題が存在すると考えられます。 たとえば、複雑なジョブをMapReduceで実行する場合、MapとReduceからなるMapReduceジョブを複数段連ねて実行する必要があります（図1）。当該ケースにおいては、MapReduceジョブの間において、分散ファイルシステムを介したデータの入出力が行われてしまい、当該入出力は、性能の観点においてはオーバーヘッドであるため、ジョブの実行時間を長くする原因の1つとなりえます。
第15回 計算機クラスタのためのリソース管理基盤 Hadoop YARN | gihyo.jp
はじめに 前回は、MapReduceとその実装であるApache Hadoopの概要について説明しました。今回は、Apache Hadoopにおいて計算機クラスタのリソース管理を行うYARNについて解説します。 多種多様な処理系の登場 Hadoopの登場を1つの契機として、コモディティな計算機を複数台用いた計算機クラスタ上でデータ処理を行うことが広く普及しつつあります。たとえば、Hadoop MapReduceと比べてアプリケーションの記述性が柔軟であり、より高効率な実行が可能であるApache Spark、Apache Tez、Apache Flinkをはじめとし、低い遅延で実行可能なApache Impala、Facebook Presto、Apache Drill、また、大量のストリームデータを低い遅延で処理可能なデータ処理系であるApache Storm、Twitter Heron
第14回 Hadoopの設計と実装～並列データ処理フレームワークHadoop MapReduce［2］ | gihyo.jp
はじめに 今回は、Hadoopの構成要素である並列データ処理フレームワークMapReduceにおける実装アーキテクチャの特徴について解説します。加えて、類似のシステムである並列データベースを取り上げ、想定するワークロードなどの違いについて解説します。 Apache Hadoopの実装における特徴 現在、Apache Hadoopは、MapReduceの一実装であるHadoop MapReduceと、Googleの分散ファイルシステムGFSのクローンであるHadoop Distributed File System（HDFS）、そしてリソース管理を行うYet Another Resource Negotiator（YARN）から構成されます。ここでは、それぞれのコンポーネント間に存在するアーキテクチャの特徴と、各コンポーネントの実装について述べます。 これら3つのコンポーネントは、すべて
第13回 Hadoopの設計と実装～並列データ処理系Hadoop MapReduce［1］ | gihyo.jp
はじめに 第一部では、Hadoopなどの並列データ処理系の基礎である並列データベース技術や分散システム技術を解説してきました。第二部では、実際の処理系により焦点を当て、それらの設計と実装を見ていきます。 第二部では、最初の4回を用いて、Apache Hadoopの並列データ処理系であるHadoop MapReduceを始めとし、当該処理系のリソース管理を行うYARNおよび、汎用的な並列データ処理系であるTezについて解説を行う予定です。 今回は、MapReduceにおける設計方針や特徴について解説します。 MapReduceとは MapReduceは、複数の計算機上で効率的に処理を行うためのデータ処理用のプログラミングモデルと、そのプログラミングモデルが動作する処理系の実装であり、GoogleのJeff Deanらにより開発が始められました。MapReduceの代表的なランタイム処理系には
第12回 複数のプロセスにおける協調動作のための仕組み─コーディネーション | gihyo.jp
はじめに 前回は、分散システム技術を基本とする耐障害性のための仕組みとして、レプリケーションとロギングについて述べました。今回は、分散システムにおいて複数のプロセスが協調して動作するための仕組みであるコーディネーションについて、その概要を説明します。 コーディネーションとは 並列データ処理系におけるコーディネーションは、複数のプロセス間において、協調して動作をする、または、同意を取るための技術です。すなわち、コーディネーションを行うことにより、並列データ処理系における複数のプロセスが同じ目的（もしくは値）を共有し、各々がその目的のもとで何らかの処理を実行できるようになります。当該技術は、たとえば、複数のプロセスにおける状態やレプリカ間の値の一貫性を保つために用いられます。 コーディネーションにおいては、多くの場合、次のことを前提として議論されるため、特に明示的に言及しない限り、本連載におい
第11回 耐障害性のための仕組み─レプリケーションとロギング | gihyo.jp
はじめに 前回までにおいては、データ処理の並列化方法および宣言型のデータ処理系における問い合わせ最適化について説明してきました。今回と次回の2回では、並列データ処理系において用いられる分散システム技術について述べていきます。まず今回は、分散システムにおける耐障害性のための仕組みであるレプリケーションとロギングについて説明します。 レプリケーションとは 並列データ処理系におけるレプリケーションは、第3回でも軽く説明したように、データを複数の計算機に保持しておくことにより、システムの耐障害性を保つための技術です。すなわち、データの複製（レプリカ）を複数の計算機で管理することにより、並列データ処理系を構成する計算機の一部が故障した場合や当該システムを構成するネットワークに分断が発生した場合においても、当該システムが管理するデータが失われる（ように見える）可能性を低減することができます。当該技術は
第10回 データ処理の最適化 | gihyo.jp
はじめに 前回は、これまで説明してきたアルゴリズムの性能を定量的に見積り、比較しました。今回は、これらの性能見積りを用いて行うデータ処理（問い合わせ）の最適化方法について説明します。 データ処理（問い合わせ）の最適化 第4回で述べたように、HadoopのSQL処理系であるHiveをはじめとし、ImpalaやPrestoなどの宣言型言語を用いるデータ処理系においては、利用者は何を（What）処理してほしいかを処理系に指示するのみであり、どのように（How）処理をしてほしいかは指定しません。すなわち、当該処理系においては、どのように処理をするかは処理系自体が決める必要があり、与えられた問い合わせ（クエリ）を最も良いと思われる方法で処理します。このように、問い合わせにおいて最良と思われるデータ処理の方法を見つけることを「（問い合わせ）最適化」と呼びます。 最適化においては、問い合わせを実行す
第9回 データ処理における性能の見積り | gihyo.jp
はじめに 前回は、ハッシュ結合における具体的な並列化方法を説明しました。今回は、これまで説明してきたアルゴリズムの性能を定量的に見積ってみます。 データ処理性能の見積り これまで、第6回では、選択処理のアルゴリズムとしてスキャン（Scan）と索引スキャン（Index Scan）について、第7回と第8回では、結合処理のアルゴリズムとしてソートマージ結合とハッシュ結合について、それらの並列化方法を説明してきました[1]。ここでは、それらのデータ処理の性能を定量的に見積り、すなわち、当該アルゴリズムの複雑さ（計算量）や処理量を数値化し、それらを比較してみようと思います。 まずは、前提条件を整理しておきます。 RとSの2つのデータが存在 R、Sは複数の計算機に均等に分割されており、各計算機においてはN個のレコード（タプル）から構成 R、Sのそれぞれのレコードのサイズ（RecordSize）は同一
第8回 データ処理における並列アルゴリズム［3］ | gihyo.jp
はじめに 前回は、結合処理の並列化における基本戦略について説明し、ソートマージ結合における具体的な並列アルゴリズムを説明しました。今回は、ImpalaやPrestoに加えて、Apache SparkやHadoop MapReduceのMap Joinにおいても用いられているハッシュ結合における具体的な並列アルゴリズムを説明します。 ハッシュ結合における並列アルゴリズム ハッシュ結合は、2つのデータにおいて同一の属性値をもつレコードを見つける方法として、レコードのハッシュ値を用いるものです[1]。すなわち、当該方法においては、一方のデータのすべてのレコードの結合キーに対してハッシュ関数を用いてハッシュ値を計算し、当該ハッシュ値からなるハッシュ表を事前に構築しておき、他方のデータのレコードの結合キーに対して同一のハッシュ関数から得られたハッシュ値を用いてハッシュ表を参照することにより、同一の
第7回 データ処理における並列アルゴリズム［2］ | gihyo.jp
はじめに 前回は、並列システムの性能指標について紹介し、また、データ処理におけるアルゴリズムと、選択処理の並列化方法を紹介しました。今回からは、結合処理の並列化方法について説明します。まずは、結合処理における基本的な並列化方法について述べ、次に、ソートマージ結合の具体的な並列アルゴリズムを説明していきます。 結合処理の並列化方法 結合処理は、前回述べたとおり、複数のデータを、当該データを構成するレコード（タプル）における属性値を用いてある条件に基づいて連結することにより、1つのデータにする処理です。簡単のため、以降では、「ある条件」は複数のデータの属性値が同一である、とします。すなわち、結合における最も一般的な方法である等結合を対象として話を進めていきます。また、特に断りがない限り、2つのデータを結合するものとします。 等結合処理における並列化の基本的な方法は、次の2つのステップからなり
第6回 データ処理における並列アルゴリズム［1］ | gihyo.jp
はじめに 前回は、データ処理における並列性について説明しました。今回からは数回に渡って、当該データ処理における具体的な並列アルゴリズムについて説明します。まずはその準備として、並列システムの性能指標について見ていきます。 並列システムや並列アルゴリズムにおける性能指標 並列システムや並列アルゴリズムを評価する場合においては、スケーラビリティ（Scalability）という指標が用いられることがあります。スケーラビリティは、仕事量や計算資源などが増加したときの処理能力や性能特性を表すものであり、データ処理におけるスケーラビリティの指標は次の2つに分類することができます。 スピードアップ（Speed-up） スケールアップ（Scale-up） スピードアップは、あるジョブを処理する場合において、当該ジョブを処理する計算機などの計算資源を増やしたときに、当該ジョブの処理するための時間がどの程度低
第5回 データ処理の並列化 | gihyo.jp
はじめに 前回は、データ処理の方法を整理し、また、宣言型言語をインターフェースとして用いる並列データベースなどのデータ処理系を詳細に見ていく準備として、当該データ処理系における実行プランの作成の流れをかんたんに説明しました。今回は、当該データ処理系において、どのように実行プランを並列化するかについて、その概要を説明します。 データ処理における並列性について 並列データベースをはじめとするデータ処理系は、SQL文などの問い合わせ（クエリ）の内容に応じてデータ処理を行うものであり、問い合わせの観点においては、当該処理系において用いられる並列性（Parallelism）は、次の2つに分類することができます。 問い合わせ間の並列性（Inter-Query Parallelism） 問い合わせ内の並列性（Intra-Query Parallelism） 問い合わせ間の並列性は、複数の異なる問い合わせ
第4回 データ処理の方法 | gihyo.jp
はじめに 前回までは、（並列）データ処理の説明をするために必要な言葉の定義や整理をしてきました。いよいよこれからは、データ処理自体について触れていきます。今回は、アプリケーション開発者の視点から見るデータ処理にはどのようなものがあり、その観点において、Hadoopがどのようなものであるか、また、Hadoopがどのようにデータ処理を構築しているかについて、その概要を説明します。 手続き型言語によるデータ処理と宣言型言語によるデータ処理 データ処理は、データ処理を行うアプリケーション開発者（ユーザ）の視点から見ると、 手続き型言語によるデータ処理 宣言型言語によるデータ処理 の2つに大別することができます。 手続き型言語によるデータ処理は、ユーザがプログラミング言語等を用いて行うデータ処理です。たとえば、CやPerlなどを用いて行うデータ処理や、汎用機においてCOBOLなどを用いた集計処理な
第3回 並列システムと分散システム | gihyo.jp
はじめに 前回は並列データ処理系の歴史や重要性について見てきました。今回は、これまで明確に説明してこなかった「並列」という言葉やその類語を定義し、本連載の対象である並列データ処理系がどのようなものであるかをより明確にしていきます。 並列と分散 ではまず、本連載における「並列（Parallel）」という言葉をもう少し明確にしましょう。コンピュータ処理においては、一般的に、2つ以上の処理が「並列」に実行される、という場合は、当該処理が「同時」に実行されることを意味します。同様の概念に「並行（Concurrent）」がありますが、2つの処理が並行に処理されるという場合は、必ずしも、2つの処理が同時に実行される必要はありません。すなわち、一般的には、並行は並列を包含する概念であると定義されています［1］。たとえば、2つの処理を交互に実行する場合は、当該処理は並行に実行されていますが、並
第2回 並列データ処理系の歴史と重要性 | gihyo.jp
はじめに 前回は、本連載の目的や、本連載で扱う並列データ処理の定義について説明しました。今回は、並列データ処理系の歴史や重要性について見ていきます。技術を学ぶうえで、その技術の歴史や重要性について理解しておくことはとても良いことですので、かんたんな読み物を読むつもりでお付き合いください。 並列データ処理系の進展 並列データ処理系における基本的なアルゴリズムや処理方式は、並列データベースと称される並列化された[1]データベースシステムにおける技術に基づいています。 並列データベースに関する研究・開発は、1970年代からの並列データベースマシン（Parallel Database Machine）［1、2、3］と称されるデータベース処理専用の並列計算機に遡ることができます。並列データベースマシンは、データ処理用途にカスタマイズされたプロセッサや記憶装置を用いていたため、必ずしも価格に見合った
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
