HBase と Drill - 緩い型付けの SQL がいかに NoSQL に適しているか

®© 2014 MapR Technologies 1

®

© 2014 MapR Technologies

Ted Dunning 2015 年 6 月 10 日


コンタクト先情報 Ted Dunning

MapR Technologies チーフアプリケーションアーキテクト Apache Drill、Zookeeper、Mahout のコミッタ & PMC

Apache Foundation のインキュベータ VP

Email [email protected] [email protected] Twitter @ted_dunning

今日のハッシュタグ: #BDE2015


アジェンダ •  Good とは何を意味するか? •  緩い型付けとは何を意味するか? •  実現できることの例 •  テーブル数が 1/10〜1/20 になる現実のデータベース •  新たな展望 •  質問


Good とは何を意味するか? (DB にとって) •  表現力が豊か (Expressive)

–  必要な概念を表現できる

•  効率的 (Efficient) –  十分に安いハードウェアで十分に高速


Good とは何を意味するか? (DB にとって) •  表現力が豊か (Expressive)

–  必要な概念を表現できる

•  効率的 (Efficient) –  十分に安いハードウェアで十分に高速

•  内観できる (Introspectable) –  データとスキーマを調べて容易に把握することができる


新たな視点 •  次の場合に、内観 (Introspection) はより優れているといえる

–  モデルを記述するのに最小限のデータエントリが使われる –  名前が多すぎることによる混乱がない –  参照のスコーピングが、より単純な問題に焦点を絞り込むことの助けになる –  多対1の関係が埋め込める

•  内観はリレーショナルモデルの目的ではなかった •  したがって、内観は結果としても実現されなかった


とてつもなく古い •  リレーショナル理論は古い (1970年)

–  データ構造より前 –  主流の再帰プロシージャより前 –  レキシカルスコープより前 –  論理プログラミングより前 –  現実的な関数プログラミングより前 (Church, McCarthy, Iverson, Backus

はおいといて)

•  内観を向上させるためには何か新しい更新が必要


リレーショナルと HBase スタイルの noSQL の比較リレーショナル

•  行はフィールドを含む •  フィールドは基本型を含む •  構造は固定で不変 •  構造は事前に定義される •  参照整合性（オプション）

•  複数行にまたがる表現

HBase / MapR DB •  行はフィールドを含む •  フィールドはバイト列 •  構造は柔軟 •  事前に定義された構造なし •  単一キー •  カラムファミリー •  タイムスタンプ •  バージョン


リレーショナルと構造化が施された HBase の比較リレーショナル

•  行はフィールドを含む •  フィールドは基本型を含む •  構造は固定で不変 •  構造は事前に定義される •  参照整合性（オプション）

•  複数行にまたがる表現

HBase + 構造化 •  行はフィールドを含む •  フィールドは基本型を含む

–  またはオブジェクトやリスト •  構造は柔軟で不規則 •  事前に定義された構造なし •  単一キー


データベースの「亀」モデル •  フィールド値として複合オブジェクトを許容する

–  JSON スタイルのリストおよびオブジェクト

•  ジョインによるオブジェクトへの参照を許容する –  リスト内で局所化された参照を含む

•  複数オブジェクトのリストと複数リストのオブジェクトはテーブルと同一構造、したがって …

•  テーブル内の複合データも、 •  複合データ内のテーブルも、 •  さらにはテーブルを含む複合データを含むテーブルも存在


ただし書き •  これは従来の BLOB とは違います •  そして配列の Lateral View のジョインとも違います

•  理由は表現法を説明していくにつれて明らかになります


noSQL 表現法のカタログ


オブジェクトとしてのテーブル、テーブルとしてのオブジェクト

c1 c2 c3

行志向の形式

c1 c2 c3

列志向の形式

[ { c1:v1, c2:v2, c3:v3 }, { c1:v1, c2:v2, c3:v3 }, { c1:v1, c2:v2, c3:v3 } ]

複数オブジェクトのリスト

{ c1:[v1, v2, v3], c2:[v1, v2, v3], c3:[v1, v2, v3] }

複数リストを含むオブジェクト


c1 c2 c3

c1 c2 c3

マイクロカラムナフォーマット

カラム型で格納されているテーブル全体が First-class の値になり得る

これは1対多の関係を埋め込むのに非常に有効


メモ •  もし埋め込んだテーブルが First-class であるなら、スキーマはデータ

になる

•  埋め込まれた際にもしスキーマがデータから導かれる場合、テーブルを最上位に持っていく構成は不可能

•  したがって、First-class オブジェクトの埋め込みはスキーマ情報の遅延検出が行われることを意味する


1つ目の例: 時系列データ


データとしてのカラム名 •  カラム名が事前定義されていない場合、カラム名は情報を伝えること

が可能

•  例 –  時系列のウインドウ内における時刻オフセット –  Web クローラのトップレベルドメイン –  顧客の購買プロファイルのベンダー ID

•  事前定義されたスキーマではこの表現法は不可能


時系列のリレーショナルモデル

15:51:0315:52:0715:52:11

101101101

Sample time

Time series ID

Row key

value

Data values

1.160.040.08

時系列 ID

サンプリング時刻

行キーデータの値


テーブル設計: ポイントごと

時系列 ID

タイムウインドウ開始時刻

カラム名はサンプリング時刻のタイムウインドウ内のオフセットになる



テーブル設計: ポイントごと + 副テーブルのハイブリッド

ウインドウが閉じた後、行内のデータは異なるカラムファミリ内にカラム志向の表形式の値として再記録される

時系列 ID

タイムウインドウ開始時刻


カラム名はサンプリング時刻のタイムウインドウ内のオフセットになる

圧縮された行を格納する1つのカラム


圧縮の結果

