分析プラットフォームでのローコードの適用

読者の皆様、良い一日を！



遅かれ早かれデータを蓄積および分析するためのITプラットフォームを構築するタスクは、知的にロードされたサービス提供モデルまたは技術的に複雑な製品の作成に基づいてビジネスを行う企業で発生します。分析プラットフォームの構築は、困難で時間のかかる作業です。ただし、どのタスクも単純化できます。この記事では、ローコードツールを使用して分析ソリューションを作成した経験を共有したいと思います。この経験は、Neoflex社のBig DataSolutionsの方向で多くのプロジェクトを実施する際に得られました。 2005年以来、NeoflexのBig Data Solutionsの方向性は、データストレージと湖の構築の問題に対処し、情報処理速度の最適化の問題を解決し、データ品質を管理するための方法論に取り組んできました。







弱くおよび/または高度に構造化されたデータの意図的な蓄積を回避することはできません。おそらく私たちが中小企業について話しているとしても。確かに、ビジネスを拡大するとき、有望な起業家はロイヤルティプログラムの開発の問題に直面し、販売ポイントの有効性を分析し、ターゲットを絞った広告について考え、付随する製品の需要に戸惑うでしょう。最初の概算として、問題は膝で解決することができます。しかし、ビジネスの成長に伴い、分析プラットフォームへの参入は依然として避けられません。



ただし、どの場合、データ分析タスクは「ロケットサイエンス」クラスのタスクに成長できますか？おそらく、本当に大きなデータになると、その瞬間に。

ロケットサイエンスのタスクを簡素化するために、象を少しずつ食べることができます。







アプリケーション/サービス/マイクロサービスの裁量と自律性が高いほど、あなた、同僚、およびビジネス全体が象を消化しやすくなります。



ほとんどすべてのクライアントがこの仮定に到達し、DevOpsチームのエンジニアリング慣行に基づいてランドスケープを再構築しました。



しかし、「分割された象」の食事をしていても、IT環境が過飽和になる可能性は十分にあります。この時点で、立ち止まって息を吐き、ローコードエンジニアリングプラットフォームに目を向ける価値があります。



多くの開発者は、コードの直接記述から、ローコードシステムのUIインターフェイスの矢印の「ドラッグ」に移行するときに、キャリアの行き詰まりの可能性に恐れを感じています。しかし、工作機械の出現はエンジニアの失踪につながるのではなく、彼らの仕事を新しいレベルに引き上げました！



その理由を理解しましょう。



ロジスティクス、テレコム業界、メディア研究、金融セクターのデータ分析は、常に次の質問に関連しています。

• 自動分析の速度。
• データ生成のメインフローに影響を与えることなく実験を実施する能力。
• 準備されたデータの信頼性。
• 変更の追跡とバージョン管理。
• データの証明、データの系統、CDC;
• 実稼働環境への新機能の迅速な提供。
• そして、その証拠：開発とサポートのコスト。

つまり、エンジニアには膨大な数の高レベルのタスクがあり、低レベルの開発タスクの心をクリアするだけで十分な効率で実行できます。



ビジネスの進化とデジタル化は、開発者が新しいレベルに移行するための前提条件になりました。開発者の価値も変化しています。自動化されたビジネスの概念を深く掘り下げることができる開発者は大幅に不足しています。



低レベルと高レベルのプログラミング言語に例えましょう。低レベルの言語から高レベルの言語への移行は、「鉄の言語での直接指示」の記述から「人々の言語での指示」への移行です。つまり、抽象化のレイヤーを追加します。この場合、高レベルのプログラミング言語からローコードプラットフォームへの移行は、「人の言語のディレクティブ」から「ビジネスの言語のディレクティブ」への移行です。この事実に悲しんでいる開発者がいるとすれば、おそらく配列ソート機能を使用するJava Scriptが生まれた瞬間からさえ、彼らは悲しんでいます。そしてもちろん、これらの機能には、同じ高レベルのプログラミングの他の手段による内部でのソフトウェア実装があります。



