[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 プラットフォーム
日立ラックサーバ
日立ストレージ
超高速データベースエンジン
□自社従来比１００倍(*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 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 クラスに世界初登録した。

Contents
9
４. おわりに

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

2.2 なぜ、Hitachi Advanced Data Binder PFを選んだか?
11
なぜ、HADB PFを選んだか聞いてみました

2.2 なぜ、Hitachi Advanced Data Binder PFを選んだか?
12
なぜ、HADB PFを選んだか聞いてみました
シンプルな構成での
システム構築が可能
運用コスト・負担を低減
ベストプラクティスモデル
により導入が容易
高速なデータアクセス
高性能・高信頼なデータ基盤
がすぐに利用可能
データマートレスの実現へ

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
ｲﾝﾎﾟｰﾄデータ
'14/4/2
'14/4/3
・・・
'14/5/1
'14/5/2
チャンク1
チャンク2
チャンク3
チャンク31
チャンク32
ＰＯＳテーブル
インポートした単位で「チャンク」
というデータの塊として管理

21
ポイント１
■ インポート対象外のチャンクはSQL操作可能
□ チャンク単位で削除が可能 ⇒ 保持期間が過ぎた日付のデータを一括削除
□ チャンク単位でエクスポートが可能
'14/4/1
'14/4/2
'14/4/3
・・・
'14/5/1
'14/5/2
チャンク1
チャンク2
チャンク3
チャンク31
チャンク32
'14/5/3
チャンク33
今回インポートするデータ。
新しいチャンクを作成
これまでのデータは、
インポート中でもＳＱＬ操作可能

22
ポイント１
■ インポート対象外のチャンクはSQL操作可能
'14/4/1
'14/4/2
'14/4/3
・・・
'14/5/1
'14/5/2
チャンク1
チャンク2
チャンク3
チャンク31
チャンク32
'14/5/3
チャンク33
インポート完了後は自動的に
ＳＱＬ操作可能な状態へ

23
ポイント１
□ インポート対象外のチャンクはSQL操作可能
■ チャンク単位で削除が可能 ⇒ 保持期間が過ぎた日付のデータを一括削除
'14/4/1
'14/4/2
'14/4/3
・・・
'14/5/1
'14/5/2
チャンク1
チャンク2
チャンク3
チャンク31
チャンク32
'14/5/3
チャンク33
チャンク単位の一括削除

24
ポイント１
□ インポート対象外のチャンクはSQL操作可能
■ チャンク単位でエクスポートが可能
'14/4/1
'14/4/2
'14/4/3
・・・
'14/5/1
'14/5/2
チャンク1
チャンク2
チャンク3
チャンク31
チャンク32
'14/5/3
チャンク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
ポイント２
＜レンジインデクスの適用＞
レンジインデクスは、チャンクの値域を管理するインデクスです。
検索時、レンジインデクス列に条件があると、対象外のチャンクにはアクセス
しないため、無駄なデータアクセスを抑止できます。
'14/4/1
'14/4/2
'14/4/3
・・・
'14/5/1
'14/5/2
'14/5/3
チャンク1
チャンク2
チャンク3
チャンク31
チャンク32
チャンク33
SELECT 店舗コード, SUM(売上) FROM POSテーブル
ﾚﾝｼﾞｲﾝﾃﾞｸｽ
・・・
CREATE INDEX IDX_RNG ON POSテーブル
(日付) IN DBAREA1 INDEXTYPE RANGE
各チャンクの「日付」列の値域を管理

27
ポイント２
■ レンジインデクス列に条件があると自動的に利用します
□ B-treeインデクスと併用可能で、両方のインデクスでデータを絞り込みます
'14/4/1
'14/4/2
'14/4/3
・・・
'14/5/1
'14/5/2
'14/5/3
チャンク1
チャンク2
チャンク3
チャンク31
チャンク32
チャンク33
該当するチャンクだけを検索対象にする
・・・

28
ポイント２
□ レンジインデクス列に条件があると自動的に利用します
■ B-treeインデクスと併用可能で、両方のインデクスでデータを絞り込みます
'14/4/1
'14/4/2
'14/4/3
・・・
'14/5/1
'14/5/2
'14/5/3
チャンク1
チャンク2
チャンク3
チャンク31
チャンク32
チャンク33
該当するチャンクだけを対象に
B-Treeインデクスを使って検索
・・・

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

30
ポイント３
＜テーブルスキャンの適用＞
ビッグデータの場合、B-treeインデクスを適切に使用して、条件も絞り込める
（全体に対する比率として）場合でも、件数そのものが膨大なため、インデクス
経由のランダムI/Oよりも、テーブルスキャンが優位なケースがあります。
データ部
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
ポイント６
, MST.商品名
, count(*) as 売上数
, MST.商品名
, MST.商品名
, POS.売上額
, POS.売上数
from (select 商品コード
, sum(売価) as 売上額
from POSテーブル
group by 商品コード
) POS
例）100商品が、1日当たりの平均で1店舗各10個売れるとし、全10店舗の１カ月の商品別売上金額を求める
ジョインしてから集計(Group By)
集計してからジョイン
■ 集計処理の後でジョインするようにSQLを書き換えます

43
ポイント６
■ 集計処理の後でジョインするようにSQLを書き換えます
例）100商品が、1日当たりの平均で1店舗各10個売れるとし、全10店舗の１カ月の商品別売上金額を求める
, MST.商品名
, MST.商品名
, MST.商品名
, POS.売上額
, POS.売上数
from (select 商品コード
, sum(売価) as 売上額
from POSテーブル
group by 商品コード
) POS
先に集計して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
・記載の会社名、製品名は、それぞれの会社の商標または登録商標です。
・製品の内容・仕様は、改良のために予告なしに変更する場合があります。
・製品写真は出荷時のものと異なる場合があります。

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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

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

More from Insight Technology, Inc.

More from Insight Technology, Inc. (20)

Recently uploaded

Recently uploaded (8)