[db tech showcase Tokyo 2014] B33: 超高速データベースエンジンでのビッグデータ分析活用事例 by 株式会社日立製作所山口健一

© Hitachi, Ltd. 2014. All rights reserved.

db tech showcase 2014

株式会社日立製作所情報・通信システム社 ITプラットフォーム事業本部開発統括本部ソフトウェア開発本部 DB設計部

2014/11/13

山口健一

超高速データベースエンジンでのビッグデータ分析活用事例


はじめに

1

＜本日のテーマ＞超高速データベースを実際に分析業務に適用した際の経験から、ビッグデータではこんなこともありますよというお話しを、データベース技術者の視点で紹介いたします。


１. 超高速データベースエンジンとは

２. ビッグデータ分析への活用例：流通分析ソリューション

３. ビッグデータ適用時、こんなことがありました！

Contents

2

４. おわりに





Contents

3

４. おわりに


1.1 超高速データベースエンジンとは

4

Hitachi Advanced Data Binder プラットフォーム

Hitachi Advanced Data Binder プラットフォーム

日立ラックサーバ

日立ストレージ

超高速データベースエンジン

□自社従来比１００倍(*3)の検索性能を誇る、超高速データベースエンジン Hitachi Advanced Data Binderを搭載。 □可用性の高い日立のサーバと高速ストレージをセット化。

(*1) 世界のトップを目指した先端的研究を推進することで、産業、安全保障等の分野における我が国の中長期的な国際的競争力、底力の強化を図るとともに、研究開発成果の国民および社会への確かな還元を図ることを目的として創設された国の研究開発プログラム。 (*2) 内閣府の最先端研究開発支援プログラム「超巨大データベース時代に向けた最高速データベースエンジンの開発と当該エンジンを核とする戦略的社会サービスの実証・評価」（中心研究者：喜連川東大教授／国立情報学研究所所長）の成果を利用』。 (*3) 当社従来製品との比較。解析系データベースに関する標準的なベンチマークを元に作成した、各種のデータ解析要求の実行性能を計測。データ解析要求の種類によって高速化率には差が見られるが、データベースにおいて特定の条件を満たす一定量のデータを絞り込んで解析を行うデータ解析要求を対象とした結果。

最先端研究開発支援プログラム(*1)において、国立大学法人東京大学が推進している超高速データベースエンジンの研究開発(*2)の成果を利用して日立が製品化したリレーショナルデータベースシステム。


1.2 Hitachi Advanced Data Binderプラットフォーム

5

高速データアクセス基盤 Hitachi Advanced Data Binder プラットフォーム

超高速データベースエンジン Hitachi Advanced Data Binder

（ＲＤＢＭＳ）

日立サーバ

日立ストレージ

ＢＩツール

業務アプリケーション

センサー

稼働ログ

売上

ＳＮＳ

受発注

契約

データソース

収集

/加

工

多種データ

高速検索

価値を創造

大量データ

ＤＷＨ

Hitachi Advanced Data Binder PFはDWHの中核を支えるDBサーバです □ 大量データのローディング処理を高速化 □ 多種多様なデータ結合処理(JOIN)を高速化

ＪＤＢＣ/ＯＤＢＣ/ＣＬＩ（ＳＱＬインタフェース）


1.2 Hitachi Advanced Data Binderの高速化技術

6

サーバ、ストレージの能力を最大限に使いきるソフトウェア技術。

内閣府の最先端研究開発支援プログラム「超巨大データベース時代に向けた最高速データベースエンジンの開発と当該エンジンを核とする戦略的社会サービスの実証・評価」（中心研究者：国立大学法人東京大学喜連川教授）の成果を利用

ＤＢ検索(ＳＱＬ)処理を並列実行単位(I/O単位)に自動分割し高多重で実行。

タスク割当検索処理Ｉ/O完了待ちディスクI/O

サーバ

ストレージ

【従来方式】：順序実行方式

【新方式】：非順序型実行原理(*2)

検索処理(μs)

同期I/O処理(ms)

【従来方式でのストレージアクセストレース】

【新方式でのストレージアクセストレース】

処理時間を大幅短縮

東京大学との超高速データベースエンジンの共同研究開発成果の製品化。自社従来比約１００倍(*1)のデータ検索性能。

(*1) 当社従来製品との比較。解析系データベースに関する標準的なベンチマークを元に作成した、各種のデータ解析要求の実行性能を計測。データ解析要求の種類によって高速化率には差が見られるが、データベースにおいて特定の条件を満たす一定量のデータを絞り込んで解析を行うデータ解析要求を対象とした結果。 (*2) 喜連川東大教授／国立情報学研究所所長・合田東大特任准教授が考案した原理。

