データエンジニアリングの領域で少し前から目にするようになった “data contract” という言葉。 なんとなく今の業務で困っている課題の解決になりそうな気がしつつもよくわかっていなかったので調べてみた。 data contract について語られているいくつかのブログ記事などを参考にしている。 Data Contract とは データの schema というのはナマモノで、いろいろな理由で変更されることがある。 schema を変更する場合、その schema のデータ (table や log) が所属する単一のビジネス機能や application のドメインで行われることになる。 そのドメインの閉じた世界で考える分にはこれで問題ないのだが、DWH や data lake など組織レベルのデータ基盤でデータを流通していた場合はその先のことも考えないといけなくなる。 このようにチームを超える影響というのは、ビジネス機能に責任を持っているチームからは見えにくくなっていることが多い。 上流の application 側で schema を変更したら下流のデータ基盤の ETL 処理がぶっ壊れてしまった、というのはデータ基盤運用あるあるではないだろうか。 というところを解決して平和に過ごせるようにすることが data contract の主なモチベーションだと思われる。 “contract” は日本語で言うところの「契約」。 組織におけるデータ流通において、データの送り手である producer 側と受け手である consumer 側との間で合意した契約を遵守することにより、前述のような問題を避けることができるというのが data contract である。 組織内のデータの見通しがよくなったり、パイプラインを宣言的に開発することができるようになるというメリットもある。 エンジニアにとっては Datafold のブログ記事の例を読むとイメージしやすいかもしれない。 To provide another analogy, data contracts are what API is for the web services. Say we want to get data from Twitter. One way is to scrape it by downloading and parsing the HTML of Twitter’s webpage. This may work, but our scraper will likely break occasionally, if Twitter, for instance, changes a name of a CSS class or HTML structure. There is no contract between Twitter’s web page and our scraper. However, if we access the same data via Twitter’s API, we know exactly the structure of the response we’re going to get. An API has required inputs, predictable outputs, error codes, SLAs (service level agreements – e.g. uptime), and terms of use, and other important properties. Importantly, API is also versioned which helps ensure that changes to the API won’t break end user’s applications, and to take advantage of those changes users would graciously migrate to the new version. ...

業務で AWS Glue Schema Registry を使おうとしたけど、やっぱりやめたというお話。 Glue Schema Registry What’s Schema Registry? AWS Glue Schema Registry は2020年に発表された AWS の機能だ。 Control the evolution of data streams using the AWS Glue Schema Registry 一方、私が最初に schema registry 的なものを見たのは Confluent の例。 Schema Registry の概要 - Confluent AWS の Glue Schema Registry はこれより後のリリースであり、同等のものの AWS マネージド版といったところだろうか。 schema registry で何ができるかは Confluent のリンク先の図がとてもわかりやすいので参考にしていただきたい。 Glue Schema Registry もだいたい同じで、ストリーム処理のための機能である。 Glue Schema Registry で解決したい課題とその機能 データ基盤上のストリーム処理における schema 管理はバッチ処理のそれとは異なる難しさがある。 これは schema evolution と呼ばれる問題で以前のポストでも述べている。 バッチ処理おじさんがストリーム処理のシステムを開発するにあたって調べたこと 難しい点として以下のようなことが挙げられる。 ...

