カーキ色はヒンディー語らしい

技術記事は https://zenn.dev/notrogue

Prefect Orionについて何か書いた

Prefectとは

AirflowやDigDagと同じワークフローエンジンです。

このブログでも紹介していますが、

などがわかりやすいと思います。

英語でもよければ、公式ページ（core部分とオーケストレーションの二つ）がわかりやすいです。

Prefect Orionとは

2021/10/6にPrefectがアナウンスした「our second-generation workflow engine」です。

まだTechnical Previewで出ている情報も少ないですが、Prefect Orionについて調べてみようというのが、今回の記事です。

正直、まだぼんやりしています。

なにはともあれ触ってみる

Getting startedがあります。

下例では既存のPrefectと分けたいのでPoetry使っていますが、適当に読み替えてください。

# インストール
poetry new advent_calendar_prefect
cd advent_calendar_prefect/advent_calendar_prefect
poetry add "prefect>=2.0.0a"
poetry shell

basic.pyとして保存します。

from prefect import flow, task
from typing import List
import httpx


@task(retries=3)
def get_stars(repo: str):
    url = f"https://api.github.com/repos/{repo}"
    count = httpx.get(url).json()["stargazers_count"]
    print(f"{repo} has {count} stars!")


@flow(name="Github Stars")
def github_stars(repos: List[str]):
    for repo in repos:
        get_stars(repo)


# run the flow!
github_stars(["PrefectHQ/Prefect", "PrefectHQ/miter-design"])

実行

python basic2.py  
07:48:04.506 | Beginning flow run 'merciful-unicorn' for flow 'Github Stars'...
07:48:04.506 | Starting executor `SequentialExecutor`...
07:48:04.731 | Submitting task run 'get_stars-e40861f0-0' to executor...
PrefectHQ/Prefect has 7906 stars!
07:48:05.229 | Task run 'get_stars-e40861f0-0' finished in state Completed(message=None, type=COMPLETED)
07:48:05.319 | Submitting task run 'get_stars-e40861f0-1' to executor...
PrefectHQ/miter-design has 12 stars!
07:48:05.796 | Task run 'get_stars-e40861f0-1' finished in state Completed(message=None, type=COMPLETED)
07:48:05.800 | Shutting down executor `SequentialExecutor`...
07:48:05.882 | Flow run 'merciful-unicorn' finished in state Completed(message='All states completed.', type=COMPLETED)

サーバを起動

prefect orion start

f:id:toukoudo:20211210075028p:plain
prefet_orion

サーバを起動する前に実行したFlowも登録されていることに注目です。

（~/.prefect/orion.dbに情報が保存されるようです）

エラー

常に起きるかは不明ですが、自分の場合以下のエラーがでました（抜粋）。

sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) no such table: flow
[SQL: INSERT INTO flow (id, created, updated, name, tags) VALUES (?, ?, ?, ?, ?) ON CONFLICT (name) DO NOTHING]
[parameters: ('cb63d353-0279-4e4c-adfd-5bb1254b88d7', '2021-12-06 22:33:35.319780', '2021-12-06 22:33:35.319804', 'my-favorite-function', '[]')]
(Background on this error at: https://sqlalche.me/e/14/e3q8)

DBをリセットするコマンドを実行すると動くようになりました。

prefect orion reset-db

画面を眺める

わくわく

f:id:toukoudo:20211210081034p:plain
トップ画面

f:id:toukoudo:20211210082020p:plain
flow run

f:id:toukoudo:20211210082108p:plain
radar

Prefectとの画面の違い

Technical Previewという事情もあり、Prefectよりも機能は（かなり）少ないです。

例えば、

  • 画面からのFlow実行
  • ログの確認
  • Interactive API

などはありません（未実装なだけなのか、意図的に実装していないのか不明）。

余談ですが、デフォルトポートが衝突（OrionのWebserverとPrefectのApollo Serverが4200）するので、そのままでは同時起動できません。

Radar

現時点でのOrionと従来のPrefectの最大の違いは、Radarかもしれません。

従来のPrefectが上から下に依存関係を配置に応じた配置を行っていたのに対し、Radarでは同心円状に配置し、依存関係のTask同士を結びます。

大規模な場合や、Subflowが多く使われている場合に便利になるらしいです（が、運用してみないとわかりませんね…）。

https://www.prefect.io/assets/img/ui-2.c31b79ad.svg （従来のPrefect。Prefect Core - Prefectより）

f:id:toukoudo:20211211070443p:plain
Radar
（Radar。Introducing Radar - Prefectより）

ビジョンのはなし

Orionが目指していることは、CEOのブログで説明されています。

方向転換というより、従来のPrefectの方向性

  • 通常のPythonコードに近い感じで書ける
  • ローカルでの開発を便利に

をさらに進めたいように感じました。

DAG-free

  • 表現力（ストリーミング、動的な依存…）と、 デベロッパーエクスペリエンスの点で、従来のDAGは制約となっている
  • DAGのようにワークフロー全体を事前に定義するのではなく、実行時に定義することで制約をなくし、 通常のPythonコードのように書けるようにしたい（「code as workflow」）

developer experience

  • 通常のPythonコードのように書ける・ローカルで実行できる（前述の「code as workflow」）
  • スケジュール実行以外は、 Orion Server無しでも同じように実行できる（「ephemeral Orion API」）
  • 広く使われているツールの上に実装することで、採用コストを下げる

※ 通常のPythonコードのように書ける例として、subflowの書き方の変化が紹介されています

youtu.be

orchestration as a service

  • オーケストレーションを、jobの実行ではなく、状態推移を管理するルールと定義
  • Orionではわかりやすいルールエンジンを書いた。これにより、推移した理由がわかりやすく説明できるようになった

機能のはなし

公式ページに大量に機能や、実装の方針が列挙されています（下図）。 ただし、Orion固有ではなくPrefectでも実装されている機能も記載されている気がします（VersioningやMapping）。

個人的には

  • Prefect IDE
  • Serverless Execution
  • The flow never stopps

あたりの記載が気になりました。

www.prefect.io

f:id:toukoudo:20211210094504p:plainf:id:toukoudo:20211210094507p:plainf:id:toukoudo:20211210094510p:plainf:id:toukoudo:20211210094514p:plain
機能たち

Data Pipelines with Apache Airflow読んだ

learning.oreilly.com

内容

  • Airflowの概要
    • ワークフローエンジンのご利益
    • 提供する機能の概要（スケジュール、DAG）
    • Airflowを選ぶ理由、選ばない理由
  • Airflowの入門
    • DAGの例
    • Task・Operator
    • Airflow UI
    • スケジュール
    • テンプレート
    • Task間の依存定義
    • トリガー
  • 外部システム（S3やRDB）との連携
    • Operator、Hookの例の説明
  • 独自のコンポーネントの作り方（Operator、Hook、Sensor）
  • テスト
  • Airflowとコンテナ
    • PythonOperatorだと依存関係大変になるので、DockerOperator・KubernetesPodOperator使う話
  • ベストプラクティス
  • 本番デプロイ（Executor、ログ、監視）
  • セキュリティ（認証・認可）
  • クラウドサービス 　 * Azure、GCP、AWS、Astronomer
    • （著者の一人がAstornomerの中の人ですが、意外とAstronomerの話題少ないです）
  • サンプル・プロジェクト
    • タクシーデータをAPIで取得して、変更

その他

  • Airflowは2系で大きく機能が増えましたが、この本は基本的に1系（1.10？）です。一部2系に関する補足説明があります
    • TaskFlow API等
  • いくつかAirflow以外の話題がありますが、それに関しては説明があるので予備知識なくても大丈夫だと思います
    • pytest
    • Dockerコンテナ
    • Sagemaker

著者

  • Bas Harenslakさん
    • AstronomerのSolution Architect・Airflowのcommitter
  • Julian de Ruiter さん
    • GoDataDriven（データエンジニアリングのコンサル会社）のデータサイエンティスト・MLエンジニア

感想

  • 一冊まるごとAirflowな、（たぶん）初めて・唯一の本。Airflow使うなら読んで損はないかと
    • 本以外なら、公式ドキュメントかUdemyにいくつかコース（例）が良さそう
  • 入門の章は公式ドキュメントで十分かも。テストとかベストプラクティスあたりの価値が高いと思う
  • 他のワークフローエンジンとの比較（e.g. DagsterやPrefect）はあまりないです
  • Airlfowの「できるけどやらない方がいい事」、「やるなら注意してやるべき事」を説明してくれているのが、良きかな
    • 「ストリーミングデータの処理」とか「xcomに大きなデータ入れる」とか「動的なDAGを書く」とか
    • Airflowは分散Python実行基盤なので、いずれもやろうと思えば出来てしまうので、↑のような制約の把握大事
  • execution dateの説明に一節丸ごと使っているのが面白い。Airflowでわかりにくい＆引っかかりやすい概念なんだな

今更ながら分散システムデザインパターン読んだ

この本は

  • 原著は2018年、翻訳は2019年
  • 著者のBurnsさんは、Google・MicrosoftでKubernetesの開発をしていた・している人
  • 書名の通り、複数のノードで処理を行う場合の色々なパターンを解説している本
    • また、副題（コンテナを使ったスケーラブルなサービスの設計）の通り、コンテナ・Kubernetesを例にした話が多い（が、それに限定されない）

内容

  • スケーラブル、疎結合にするため分散システム増えたよね
  • パターンを知っておくと良いよ
  • 各パターン（12個？）の紹介。各パターンに関して、おおよそ以下の記載
    • 概要
    • 使用する例
    • ハンズオン（Kubernetesの上でnginxやConsul等）

紹介されているパターン

感想

  • ぼんやり思っていた概念に、名前与えられて言語化できた気がする。思考の節約や議論の共通化に良さげ
    • 一章に記載されている、パターンとして学ぶことのメリット
  • 「オーナーシップ」の章を読むと、分散システムで（正しく）ロックするの大変だなーとの思い
    • 分散でなくても大変だろうけど
  • ワークキューの話でメッセージの重複（exactly-onceとか）の記載が（多分）無いのが意外。新しい概念なのかな？

「Software Engineering Daily:(1273)AWS with Pete Cheslock] 」聞いた