顧客情報明細履歴情報注文情報

検索処理(μs)

同期I/O処理(ms)

サーバ

ストレージ


1.3 Hitachi Advanced Data Binderの高速化技術

7

非順序実行原理では、発行したＩ/Ｏを待たずに、次々にレコード処理を行うため、並列度を高めやすい。レコード処理順序に依存しない集合演算や結合処理が得意。

＜順序実行＞＜非順序実行＞


1.4 TPC-H 100TBクラスで世界初登録

8

Hitachi Advanced Data Binderプラットフォーム、世界初の100TBクラス登録

日刊工業新聞社第５６回十大新製品賞「増田賞」受賞

産学連携による研究開発の成果を基に、「非順序型実行原理*１」に基づく処理機構をもつ純国産の超高速データベースエンジンを搭載し、非常に優れた処理性能を発揮できる革新的な製品を実現し、２０１３年１０月には、データベースシステムの業界標準ベンチマーク（性能測定基準）である「ＴＰＣ-Ｈ」の最大クラス（１００ＴＢ）に世界で初めて登録されたことなどが評価された。

TPC-H： TPC協会が定めるデータベースの業界標準ベンチマークテストのひとつ。データ規模で7つのクラス(100GB～100TB)があり、最大規模である100TBクラスに世界初登録した。

(*1) 喜連川東大教授／国立情報学研究所所長・合田東大特任准教授が考案した原理。





Contents

9

４. おわりに


2.1 ビッグデータ分析への活用例流通分析ソリューション

10

小売業のビッグデータ利活用を支援する「流通分析ソリューション」のデータ管理基盤に適用。

データウェアハウス

流通分析ソリューション

「流通分析ソリューション」は、売上や在庫数だけでなく、時間や分類といったさまざまな切り口で、POSデータの分析を容易に実現する「商品分析システム」、RFM分析やデシル分析をはじめさまざまな分析手法によって会員情報を分析し、会員への必要なアプローチ施策の決定を支援する「顧客分析システム」を提供


2.2 なぜ、Hitachi Advanced Data Binder PFを選んだか?

11

なぜ、HADB PFを選んだか聞いてみました

(*1) 喜連川東大教授／国立情報学研究所所長・合田東大特任准教授が考案した原理。 (*2) 当社従来製品との比較。解析系データベースに関する標準的なベンチマークを元に作成した、各種のデータ解析要求の実行性能を計測。データ解析要求の種類によって高速化率には差が見られるが、データベースにおいて特定の条件を満たす一定量のデータを絞り込んで解析を行うデータ解析要求を対象とした結果。


2.2 なぜ、Hitachi Advanced Data Binder PFを選んだか?

12

なぜ、HADB PFを選んだか聞いてみました

シンプルな構成でのシステム構築が可能

運用コスト・負担を低減

ベストプラクティスモデルにより導入が容易

高速なデータアクセス

高性能・高信頼なデータ基盤がすぐに利用可能

データマートレスの実現へ

(*1) 喜連川東大教授／国立情報学研究所所長・合田東大特任准教授が考案した原理。 (*2) 当社従来製品との比較。解析系データベースに関する標準的なベンチマークを元に作成した、各種のデータ解析要求の実行性能を計測。データ解析要求の種類によって高速化率には差が見られるが、データベースにおいて特定の条件を満たす一定量のデータを絞り込んで解析を行うデータ解析要求を対象とした結果。


2.3 流通分析ソリューションとは

13

流通分析ソリューションの特長


2.4 流通分析ソリューションの機能：商品分析

14

商品分析によるPDCA さまざまな売り場改善のPDCAを多彩な分析メニューで支援


2.5 流通分析ソリューションの機能：商品分析

15

流通分析ソリューション：商品分析メニュー


2.6 流通分析ソリューションの機能：顧客分析

16

顧客分析によるPDCA 「個客対応」実現のPDCAを多彩な分析メニューで支援


2.7 流通分析ソリューションの機能：顧客分析

17

流通分析ソリューション：顧客分析メニュー





Contents

18

４. おわりに


3.1 ビッグデータのデータメンテナンスってどうしよう？

19

ポイント１数十億件オーダのPOSデータ。日々のデータ追加や削除はどうしよう？

一日当たりのデータ量も膨大。どうやって運用しよう・・・



20


＜マルチチャンク表とバッググランドインポート機能の適用＞

マルチチャンク表では、バッググランドインポート１回分のデータにIDを割当てて、論理的なデータの塊（チャンク）で区別します。日次でデータを追加するような場合は、日付単位でチャンクを作成できます。

