非常に効率的で安価な DataLake をどのように構成したか、そしてその理由

私たちは、「複数の文字」を深く掘り下げることなく、いくつかの既製のオープンソース ツールを素早く簡単に接続し、スタックオーバーフローのアドバイスに従って「意識をオフにして」セットアップし、起動できる素晴らしい時代に生きています。商業運転を開始します。 そして、更新/拡張する必要があるとき、または誰かが誤っていくつかのマシンを再起動したとき、ある種の執拗な悪い夢が現実に始まっていることに気づき、すべてが突然認識できないほど複雑になり、後戻りはできず、未来は漠然としていますそしてより安全なのは、プログラミングの代わりにミツバチを繁殖させてチーズを作ることです。

経験豊富な同僚たちが、頭がバグだらけですでに頭が真っ白になりながら、「最新の言語」で、「キューブ」の「コンテナ」のパックを信じられないほど高速に数十台のサーバーに展開し、非同期ノンブロッキング I/O、控えめに微笑みます。 そして彼らは黙って「man ps」を読み直し、「nginx」のソースコードを目から血が出るほど掘り下げて、単体テストを書き、書き、書き続けます。 同僚たちは、大晦日の夜、ある日「すべて」が賭けられたときに最も興味深いことが起こることを知っています。 そして、UNIX の性質、記憶された TCP/IP 状態テーブル、および基本的な並べ替え検索アルゴリズムを深く理解することによってのみ役立ちます。 チャイムが鳴ると同時にシステムを元の状態に戻すためです。

そうそう、少し話がそれてしまいましたが、期待の様子が伝われば幸いです。
今日は、まったく異なる構造部門の社内の分析タスクの大部分を解決する、DataLake 用の便利で安価なスタックの導入に関する経験を共有したいと思います。

少し前に、私たちは企業が製品分析と技術分析の両方の成果をますます必要とし（機械学習というおまけは言うまでもありません）、傾向とリスクを理解する必要があることを理解しました。収集して分析する必要があるのです。メトリクスがどんどん増えていきます。

Bitrix24 の基本的なテクニカル分析

数年前、Bitrix24 サービスの開始と同時に、インフラストラクチャの問題を迅速に特定し、次のステップを計画するのに役立つ、シンプルで信頼性の高い分析プラットフォームの作成に時間とリソースを積極的に投資しました。 もちろん、できるだけシンプルでわかりやすい既製のツールを使用することをお勧めします。 その結果、監視には nagios が、分析と視覚化には munin が選択されました。 現在、nagios には数千のチェックがあり、munin には数百のチャートがあり、同僚はそれらを毎日問題なく使用しています。 メトリクスもグラフも明確で、システムは数年間にわたって確実に動作しており、新しいテストとグラフが定期的に追加されています。新しいサービスを運用するときは、いくつかのテストとグラフを追加します。 幸運を。

フィンガー・オン・ザ・パルス - 高度なテクニカル分析

問題に関する情報を「できるだけ早く」受け取りたいという欲求から、私たちはシンプルでわかりやすいツールである pinba と xhprof を使用した積極的な実験を行いました。

Pinba は、PHP での Web ページの一部の動作速度に関する UDP パケットの統計を私たちに送信してくれたので、MySQL ストレージ (Pinba には高速イベント分析用の独自の MySQL エンジンが付属しています) でオンラインで問題の短いリストを確認し、対応することができました。彼ら。 また、xhprof を使用すると、クライアントから最も遅い PHP ページの実行グラフを自動的に収集し、何が原因でそうなる可能性があるかを分析できるようになりました (落ち着いてお茶か何か強めの飲み物を注ぐなど)。

少し前に、このツールキットには、伝説的な Lucene ライブラリである Elastic/Kibana に完全に実装された、逆インデックス作成アルゴリズムに基づく別の非常にシンプルでわかりやすいエンジンが補充されました。 ログ内のイベントに基づいてマルチスレッドでドキュメントを逆 Lucene インデックスに記録し、ファセット分割を使用してドキュメントをすばやく検索するというシンプルなアイデアが非常に便利であることがわかりました。

Kibana のビジュアライゼーションは、「バケツ」「上向きに流れる」などの低レベルの概念や、まだ完全に忘れ去られていないリレーショナル代数の再発明された言語を使用してかなり技術的に見えますが、このツールは次のタスクでよく役立ち始めました。