「データレイク」という言葉は使う人によって異なった意味があるように感じており、気になっていた。 このポストではアーキテクチャ目線でのデータレイクと内容物目線でのデータレイクの違いについて書いてみる。 便宜上前者を「データレイク」、後者を「データレイク層」と呼ぶことにする。 アーキテクチャ目線の「データレイク」 「データレイク」については以前こちらのポストで書いたのでここでは詳しく触れない。 詳細はリンク先を見ていただきたい。 ここでキーとなるのが、 加工前データや非構造化データを含むあらゆるデータを保存 一元的なデータ管理 という部分だ。 あらゆるデータを一元的に管理するという思想であり、これができるアーキテクチャがデータレイクということだ。 例えば AWS や Azure のドキュメントを見るとデータレイクの中が zone に分けられており、生データを保持する raw zone や加工されたデータを置いておく curated zone などがある。 (zone の命名にもいくつかの流派があるようだ…) Reference architecture - Data Analytics Lens Data lake zones and containers - Cloud Adoption Framework | Microsoft Docs 次の Robinhood 社の例でもデータレイク中に生データとその派生データが存在している。 Fresher Data Lake on AWS S3 | by Balaji Varadarajan | Robinhood 内容物目線の「データレイク層」 一方でデータレイクには生データのみを置くべき、という考えもある。 本書におけるデータレイク（DataLake）層とは、元のデータをコピーして、1つのシステムに集約したものを指します。 データソース（＝水源）から流れてきたデータを蓄える場所なのでレイク（湖）と呼びます。 ECサイトの注文履歴データを、分析用DBにコピーしている場合、それがデータレイクと言えます。データレイクのデータは、データソースと一対一の関係にあります。何も加工していない、ただのコピーだからです。 何も加工していない、ただのコピーであることが重要です。仮にデータの中身に誤りがあったとしても、修正や加工をせず、そのまま集約しましょう。 – ゆずたそ,渡部 徹太郎,伊藤 徹郎. 実践的データ基盤への処方箋〜 ビジネス価値創出のためのデータ・システム・ヒトのノウハウ (Japanese Edition) (pp.57-58). Kindle 版. ...

ポエムです。 事業フェーズごとのデータサイエンティストの役割 まずはこちらの発表。 事業立ち上げにデータサイエンティストは必要なのか？ | CA BASE NEXT とても納得できる内容だった。 一部抜き出して要約すると 事業の立ち上げフェーズ データがまだなかったり、整備されていない状態 データサイエンスによる改善がしにくい 事業のグロースフェーズ 大規模なデータが使える状態 データサイエンスによる改善がやりやすい とのこと。異論はない。 では事業が立ち上がり、グロースが落ち着いたその後の成熟フェーズではどうなのだろうかという話。 成熟フェーズにおける改善の難しさ 端的に言うと成熟フェーズでは ML によるさらなる改善は困難になってくると思う。 ここで言う成熟フェーズにおいてはプロダクトの進化とともに機械学習もそれなりに適用されてきたものとする。 成熟フェーズということで既存の ML モデル、特にビジネスインパクトが大きい箇所はこれまでいろいろな改善が重ねられてきている。 そのモデルの精度をさらに上げるとなると、より高度なアルゴリズム、より複雑なデータ等を扱う必要がある。 しかし技術的によっぽど大きなブレークスルーがない限りは精度の改善幅はグロースフェーズよりもかなり小さいものとなるだろう。 精度が上がれば上がるほど、次の1%を上げるためのコストは大きくなっていく。 改善が進むほどに次の改善業務は困難になっていく。 (蛇足だがある程度大きな組織でなければ高度で state-of-the-art な ML アルゴリズムは運用しない方がいいと考えている) では既存ではない新しい適用箇所に ML を使えばいいのではとなるかもしれない。 しかしやはりそれも難しい。 ビジネスインパクトが大きく、かつわかりやすい適用箇所にはおそらくすでに ML が適用されているからだ。 その状態から更によい適用箇所を見つけるには深いドメイン知識が必要になったりする。 という感じでいわゆるキラキラした「ML でビジネスをドライブ！」みたいなことは成熟フェーズでは難しいことが多いのではないか。 しかしデータサイエンティストにやることがないわけではない。 成熟フェーズで何ができるか ぱっと思いつくのは次のような仕事。 データドリブンな施策の立案・評価 これは事業フェーズ問わずあるべき ドメイン知識が必要 ML エンジニアリング パイプラインの改善や属人性をなくすお仕事 ML モデルの受動的なメンテナンス 精度が変化したときの調査 内部的・外部的要因によるデータの変化への対応 やっぱり ML モデルの精度改善 成熟フェーズということでビジネスもスケールしていれば 0.1% の精度改善でも売上的なインパクトは大きいかもしれない いわゆる狭義のデータサイエンスではなく、ドメイン知識であったりアナリストやエンジニア的な視点が絡んだ仕事が増えてくる。 よくある「ML だけじゃなく◯◯もできると強いよね」みたいな話になってしまった。 おわりに …という話が少し前に Twitter で知人との話題に上がった。 若者が歴史的にいろんな人が改善に取り組んできた ML モデルの改善にアサインされている、というのが近いところで観測されたのでたいへんそうだなあと思いつつこの件を思い出したので書いてみた。 ...