'14/4/1 ｲﾝﾎﾟｰﾄデータ



・・・



チャンク1 チャンク2 チャンク3 チャンク31 チャンク32

ＰＯＳテーブル

インポートした単位で「チャンク」というデータの塊として管理



21




■ インポート対象外のチャンクはSQL操作可能 □ チャンク単位で削除が可能 ⇒ 保持期間が過ぎた日付のデータを一括削除 □ チャンク単位でエクスポートが可能




・・・






チャンク33

今回インポートするデータ。新しいチャンクを作成

これまでのデータは、インポート中でもＳＱＬ操作可能



22




■ インポート対象外のチャンクはSQL操作可能 □ チャンク単位で削除が可能 ⇒ 保持期間が過ぎた日付のデータを一括削除 □ チャンク単位でエクスポートが可能




・・・






チャンク33

インポート完了後は自動的にＳＱＬ操作可能な状態へ



23




□ インポート対象外のチャンクはSQL操作可能 ■ チャンク単位で削除が可能 ⇒ 保持期間が過ぎた日付のデータを一括削除 □ チャンク単位でエクスポートが可能




・・・






チャンク33

チャンク単位の一括削除



24




□ インポート対象外のチャンクはSQL操作可能 □ チャンク単位で削除が可能 ⇒ 保持期間が過ぎた日付のデータを一括削除 ■ チャンク単位でエクスポートが可能




・・・






チャンク33

チャンク単位のエクスポート


3.2 無駄なデータにはアクセスしたくない！

25

ポイント２集計期間を条件にするので、日付列はインデクスに入れておきたい。でも、日付列は範囲条件になり、インデクス列の定義順序が難しい

SELECT 店舗コード, sum(売上) FROM POSテーブル WHERE 日付 BETWEEN '14/4/2' AND '14/5/1' AND 店舗コード in ('aaa', 'bbb', 'ccc') GROUP BY 店舗コード

CREATE INDEX IDX01 on POSテーブル ( 日付, 店舗コード) ・・・？？？ ( 店舗コード, 日付) ・・・？？？

B-treeインデクス定義



26


＜レンジインデクスの適用＞

レンジインデクスは、チャンクの値域を管理するインデクスです。検索時、レンジインデクス列に条件があると、対象外のチャンクにはアクセスしないため、無駄なデータアクセスを抑止できます。




・・・




チャンク1 チャンク2 チャンク3 チャンク31 チャンク32 チャンク33

SELECT 店舗コード, SUM(売上) FROM POSテーブル WHERE 日付 BETWEEN '14/4/2' AND '14/5/1' AND 店舗コード in ('aaa', 'bbb', 'ccc') GROUP BY 店舗コード


ﾚﾝｼﾞｲﾝﾃﾞｸｽﾚﾝｼﾞｲﾝﾃﾞｸｽﾚﾝｼﾞｲﾝﾃﾞｸｽ・・・ﾚﾝｼﾞｲﾝﾃﾞｸｽﾚﾝｼﾞｲﾝﾃﾞｸｽﾚﾝｼﾞｲﾝﾃﾞｸｽ

CREATE INDEX IDX_RNG ON POSテーブル (日付) IN DBAREA1 INDEXTYPE RANGE

各チャンクの「日付」列の値域を管理



27




■ レンジインデクス列に条件があると自動的に利用します □ B-treeインデクスと併用可能で、両方のインデクスでデータを絞り込みます




・・・





該当するチャンクだけを検索対象にする






28




□ レンジインデクス列に条件があると自動的に利用します ■ B-treeインデクスと併用可能で、両方のインデクスでデータを絞り込みます




・・・





該当するチャンクだけを対象に B-Treeインデクスを使って検索





3.3 B-treeインデクスを使った方がいいはず・・・？

29

ポイント３ B-Treeインデクスはちゃんと使っていて、絞り込みも期待できるはずだけどなんとなく遅い気がする・・・

インデクスはちゃんと使っているんだけどなあ？



30


＜テーブルスキャンの適用＞

ビッグデータの場合、B-treeインデクスを適切に使用して、条件も絞り込める（全体に対する比率として）場合でも、件数そのものが膨大なため、インデクス経由のランダムI/Oよりも、テーブルスキャンが優位なケースがあります。

データ部

B-treeインデクス


B-treeインデクスで絞り込み

ランダムI/O

ＳＱＬ検索

データ部


ＳＱＬ検索

＜インデクス経由の検索＞＜テーブルスキャン＞



31