• 過去 24 時間に、p1 ポータルで BitrixXNUMX クライアントに発生した PHP エラーは何件ありますか? 理解し、許し、すぐに修正してください。
• 過去 24 時間にドイツのポータルでビデオ通話が何回行われましたか?その品質はどれくらいですか?また、チャネル/ネットワークに問題はありましたか?
• 最新のサービス更新でソースからコンパイルされ、クライアントに展開されたシステム機能 (PHP 用の C 拡張機能) はどの程度うまく機能しますか? セグメンテーション違反はありますか?
• 顧客データは PHP メモリに収まりますか? プロセスに割り当てられたメモリの超過に関するエラー (「メモリ不足」) はありますか? 見つけて無力化する。

具体的な例を示します。 徹底した複数レベルのテストにもかかわらず、クライアントは非常に非標準的なケースと破損した入力データを抱えていたため、迷惑な予期せぬエラーを受け取り、サイレンが鳴り、それを迅速に修正するプロセスが始まりました。

さらに、kibana を使用すると、指定したイベントの通知を整理することができ、短期間のうちに社内のこのツールは、テクニカル サポートや開発から QA に至るまで、さまざまな部門の数十人の従業員によって使用されるようになりました。

社内のあらゆる部門のアクティビティを追跡および測定するのが便利になりました。サーバー上のログを手動で分析する代わりに、解析ログを一度セットアップしてエラスティック クラスターに送信するだけで、たとえば kibana で熟考することができます。ダッシュボードには、先月の 3D プリンターで印刷された双頭の子猫の販売数が表示されます。

基本的なビジネス分析

企業におけるビジネス分析は、多くの場合、Excel を積極的に使用することから始まることは誰もが知っています。 しかし重要なことは、それだけでは終わらないということです。 クラウドベースの Google Analytics も火に油を注ぐため、すぐに良いものに慣れ始めてしまいます。

調和のとれた発展を遂げる当社では、より大規模なデータを使ったより集中的な作業の「予言者」があちこちに現れ始めました。 より詳細で多面的なレポートの必要性が定期的に現れ始め、さまざまな部門の人々の努力により、しばらく前に、ClickHouse と PowerBI を組み合わせた、シンプルで実用的なソリューションが組織されました。

かなり長い間、この柔軟なソリューションは非常に役に立ちましたが、徐々に、ClickHouse はゴムではなく、そのように嘲笑することはできないという理解が得られ始めました。

ここで、ClickHouse、Druid、Vertica、Amazon RedShift (postgres ベース) などは、非常に便利な分析 (合計、集計、列ごとの最小値と最大値、およびいくつかの可能な結合) のために最適化された分析エンジンであることをよく理解することが重要です。 ）、 なぜならMySQL や既知の他の (行指向) データベースとは異なり、リレーショナル テーブルの列を効率的に格納できるように編成されています。

本質的に、ClickHouse は、より容量の大きい「データベース」に過ぎず、ポイントごとの挿入はそれほど便利ではありません (それが意図されているので、すべて問題ありません) が、快適な分析と、データを操作するための興味深い強力な関数のセットを備えています。 はい、クラスターを作成することもできます。しかし、顕微鏡を使って釘を打つことが完全に正しいわけではないことは理解されており、私たちは他の解決策を探し始めました。

Python とアナリストの需要

当社には、10 ～ 20 年間、ほぼ毎日、PHP、JavaScript、C#、C/C++、Java、Go、Rust、Python、Bash でコードを書いている開発者が多数います。 また、統計の法則に当てはまらない、信じられないような災害を複数回経験した経験豊富なシステム管理者も数多くいます (たとえば、RAID-10 内のディスクの大部分が強い落雷によって破壊された場合など)。 このような状況では、長い間、「Python アナリスト」が何なのかは明確ではありませんでした。 Python は PHP に似ていますが、名前が少し長いだけで、インタプリタのソース コードには精神を変化させる物質の痕跡が少し少なくなっています。 しかし、より多くの分析レポートが作成されるにつれて、経験豊富な開発者は、numpy、pandas、matplotlib、seaborn などのツールの狭い専門分野の重要性をますます理解し始めました。
おそらく決定的な役割を果たしたのは、「ロジスティック回帰」という言葉と、そうそう、pyspark を使用した大規模データの効果的なレポートのデモンストレーションの組み合わせによる従業員の突然の失神でした。

Apache Spark、リレーショナル代数が完璧に適合するその関数パラダイム、およびその機能は、MySQL に慣れている開発者に大きな印象を与え、経験豊富なアナリストとのランクを強化する必要性が日に日に明らかになりました。

Apache Spark/Hadoop のさらなる試みと、スクリプトどおりに進まなかった点

