Clever Geek Handbook

Sparkアプリケーションコード管理





プロジェクトの複雑さが時間の経過とともに増大するのを防ぐために、アプリケーションコードを構築するための多くのアプローチがあります。たとえば、オブジェクト指向のアプローチと多くの添付パターンにより、プロジェクトの複雑さを同じレベルに維持しなくても、少なくとも開発中にプロジェクトを制御し、チームの新しいプログラマーがコードを利用できるようにすることができます。



SparkでETL変換プロジェクトの複雑さをどのように管理できますか？



それほど単純ではありません。



実生活ではどのように見えますか？顧客は、店頭を収集するアプリケーションを作成することを提案します。 Spark SQLを使用してコードを実行し、結果を保存する必要があるようです。開発中に、このマートを構築するには20のデータソースが必要であることが判明しました。そのうち15は類似しており、残りはそうではありません。これらのソースを組み合わせる必要があります。さらに、それらの半分については、独自のアセンブリ、クリーニング、および正規化の手順を作成する必要があることがわかりました。



そして、詳細な説明の後、単純なショーケースは次のようになります。







その結果、Sparkでショーケースを収集するSQLスクリプトを実行するだけの単純なプロジェクトは、独自のコンフィギュレータ、多数の構成ファイルを読み取るためのブロック、独自のマッピングブランチ、いくつかの特別なルールのトランスレータを取得します。等



プロジェクトの途中で、作成者だけが結果のコードをサポートできることがわかりました。そして彼はほとんどの時間を思考に費やしています。一方、顧客は、数百のソースに基づいて、さらにいくつかのショーケースを収集するように求めています。同時に、Sparkは一般的に独自のフレームワークの作成にはあまり適していないことを覚えておく必要があります。



たとえば、Sparkは、コードを次のように表示するように設計されています（疑似コード）。 



park.sql(“select table1.field1 from table1, table2 where table1.id = table2.id”).write(...pathToDestTable)


代わりに、次のようなことを行う必要があります。 



var Source1 = readSourceProps(“source1”)
var sql = readSQL(“destTable”)
writeSparkData(source1, sql)


つまり、コードのブロックを個別のプロシージャに移動し、設定によってカスタマイズできる独自のユニバーサルなものを作成しようとします。



同時に、プロジェクトの複雑さはもちろん同じレベルのままですが、プロジェクトの作成者だけが、そして短時間だけです。招待されたプログラマーは習得するのに長い時間がかかります。主なことは、SQLだけを知っている人々をプロジェクトに引き付けることはできないということです。



Spark自体は、SQLしか知らない人のためにETLアプリケーションを開発するための優れた方法であるため、これは残念なことです。



そして、プロジェクトの開発の過程で、単純なものが複雑なものに変わったことがわかりました。

ここで、写真のように数十、場合によっては数百ものストアフロントがあり、さまざまなテクノロジーを使用している実際のプロジェクトを想像してみてください。たとえば、XMLデータの解析に基づくものと、ストリーミングデータに基づくものがあります。



どういうわけか、プロジェクトの複雑さを許容できるレベルに保ちたいと思います。これはどのように行うことができますか？

解決策は、開発環境が決定したときにローコードのツールとアプローチを使用することです。これはすべての複雑さを取り、この記事で説明するような便利なアプローチを提供し ます。



この記事では、この種の問題を解決するためにツールを使用することのアプローチと利点について説明します。特に、Neoflexは独自のソリューションNeoflexDatagramを提供しています 、さまざまな顧客によって正常に使用されています。



しかし、そのようなアプリケーションを常に使用できるとは限りません。



何をすべきか？



この場合、必要に応じて、従来はOrc-Object Spark、またはOrkaと呼ばれるアプローチを使用します。



初期データは次のとおりです



。PythonまたはScalaコードを開発するためのHue、HiveまたはImpalaを介したSQLデバッグ用のHueエディター、およびOozieワークフローエディターの標準ツールセットがある職場を提供する顧客がいます。これはそれほど多くはありませんが、問題を解決するには十分です。さまざまな理由により、環境に何かを追加したり、新しいツールをインストールしたりすることはできません。