■ ヒント句で明示的にテーブルスキャンすることを指定 □ セグメント単位I/Oかつテーブルスキャン専用バッファで高速アクセス □ テーブルスキャンでもレンジインデクスで対象データを絞り込み

データ部




ランダムI/O

ＳＱＬ検索

データ部


ＳＱＬ検索

ヒント句でテーブルスキャン指定



32




□ ヒント句で明示的にテーブルスキャンすることを指定 ■ セグメント単位I/O （テーブルスキャン専用バッファ利用）で高速アクセス □ テーブルスキャンでもレンジインデクスで対象データを絞り込み

データ部




ランダムI/O

ＳＱＬ検索

データ部


ＳＱＬ検索

セグメント単位I/O （専用バッファ利用）



33




□ ヒント句で明示的にテーブルスキャンすることを指定 □ セグメント単位I/O （テーブルスキャン専用バッファ利用）で高速アクセス ■ テーブルスキャンでもレンジインデクスで対象データを絞り込み

データ部




ランダムI/O

ＳＱＬ検索

データ部


ＳＱＬ検索

レンジインデクスで対象データを絞り込み


3.4 ジョイン方式によって検索性能は変わる？

34

ポイント４インデクスを適切に使ったネストジョイン方式になってるのに、なんだか遅い気がする・・・

商品マスタ

POSﾃﾞｰﾀ００１

POSﾃﾞｰﾀ００２

POSﾃﾞｰﾀ００３

POSﾃﾞｰﾀ００４

POSﾃﾞｰﾀ００５

・・・

商品００１

商品００２

商品００３

商品００４

商品００５

・・・

POSテーブル

ジョインするとなんだか遅いなあ？



35


＜ハッシュジョイン方式の適用＞

ビッグデータの場合、内側表・外側表の件数に応じて繰り返し処理回数が増えるネストジョイン方式よりも、両表を１回ずつスキャンするハッシュジョイン方式が優位となる場合があります。

内側表・外側表の件数に応じて結合回数が増加

＜ネストジョイン方式＞

商品マスタ






・・・

商品００１

商品００２

商品００３

商品００４

商品００５

・・・

POSテーブル

＜ハッシュジョイン方式＞

ハッシュテーブル

商品マスタを１回スキャンしてﾊｯｼｭﾃｰﾌﾞﾙに登録

POSﾃｰﾌﾞﾙを１回ｽｷｬﾝしてﾊｯｼｭﾃｰﾌﾞﾙで突き合わせ

商品マスタ






・・・

商品００１

商品００２

商品００３

商品００４

商品００５

・・・

POSテーブル



36


＜ハッシュジョイン方式の適用＞

ビッグデータの場合、内側表・外側表の件数に応じて繰り返し処理回数が増えるネストジョイン方式よりも、両表を１回ずつスキャンするハッシュジョイン方式が優位となる場合があります。

■ コスト情報を取得することで、コストに応じてハッシュジョインを選択 ■ コスト情報がない場合でもヒント句でハッシュジョイン化することが可能

＜ネストジョイン方式＞

商品マスタ






・・・

商品００１

商品００２

商品００３

商品００４

商品００５

・・・

POSテーブル

＜ハッシュジョイン方式＞

ハッシュテーブル

商品マスタ






・・・

商品００１

商品００２

商品００３

商品００４

商品００５

・・・

POSテーブル

内側表・外側表の件数に応じて結合回数が増加

商品マスタを１回スキャンしてﾊｯｼｭﾃｰﾌﾞﾙに登録

POSﾃｰﾌﾞﾙを１回ｽｷｬﾝしてﾊｯｼｭﾃｰﾌﾞﾙで突き合わせ


3.5 クライアントとサーバ間のデータ転送も効率よく！

37

ポイント５検索結果が多いけど、クライアント－サーバ間のデータ転送オーバヘッドは大丈夫だろうか？

検索結果が多いけど大丈夫かなあ？



38

＜Fetch処理の一括送信機能の適用＞

クライアント－サーバ間で検索結果を1件ずつやりとりしていると、検索結果が多い時のオーバヘッドが増加します。Fetch処理の一括送信機能で複数件をまとめて送受信することで、効率的に処理できます。


データベース

転送回数が増大

HADBクライアント



ＨＡＤＢサーバＵＡＰ

ＨＡ

ＤＢ

クラ

イア

ント

I/F

Fetch要求



39

＜Fetch処理の一括送信機能の適用＞

クライアント－サーバ間で検索結果を1件ずつやりとりしていると、検索結果が多い時のオーバヘッドが増加します。Fetch処理の一括送信機能で複数件をまとめて送受信することで、効率的に処理できます。