しかし、Spark にはシステム的に何か問題があるか、単に手をよく洗う必要があることがすぐに明らかになりました。 Hadoop/MapReduce/Lucene スタックがかなり経験豊富なプログラマによって作成されたものである場合 (Java のソース コードや Lucene での Doug Cutting のアイデアをよく観察すれば明らかです)、Spark は突然、エキゾチックな言語 Scala で書かれています。実用性の観点から非常に物議を醸しており、現在は開発されていません。 そして、リデュース操作のためのメモリ割り当てによる非論理的であまり透明性の低い作業 (多くのキーが一度に到着する) による Spark クラスターでの計算の定期的な低下により、成長の余地があるものの周囲に後光が生成されます。 さらに、状況は、多数の奇妙に開いたポート、最も理解できない場所で成長する一時ファイル、および膨大な jar 依存関係によってさらに悪化しました。これにより、システム管理者は、子供の頃からよく知られていた感情、つまり激しい憎しみ (またはおそらく) を抱くようになりました。彼らは石鹸で手を洗う必要がありました）。

その結果、私たちは、Apache Spark (Spark Streaming、Spark SQL を含む) と Hadoop エコシステム (など) を積極的に使用するいくつかの内部分析プロジェクトを「生き延びました」。 時間が経つにつれて、「それ」を非常にうまく準備して監視する方法を学び、データの性質の変化や均一な RDD ハッシュの不均衡によって「それ」が突然クラッシュすることはほとんどなくなりましたが、すでに準備ができているものを使用したいという欲求は、 、クラウドのどこかで更新および管理され、ますます強力になりました。 私たちがアマゾン ウェブ サービスの既成のクラウド アセンブリを使用しようとしたのはこの時でした。 EMR そしてその後、それを使用して問題を解決しようとしました。 EMR は、Cloudera/Hortonworks ビルドと同様に、エコシステムの追加ソフトウェアを使用して Amazon によって準備された Apache Spark です。

分析用のラバーファイルストレージは緊急のニーズです

体のさまざまな部分に火傷を負い、Hadoop/Sparkを「調理」した経験は無駄ではありませんでした。 ハードウェア障害に強く、さまざまなシステムからさまざまな形式でファイルを保存し、このデータからレポート用の効率的かつ時間効率の高いサンプルを作成できる、安価で信頼性の高い単一のファイル ストレージを作成する必要性がますます高まっています。クリア。

また、このプラットフォームのソフトウェアの更新が、20 ページの Java トレースを読み取り、Spark History Server とバックライト付き虫眼鏡を使用してクラスターの数キロメートルにわたる詳細なログを分析するという新年の悪夢にならないようにしたいとも思いました。 ソース データ パーティショニング アルゴリズムが適切に選択されていないためにデータ削減ワーカーがメモリ不足になり、開発者の標準 MapReduce リクエストが実行を停止した場合に、定期的に内部に潜る必要のない、シンプルで透過的なツールが必要でした。

Amazon S3 は DataLake の候補ですか?

Hadoop/MapReduce の経験から、スケーラブルで信頼性の高いファイル システムと、その上にあるスケーラブルなワーカーが必要であり、ネットワーク上でデータを転送しないようにデータに「近づく」必要があることが分かりました。 作業者はさまざまな形式のデータを読み取れる必要がありますが、不要な情報を読み取らず、作業者にとって使いやすい形式でデータを事前に保存できることが望ましいです。

もう一度、基本的な考え方を。 ビッグデータを単一のクラスター分析エンジンに「注ぎ込む」ことは望ましくありません。遅かれ早かれ機能不全に陥り、醜いシャード化が必要になります。 ファイル (単なるファイル) をわかりやすい形式で保存し、別のわかりやすいツールを使用してそれらに対して効果的な分析クエリを実行したいと考えています。 そして、さまざまな形式のファイルがますます多くなるでしょう。 また、エンジンではなくソース データをシャード化することをお勧めします。 拡張可能でユニバーサルな DataLake が必要であると判断しました...

Hadoop から独自のチョップを準備することなく、使い慣れたよく知られたスケーラブルなクラウド ストレージ Amazon S3 にファイルを保存したらどうなるでしょうか?

個人データが「少ない」ことは明らかですが、それを取り出して「効果的に活用」した場合、他のデータはどうなるでしょうか?

アマゾン ウェブ サービスのクラスター、ビッグデータ、分析のエコシステム - 非常に簡単な言葉で言うと

AWS での経験から判断すると、Apache Hadoop/MapReduce は、DataPipeline サービスなど、さまざまなソースで長期間にわたって積極的に使用されてきました (同僚がうらやましいです。彼らは正しく準備する方法を学んでいました)。 ここでは、DynamoDB テーブルのさまざまなサービスからのバックアップをセットアップします。