Podcast Software Engineering Daily
エピソード (#1273)AWS with Pete Cheslock |

# 1273~1277 |

公開 2021/06/7
トピック クラウド
ホスト Corey Quinn（代理ホスト） |

ゲスト Pete Cheslock(#1273, AWS回)、Allmaの人

コンテキスト

聞き取ったこと

  • JEDIの話
  • サービス・アップデートが多いのでついていくの大変
    • どれが重要なのか
  • AWSの開発スピード
    • 早いし、顧客が多いのでフィードバックも多くもらえる
    • フィードバックの聞き取りどうしてるんだろうね。アカウントマネージャだとスケールしないのでは
    • 最初の方は駄目なこともあるので、後で検討する時は、思い出すのではなく、再度確認すること大事
  • 製品をdeprecationしないのがすごい
    • 放置はするけど、deprecationにはならない
    • SimpleDBと古いインスタンスクラスが例
  • Two Pizza teamの文化が強い
    • 製品で画面が違うのはこのせい
  • 歴史の話
    • S3の登場はすごかったが、みんなが理解するのに時間がかかった
    • 最初の頃は競合いなかった
    • データの移動は難しいので、最初にS3にデータをどんどん入れさせることで、AWSからの移行の可能性が下がった
  • "old guard enterprise"の話。Microsoftが強いね
    • ストーリの伝え方
    • 40年に渡る存在感と、欠陥を誤り続けた経験、ActiveDirectoryなど
      • 壊れる時は壊れる

「Software Engineering Daily:(#1277)Oracle Cloud with Salman Paracha」聞いた

Podcast Software Engineering Daily
エピソード (#1277)Oracle Cloud with Salman Paracha
# 1273~1277
公開 2021/06/11
トピック クラウド
ホスト Corey Quinn（代理ホスト）
ゲスト Salman Paracha（Oracle回）、OracleのGroup Vice Presidentの人

コンテキスト

聞き取ったこと

  • ゲスト（Salman Parachaさん）は元々AWSの人、今はOracleの「Group Vice President, Cloud Engineering Cloud」
  • 「second generation cloud」の話
    • Oracleの用語っぽい
    • レガシーなソフトウェアを使っている顧客が移行しやすい点を重視
    •  オンプレからlift and shiftの例として、L2レイヤーの話
  • 費用のメリット話
  • Oracle Cloud顧客の例
    • VMWareのユーザ
    • HPC
    • Independent Software Vendor(Zoom)
  • Oracle Cloudの投資の話
    • AWS/Azure/GCPが「multiple tens of billions」を四半期に設備投資しているが、Oracleはしていないのでは？とのツッコミ
  • オンプレ移行の話
    • 冗長性を維持しつつ、小さな規模で初めて、線形にスケールできる
    • 規制やレイテンシでクラウド移行が難しい顧客のために、Oracle Cloud一式をデータセンターに配置することもできる

  • データセンターにOracle Cloudを配置する Cloud@Customerの話

    • 2000平方フィート（185平方メートル）、50万ワットをデータセンター内に確保してくれれば、Oracle Cloudのリージョン一式を持ってこれる      

      感想

  • エンタープライズ企業・オンプレからの移行の話題が、他のクラウド回より多い印象

  • 「linearly scale」という用語が頻繁にでてきた。何かアピールポイントなのかな
  • 全般的にOracleに対する当たりが強い
    • 「Oracle, one of the most hated names in tech in some ways」
    • 「People will complain about Oracle, the overall company, without any provocation. And let's be honest, a lot of this is very well deserved」        

「 Technology never has an off-season 」聞いた

Podcast The Cloudcast
エピソード Technology never has an off-season
# 515
公開 2021/05/16
トピック キャリア
ゲスト なし（ホストだけ？）
ゲストの肩書

聞き取ったこと

概要

  • テクノロジー業界は「off-season」ないから大変だよね
    • （技術の変化が止まらないくらいのニュアンス？）
  • 「off-season」が無い理由
  • 「off-season」が無いことへの対処
    • 健康第一
    • 意図的に無視する領域を作る
    • 勉強する価値があるかを評価する
    • 勉強のためだけのサイドブロジェクト
    • 無視することに決めた後、それを評価して精度を上げる
    • 他の人とつながる。メンターとかグループ

感想

  • コロナ下だと、特に意識的休むこと大事だと思った
    • ネットの繋がりだけだと強い人だけ可視化されるので、特にメンタル弱りそう
  • 技術領域の話、t-wadaさんの話をなんとなく思い出した

Making Spark Cloud Native At Data Mechanics - Episode 184聞いた

podcast
Podcast Data Engineering Podcast
エピソード Making Spark Cloud Native At Data Mechanics - Episode 184
公開 2021/05/07
トピック Spark
ゲスト Jean-Yves Stephan さん
ゲストの肩書 DataMechanicsのCEO・創業者

聞き取ったこと

概要

DataMechanicsが提供するもの

  • 色々な「knob」（設定項目？）があるのでSparkの設定が難しい。DataMechanicsはチューニングしたコンテナイメージを提供
    • また、パッケージ間の依存関係を気にする度合いが少なくなる
  • オンプレだとクラスタが固定だけど、DataMechanicsではオートスケールを提供しているので、コスト削減につながる
  • モニタリング用のダッシュボード
    • ちなみにOSS
  • AirflowやJupyuterからの操作

気になる