では、ETLアプリケーションをどのように開発しますか。これは、通常どおり、複雑さに溺れることなく、書きすぎずに、数百のデータソーステーブルと数十のターゲットマートが参加する大規模なプロジェクトに成長します。



問題を解決するために、いくつかの規定が使用されます。それらは独自の発明ではありませんが、Spark自体のアーキテクチャに完全に基づいています。



  1. すべての複雑な結合、計算、および変換は、SparkSQLを介して行われます。Spark SQLオプティマイザーはリリースごとに改善され、非常にうまく機能します。したがって、SparkSQLを計算するすべての作業をオプティマイザに渡します。つまり、コードはSQLチェーンに依存しており、ステップ1でデータを準備し、ステップ2で結合し、ステップ3で計算します。
  2. Spark, Spark SQL. (DataFrame) Spark SQL.
  3. Spark Directed Acicled Graph, , , , , 2, 2.
  4. Spark lazy, , , .


その結果、アプリケーション全体を非常に簡単にすることができます。



データソースの単一レベルのリストを定義するための構成ファイルを作成するだけで十分です。このデータソースの順次リストは、アプリケーション全体のロジックを説明するオブジェクトです。



各データソースには、SQLへのリンクが含まれています。現在のソースのSQLでは、Hiveにはないが、現在のソースの上の構成ファイルに記述されているソースを使用できます。



たとえば、ソース2をSparkコードに変換すると、次のようになります（疑似コード）。 



var df = spark.sql(“select * from t1”);
df.saveAsTempTable(“source2”);


そして、ソース3はすでに次のようになっている可能性があります。 



var df = spark.sql(“select count(*) from source2”)
df.saveAsTempTable(“source3”);


つまり、ソース3は、それ以前に計算されたすべてのものを参照します。



また、ターゲットショーケースであるソースの場合、このターゲットショーケースを保存するためのパラメーターを指定する必要があります。



その結果、アプリケーション構成ファイルは次のようになります。 



[{name: “source1”, sql: “select * from t1”},
{name: “source2”, sql: “select count(*) from source1”},
...
{name: “targetShowCase1”,  sql: “...”, target: True, format: “PARQET”, path: “...”}]


そして、アプリケーションコードは次のようになります。 



List = readCfg(...)
For each source in List:
 df = spark.sql(source.sql).saveAsTempTable(source.name)
 If(source.target == true) {
    df.write(“format”, source.format).save(source.path)
 }


実際、これはアプリケーション全体です。一瞬を除いて、他に何も必要ありません。



これをすべてデバッグする方法は？



結局のところ、この場合のコード自体は非常に単純で、何をデバッグする必要がありますが、実行されていることのロジックを確認するとよいでしょう。デバッグは非常に簡単です。すべてのアプリケーションを調べて、チェック対象のソースに到達する必要があります。これを行うには、Oozieワークフローにパラメーターを追加して、スキーマとコンテンツをログに出力することにより、必要なデータソースでアプリケーションを停止できるようにします。



このアプローチは、すべてのアプリケーションロジックがSparkコードから分離され、アプリケーション記述オブジェクトである単一の非常に単純な構成ファイルに格納されるという意味で、オブジェクトスパークと呼ばれています。



コードはシンプルなままで、一度作成すると、SQLしか知らないプログラマーを使用して複雑なストアフロントを開発できます。



開発プロセスは非常に簡単です。最初は、経験豊富なSparkプログラマーが関与し、ユニバーサルコードを作成します。次に、そこに新しいソースを追加して、アプリケーション構成ファイルを編集します。



このアプローチが与えるもの：



  1. 開発にSQLプログラマーを参加させることができます。
  2. Oozieのパラメーターを指定すると、そのようなアプリケーションのデバッグは簡単になります。これは、中間ステップのデバッグです。アプリケーションは、すべてを目的のソースまで処理し、計算して停止します。
  3. ( … ), , , , , . , Object Spark;
  4. , . . , , , XML JSON, -. , ;
  5. . , , , , .


More articles:


All Articles