Fundamentals of Data Engineering 輪読会資料 第8回分 20230605開催

本記事の位置付け

こちらの勉強会　英語で技術書を読もう：Fundamentals of Data Engineering 第8回　に参加し、発表するためにまとめたもの。

• 今回の対象は以下
  • Chapter4 Choosing Technologies Across the Data Engineering Lifecycle より
    • Today Versus the Future: Immutable Versus Transitory Technologies
    • Our Advice の終わり、Location の手前まで

Chapter4 Choosing Technologies Across the Data Engineering Lifecycle

Today Versus the Future: Immutable Versus Transitory Technologies

タイトル翻訳案：現在VS未来：変わらない技術と変わりゆく技術」

• 上記は筆者によるタイトルの翻訳案ですが、スガシカオの「Story」という曲の「かわってく心　変わらない願い」という歌詞が思い起こされるなあと思いました。本文の趣旨とはちょっと違うものですが。

1パラグラフ目：現在と未来

• データエンジニアリングのような面白い領域を見ていると、つい今の需要を無視してどんどん進化していく未来ばかり見がちです。
• より良い未来を築こうという意図は高尚で結構ですが、設計や構築においてやりすぎてしまいがちです。
• 未来のために選ばれた道具は、未来がきたら古くて時代遅れになります。
  • その未来も、かつて夢見たはずの姿と比べると随分小さく見えることが多々あります。

2パラグラフ目：今！ここ！

• 人生の先輩がよく言うように、今に集中しましょう。
  • 以下ツイートは、今に集中する、という事を描いたサンプルです。

バガボンドの吉岡編の

植田良平の最後の一撃の回想めっちゃ良くない？
吉岡三兄弟の視点で書かれる
エピソード全部グッと来る。

宮本武蔵がこれから背負う罪悪感とか虚しさにグッと引き込む
1人、1人の人生を主人公が終わらせて行く。
作者も苦しくなりそう。 pic.twitter.com/bhojw7LmjP

— じゅんぺい (@gomennat) September 4, 2017

• 今と近い未来に対して最もよい技術を選ぶべきです。ただし今後あり得る未知のものや進化にも対応しうるようなものを。
• 自分に問いましょう。
  • 自分は今、何処にいるのか
  • 自分が目指す未来のゴールは何なのか
• この問いへの答えは、あなたのアーキテクチャや、そのアーキテクチャで使われる技術についてを知らせてくれるはずです。
• この答えは変わりそうなものや変わらなさそうなものを理解する事により出てきます。

3パラグラフ目：変わらないもの、変わりゆくもの

• 以下、2種類のツール郡について考えます。
  • 変わらないもの
  • かわりゆくもの
• 変わらないものについて
  • クラウドの土台になるような技術
  • 時の試練に耐えるような言語やパラダイム
  • クラウド技術の例：
    • オブジェクトストレージ
    • ネットワーク
    • サーバー
    • セキュリティ
  • S3やAzure Object Storageなどのオブジェクトストレージ等は、あと10年以上は変わらずにいるでしょう。
  • オブジェクトストレージにデータを格納することは賢い選択です。
  • オブジェクトストレージは様々に進化を遂げ、色々なオプションをつけてきますが、全体的な技術進歩の速さに関わらず、あなたのデータはオブジェクトストレージ内で安全で使える状態であることでしょう。

4パラグラフ目：変わらないものの例

• 言語について言えば、SQLやbashは長期にわたりそこにいてくれました。それがすぐに消えることはありません。
• 変わらない技術はリンディ効果の利益を受けています。
  • その技術が長く続いているほど、その技術は使われる、ということです。
  • リンディ効果(Wikipedia)
• 例えば以下のものを考えてみましょう。
  • 送電網
  • リレーショナル・データベース
  • C言語
  • X86 プロセッサアーキテクチャ
• ある技術が変わらないものかどうかを決めるためのリトマス紙として、リンディ効果を適用することを提案します。

5パラグラフ目：変わりゆくものの例

• 変わりゆく技術とは、来ては去っていくものです。
• その典型的な軌跡は、多くの過大広告で始まり、人気が急上昇し、その後だんだんよく知られなくなっていきます。
• Javascriptのフロントエンドが古典的な例です。
• 2010年から2020年の間にいくつのJavascriptのフロントエンドフレームワークが生まれては消えていったことでしょう。
• Backbone.js, Ember.js, そしてKnockout が2010年代初頭に流行っていました。現在はReactやVue.jsが多くの人々の心を占めています。
• 3年後に流行っているJavascriptのフロントエンドは何かって、誰にわかるというのでしょうか。

6パラグラフ目

• データ関連の世界には毎日のように資金力のある新規参入企業やオープンソースプロジェクトが入ってきます。
• 全てのベンダーは、自社製品が業界をよりよくし、世界をより良い場所に変える、と言います。
• これらの企業やプロジェクトの多くは長期の牽引力を持たず、だんだんと名前が消えていきます。
• トップクラスのベンチャーキャピタル（VC）は、データ関連ツールへの投資のほとんどが失敗することを知りつつ、大金を賭けた投資をしています。
• もし、VCが何百万（あるいは何十億）もの資金をデータ関連ツールへの投資につぎ込んでいるにもかかわらず、それがうまくいかないとしたら、 データアーキテクチャのためにどの技術に投資すべきかを知ることができるでしょうか？
• 難しいですよね。
• チャプター１で紹介した、マット・タークのML,AI,データに関する有名な絵を考えてみてください。（図4-1）

7パラグラフ目

• 比較的成功した技術でさえ、素早い適応のあとで、（成功の犠牲として？）、名前が消えていきます。
• 例えば2010年代初頭、Hiveは、分析者やエンジニアがMapreduceのジョブを手でコーディングせず大規模データセットをクエリできることから急速に普及しました。
• Hiveの成功をイメージしてその欠点を克服するため、エンジニアはPrestoやその他の技術を開発しました。
• Hiveは現在、主にレガシーな実装として見られます。ほとんどすべてのテクノロジーが、このような必然的な衰退の道をたどります。

Our Advice

1パラグラフ目

• ツールとそのベストな運用の素早い運用の変化を見ると、2年に1度はツールの評価をするべきでしょう。（図4-2）
• できる限り、データエンジニアリングのライフサイクルの中で変わらない技術を見つけてそれを基本として使いなさい。
• 変わりゆく技術はかwらない技術の周辺に置きましょう。

2パラグラフ目

• 多くのデータ技術の失敗についての納得行く理由から、一度選んだ技術から別な技術へどれだけ簡単に移行できるかを考える必要があります。

• 何が（今ある技術から）離れる理由でしょうか。

• 以前機会コストについて記述した通り、「トラバサミ」を避けましょう。

• プロジェクトが頓挫するかもしれない、会社が存続できないかもしれない、あるいはその技術がもう合わないということを知った上で、広い視野で新しい技術に取り組みましょう。

単語帳

• immutable：不変
• transitory:一時的な
• underpin：土台
• obscurity:無名、曖昧（今回は無名、のほう）
• thus:したがって
• meteoric: 素早い　（彗星の、という意味もあります。この単語をググると彗星が落ちてきました）
• well-funded：資金力のある
• entrants：参加者
• traction:牽引力
• uptake:普及