そして、これらは数年前から時計仕掛けのように、組み込みの Hadoop/MapReduce クラスター上で定期的に実行されています。 「設定したらあとは忘れる」:

また、アナリスト用にクラウドに Jupiter ラップトップをセットアップし、AWS SageMaker サービスを使用して AI モデルをトレーニングして戦闘に導入することで、データ悪魔崇拝に効果的に取り組むこともできます。 私たちにとっては次のようになります。

そしてはい、自分自身またはクラウド内のアナリスト用にラップトップを選択し、それを Hadoop/Spark クラスターに接続し、計算を行って、すべてを確定することができます。

個々の分析プロジェクトには非常に便利で、一部では大規模な計算と分析に EMR サービスを使用して成功しました。 DataLake のシステム ソリューションについてはどうでしょうか。うまくいきますか? この瞬間、私たちは希望と絶望の狭間で捜索を続けました。

AWS Glue - 強化された Apache Spark をきちんとパッケージ化

AWS には独自バージョンの「Hive/Pig/Spark」スタックがあることが判明しました。 Hive の役割、つまりDataLake 内のファイルとその種類のカタログは、「データ カタログ」サービスによって実行されます。このサービスは、Apache Hive 形式との互換性を隠しません。 ファイルの場所と形式に関する情報をこのサービスに追加する必要があります。 データは s3 だけでなくデータベースにも存在しますが、それはこの投稿の主題ではありません。 DataLake データ ディレクトリは次のように構成されています。

ファイルが登録されました。 ファイルが更新されている場合は、手動またはスケジュールに従ってクローラーを起動し、レイクからクローラーに関する情報を更新して保存します。 その後、湖からのデータを処理し、結果をどこかにアップロードできます。 最も単純なケースでは、s3 にもアップロードします。 データ処理はどこでも実行できますが、AWS Glue API による高度な機能を使用して Apache Spark クラスターで処理を設定することをお勧めします。 実際、pyspark ライブラリを使用して古き良き使い慣れた Python コードを取得し、Hadoop の中身を掘り下げて docker-moker コンテナをドラッグしたり、依存関係の競合を排除したりすることなく、監視付きのある程度の容量を持つクラスターの N ノード上でその実行を構成できます。 。

またしてもシンプルなアイデア。 Apache Spark を構成する必要はありません。必要なのは、pyspark 用の Python コードを作成し、デスクトップ上でローカルにテストしてから、ソース データの場所と結果の保存場所を指定して、クラウド内の大規模なクラスター上で実行するだけです。 場合によってはこれが必要で便利です。その設定方法は次のとおりです。

したがって、s3 のデータを使用して Spark クラスターで何かを計算する必要がある場合は、Python/pyspark でコードを作成し、テストして、クラウドに幸運をもたらします。

