ablog

不器用で落着きのない技術者のメモ

db tech showcase 2018 Day 1

DB

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

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


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

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

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

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

概要
  • 講師: 石井 達夫さん（SRA OSS, Inc. 日本支社 - 取締役支社長 / PostgreSQLコミッター）
  • 講師略歴: 経営者でありながら現役のプログラマとして活動。日本人として始めて PostgreSQLコミッターになった。現在は、PostgreSQL専用ミドルウェアの Pgpool-II の開発に注力し、プロジェクトのオーガナイザーを努める。
  • 概要: PostgreSQLに組み込みのレプリケーション機能を使うと、データベースサーバを複数使ったクラスタが容易に構築できます。しかし、運用局面や、アプリケーションからの利用となると、単一のPostgreSQLサーバでは起こらないような事態や、一筋縄では行かない問題が発生しがちです。本講演では、PostgreSQLのクラスタ利用での注意点やはまりどころを解説し、次にPgpool-IIを使ってこうした問題をどのように解決できるかを、デモを交えて説明します。
スライド
  • To be uploaded
メモ
  • P.9 の絵は複数のサーバプロセスがあるが簡略化した絵になっている
  • P.11 一時テーブル、強いロックなどはスタンバイで使えない。
  • 2010年に PostgreSQL 9.0 でトランザクションログの非同期レプリケーションが実装され、その後同期レプリケーションが実装され、現在、マルチマスタレプリケーションやシャーディングが開発されている。
  • 参照だけスタンバイに接続する場合、アプリ側で振り分けを実装したり、参照でも一貫性を求めるものはマスターを見るなど考慮点が多いが、Pgpool-II はアプリに意識させなくてもよろしくやってくれる質実剛健な機能が豊富に揃っていると感じた。
  • 紹介されていた Pgpool-II とレプリケーションによる構成は「レプリケーション」というと Oracle では Data Guard と比較しそうになるが、災害対策ではなく同一サイトでの耐障害性対策としての機能が多く、Oracle でいうと RAC と比較するのが適切なケースもあると感じた*1。優劣の比較ではなく各機能がどんな課題を解決するためにあり、Oracle ではどの機能がソリューションになるかという意味での比較。

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

概要
  • 講師: 嶋内 翔さん（Cloudera 株式会社 - セールスエンジニア）
  • 講師略歴: 京都大学工学部卒業、NECでエンタープライズOSSのSI支援業務に従事。2011年にClouderaの最初の日本人社員として入社。サポートエンジニアとして3年勤めた後、セールスエンジニアとしてHadoopを中心としたビッグデータ基盤に関する豊富な経験を積む。監訳書に「Apache Sqoopクックブック」などがある。
  • 概要: Apache Hadoopのためのオープンソース分析データベース、Impalaのベストプラクティスをご紹介します。
スライド

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

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

概要
  • 講師:佐藤 貴彦さん（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 も同一サイトの耐障害性対策としても使える