Hatena::ブログ(Diary)

ablog このページをアンテナに追加 RSSフィード Twitter

2018-09-19

db tech showcase 2018 Day 1

年に一度のデータベース界の同窓会的なイベント db tech showcase 2018 Day 1 に参加してきた。写真は懇親会でのマグロ解体ショー。

f:id:yohei-a:20180920032213j:image:w640

小幡さん、おつかれさまでした!

f:id:yohei-a:20180920042610j:image:w640


以下は聴講したセッションのメモ。

顧客理解のためのDWHにおける、ビッグデータ品質マネジメント

概要
  • 講師: 木村 豊さん(楽天株式会社 - グローバルデータ統括部データサイエンス部)
  • 講師略歴: 大手電機メーカーにてソフトウェア開発者からデータサイエンティストに転身。データ関連ビジネスの立ち上げ等に関わった後楽天にてCustomerDNAの開発に従事
  • 概要: 楽天で構築中のDWH、CustomerDNAの概要解説と、そこで実施しているデータ品質マネジメントの実例についてご紹介します。(資料非公開)
サマリ
  • DWHでどのようにデータ品質をチェックしているかというお話。
  • データ処理の部分だけでなく、データソースもきちんとテストする必要がある。
  • プロセス(データ処理部分)のテスト観点
    • 正確性: 仕様通りマッピング・変換されているか
    • 非重複性: ユニークになるべきデータの組み合わせがユニークになっているか
    • 完全性: 投入されるべきデーアが全て投入されているか
    • 一貫性: テーブル・パーティション同士の関連性が一貫しているか
  • 課題
質疑応答
  • ETLツールでも同じようなことができるのではないか?
  • RDBの制約などの機能でチェックできるのではないか?
    • データサイズが大きいのでRDBではしんどい。
  • 何に時間が一番がかかるか?
    • データを知るのに時間がかかる。どこに何のデータがあるか。
  • データディクショナリを作っているか
    • 作っているが、変更が入るので最新には追いつかない。

Pgpool-IIではじめるPostgreSQLクラスタ運用

f:id:yohei-a:20180920042400j:image:w640

概要
スライド
  • To be uploaded
メモ
  • P.9 の絵は複数のサーバプロセスがあるが簡略化した絵になっている
  • P.11 一時テーブル、強いロックなどはスタンバイで使えない。
  • 2010年に PostgreSQL 9.0 でトランザクションログの非同期レプリケーションが実装され、その後同期レプリケーションが実装され、現在、マルチマスタレプリケーションやシャーディングが開発されている。
  • 参照だけスタンバイに接続する場合、アプリ側で振り分けを実装したり、参照でも一貫性を求めるものはマスターを見るなど考慮点が多いが、Pgpool-II はアプリに意識させなくてもよろしくやってくれる質実剛健な機能が豊富に揃っていると感じた。
  • 紹介されていた Pgpool-II とレプリケーションによる構成は「レプリケーション」というと Oracle では Data Guard と比較しそうになるが、災害対策ではなく同一サイトでの耐障害性対策としての機能が多く、Oracle でいうと RAC と比較するのが適切なケースもあると感じた*1。優劣の比較ではなく各機能がどんな課題を解決するためにあり、Oracle ではどの機能がソリューションになるかという意味での比較。

爆速データレイクがほしい人向けImpalaパフォーマンスチューニング

f:id:yohei-a:20180920042139j:image:w640

概要
スライド

Impala のパフォーマンス・チューニングI/Oノード通信を減らすのが肝で、Hive や Spark でも通用する話。小手先のクエリチューニングではなくデータ構造が命。PROFILE で時間ベースで分析しよう。といった内容で本質的で非常に分かりやすかった。Parquet の説明は今まで見た中で一番分かりやすかった。Impala は統計情報をベースにコストベースオプティマイザで動作しているとのこと、統計情報は Hive カタログに保存されているのだろうと思う。


分散DB Apache Kuduのアーキテクチャ - DBの性能と一貫性を両立させる仕組み「HybridTime」とは

f:id:yohei-a:20180920042256j:image:w640

概要
  • 講師:佐藤 貴彦さん(Cloudera 株式会社 - セールスエンジニア
  • 講師略歴: 奈良先端技術大学院大学ネットワークの研究をし、インフラなど低レイヤーの技術が好きになる。卒業後はOracleで、データベースを中心にインフラ全般のコンサルティングなどを行う。その後、Basho TechnologyでNoSQL及び分散システムに触れ、現在はClouderaでHadoop関連技術を中心に、幅広く手がける。趣味はクライミング。共著で「絵で見てわかるITインフラの仕組み」を執筆。
  • 概要: Apache Kudu は分析系クエリに強いカラムナー型の分散データベースです。KuduはOLTPとOLAPの両方のワークロードに耐えられる、HTAPと呼ばれる種類のDBで、昨年の #dbts2017では、Kuduの「速さ」について紹介しました。KuduはBI/DWHなど分析向けのDBといったイメージが強い一方で、 元々はGoogleのSpanner論文など触発されて開発されており、地理位置が離れたノード間でも一貫性を担保する仕組みを持っています。その仕組の元にあるのが、「HybridTime」と呼ばれるDBの内部時計です。今回はHybridTimeについて、その論文を紹介しながら仕組みに触れ、どのような特性を持っているのか、なぜこれがKuduの「速さ」にもつながるのかについてお話したいと思います。
スライド
  • To be uploaded
  • Kudu はC++で書かれたストレージエンジンで Impala や Spark などから使うことができる HTAP なDB。Exadata のストレージサーバのように push down 機能がある。MVCC だが単一行でしか対応していない。

P.S.

MySQL 界隈の方々と二次会に行って MySQL の Performance Schema について質問したり、各社の運用事情など聞けて楽しかった。

*1:Data Guard も同一サイトの耐障害性対策としても使える

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/yohei-a/20180919/1537381125