ビッグデータってデータウェアハウスじゃダメですか ?

Transcription

1 ビッグデータ時代に ますます重要性を増す DBMS 2013 年 5 月 24 日翔泳社 DB オンラインチーフキュレーターブレインハーツ株式会社谷川耕一

2 自己紹介 SI 会社でエンジニア 担当は AI エキスパートシステムなど 出版社アスキーで月刊誌 UNIX MAGAZINE の編集担当 日本オラクルでマーケティング担当 データウェアハウス関連製品 エンタープライズ系 Oracle Database 製品 広報 マーケティング コミュニケーション 現在はブレインハーツ株式会社というソフトハウスに所属 オープン系システムの開発会社 最近はクラウド モバイル NFC などに関連する開発に注力中 ebookpro という屋号で 電子書籍関係のビジネスも 上記会社の業務とは別に フリーランス ジャーナリストの立場で取材 記事執筆などに従事 翔泳社 DB Online チーフ キュレーター

3 翔泳社 EnterpriseZine DB Online 全体ページビュー : 約 110,000PV/ 月間 (2013 年 2 月現在 ) データベースに特化した情報サイトであり 企業 IT 向け Web サイト EnterpriseZine のコアとなるチャンネルの 1 つ

4 1990 年代前半の データベースの世界 世の中のオープンシステム化が進み UNIX プラットフォーム上でリレーショナル データベースを利用するように 1990 年代初頭には ビル インモン氏が データウェアハウス という言葉を自身の著書 Building the Data Warehouse で初めて使用 データウェアハウス BI などの言葉が 日本のおいても業界のキーワードに

5 1990 年ころのデータベース Oracle/Informix/Sybase/Ingres Teradata/ タンデムコンピュータズ NonStop Himalaya/Red Brick Warehouse DB2 SQL Server PostgreSQL/MySQL HiRDB/Symfoware

6 ビッグデータ時代の リレーショナル データベース Oracle Microsoft SQL Server DB2 Teradata PostgreSQL/MySQL/MariaDB EMC Greenplum HP Vertica Analytics System/Vectorwise/InfiniDB SAP HANA

7 ビッグデータ時代の NoSQL データベース Apache Hadoop/HBase Apache Cassandra Amazon DynamoDB Google Big Table MongoDB/CouchDB( ドキュメント指向 ) Neo4j/InfiniteGraph( グラフ ) Okuyama/Kyoto Cabinet/HIBARI( 国産 ) Oracle Coherence

8 ビッグデータとは? 総務省の 情報通信白書 24 年版 には ビッグデータとは何か ビッグデータを 事業に役立つ知見を導出するためのデータ とし ビッグデータビジネスについて ビッグデータを用いて社会 経済の問題解決や 業務の付加価値向上を行う あるいは支援する事業 と目的的に定義している例がある ビッグデータは どの程度のデータ規模かという量的側面だけでなく どのようなデータから構成されるか あるいはそのデータがどのように利用されるかという質的側面において 従来のシステムとは違いがあると考えられる 引用部分は 鈴木良介著 ビッグデータビジネスの時代 ( 平成 23 年 11 月 )p.14 からの引用

9 DB Online 的 ビッグデータ活用の定義 これまでより量や種類を増やしたデータを収集 分析 活用し なんらか新たな知見を得て ビジネスプロセスなりを効率化すること データの絶対量はあまり関係なく 頻度を倍に増やす あるいは 1 桁以上データ量増やしたり データの種類を増やしたりするのもビッグデータ 得られたビッグデータに対し 統計処理など高度な分析を行うこともあるが 単純な繰り返し処理を莫大なデータに対して行うようなものもある 大量データのバッチ処理の高速化も 場合によってはビッグデータ活用になりうる 鍵は 結果をビジネスプロセスの効率化などに反映し ビジネスに新たな価値を生み出せるかどうか

10 ところで Hadoop= ビッグデータ? Hadoop は 独自のファイルシステム HDFS と並列処理フレームワークの Map/Reduce を組み合わせた NoSQL ハッシュ関数を用いてノード分散し 並列処理で処理を高速化するのが基本的な考え方 これは データウェアハウスなどに長らく関わってきた技術者にとっては 特別新しいものとは感じられない (by 東京大学喜連川教授 )

11 Hadoop のすごいところ 数千といった 極めて数多くの分散ノードで超並列処理ができ それによりペタバイトクラスの大量データも高速に処理できる ポイントは この数千にも及ぶ数多くの分散ノードの存在 これを実際のハードウェアで実装し 運用できるのがすごい!

12 Hadoop のだめなところ トランザクション処理には向かない プログラミングが特殊でSQLより難しい HDFSのファイルシステムにデータを持っていくのにリソースコストがかかる 効果を発揮するような 数千ノードの運用とか恐ろしすぎる

13 NoSQL でやるのか RDBMS でもできるのか そもそも そのビッグデータは本当に RDBMS に入りきらないものなのかを検証すべし そのデータを蓄積するのに RDBMS ではうまくいかないのは本当か? そのビッグデータは 本当に全部必要なのか? 結局は NoSQL での処理結果を RDBMS のデータと付き合わせなければならない Hadoop なりを否定しないが 使い慣れた RDBMS でも 自分たちのやりたいビッグデータ活用はできるかもしれない

