検索

【TU-3】ロジカルDWH - データとクエリーの配置は最適化できるのか?|ヤフー株式会社


【Teradata Universe Tokyo 2017イベントレポート】

オープニング・セッションに続き、ヤフー株式会社データサービス本部DWHチーム 櫻井史彦氏より「Logical DWH - データとクエリーの配置は最適化できるのか?」というタイトルで、大量のデータを格納する多数のデータ基盤を連携して活用する取り組みについての紹介があった。

櫻井氏は、DWH(データウェアハウス)エンジニア歴17年のベテランであり、そのキャリアの約半分をヤフーで培った。現在は、社内ビジネス・ユーザーが使用するアドホック分析環境を運営している。特に関心のあるTeradata製品は、QueryGrid、UnityおよびAppCenterであり、これらを今後のテラデータの中核製品であると評価している。

Logical DWHとヤフーがそれを必要とする理由

“Logical DWH”とはガートナーが定義した様々なデータ基盤をつなげて、論理的に統合されたDWHのことをいう。テラデータが提唱するUDA(Unified Data Architecture)もその1つである。ヤフーがそれを必要とする理由を理解するために、まず同社の現状を見ていこう。

同社を数字で紹介すると以下のようになる。

  • 世界のインターネット市場で18番目の売上高、6番手グループの1つ

  • 100を超えるサービスを持つ

  • 月間アクティブユーザーID数3900万

  • デイリーユニークブラウザ数9000万

  • 1日のデータ処理量 90TB

90TBのデータは圧縮されたサイズで、これらを収集することも大変だが、1次処理、2次処理を施してDWHを含む各データ基盤にロードするのもチャレンジだと言える。しかし、100を超えるサービスから発生するデータをかけ合わせて分析することではじめて顧客のプロフィールが見えるようになるため、避けては通れないチャレンジだ。

データ基盤も年々成長しており、2016年と2017年を比較しただけでも、DWHのクエリー数は2倍、Hadoopは6000ノードから7000ノードへ、RDB数は800から1000へ、NoSQLは900ノードから1500ノードへ、オブジェクト・ストレージに関しては4倍以上に増強された。さらに今年新たに、60ノードのPrestoが追加される。

Teradataも何世代にもわたって増強してきており、現在は2システムで1.7PBのシステムになり、発生するクエリー数は1日60万件となった。クエリー数は前述した通り、昨年の2倍である。

以上見てきたように、ヤフーでは顧客を知るためにデータ分析が欠かせないが、大量のデータが様々なデータ基盤に存在し、急激な勢いで増加している。そのため、Logical DWHの構築は最重要テーマなのである。

ヤフーにおけるLogical DWHの構築

櫻井氏によれば、ヤフーにおけるデータウェアハウスの課題は大きく2つある。

まず、複数データソースをどうやって接続するのかということ。

たとえば、JSONのように、RDBには向かないデータ形式が登場してきている。複雑なためSQLでは表現できず、ライブラリを使うクエリーも当たり前になってきた。データやクエリーの特性に合わせてTeradata、Hadoop、RDB、NoSQLなどのデータソースを使い分けたい。ただし、これらのデータソースから、必要に応じて自由にデータを取り出してJOINできるようにしたい。

もう1つは、データはどこにあるという質問に年々答えにくくなっていること。

分散型になればなるほど分かりにくくなるが、それをどう解決すればいいのか。社内Wikiは存在するが、更新が遅かったり、更新そのものを忘れられたりしている。

メタデータを収集しても、システムごとに存在しているので解決にならない。何とかメタデータを統合できないかというのは、大きなテーマである。

これらの課題解決への取り組みがLogical DWHの構築であり、現時点での構想は図の通りである。

2系統のTeradataシステムをつなぐのがQueryGridである。この2つに同じデータを揃えるには、それぞれにロードする方法もあるが、ヤフーではQueryGridを使ってSQLで移送している。この方法で、1日2200クエリーで235億レコード、テーブル数でいえば170テーブルのデータを同期している。Teradata同士の同期はすでに2年実施しているので、どのぐらいのデータを移送できるかまで理解している。

Prestoは、今年2017年に導入した。これは、Facebookが開発し、OSS(オープンソースソフトウェア)化したクエリー・エンジンで、テラデータも開発に参加している。Prestoを採用したのは、以下の理由からLogical DWHを支えるのに適切なエンジンと評価したからである。

  • ANSIのSQL規格のかなり新しいものに対応していること

  • 様々なデータソースにつながること

  • スクリプトではなくSQLで処理できるため、多くの技術者が使えること

  • テラデータから技術情報を得やすいこと

TeradataからPrestoへの接続はすでにテストを完了し、PrestoからTeradataへの接続は今夏にはクラスタを構築できる予定だという。

Teradataのクエリー数が倍になったこと等への対応

Logical DWHの構築は進んでいるが、その間に新たな課題が2つ発生したという。

1つは前述した、Teradataのクエリー数が昨年の倍になったことである。

2システムのうち使われているほうの平均CPU使用率が80%~90%であり、運用的には限界が近づいている。リプレースが必要だが、するにしても時間がかかるので、それまで安定運用させることが重要課題となる。

対策としては、2系統のTeradataシステムとPrestoを組み合わせて、負荷分散する。これは今から実現していく予定だという。

もう1つの大きな課題は、バックアップ時間が取れなくなっていることだ。頻繁なロードで、そもそもバックアップ時間が取れない上に、長時間のバックアップがロードをブロックするという板挟みになっていた。

そこで、Teradataからオブジェクト・ストレージにバックアップし、それをアーカイブにも兼用、Prestoからはアーカイブに対してクエリーを実行することにした。当初は、複雑なJOINでないシンプルなクエリーから始め、今後ミックスワークロード等に対応する予定だという。

ヤフーのこれからのチャレンジ

最後に櫻井氏は、Logical DWHを構築する上での今後のチャレンジについてまとめた。

第1フェーズとして、前述した2系統のTeradataシステムとPrestoを組み合わせた負荷分散を実現する。その後、第2フェーズでは、様々なデータ基盤にデータとクエリーを配分し、どこでクエリーを実行するのが最適かを探る。

次に、データを統合する方法としては、同期とフェデレーションがあるが、これらをどう使い分けて管理していくのが最適かを探っていく。

さらに、利用者の適切なデータ基盤への誘導を実現したい。これについては、検討を開始したところで、大きなチャレンジだと思っているという。

ユーザーからのニーズも多いので、HadoopとTeradataで相互にデータ移送したいとも考えている。これは、次のバージョンのQueryGridとPrestoで解決できそうだという。

Teradata Universe Tokyo 2017イベントレポート特集ページはこちら。