Python+ビッグデータコンピューティングプラットフォーム、PyODPSアーキテクチャ構築

データ分析と機械学習

ビッグデータは基本的に、実際にはJava環境であるHadoopシステムのエコシステム上に構築されています。多くの人はデータ分析に Python と R を使用することを好みますが、これは多くの場合、小さなデータの問題やローカル データ処理の問題に対応します。 2 つをどのように組み合わせてより大きな価値を持たせるか? Hadoop の既存のエコシステムと既存の Python 環境を上の図に示します。

MaxCompute

MaxCompute は、オフライン コンピューティング用のビッグ データ プラットフォームで、TB/PB レベルのデータ処理、マルチテナンシー、すぐに使用できる機能、およびセキュリティを確保するための分離メカニズムを提供します。 MaxCompute の主な分析ツールは SQL です。SQL は非常にシンプルで使いやすく、説明的です。トンネルは、SQL エンジンによるスケジュールを必要とせずに、データのアップロードおよびダウンロード チャネルを提供します。

Pandas

Pandas は、numpy に基づくデータ分析ツールです。最も重要な構造は、一連の描画 API を提供する matplotlib の操作であり、Python サードパーティ ライブラリとの対話が非常に簡単です。 。

PyODPS アーキテクチャ

PyODPS はビッグ データ分析に Python を使用しており、そのアーキテクチャは上の図に示されています。最下層は基本 API で、MaxCompute 上のテーブル、関数、リソースを操作するために使用できます。上記の DataFrame フレームワークは 2 つの部分で構成されており、1 つはフロントエンドで、ユーザーが記述したコードは通常の言語と同じ式ツリーに変換されます。ユーザーは機能をカスタマイズし、サードパーティのライブラリを視覚化し、操作することができます。バックエンドの下部にはオプティマイザーがあり、式ツリーを最適化するために使用されます。 ODPS とパンダは両方とも、コンパイラーとアナライザーを通じて実行するためにエンジンに送信されます。

背景

なぜ DataFrame フレームワークを構築するのですか?

ビッグ データ分析ツールでは、式、API、構文、プログラミング言語がシンプルで直観的であるか、データ、ストレージが可能か、という 3 つの次元の問題に直面することになります。メタデータは圧縮され、効果的ですか? エンジンと計算のパフォーマンスは十分ですか? したがって、パンダと SQL の 2 つの選択肢に直面することになります。

上の図に示すように、パンダは非常に優れた表現力を持っていますが、そのデータはメモリにのみ配置でき、エンジンはスタンドアロンのマシンであり、マシンのパフォーマンスによって制限されます。 SQL の表現力には限界がありますが、データ量が少ない場合にはエンジンのメリットがありませんが、データ量が多くなるとエンジンが非常に有利になります。 。 ODPS の目標は、両方の利点を組み合わせることです。

PyODPS DataFrame

PyODPS DataFrameはPython言語で書かれており、Pythonの変数や条件判定、ループなどが利用できます。表現力を高めるために、パンダのような構文を使用して独自のフロントエンドのセットを定義できます。バックエンドは、訪問者の設計パターンであり拡張可能なデータ ソースに基づいて特定の実行エンジンを決定できます。実行全体が遅延し、ユーザーがすぐに実行されるメソッドを呼び出さない限り、直接実行されません。

上の図からわかるように、構文はパンダに非常に似ています。

式と抽象構文ツリー

上の図から分かるように、ユーザーは元の Collection から GroupBy 操作を実行し、次に列選択操作を実行します。一番下は Source の Collection です。 2 つのフィールド、つまり種が取得されます。これらの 2 つのフィールドは By 操作によって実行され、pental_length は集計値を取得するための集計操作に使用されます。 Species フィールドを直接取り出し、最も短いフィールドを 1 つ追加します。

オプティマイザー (操作のマージ)