サンプルは 64 ビットの時刻, 16 ビットのサンプル値

サンプリングレートは 10kHz 本来のタイムスタンプを維持することが重要であり、それはサンプル時刻のジッタ次第タイムスタンプを保持するための容量オーバーヘッドはどれくらい?


2つ目の例: 音楽メタデータ


NoSQL 上の MusicBrainz •  アーティスト、アルバム、曲名、ラベルが主要なオブジェクト •  現実の把握:

–  制作(作曲)、レコーディング、リリース、リリースグループを追加 •  アーティストだけで 7 テーブル •  場所が 12、ラベルが 7、リリース/グループが 17、制作が 8

–  (でもレコーディングは 4 だけ!) –  合計 12 + 7 + 17 + 8 + 4 = 48 テーブル

•  しかし待て、まだある! –  注釈テーブルが 10、編集テーブルが 10、タグテーブルが 19、レーティングテーブ

ルが 5、リンクテーブルが 86、カバーアートテーブルが 5、CD タイミング情報のテーブルが 3 (計 138)

–  さらに 50 以上のテーブルはドキュメント化されていない



あと180テーブルが未表示


7種類のものを表現するための236テーブル


もっとうまくできるでしょうか?


artist

idgidnamesort_namebegin_dateend_dateendedtypegenderareabeing_areaend_areacommentlist<ipi>list<isni>list<alias>list<release_id>list<recording_id>

artist

idgidnamesort_namebegin_dateend_dateendedtypegenderareabeing_areaend_areacommentlist<ipi>list<isni>list<alias>


artist

idgidnamesort_namebegin_dateend_dateendedtypegenderareabeing_areaend_areacommentlist<ipi>list<isni>list<alias>list<release_id>list<recording_id>

Primitive values

One to many relations

Equivalent to indexes

プリミティブな値

1対多のリレーション

インデックスと同等


artist

idgidnamesort_namebegin_dateend_dateendedtypegenderareabegin_areaend_areacommentlist<ipi>list<isni>list<alias>list<release_id>list<recording_id>

{ name, begin_date, end_date }



{id, recording_id, name, list<credit>length}

recordingidgidlist<credit>namelist<track_ref>

releaseidgidrelease_group_idlist<credit>namebarcodestatuspackaginglanguagescriptlist<medium>

{id, format, name, list<track>}

release_groupidgidnamelist<credit>typelist<release_id>


27テーブルが4に減った


27テーブルが4に減った今のところは


さらなる削減 •  86 のリンクテーブルはすべてアーティスト、リリース、その他の項目

のプロパティになる •  44 のタグ、レーティング、注釈テーブルはすべてリストプロパティにな

る •  5 つのカバーアートテーブルはすべてファイル参照のリストになる

•  現在のスコア: 162 テーブルが 4 に

•  ご理解いただけたでしょうか


これは Good か? •  表現性

–  JSON データモデルは少なくとも元々のリレーショナルモデルと同等の表現力

•  ネストデータを記述するのが多くの場合、より簡単 •  難しくなることはない

•  効率性 –  埋め込みによりデータサイズが増える可能性がある。ただし局所性は向上 –  セッションにまとめることでデータサイズを大幅に削減できる –  逆参照の埋め込みは一般的なインデックスよりも効率的 –  埋め込みカラム型データは時系列データで 1000 倍の速度向上

•  内観（ご判断ください）


でもどうやってクエリを実行できる? •  SQL は使えない

–  SQL は厳密な型付け –  SQL は元々のリレーショナルモデルに強く結びついている –  SQL 生成ツールはリレーショナルモデルを要求する

•  SQL を使う必要がある –  膨大な数のツールや開発者が SQL の記述方法を理解している –  SQL はデータベースの世界の共通言語 (lingua franca)


不可能に挑戦 •  Apache Drill を利用

•  Drill は SQL 準拠 –  標準のシンタックスとセマンティクスを使用

•  Drill は SQL を拡張 –  オブジェクトおよびリストを First Class として扱う –  構造の分解、フラット化を完全サポート –  リレーショナルモデルを最大限複合データに適用可能


Drill はスケーラブルで拡張された SQL を提供


クエリの例 •  Elvis を見つける

select distinct id, name, alias from ( select id, flatten(alias.name) alias from artist where alias like 'Elvis%Presley' )


クエリの例 •  Elvis がクレジットされているアルバムを見つける

select distinct album_id, namefrom( select id album_id, name, flatten(credit) from release) albumsjoin( select distinct artist_id from ( select id artist_id, flatten(alias) from artist where name like 'Elvis%Presley’ )) artistsusing artist_id


まとめ •  リレーショナルモデルの拡張により、極めてシンプルになる

–  実際の例では、テーブル数を 1/20 以下に削減できた

•  シンプルにすることで、内観の改善につながる –  これは good

•  Apache Drill は拡張されたリレーションの問題に対して非常に高速な処理を行うことが可能

•  今すぐに試すことができる



Ted Dunning と Ellen Friedman による小冊子 •  オライリーより 2014 年および 2015 年に出版 •  Amazon およびオライリーで販売中 •  MapR の厚意により無料 e-book が入手可

http://bit.ly/ebook-real-world-hadoop

http://bit.ly/mapr-tsdb-ebook

http://bit.ly/ebook-anomaly

http://bit.ly/recommendation-ebook


Real World Hadoop Ted Dunning、Ellen Friedman 著、2015 年 3 月出版（オライリーより）

本日サイン会にて無料配布


ありがとうございました!


Q & A

@mapr maprtech

[email protected]

Engage with us!

MapR

maprtech

mapr-technologies

Data & Analytics

HBase と Drill - 緩い型付けの SQL がいかに NoSQL に適しているか