Google Summer of Codeは私にとって素晴らしい学習経験でした。オープンソースに貢献し、Apache Beamの内情を学び、世界最高のエンジニアと協力することができました。

モチベーション

2人の友人が2018年にGSoCに参加していました。彼らの経験に興味を持ちました。世界中の開発者が潜在的に使用できるオープンソースソフトウェアに取り組みながら、その分野で最高のメンターから指導を受けるという考えは、刺激的でした！そこで、今年はGoogle Summer of Codeに挑戦することにしました。

Google Summer of Codeとは？

Google Summer of Codeは、Googleが主催するグローバルプログラムで、学生をオープンソースソフトウェア開発の世界に紹介することを目的としています。学生は、大学の休暇中にオープンソース団体と協力して、3ヶ月間のプログラミングプロジェクトに取り組みます。

Apache Beamを選んだ理由

Atlanでのインターンシップ中に、データエンジニアリングの分野を発見しました。そこで出会ったエンジニアの課題と議論に興味を持ちました。「Streaming Systems」という書籍を調査中に、バッチとストリーミングシステムの統一モデルであるApache Beamに出会い、魅了されました。データエンジニアリングを探求したかったので、GSoCではその分野のプロジェクトに取り組みたいと思いました。インターンシップの終わり頃には、Apache Airflow（非常に優れたプロジェクト）とApache Beamへの貢献を始め、どちらかがGSoCに参加してくれることを期待していました。そして幸運にも実現しました！

また、SpotifyのDiscover WeeklyもApache Beamを使用しています！

準備

Streaming Systemsの本は既に読んでいたので、Beamの基礎となる概念は理解していましたが、実際にはBeamを使ったことはありませんでした。提案を提出する前に、Beamについての具体的な理解を確実にするために、多くのリソースを調べました。Tyler AkidauによるStreaming 101とStreaming 102のブログ記事を読みました。これらは、Beamのバッチとストリーミングの統一モデルを紹介するのに最適です。さらに、YouTubeのすべてのBeamに関する講演を視聴しました。Beamのウェブサイトで見つけることができます。Beamには本当に優れたドキュメントがあります。プログラミングガイドはBeamのすべての概念を非常に分かりやすく説明しています。Beamの実行モデルも詳細に記述されており、Beamがどのようにデータを処理するかを理解するために必読です。waitingforcode.comにも、Beamの概念に関する優れたブログ記事があります。Beamのコードベースをより良く理解するために、実際に使用していくつかのPRに取り組み、テストスイートとワークフローに慣れました。

GSoCの道のり

GSoCには2つのフェーズがあります。最初のフェーズはコミュニティ・ボンディング期間で、学生はプロジェクトとコミュニティに慣れます。もう1つのフェーズは実際のコーディング期間で、学生は自分のプロジェクトに取り組みます。コーディング期間には1ヶ月ごとに3回の評価があるので、実装、テスト、ドキュメントまたは改善に焦点を当ててプロジェクトを3つの部分に分割しました。

プロジェクト

私のプロジェクト(BEAM-6611)は、ストリーミングパイプラインにBigQueryにデータを挿入するファイルロード方式のサポートを追加しました。これは、バッチパイプラインでファイルロード方式を使用してBigQueryへの書き込みをPython SDKに追加したBEAM-6553のPR - #7655に基づいています。デフォルト以外のウィンドウ処理、トリガー、蓄積モードを使用するストリーミングパイプラインは、ファイルロード方式を使用してBigQueryにデータを書き込むことができます。失敗した場合、パイプラインはアトミックに失敗します。つまり、各レコードは最大1回BigQueryにロードされます。私の提案はこちらにあります。

コミュニティ・ボンディング期間

GSoCが始まったとき、まだ期末試験が終わっていませんでした。その結果、あまり作業を進めることができませんでした。Python SDKの3つのPTransform（Latest、WithKeys、Reify）に取り組みました。

コーディング期間I

この期間では、ストリーミングモードでストリーミング挿入を使用してBigQueryシンクの統合テストをいくつか記述しました。私のプロジェクトの失敗している統合テストに取り組みました。また、プロジェクトの実装を完了しました。しかし、PostCommitテストの1つがパスしませんでした。BigQueryの結果をクエリする統合テストのマッチャーは、バッチモードで使用されることを意図していることに気付きました。そこで、ストリーミングモードで動作するマッチャーのバージョンを作成しました。

コーディング期間II

ストリーミングモードのマッチャーを追加した後でも、PostCommitテストはパスしませんでした。指定されていないテストも実行されていました。失敗の原因をnose(Pythonテストフレームワーク)のマルチプロセスプラグインの制限に絞り込みました。そのため、指定されたよりも多くのテストが見つかりました。これを見つけるのにしばらく時間がかかりました。この期間中に、私のプロジェクトの変更がマージされました。また、テスト関連の小さな問題にも取り組みました。

この期間は、いくつかのエキサイティングな出来事がありました。

• apache/beamのトップ100貢献者に入りました。
• オープンソースプロジェクトでの初めてのPRレビューでした。

コーディング期間III

これはプログラム終了前の最後のコーディング期間でした。私のプロジェクトは予想よりも早くマージされたため、メンターは同じ分野（BigQueryIO）の別の問題(BEAM-7742)を提案し、興味深い問題だと思いました。そこで、BigQueryに書き込まれたファイルをパーティション分割して、トリガーされるすべてのロードジョブがBigQueryに対して指定されたロードジョブサイズの制限に準拠するようにしました。プロジェクトに取り組んでいる間は、変更を検証するために、PubSubをソースとしてBigQueryをシンクとして使用するパイプラインを使用していました。メンターは、BigQueryIOの究極のテストとなるため、Beamのテストスイートに追加することを提案しました。また、このテストをBeamに追加する作業にも取り組みました。

私が取り組んだPRのリストはこちらにあります。

結論

GSoCは私にとって規律と目標設定のレッスンでした。何をどのように行うかを決めることは重要なレッスンでした。リモートで作業したことがなかったので、これは新しい経験でした。最初は苦労しましたが、それがもたらす柔軟性を高く評価しています。また、Apache Beamの内情や、同じエコシステム内の他のツールについて学ぶのもとても楽しかったです。これは、テストファーストのアプローチでコードを書いた初めての経験でもありました。

メンターのPablo Estrada氏、Apache Beam、Apache Software Foundation、そしてGoogle Summer of Codeにこの機会を与えてくれたことに感謝します。また、必要なことすべてを助けてくれたメンターと、サポートして励ましてくれたApache Beamコミュニティにも感謝しています。

適切な努力、忍耐力、確信、そして計画があれば、何でも可能です。何でも。