したがって、ローコードは、抽象化の別のレイヤーの出現にすぎません。

ローコード使用の応用経験

ローコードのトピックは非常に広いですが、ここで、私たちのプロジェクトの1つの例を使用して、「ローコードの概念」の適用アプリケーションについて説明したいと思います。



Neoflex社のBigData Solutions部門は、ビジネスの金融セクター、ストレージとデータレイクの構築、およびさまざまなレポートの自動化をより専門としています。このニッチでは、ローコードの使用が長い間標準になっています。その他のローコードツールには、ETLプロセスを整理するためのツール（Informatica Power Center、IBM Datastage、Pentaho Data Integration）が含まれます。または、データにアクセスして編集するためのインターフェイスを迅速に開発するための環境として機能するOracleApex。ただし、ローコード開発ツールの使用は、ベンダーに大きく依存する商用テクノロジースタックでのターゲットを絞ったアプリケーションの構築に常に関連しているわけではありません。



ローコードプラットフォームを使用して、データストリームのオーケストレーションを整理したり、データサイエンスプラットフォームを作成したり、データ品質管理モジュールなどを作成したりすることもできます。



ローコード開発ツールの使用経験の応用例の1つは、Neoflexとロシアのメディア研究市場のリーダーの1つであるMediascopeとのコラボレーションです。この会社のビジネス目標の1つは、広告主、インターネットサイト、TVチャネル、ラジオステーション、広告代理店、およびブランドが広告を購入し、マーケティングコミュニケーションを計画することに基づいて、データを作成することです。







メディア研究は、技術集約型のビジネス分野です。ビデオシーケンスの認識、表示を分析するデバイスからのデータの収集、Webリソースでのアクティビティの測定-これはすべて、企業に大規模なITスタッフがいて、分析ソリューションの構築に豊富な経験があることを意味します。しかし、情報の量、そのソースの数と多様性の指数関数的な成長により、ITデータ業界は絶えず進歩しています。すでに機能している分析プラットフォームMediascopeをスケーリングするための最も簡単なソリューションは、ITスタッフの増員である可能性があります。しかし、はるかに効率的な解決策は、開発プロセスをスピードアップすることです。この方向につながるステップの1つは、ローコードプラットフォームの使用である可能性があります。



プロジェクトの開始時点で、同社はすでに機能する製品ソリューションを持っていました。ただし、MSSQLでのソリューションの実装では、許容可能な改訂コストを維持しながら、機能を拡張するという期待に完全に応えることはできませんでした。



私たちの前の仕事は本当に野心的でした-MVPが作業開始日から第1四半期内にリリースされた場合、NeoflexとMediascopeは1年以内に産業用ソリューションを作成する必要がありました。



Hadoopテクノロジースタックは、ローコードコンピューティングに基づく新しいデータプラットフォームを構築するための基盤として選択されました。 HDFSは、寄木細工のファイルを使用したデータストレージの標準になりました。プラットフォーム内のデータにアクセスするために、Hiveが使用され、利用可能なすべてのストアフロントが外部テーブルの形式で表示されます。ストレージへのデータのロードは、KafkaとApacheNiFiを使用して実装されました。



この概念のlowe-code-toolは、分析プラットフォームを構築する際に最も労働集約的なタスク、つまりデータを計算するタスクを最適化するために使用されました。







ローコードのデータグラムツールが、データマッピングの主要なメカニズムとして選択されました。Neoflex Datagramは、変換とデータストリームを設計するためのツールです。

このツールを使用すると、Scalaコードを「手作業で」作成することを回避できます。Scalaコードは、モデル駆動型アーキテクチャのアプローチを使用して自動的に生成されます。



このアプローチの明らかな利点は、開発プロセスの加速です。ただし、速度に加えて、次の利点もあります。

• ソース/宛先のコンテンツと構造の表示。
• 個々のフィールド（系統）へのデータフローオブジェクトの起点を追跡します。
• 中間結果を表示する変換の部分的な実行。
• ソースコードを表示し、実行前に修正します。
• 変換の自動検証。
• 自動データロード1in1。