ストリーム処理のフレームワークが備える backpressure という機能がある。 このポストでは Apache Flink の backpressure について調べたことを記載する。 Backpressure の目的 backpressure はストリーム処理システムにおける負荷管理の仕組みの一つ。 一時的な入力データ量の増大に対応する。 インターネットユーザの行動履歴やセンサーデータなどは常に一定量のデータが流れているわけではなく、単位時間あたりのデータ量は常に変動している。 一時的にスパイクしてデータ量が増大するようなことも起こりうる。 複数の operator からなる dataflow graph により構成されるストリーム処理システムにおいては、処理スピードのボトルネックとなる operator が存在する。 一時的に入力データ量が増えてボトルネックの operator の処理速度を上回ってしまった場合に、データの取りこぼしが発生するのを防ぐのが backpressure の目的となる。 Backpressure の仕組み Buffer-based ここでは以前のブログでも紹介した、ストリーム処理で必要とされる機能について書かれた Fragkoulis et al. 1 を引用して一般論としての backpressure について述べたい。 上流／下流の operator をそれぞれ producer, consumer とする。 producer, consumer (それらの subtask と言ってもいいかも) がそれぞれ異なる物理マシンに deploy されているケースが Figure 12b となる。 各 subtask は input と output の buffer を持っており、 producer は処理結果を output buffer に書き出す TCP 等の物理的な接続でデータを送信 consumer 側の output buffer にデータを格納 consumer がそれを読み込んで処理する というような流れになる。 buffer はマシンごとの buffer pool で管理されており、input/output で buffer が必要となった場合はこの buffer pool に buffer が要求される。 ...

はじめに 前回のポストではデータレイクとはどういうものかというのを調べた。 今回はデータレイクの文脈でどのような OSS が注目されているのかを見ていきたい。 以下は NTT データさんによる講演資料であり、その中で「近年登場してきた、リアルタイム分析に利用可能なOSSストレージレイヤソフト」というのが3つ挙げられている。 大規模データ活用向けストレージレイヤソフトのこれまでとこれから（NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05） from NTT DATA Technology & Innovation Delta Lake Apache Hudi Apache Kudu これらはすべて論理的なストレージレイヤーを担う。 こちらの講演資料に付け足すようなこともないかもしれないが、このポストではデータレイクという文脈から自分で調べて理解した内容をまとめるということを目的にする。 当然 Hadoop, Hive, Spark 等もデータレイクの文脈において超重要だが、「データレイク」という言葉がよく聞かれるようになる前から普及していたのでこのポストでは触れないことにする。 Delta Lake https://delta.io/ Delta Lake is an open-source storage layer that brings ACID transactions to Apache Spark™ and big data workloads. Delta Lake Delta Lake は Apache Spark の読み書きに ACID な transaction を提供するストレージレイヤーの OSS である。 Databricks が作り、2019年4月に v0.1.0 がリリースされたのが最初だ。 使い方はめちゃ簡単で、dependency を設定した上で Spark で ...

