OSS Consortium


 

日本語 | English

開発基盤部会 Blog

開発基盤部会 Blog >> Article details

2021/11/08

.NET for Apache Sparkで見えた、配管工おじさん入門への道(4)

Tweet ThisSend to Facebook | by nishino
 前回(1)の続きになりますが、その前回(1)で、タイトルにある「.NET for Apache Spark」は一旦、吹き飛んでしまって、PySparkを使っての技術検証を粛々と進めていますが、お陰様で(?)、Databricks上でKafKaと連携したSpark Structured Streaming的なモノを動かせたような気がします(現時点で、標準出力での出力を確認できてませんがw)。

 ソコで、気が付いた事は、既に前回(2)で書いたんですが、昨今の生産技術の施策、「BFマーケティング → コンセプト設計(ココが肝) → 情報展開 → FEニーズとの適合度合いを測定。」と言う流れを念頭にプロジェクト選定した方が良いんじゃないか?なんて思ったりしました。

 そして、「オーケストレーター(パッケージャ」~「パーソナルエージェント(購買代理業者」辺りに、どのようにポジショニングして行くか?という点が、パーソナルエージェント寄りということもあると思いますが、弊部会が「繋ぎ目部会」と別称を名乗っているのも納得で、「より、繋ぎ目が重要になってきている。」と思います(上記のコンセプト設計も、この繋ぎ目と言うキーワードを意識した内容になる)。

 ...と言うのも、今回の検証、やはり、世間で騒がれているキーワード(≒ ハズワード)に照らし合わせると、どうしても Spark が中核に見えるんですが、全体をやってみると、重要なのは、クラウドやDockerを用いたIaCだったなぁ。...感が強いんですよね。

 要するに、適切に試せる環境を迅速に作成する方が重要だったように思います。そして、初めて使うコネクタ系のライブラリに、認証オプションを加えて疎通を通すと言う苦行を如何にサクッと完遂させるか?がある意味テーマと言えるように思いました。

 もちろん、Spark SQLやDataFrame API、Spark Structured Streamingについての理解を深めることも重要ですが、コレは、専門業者のサポートを受けたりすることでワリとなんとかなると思うんですよね(スタックは簡単でコラボレーションが難しい)。現在のRDBMSというプロダクトの分業のあり方なんかを見ているとそう思います。

 ...で、ココまでやって、漸くテンプレートが作成されるに到るのですが、テンプレートの段階で十分複雑なので、恐らく、ココに到達するまでに、環境構築や開発物のビルド&デプロイもある程度、自動化されていると思います。そして、ココから更に、DevOps Pipelineに乗せるとか、そう言う感じの事をヤって行くと言うのもアリだと思います。

 で、...ですね、最後になりますが、ここ最近の投稿で、既に、言及しましたが、問題は、この、世間の認知から若干、乖離した「繋ぎ目」をどうやって予算化するか?と言う話になります。確かに、「DX 系 DataPipeline の開発を DevOps Pipelineに乗せて行くタメの各種リサーチ」って言っても販社や受託の頃のVC(バリュー・チェーン)と同じ認識の人達には意味が解らないですから。なので、AIとかノーコードとか言って騙すしか無くなってくるんですが(≒ バズ単品問題)、コレだとココからブレークダウンする際に誤解を生んでしまって上手く行きません(と言うか、実際は、考えてないからバズ単品で妥協するんで、ココでの誤解は、そう言う人達にとっては誤解ではないんでしょうね)。

 なんとなくですが、この問題、伝言ゲームの中間で起こっているようなので、なんだかんだ言って、「天地人」を待つしか無いのかもしれませんが、「モノ売りからコト売りへ」(モノ=バズ単品から、コト=組立てられた価値)と言う変化が、配管工おじさんの更なる多能工化(マーケティング、企画、プログラム・マネジメント、開発)の追い風になっている気がします。
09:00 | Impressed! | Voted(0) | Comment(0) | ご報告