変換を生成するためのローコードソリューションを入力するためのしきい値は非常に低く、開発者はSQLを理解し、ETLツールの経験を持っている必要があります。コード駆動型変換ジェネレーターは、広義のETLツールではないことに注意してください。ローコードツールには、独自のコード実行環境がない場合があります。つまり、生成されたコードは、ローコードソリューションのインストール前でもクラスター上にあった環境で実行されます。そして、これはおそらく、ローコードカルマのもう1つのプラスです。 low-code-commandと並行して、「クラシック」コマンドが機能するため、たとえば、純粋なScalaコードで機能を実装します。両方のチームの作業を本番環境に取り込むのは簡単でシームレスです。



おそらく、ローコードに加えて、コードなしのソリューションもあることに注意する価値があります。そして本質的に、それらは異なるものです。ローコードを使用すると、開発者は生成されたコードを大幅に妨害できます。Datagramの場合、生成されたScalaコードを表示および編集することは可能ですが、コードなしではそのような機会が提供されない場合があります。この違いは、ソリューションの柔軟性だけでなく、データエンジニアの作業における快適さとモチベーションの観点からも非常に重要です。

ソリューションアーキテクチャ

ローコードツールが、データ計算機能の開発速度を最適化する問題の解決にどのように役立つかを正確に理解してみましょう。まず、システムの機能アーキテクチャを見てみましょう。この場合の例は、メディア研究のデータ生成モデルです。







私たちの場合のデータソースは非常に異質で多様です。

• (-) — - , – , , . – . Data Lake , , , . , , ;
• ;
• web-, site-centric, user-centric . Data Lake research bar VPN.
• , - ;
• -.

ソースシステムから生データのプライマリステージングへのロードの実装は、さまざまな方法で整理できます。これらの目的でローコードを使用すると、メタデータに基づいてロードスクリプトを自動的に生成できます。この場合、ソースからターゲットへのマッピングの開発レベルに下がる必要はありません。自動ロードを実装するには、ソースとの接続を確立してから、ロードするエンティティのリストをロードインターフェイスで定義する必要があります。 HDFSでのディレクトリ構造の作成は自動的に行われ、ソースシステムのデータストレージ構造に対応します。



ただし、このプロジェクトのコンテキストでは、MediascopeがNifi + Kafkaリンクで同様のサービスの作成にすでに独自に取り組んでいるため、ローコードプラットフォームのこの機会を使用しないことにしました。



これらのツールは互換性がなく、相互に補完的であることにすぐに注意する必要があります。 NifiとKafkaは、直接（Nifi-> Kafka）バンドルと逆（Kafka-> Nifi）バンドルの両方で機能します。メディア研究プラットフォームでは、最初のリンクが使用されました。







私たちの場合、ソースシステムからのさまざまなタイプのデータを処理して、Kafkaブローカーに送信する必要がありました。同時に、特定のKafkaトピックへのメッセージの送信は、PublishKafkaNifiプロセッサを使用して実行されました。これらのパイプラインのオーケストレーションとメンテナンスは、ビジュアルインターフェイスで行われます。 NifiツールとNifi + Kafkaバンドルの使用は、開発へのローコードアプローチとも呼ばれます。これは、ビッグデータテクノロジーへの参入のしきい値が低く、アプリケーション開発プロセスを加速します。



プロジェクトの実装における次の段階は、詳細データの単一のセマンティックレイヤーの形式への縮小でした。エンティティに履歴属性がある場合、計算は問題のパーティションのコンテキストで実行されます。エンティティが履歴ではない場合、オプションで、オブジェクトのコンテンツ全体を再計算するか、（変更がないために）このオブジェクトの再計算をまったく拒否することができます。この段階で、すべてのエンティティのキ​​ーが生成されます。キーは、マスターオブジェクトに対応するHbaseディレクトリに保存され、分析プラットフォームのキーとソースシステムのキーの間の対応が含まれます。アトミックエンティティの統合には、予備計算の結果による分析データの強化が伴います。データを計算するためのフレームワークはSparkでした。データを単一のセマンティクスに変換する説明された機能も、ローコードツールデータグラムのマッピングに基づいて実装されました。