最近よく聞かれるようになった「データレイク」という概念にあまりついていけていなかったため、いまさらながらざっと調べてみた。 データレイクとは Wikipedia によると最初にこの言葉を使ったのは Pentaho 社の CTO である James Dixon らしい。 その時の彼のブログ (10年前…) を読むと、既にあったデータマートに対して Only a subset of the attributes are examined, so only pre-determined questions can be answered. The data is aggregated so visibility into the lowest levels is lost –Pentaho, Hadoop, and Data Lakes - James Dixon’s Blog というような問題意識からデータレイクというコンセプトを提案したようだ。 最近？のデータレイクについてはベンダー等の記事が参考になる。 データレイクとは - AWS データレイクとは？ - talend データレイクとは？データレイクの落とし穴と効果 - Informatica 書籍だと『AWSではじめるデータレイク: クラウドによる統合型データリポジトリ構築入門』がいいだろうか。 データレイクの概要と AWS が考えている構築・運用がざっとわかる。 Amazon で検索した限りだと現時点でタイトルに「データレイク」を含む和書はこれのみだった。 ...

ストリーム処理における CSV ファイルの読み込み Apache Flink は unbounded なストリームデータを処理するためのフレームワークだ。 しかし現実的な application を開発する場合、ストリームデータに加えて static なファイルや DB 等を読み込みたいこともある。 star schema における dimension table 的な情報をストリームに結合したい場合 等が考えられる。 このポストでは Flink で DataStream API ベースでの実装において CSV ファイルを読むことを考える。 Flink は現時点の stable である v1.11 を想定。 CSV ファイルを読む方法 DataStream API ベースの実装で CSV ファイルを読むには StreamExecutionEnvironment のメソッドである readFile() を使う。 overload された同名のメソッドがいくつか存在するが、次の2つの引数が特に重要だろう。 まず1つめは FileInputFormat<OUT> inputFormat であり、こちらは data stream の生成に用いる入力フォーマットを指定する。 おそらく最も一般的なのが TextInputFormat だと思われる。 もちろん単なる text として CSV ファイルを読み込み、後続の処理で各レコードを parse することも可能だが CSV 用の入力フォーマットがいくつか用意されているようだ。 PojoCsvInputFormat RowCsvInputFormat TupleCsvInputFormat なんとなく名前でわかると思うが、それぞれ readFile() の結果として返される DataStreamSource が内包する型が異なる。 これについては後述の実験にて確認する。 ...