バックエンドは、最初にオプティマイザーを使用して式ツリーを最適化し、最初に GroupBy を実行し、次に操作のマージを通じて、petal_length を集計操作のために削除できます。最後に、GroupBy のコレクションが形成されます。

オプティマイザー(列プルーニング)

ユーザーが 2 つのデータ フレームを結合し、データ フレームから 2 つの列を取得する場合、データ フレームがビッグ データ環境に送信される場合、すべての列が使用されるわけではないため、このようなプロセスは非常に非効率的です。したがって、結合されている列は削除する必要があります。たとえば、データ フレーム 1 ではフィールドを 1 つだけ使用します。必要なのは、フィールドをインターセプトして射影を作成して新しいコレクションを形成することだけです。これはデータ フレーム 2 にも当てはまります。このようにして、これら 2 つの部分で検証操作を実行するときに出力されるデータの量を大幅に削減できます。

オプティマイザー (述語プッシュダウン)

2 つのデータ フレームが結合されてから個別にフィルター処理される場合、結合された入力の量を減らすために、このフィルター操作は実行のために一番下にプッシュダウンされる必要があります。

視覚化

は、ユーザーの視覚化を容易にするためにvisual()を提供します。右側の例でわかるように、ODSP SQL バックエンドは SQL 実行にコンパイルされます。

バックエンド

上の図からわかるように、コンピューティング バックエンドは非常に柔軟です。ユーザーは、pandas データ フレームに結合して、前のテーブルからの maxcompute データを作成することもできます。

Analyzer

Analyzer の役割は、特定のバックエンド用に一部の操作を変換することです。例:

value_counts などの一部の操作は pandas 自体によってサポートされているため、pandas バックエンドの場合は処理は必要ありません。ODPS SQL バックエンドの場合は実行する直接操作がないため、アナライザーが実行されると、 groupby + sort 操作として書き換えられます。

ODPS SQL にコンパイルするときに組み込み関数では完了できない演算子もあり、カスタム関数に書き換えられます。

ODPS SQL バックエンド

ODPS SQL バックエンドは SQL のコンパイルと実行をどのように実行しますか? コンパイラーは式ツリーを上から下まで走査して、Join または Union を見つけます。サブプロセスの場合は、再帰的にコンパイルします。特定の実行用のエンジンに関しては、Analyzer を使用して式ツリーを書き換え、トップダウンのサブプロセスをコンパイルし、ボトムアップで SQL 文をコンパイルします。最終的に、完全な SQL ステートメントが取得されます。送信すると、タスクが返されます。

pandas バックエンド

は、最初に式ツリーにアクセスし、次に式ツリー全体を走査した後に各式ツリー ノードの pandas 操作に対応します。エンジンの実行は DAG トポロジの順序で実行され、継続的にパンダの操作に適用され、最終的に結果が得られます。ビッグ データ環境の場合、pandas バックエンドの役割はローカル DEBUG を実行することであり、データ量が少ない場合は計算に pandas を使用できます。

困難と落とし穴

バックエンドのコンパイルエラーにより、コンテキストが失われやすくなります。複数の最適化と分析により、問題の原因となった以前の訪問ノードを特定することが困難になります。解決策: 各モジュールの独立性を確認し、テストを完了します。

バイトコードの互換性の問題については、maxcompute は Python 2.7 のカスタム関数の実行のみをサポートします。

ML 機械学習

機械学習は、データ フレームの入力と出力です。たとえば、iris データ フレームがある場合、まず名前フィールドを使用して分類フィールドを作成し、split メソッドを呼び出して、60% のトレーニング データと 40% のテスト データに分割します。次に、決定木を含む RandomForest を初期化し、train メソッドを呼び出してトレーニング データをトレーニングし、predict メソッドを呼び出して予測データを形成し、segments[0] を呼び出して視覚的な結果を確認します。

将来の計画

分散 numpy、DataFrame は分散 numpy バ​​ックエンドに基づいており、

インメモリ コンピューティングによりインタラクティブなエクスペリエンスを向上させます。