ターゲットアーキテクチャでは、ビジネスユーザーにSQLデータアクセスを提供する必要がありました。このオプションにはハイブが使用されました。low-code-toolで[RegistrHive Table]オプションを有効にすると、オブジェクトがHiveに自動的に登録されます。

支払いフロー制御

Datagramには、ワークフロー設計を構築するためのインターフェイスがあります。マッピングは、Oozieスケジューラーを使用して起動できます。ストリームの開発者のインターフェースでは、並列、順次、またはデータ変換の実行の指定された条件に応じて、スキームを作成することができます。シェルスクリプトとJavaプログラムがサポートされています。ApacheLivyサーバーを使用することもできます。Apache Livyは、開発環境から直接アプリケーションを実行するために使用されます。



会社がすでに独自のプロセスオーケストレーターを持っている場合は、RESTAPIを使用して既存のストリームにマッピングを埋め込むことができます。たとえば、PLSQLとKotlinで記述されたオーケストレーターにScalaマッピングを埋め込むというかなり成功した経験がありました。ローコードツールのRESTAPIは、マッピングデザインに基づいて実行可能年を生成する、マッピングを呼び出す、マッピングのシーケンスを呼び出す、そしてもちろん、マッピングを起動するためにURLにパラメータを渡すなどの操作の存在を意味します。



Oozieとともに、Airflowを使用して計算のフローを整理することができます。おそらく、OozieとAirflowの比較については長い間詳しく説明しませんが、メディア研究プロジェクトでの作業のコンテキストでは、選択はAirflowに向けられたと簡単に言えます。今回の主な議論は、製品を開発するより活発なコミュニティと、より開発されたインターフェース+ APIであることが判明しました。



Airflowは、最愛のPythonを使用して計算プロセスを記述するため、優れています。一般に、オープンソースのワークフロー管理プラットフォームはそれほど多くありません。プロセス（ガントチャートを使用するプロセスを含む）の実行を起動および監視すると、Airflowのカルマにポイントが追加されるだけです。



ローコードソリューションマッピングを起動するための構成ファイルの形式はspark-submitです。これは2つの理由で起こりました。まず、spark-submitを使用すると、コンソールから直接jarファイルを実行できます。次に、ワークフローを構成するために必要なすべての情報を含めることができます（これにより、Dagを形成するスクリプトを簡単に作成できます）。

この場合のAirflowワークフローの最も一般的な要素は、SparkSubmitOperatorです。