ちょっと昔話 かつて参画したプロジェクトの話。 そのプロジェクトでは他社から受注した受託開発として機械学習系のシステムを開発していた。 当時としては新しいフレームワークを使い、かなり頑張ってなんとか納期内で完成させた。 その中の1つの機能として A/B テストができるようにしていた。 パラメータチューニングによりパフォーマンスを改善することを想定していた。 しかし結局その機能は使われることがなかった。 なぜか。 A/B テストを実施するためのクライアントの追加の予算がつかなかったためである。 受託なのでなおさらなのだが、売上にならなければ工数をかけるこはできない。 工数を使ってパフォーマンス改善することはできなかった。 手はあるのに。 機械学習の精度は必ずしも利益に結びつかない この昔話で何が言いたいかというと、機械学習の精度改善は必ずしも利益に結びつかないということである。 そのことを示しているとても素晴らしい資料がこちら。 機械学習の精度と売上の関係 from Tokoroten Nakayama 前述の昔話の例はこの資料で言うところの③ロジスティック型 (=外注) となる。 いったん売上が立った後、追加予算がつかなかったので精度改善では売上は増えなかったのだ。 倫理感による精度改善 受託開発を主としている組織であれば工数にはシビアなので、売上の立たない工数をかけることはあまりないだろう。 (よっぽどの炎上鎮火とかでなければ) しかし自社で製品やサービスを作って提供しているような組織の場合、利益にならない精度改善をしているのを時折見かける。 なぜそのようなことが起こるかと言うと多くの場合はデータサイエンティスト／機械学習エンジニアとしての倫理感からなのではないだろうか。 「◯◯予測という機能なのでできるだけ良い予測精度を示すべきだ」 「ユーザには気づかれない部分だが精度が悪いので改善したい」 倫理感や興味が先行してしまっているのだ。 しかしその精度を上げた先に利益があるとは限らない。 機械学習で職を得ている人間は自分の仕事を機械学習の精度を上げるゲームだとみなす傾向があるように思う。 例えばインターネット広告の CTR 予測。 これは予測精度が高いほど利益は改善するし、広告主に価値も提供できる。 精度改善に倫理と利益が伴っている、とても機械学習がハマる例だと思う。 本来はこれらを兼ね備えているのが良い適用先であるはずだ。 イシューは行き渡っているのか 利益に結びつかない、または間接的にしか結びつかないような精度改善をやることが許されるというのは組織に余裕があるということで悪いことではないのかもしれない。 しかし単によいイシューの設定ができてないだけという可能性もある。 自社で製品やサービスを作って提供しているような組織において、単純なロジスティック回帰でコアなところのビジネスを大きく加速させることができた時期を過ぎると機械学習で解くのに適したよい問題を恒常的に見つけ出すのは実は難しいのではないだろうかと最近考えるようになった。 ビジネスの領域拡大よりも既存領域への機械学習の適用の方が速いということは十分ありうる。 もちろんチームの規模にもよる。 機械学習チームの人的リソースの規模に対して機械学習で解くべきよいイシューを見つけ出せているのか、ということだ。 少し前にちょっと話題になったこちらの件もイシューが大事だと言っている。 全ての機械学習の論文は新しいアルゴリズムを提案しているのですか？ - Quora キャリアの行く末 事業会社においてビジネスの領域拡大よりも既存領域への機械学習の適用の方が速く、よいイシューを提供しにくいということがよく起こるのであれば、機械学習チームのリソースは余剰気味になりやすいということになる。 これが続くと今後機械学習しかやらない人材の市場価値は下がっていくのかもしれない。 もしくは自社で製品やサービスを持っている組織ではなく、受託開発やコンサルが主戦場になっていくのかもしれない。 何にせよ特定のプロダクトに commit したいのであれば機械学習エンジニアは機械学習以外のスキルも磨いていく必要があるように思う。 おわりに 見える範囲にいる人が利益にならない精度改善をしているのを横目で見てこのようなことを考えていた。 難しいけどできるだけ金を生んでいきたい。

はじめに このポストではストリーム処理の survay 論文の話題に対して Apache Flink における例を挙げて紹介する。 論文概要 Fragkoulis, M., Carbone, P., Kalavri, V., & Katsifodimos, A. (2020). A Survey on the Evolution of Stream Processing Systems. 2020年の論文。 過去30年ぐらいのストリーム処理のフレームワークを調査し、その発展を論じている。 ストリーム処理に特徴的に求められるいくつかの機能性 (functionality) についてその実現方法をいくつか挙げ、比較的古いフレームワークと最近のフレームワークでの対比を行っている。 このポストのスコープ このポストでは前述のストリーム処理システムに求められる機能性とそれがなぜ必要となるかについて簡単にまとめる。 論文ではそこからさらにその実現方法がいくつか挙げられるが、ここでは個人的に興味がある Apache Flink ではどのように対処しているかを見ていく。 ちなみに論文中では Apache Flink はモダンなフレームワークの1つとしてちょいちょい引き合いに出されている。 ここでは Flink v1.11 をターゲットとする。 以下では論文で挙げられている機能性に沿って記載していく。 Out-of-order Data Management Out-of-order ストリーム処理システムにやってくるデータの順序は外的・内的要因により期待される順序になっていないことがある。 外的要因としてよくあるのはネットワークの問題。 データソース (producer) からストリーム処理システムに届くまでのルーティング、負荷など諸々の条件により各レコードごとに転送時間は一定にはならない。 各 operator の処理などストリーム処理システムの内的な要因で順序が乱されることもある。 out-of-order は処理の遅延や正しくない結果の原因となることがある。 out-of-order を管理するためにストリーム処理システムは処理の進捗を検出する必要がある。 “進捗” とはある時間経過でレコードの処理がどれだけ進んだかというもので、レコードの順序を表す属性 A (ex. event time) により定量化される。 ある期間で処理された最古の A を進捗の尺度とみなすことができる。 ...