オーケストレーションについてはどうですか？ タスクが落ちて消えてしまったらどうなるでしょうか? はい、Apache Pig スタイルで美しいパイプラインを作成することが提案されており、私たちも試してみましたが、今のところ、PHP と JavaScript で深くカスタマイズされたオーケストレーションを使用することにしました (認知的不協和があることは理解していますが、それは機能します。年、エラーなし）。

レイクに保存されるファイルの形式がパフォーマンスの鍵となります

さらに XNUMX つの重要なポイントを理解することが非常に重要です。 レイク内のファイル データに対するクエリをできるだけ早く実行し、新しい情報が追加されたときにパフォーマンスが低下しないようにするには、次のことを行う必要があります。

• ファイルの列を個別に保存します (列の内容を理解するためにすべての行を読む必要がなくなります)。 このために、圧縮付きの寄木細工の形式を採用しました。
• ファイルを言語、年、月、日、週などのフォルダーに分割することが非常に重要です。 このタイプのシャーディングを理解するエンジンは、行内のすべてのデータを調べずに、必要なフォルダーのみを調べます。

基本的に、この方法で、上部に吊り下げられた分析エンジンにとって最も効率的な形式でソース データをレイアウトします。分析エンジンは、シャード フォルダー内であっても、ファイルから必要な列のみを選択して入力して読み取ることができます。 データをどこにも「埋める」必要はありません (ストレージがパンクするだけです)。ただちに正しい形式でファイル システムに賢明に配置するだけです。 もちろん、巨大な CSV ファイルを DataLake に保存することは、列を抽出するためにクラスターによって最初に XNUMX 行ずつ読み取られる必要があるため、あまりお勧めできないことはここで明らかです。 なぜこのようなことが起こっているのかがまだ明らかでない場合は、上記の XNUMX つの点をもう一度考えてください。

AWS Athena - びっくり箱

そして、湖を作成しているときに、どういうわけか偶然 Amazon Athena に遭遇しました。 巨大なログ ファイルを正しい (寄木細工の) 列形式でフォルダー シャードに慎重に配置することで、Apache Spark/Glue クラスターを使用せずに、それらから非常に有益な選択を非常に迅速に行い、レポートを作成できることが突然判明しました。

S3 のデータを利用した Athena エンジンは、伝説的なエンジンに基づいています。 プレストで - MPP (大規模並列処理) ファミリのデータ処理アプローチの代表であり、s3 や Hadoop から Cassandra や通常のテキスト ファイルまで、データが存在する場所にデータを取り込みます。 Athena に SQL クエリの実行を依頼するだけで、すべてが「迅速かつ自動的に動作」します。 Athena は「スマート」であることに注意することが重要です。Athena は必要なシャードフォルダーのみにアクセスし、リクエストで必要な列のみを読み取ります。

Athena へのリクエストの価格設定も興味深いです。 私たちが支払います スキャンしたデータの量。 それらの。 100 分あたりのクラスター内のマシン数ではなく、500 ～ XNUMX 台のマシンで実際にスキャンされたデータのうち、リクエストを完了するために必要なデータのみです。

そして、正しくシャーディングされたフォルダーから必要な列のみをリクエストすることにより、Athena サービスには月額数十ドルの費用がかかることが判明しました。 クラスターの分析と比較すると、ほとんど無料で素晴らしいです。

ちなみに、s3 でデータをシャーディングする方法は次のとおりです。

その結果、短期間のうちに、情報セキュリティから分析まで、社内のまったく異なる部門が Athena に積極的にリクエストを送信し始め、数か月、数ヶ月というかなり長期間にわたって「ビッグ」データから有用な回答を数秒で迅速に受け取りました。 XNUMX か月など。P.

しかし、私たちはさらに進んで、クラウドに答えを求め始めました。 ODBCドライバー経由: アナリストは使い慣れたコンソールで SQL クエリを作成します。このコンソールは 100 ～ 500 台のマシンで「3 セントで」データを sXNUMX に送信し、通常は数秒で応答を返します。 快適。 そして速い。 まだ信じられません。

その結果、効率的な列指向形式で、データをフォルダーに適切にシャーディングして、データを s3 に保存することを決定し、DataLake と高速で安価な分析エンジンを無料で受け取りました。 そして彼は社内でとても人気者になった、なぜなら... SQL を理解し、クラスターの開始/停止/セットアップよりも桁違いに高速に動作します。 「結果が同じなら、なぜもっとお金を払う必要があるのでしょうか?」

Athenaへのリクエストはこんな感じ。 もちろん、必要に応じて、十分な形式を作成できます 複雑な複数ページの SQL クエリですが、ここでは単純なグループ化に限定します。 数週間前にクライアントが Web サーバー ログに記録していた応答コードを確認し、エラーがないことを確認してみましょう。

所見

長くて苦しい道のりは言うまでもありませんが、リスクと複雑さのレベル、サポートのコストを常に適切に評価しながら、スピードと所有コストの両方で満足していただける DataLake と分析のソリューションを見つけました。

会社のまったく異なる部門のニーズに合わせて、効果的、高速、低コストで運用できる DataLake を構築することは、アーキテクトとして働いたことがなく、正方形の上に正方形を描く方法を知らない経験豊富な開発者でも完全に能力の範囲内であることがわかりました。矢印を使用して、Hadoop エコシステムの 50 の用語を理解します。

旅の初め、私の頭は、オープンソフトウェアとクローズドソフトウェアの多くの野生動物園と、子孫への責任の負担の理解から分裂していました。 nagios/munin -> elastic/kibana -> Hadoop/Spark/s3... という単純なツールから DataLake の構築を開始し、フィードバックを収集し、発生するプロセスの物理を深く理解します。 すべてが複雑で曖昧です - それを敵や競争相手に渡します。

クラウドには行きたくないが、オープンソース プロジェクトのサポート、更新、パッチ適用を希望する場合は、Hadoop と Presto を搭載した安価なオフィス マシン上で、私たちのものと同様のスキームをローカルで構築できます。 重要なことは、立ち止まらずに前進し、数え、シンプルで明確な解決策を探すことです。そうすればすべては間違いなくうまくいきます。 皆さん頑張ってください、またお会いしましょう！

出所： habr.com