SparkSubmitOperatorを使用すると、jar`niksを実行できます。これは、事前に形成された入力パラメーターを使用してパックされたデータグラムマッピングです。



各Airflowタスクは別々のスレッドで実行され、他のタスクについては何も知らないことに注意してください。これに関連して、タスク間の相互作用は、DummyOperatorやBranchPythonOperatorなどの制御演算子を使用して実行されます。



全体として、構成ファイルのユニバーサル化（Dagの形成）と組み合わせたDatagramローコードソリューションの使用により、データダウンロードストリームの開発プロセスが大幅に加速および簡素化されました。

ショーケースの計算

おそらく、分析データの生成で最もインテリジェントにロードされる段階は、店頭の構築ステップです。調査会社のデータフローの1つに関連して、この段階では、放送グリッドを参照するタイムゾーンの修正を考慮して、参照放送への変換が行われます。ローカル放送ネットワーク（ローカルニュースや広告）に合わせて調整することも可能です。特に、このステップでは、視聴間隔の分析に基づいて、メディア製品の連続視聴間隔を分類します。すぐに、表示値は、その重要性に関する情報（補正係数の計算）に基づいて「重み付け」されます。







データ検証は、データマートを準備するための別のステップです。検証アルゴリズムは、いくつかの数学的科学モデルを使用します。ただし、ローコードプラットフォームを使用すると、複雑なアルゴリズムをいくつかの個別の視覚的に読み取り可能なマッピングに分割できます。各マッピングは狭いタスクを実行します。その結果、データ準備段階の中間デバッグ、ロギング、および視覚化が可能になります。



検証アルゴリズムを次のサブステージに離散化することが決定されました。

• 地域内のすべてのネットワークを60日間視聴しながら、地域内のテレビネットワークを視聴することの依存関係の回帰をプロットします。
• すべての回帰ポイントと計算された日の学生化残差（回帰モデルによって予測されたものからの実際の値の偏差）の計算。
• 異常な地域とネットワークのペアのサンプル。計算された日の残りの学生が標準（操作設定で指定）を超えています。
• この回答者をサンプルから除外した場合の、この回答者の貢献度（学生化された残差の変化の値）を決定して、領域内のネットワークを表示した各回答者の異常な領域とネットワークのペアの修正された学生化された残差の再計算。
• 候補者を探します。候補者を除外すると、決済日の学生のバランスが通常に戻ります。

上記の例は、データエンジニアがとにかく頭の中にあまりにも多くを持っている必要があるという仮説の確認です...そしてこれが本当に「エンジニア」であり「コーダー」ではない場合、ローコードツールを使用するときの専門家の劣化の恐れ彼は最終的に撤退しなければなりません。

ローコードは他に何ができますか？

Scalaコードを手動で記述せずにデータをバッチ処理およびストリーミングするためのローコードツールの範囲は、それだけではありません。



データレイクの開発におけるローコードの使用は、すでに私たちの標準になっています。おそらく、Hadoopスタックのソリューションは、RDBMSに基づく従来のDWHの開発の道をたどっていると言えます。 Hadoopスタックのローコードツールは、データ処理タスクと最終的なBIインターフェイスを構築するタスクの両方を解決できます。さらに、BIはデータの表現だけでなく、ビジネスユーザーの力による編集も意味する可能性があることに注意してください。金融セクター向けの分析プラットフォームを構築する際に、この機能をよく使用します。







特に、ローコード、特にデータグラムを使用すると、アトミック性を備えたデータフローオブジェクトの起点を個々のフィールド（系統）まで追跡する問題を解決できます。これを行うために、ローコードツールはApacheAtlasおよびClouderaNavigatorとのインターフェイスを実装します。実際、開発者はAtlas辞書にオブジェクトのセットを登録し、マッピングを作成するときに登録されたオブジェクトを参照する必要があります。データの出所を追跡したり、オブジェクトの依存関係を分析したりするメカニズムは、計算アルゴリズムを改善する必要がある場合に多くの時間を節約します。たとえば、財務諸表を作成する場合、この機能を使用すると、法改正の期間をより快適に乗り切ることができます。結局のところ、詳細レイヤーのオブジェクトのコンテキストでのフォーム間の依存関係をよりよく理解すると、「突然の」欠陥に遭遇することが少なくなり、やり直しの回数が減ります。

データ品質とローコード

Mediascopeプロジェクトのローコードツールによって実装されるもう1つのタスクは、DataQualityクラスのタスクです。調査会社のプロジェクトのデータ検証パイプラインの実装の特徴は、メインのデータフローのパフォーマンスと速度に影響がないことでした。おなじみのApacheAirflowを使用して、独立したスレッドによるデータ検証のオーケストレーションを可能にしました。データ生成の各ステップの準備が整うと、DQパイプラインの個別の部分が並行して開始されました。



分析プラットフォームでデータの品質を最初から監視することをお勧めします。メタデータに関する情報があれば、情報がプライマリレイヤーに入った瞬間から、基本条件が満たされているかどうかを確認できます。nullではなく、制約、外部キーです。この機能は、Datagramでデータ品質ファミリの自動生成されたマッピングに基づいて実装されます。この場合のコード生成もモデルメタデータに基づいています。Mediascopeプロジェクトでは、インターフェイスはEnterpriseArchitect製品のメタデータを使用していました。



ローコードツールとEnterpriseArchitectをペアリングすることにより、次のチェックが自動的に生成されました。

• 「notnull」修飾子を使用してフィールドに「null」値が存在するかどうかを確認します。
• 主キーの重複の存在を確認します。
• エンティティの外部キーの検証。
• 一連のフィールドに対して文字列の一意性をチェックします。

より高度なデータの可用性と妥当性のチェックのために、Zeppelinのアナリストによって準備された外部のSparkSQLチェックコードを受け入れるScala式マッピングが作成されました。







もちろん、徐々に小切手の自動生成に至る必要があります。説明されているプロジェクトのフレームワーク内で、これに続いて次の手順が実行されました。

• Zeppelinノートブックに実装されたDQ。
• DQ組み込みマッピング。
• 特定のエンティティのチェックのセット全体を含む個別の大規模なマッピングの形式のDQ。
• メタデータとビジネス検証情報を入力として受け入れるユニバーサルパラメータ化DQマッピング。

おそらく、パラメータ化されたチェックのサービスを作成する主な利点は、本番環境への機能の配信時間の短縮です。新しい品質チェックでは、開発環境とテスト環境を介して間接的にコードを配信するという従来のパターンを回避できます。

• EAでモデルが変更されると、すべてのメタデータチェックが自動的に生成されます。
• データ可用性チェック（ある時点でのデータの存在を判断する）は、オブジェクトのコンテキストで次のデータが出現する予想されるタイミングを格納するディレクトリに基づいて生成できます。
• ビジネスデータの検証は、Zeppelinノートブックのアナリストによって作成されます。そこから、実稼働環境のDQモジュールセットアップテーブルに直接移動します。

スクリプトを本番環境に直接出荷するリスクはありません。構文エラーがあっても、データ計算のフローと品質チェックの開始のフローが互いに分離されているため、私たちを脅かす最大の問題は、1つのチェックの実行の失敗です。



実際、DQサービスは実稼働環境で永続的に実行されており、次のデータが表示されたときに機能を開始する準備ができています。

結論の代わりに

ローコードを使用する利点は明らかです。開発者は、アプリケーションを最初から開発する必要はありません。追加のタスクから解放されたプログラマーは、より速く結果を出します。次に、速度は、最適化の問題を解決するための追加の時間リソースを解放します。したがって、この場合、より優れた、より高速なソリューションを期待できます。



もちろん、ローコードは万能薬ではなく、魔法はそれ自体では起こりません。

• ローコード業界は「成長」の段階を経ており、これまでのところ、統一された業界標準はありません。
• 多くのローコードソリューションは無料ではありません。それらを購入することは意図的なステップである必要があります。これは、それらの使用による経済的利益に完全に自信を持って行う必要があります。
• GIT / SVN. ;
• – , , « » low-code-.
• , low-code-. . / IT- .

ただし、選択したシステムのすべての欠点を知っていて、それでもその使用による利点が圧倒的に多い場合は、恐れることなく小さなコードに進んでください。さらに、それへの移行は避けられません-どんな進化も避けられないので。



ローコードプラットフォーム上の1人の開発者が、ローコードなしの2人の開発者よりも速く仕事をこなせる場合、これは会社にあらゆる点で有利なスタートを与えます。ローコードソリューションを入力するためのしきい値は、「従来の」テクノロジーよりも低く、これはスタッフ不足の問題にプラスの効果をもたらします。ローコードツールを使用すると、機能チーム間の相互作用を加速し、選択したデータサイエンス研究パスの正確性についてより迅速な決定を下すことができます。生成されたソリューションは技術者以外の専門家（特にビジネスユーザー）が理解できるため、低レベルのプラットフォームは組織のデジタル変革を推進できます。



締め切りが厳しく、ビジネスロジックが忙しく、技術的な専門知識が不足していて、市場投入までの時間を短縮する必要がある場合は、ローコードがニーズを満たす方法の1つです。



従来の開発ツールの重要性を否定することはできませんが、多くの場合、ローコードソリューションの使用は、解決される問題の効率を高めるための最良の方法です。