14 ビッグデータの登場で 再び主役になる RDBMS RDBMS はもはやインフラとなり 裏方としてひっそりと安定して動いてくれていればいいという存在になっていた それが ビッグデータの登場で大容量への対応が求められるように ビッグデータの登場でさらなる高速性能が求められるように Hadoop なりを活要しようとすれば 既存の RDBMS との連携 融合は必ず必要に 結局はデータを構造化しないと 高度な分析処理は難しい

15 NewSQL って何だ? NoSQL と RDBS を両立するデータベース この言葉自体はまだ一般的ではないが NoSQL 側からも RDBMS 側からも両者の融合 統合 連携の方向性は進んでいる MySQL のテーブルに memcached protocol でアクセスできる Memcached Plugin Oracle SQL Connector for Hadoop Distributed File System Hadoop デストリビュータである Cloudera の SQL-on- Hadoop を実現する Impala

16 ビッグデータ時代のテクノロジートピック インメモリーデータベース SAP HANA の登場で一気に注目を浴びることに 既存の RDBMS にメモリーを大量に搭載するのとは異なり インメモリだけで高速に処理できる専用のアーキテクチャ チューニングなしにとにかく速い データの永続性やシステムとしての可用性 信頼性には不安もある メモリーは安くなったといえ まだまだ大規模になればかなり高額な構成に まだまだ実績が乏しいので 保守的なユーザーは様子見

17 ビッグデータ時代のテクノロジートピック アプライアンスの利点 Oracle Exadata の登場が注目を集めるきっかけに Oracle ではアプライアンスではなく エンジニアードシステム と呼ぶ とにかく 購入すればすぐに利用できる ベンダーの手により最適構成済みなので あまり手を入れずとも性能を十分に引き出せる ハードウェアもソフトウェアも 1 つのベンダーによるワンストップ サポートを受けられる

18 ビッグデータ時代のテクノロジートピック 時代遅れのハードウェアでは? ハードウェアとソフトウェアが密に連携 融合していると 最新のハードウェアが選択できない ちょうどいいサイジングのアプライアンスがない 拡張性が心配 アプライアンスの懸念点 アプライアンスの中に自由にソフトウェアをインストールできない 何かソフトウェアを追加で入れるとサポート対象外に バージョンアップ時には 丸ごと交換?

19 ちなみに MySQL ベースの Database Appliance の可能性は? Oracle Corp のアンディ メンデルソン氏曰く 現状では そういうことは考えていない 顧客からの強い要望あれば検討するかもしれない とのこと なぜ Oracle は MySQL のアプライアンスを出さないのか? MySQL は アプライアンスが必要ないくらいシンプルで使いやすいデータベース 現状の Oracle Database Appliance のユーザーは おもに高可用性などの価値を求めていて MySQL のターゲットとは少し異なる

20 ビッグデータ時代のテクノロジートピック SSD/ フラッシュストレージ SSD やフラッシュストレージの価格が下落 手を出しやすい値頃感に 導入するだけで 数倍から数十倍のパフォーマンス改善も オールフラッシュのアプライアンスも登場 今後さらに値段は下がり 確実に SSD やフラッシュストレージ HDD を適材適所で組み合わせて利用するようになる ちなみに SSD と PCIe に直接接続するフラッシュストレージでは その構造 性能 信頼性にも違いがあることを データベースエンジニアも知っておくべき

21 ビッグデータ時代のテクノロジートピック ストリームデータ処理 ビッグデータ 溜めたら負け 溜めるのにも膨大なコストと手間が 大量データを高速に処理するのには 膨大なコンピュータリソースが必要に 溜めてから分析するとなると 結果が出るまで時間がかかる データが発生するそばからリアルタイムに処理する 発生したデータが流れている状態で処理するというのが これからは注目を集めることに

22 ビッグデータ時代に 考慮すべきポイントは ビッグデータ活用とビッグデータ テクノロジーの活用は 区別して考えるべし ビッグデータの活用は 分析し得られた知見を活用することで ビジネスにどのようなメリットをもたらすのかというところから始めるべき ビッグデータ テクノロジーの活用は 現状の課題 これからの課題に対し 新しいテクノロジーを適宜選択し 解決していくにはどうすればいいかを考える

23 ビッグデータはサーバー ストレージ DB ベンダーが見つけたおいしいビジネス領域 当然だけれど ビッグデータを格納するためのストレージがたくさん売れる 分散処理が必要だからサーバーがたくさん必要 高度で複雑な分析では CPU リソースもメモリも大量に消費 データサイエンティストという特別なスキルを持った職種も出現 新たな領域なので高くても買ってもらえるかも いまのビッグデータブームは こういうベンダーの思惑の上にできあがっていることを認識すべし ベンダーの宣伝文句に あまり踊らされないようにする

24 小さく始めて大きく育てる ビッグデータ Hadoop で多ノード運用は大変そうだし ビッグデータ活用とはいえ いきなり Oracle Exadata は買えないよね ビッグデータ活用で どういうビジネス効果があるのか分からない段階で大きな投資はできない 小さくてもそれなりにパフォーマンスの得られるソリューションを選択し 試してみるというアプローチ まずは OSS 系など素早く展開できるデータベースを導入する クラウドサービスの利用も検討してみる これからのデータベース選択は そもそも自分たちの目的が何かをはっきりさせること そして将来を見据えた拡張性が確保できるか 移行が容易かを十分に配慮すること 手許にある データベースを今一度見直してみる時かもしれない