私の名前はジェームズ・ローワンです。MITで数学を学ぶ3年生です。夏休みはedXの分析チームでインターンとして働き、 データパイプライン分析チームは、edXのコースチーム、研究者、そして社内チームが利用できるデータと指標を提供しています。この夏の私の仕事は、マーケティングチームと経営陣向けの社内レポート作成に使用されるHP Verticaデータベースであるデータウェアハウスの改善に集中しました。
データウェアハウスの拡張
私の最初のプロジェクト コースの科目領域に関する情報をデータウェアハウスに追加するという目標がありました。当初のウェアハウススキーマでは、アナリストはコースごとに登録状況や活動状況のメトリクスを照会できましたが、科目領域ごとにコースを集計・比較する方法がありませんでした。ウェアハウスにコースの科目領域情報があれば、例えばマーケティングチームはどの科目領域の認定資格取得率が最も高いかを把握でき、他のアナリストは科目領域ごとの受講パターン（数学コースでは多くの学習者が問題に取り組む傾向があるのに対し、人文科学コースではディスカッションフォーラムの利用が多いなど）を尋ねることができます。
このタスクを実行するには、まず ルイジオープンedXパイプラインが使用するデータ処理フレームワークです。LuigiはSpotifyが開発したオープンソースのPythonデータ処理フレームワークで、データ処理ワークフローをそれぞれ独自の出力を持つ一連のタスクに分割します。これにより、依存関係の処理が簡素化され、中間ステップが失敗した場合でもワークフローを再開できます。このLuigiの特性により、私たちは可能な限りモジュール化されたワークフローを目指すことができます。
コース科目領域のワークフローには 3 つの部分があります。
- コール コースカタログAPIには、サイトで販売されているすべてのコースのリストと、その科目、インストラクター、長さなどの情報が含まれています。
- API の出力をタブ区切り値のファイルに解析します。各行には、コース ID、コースの科目領域、および追加情報が含まれます。
- このサブジェクト領域のデータを Vertica データベースにロードします。
上記で特定したこのプロセスの3つの異なるフェーズは、Luigiタスクに自然に反映され、最初の2つは比較的簡単に作成できました。3つ目はより興味深いものでした。LuigiにはMySQLデータベースへのロード用のタスクがあらかじめ用意されていますが、Vertica用のロードタスクはあらかじめ用意されていませんでした。そのため、まずはVerticaをバルクロードする汎用的なLuigiタスクを作成する必要がありました。この汎用バルクローダーは、夏の間、他のチームメンバーによって使用されました。パイプラインのこの部分を所有できたことは、私にとって大きな喜びでした。この部分は、社内の分析ウェアハウスをさらに拡張するための将来のワークフローの基盤となるでしょう。
次のグラフは、このプロジェクトのおかげでアナリストが回答できるようになった質問の例を示しています。edx.orgのコースでアクティブな学習者のうち、特定の分野のコースでアクティブな学習者の割合を示しています。2014年秋には、アクティブな学習者の約10%がコンピュータサイエンス、ビジネス、データ分析、人文科学の各コースでアクティブでした。しかし、2015年には、edx.orgのコースでアクティブな学習者のうち、コンピュータサイエンスのコースでアクティブな学習者の割合が大幅に増加しました。2015年6月には、edx.orgのアクティブな学習者のほぼ半数がコンピュータサイエンスのコースでアクティブでした。表示されている他の3つの分野でも、アクティブユーザーの間で人気が高まり、それぞれ20%に上昇しました。
サブジェクトエリアプロジェクトの後、私は製品分析のための実験的な機能に取り組みました。動画の再生から問題の解答、ユーザープロフィールの編集まで、プラットフォームにおけるすべてのユーザーインタラクションが分析のために記録されます。新機能が追加されイベントが発行され始めると、製品チームはその機能がどのくらいの頻度で使用されているか、あるいはデスクトップブラウザでの使用率が不均衡に高い（モバイル互換性に問題があることを示唆している）かどうかを把握したいと考えるかもしれません。分析チームが新機能に関する追跡ログ情報を集約するためのパイプラインワークフローを構築するのを待つのではなく、製品チームやその他のチームがイベントログの予備分析を自ら行えるようにする必要があります。
イベントログを直接クエリする際の難しさは、イベントログが半構造化されており、JSON形式で保存されていることです。イベントの種類によって属性が異なるため、イベント用の単一のテーブルスキーマを作成しようとすると扱いにくくなります。そこで、 Verticaのフレックステーブル そして、ほぼすべてのイベントに共通するフィールド（ユーザー名、タイムスタンプ、ユーザーのデバイスタイプなど）をマテリアライズド列（ファーストクラスSQLテーブル列）で表すテーブルスキーマを選択しました。同時に、ユーザーがイベント固有のフィールド（ユーザーが現在閲覧している動画内のタイムスタンプなど）をクエリできるようにしました。これが今後の製品分析のフレームワークになるかどうかは分かりませんが、ウェアハウスの機能を探る上で役立ちました。
BIデータ処理をパイプラインに統合する
私がこの夏edXで働き始めたとき、私たちは基本的に2つの別々のパイプラインを持っていました。1つはInsightsで使用される講師向けデータ用（Open edXの分析ダッシュボード）と社内のビジネスインテリジェンス（BI）レポート用のパイプラインがあります。外部向けデータ用のパイプラインはLuigiで記述されており、バッチHadoopジョブを使用して結果ストアにデータを入力します。 データAPI一方、内部レポート用のパイプラインでは、Pentaho Data Integrationを使用してLMSと結果ストアからデータを抽出し、変換してウェアハウスにロードしています。BIパイプラインはメインパイプラインの一部の結果に依存していましたが、これらの依存関係をメインパイプラインに伝達できなかったため、チームはJenkinsビルドサーバー上でタスクの実行時間を慎重に調整する必要があり、依存関係の処理にLuigiを使用する本来の目的が達成されませんでした。
データ フローの 2 つの分離したパスを持つ古い分析パイプライン アーキテクチャ。
2つのシステムを維持することに伴う技術的負債を軽減するために、私は次のような課題に取り組みました。 PentahoタスクからLuigiタスクへの移行を開始単一のデータ処理フレームワークへの移行による明らかなメリットに加え、この取り組みはデータウェアハウスのさらなる改善への道を開きます。この新しいアーキテクチャでは、ウェアハウスへのすべての書き込みがパイプラインを介して行われるため、新しいデータ処理タスク（上記の私のコースの科目領域のタスクなど）は、Pentahoのデータ読み込みステップに合わせて手動でスケジュールを設定することなく、ウェアハウスへの書き込みが可能になります。統合されたデータ処理ワークフローはデータ検証も容易にします。Luigiタスクを統合パイプラインに追加するだけで、データ検証タスクを処理ステップに組み込むことができます。
Pentaho 廃止後の内部分析 (BI) アーキテクチャが完了しました。
このプロジェクトでは、パイプラインのテクノロジースタック全体を扱うことができました。MySQL LMSデータベース、イベントトラッキングログ、Apache Hive中間結果ウェアハウス、そして完成したVerticaデータプロダクトウェアハウスと連携するタスクを作成する機会に恵まれ、夏の間に習得してきたスキルを結集させる良い機会となりました。
結論
この夏、edXで働く機会を得て大変嬉しく思っています。このインターンシップでは、Luigiフレームワーク、MapReduceパラダイム、SQL、Gitといった様々な技術スキルを習得することができました。また、アナリティクスチームに所属することで、データ処理アーキテクチャの設計、大規模コードベースの保守、ソフトウェアおよびデータ製品の開発サイクルを直接体験することができました。アジャイルチームで働くことを学ぶことは、幅広い応用が利くスキルであり、仕事以外の環境におけるグループダイナミクスやプロジェクトマネジメントについて、より意識的に考えるようになりました。
技術的なパイプラインの質問に回答してくれた John Baker、Gabe Mulley、Brian Wilson、素晴らしい作業環境を提供してくれた分析チームの他のメンバー、そしてこの夏を楽しいものにしてくれた edX の全員に感謝します。