■ システムの平均的な検索量に合わせて一括送信件数を指定します（デフォルトで一括送信件数：２００件）


データベース

一括送信機能で検索結果をまとめて送信

HADBクライアント



ＨＡＤＢサーバＵＡＰ

ＨＡ

ＤＢ

クラ

イア

ント

I/F

Fetch要求


3.6 ジョインするタイミングに気をつけよう！

40

ポイント６売上集計するSQLで、名称を付加するためにマスタ表をジョインしているが、アクセス回数が多い気がする・・・

１対１ジョインのはずなのにずいぶん時間がかかるなあ？

select POS.商品コード , MST.商品名 , SUM(POS.売価) as 売上額 , COUNT(*) as 売上数 from POSテーブル POS left outer join 商品マスタ MST on POS.商品コード=MST.商品コード where 日付 between '14/9/1' and '14/9/30' group by POS.商品コード , MST.商品名;



41


＜集計処理(Group by)がある場合、ジョインするタイミングに注意＞

集計処理をする前にジョインするか、後にジョインするかでジョイン回数が大きく変わることがあります。ビッグデータでは特に顕著に現れます。



42


select POS.商品コード , MST.商品名 , SUM(POS.売価) as 売上額 , count(*) as 売上数 from POSテーブル POS left outer join 商品マスタ MST on POS.商品コード=MST.商品コード where 日付 between '14/9/1' and '14/9/30' group by POS.商品コード , MST.商品名

select POS.商品コード , MST.商品名 , POS.売上額 , POS.売上数 from (select 商品コード , sum(売価) as 売上額 , count(*) as 売上数 from POSテーブル where 日付 between '14/9/1' and '14/9/30' group by 商品コード ) POS left outer join 商品マスタ MST on POS.商品コード=MST.商品コード

例）100商品が、1日当たりの平均で1店舗各10個売れるとし、全10店舗の１カ月の商品別売上金額を求める

ジョインしてから集計(Group By)

集計してからジョイン



■ 集計処理の後でジョインするようにSQLを書き換えます



43




■ 集計処理の後でジョインするようにSQLを書き換えます

例）100商品が、1日当たりの平均で1店舗各10個売れるとし、全10店舗の１カ月の商品別売上金額を求める

select POS.商品コード , MST.商品名 , SUM(POS.売価) as 売上額 , count(*) as 売上数 from POSテーブル POS left outer join 商品マスタ MST on POS.商品コード=MST.商品コード where 日付 between '14/9/1' and '14/9/30' group by POS.商品コード , MST.商品名

select POS.商品コード , MST.商品名 , POS.売上額 , POS.売上数 from (select 商品コード , sum(売価) as 売上額 , count(*) as 売上数 from POSテーブル where 日付 between '14/9/1' and '14/9/30' group by 商品コード ) POS left outer join 商品マスタ MST on POS.商品コード=MST.商品コード

先に集計して100件(商品)の結果を求めてからジョインするので、ジョイン回数は100回。

100商品×10個/日×10店舗×30日 ⇒ 300,000 回のジョインをして名称付加してから集計。検索結果は100件(商品)。 ⇒ 同じ商品コードで何度も商品名を付加。





Contents

44

４. おわりに


4．おわりに

45

１．超高速データベースエンジンとは

Hitachi Advanced Data Binderプラットフォーム「自社従来比100倍」、「TPC-H 100TBクラス世界初登録」、「増田賞受賞」

⇒ ＰＲはすごいけど、現場で使われてる？２．ビッグデータ分析への活用例：流通分析ソリューション

日立の小売業向け「流通分析ソリューション」に採用

⇒商品分析、顧客分析のデータ基盤で使われています。３．ビッグデータ適用時、こんなことがありました！

実際に分析業務に適用した際の経験をいくつかご紹介

⇒ビッグデータを対象にすることで、気をつけないといけないことも。


株式会社日立製作所情報・通信システム社 ITプラットフォーム事業本部開発統括本部ソフトウェア開発本部 DB設計部

超高速データベースエンジンのビッグデータ分析活用事例

2014/11/13

山口健一

END

46


他社商品名、商標等の引用に関する表示

47

・記載の会社名、製品名は、それぞれの会社の商標または登録商標です。・製品の内容・仕様は、改良のために予告なしに変更する場合があります。・製品写真は出荷時のものと異なる場合があります。

Technology

[db tech showcase Tokyo 2014] B33: 超高速データベースエンジンでのビッグデータ分析活用事例 by 株式会社日立製作所 山口健一

[db tech showcase Tokyo 2014] B33: 超高速データベースエンジンでのビッグデータ分析活用事例 by 株式会社日立製作所山口健一