何のためでもない、より経験豊富な同僚は、頭にバグが散らばっていて、このすでに白髪の人から、非同期非ブロッキング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逆インデックスにドキュメントをマルチスレッドで書き込み、ファセット分割を使用してそれらをすばやく検索するという単純なアイデアは、非常に便利であることがわかりました。
「バケツ」のような「流れる」低レベルの概念と、まだ忘れられていない関係代数の新しく発明された言語を備えたキバナのかなり技術的な種類の視覚化にもかかわらず、ツールは次のタスクで私たちをうまく助け始めました：
- 過去1時間にBitrix24クライアントがp1ポータルで発生したPHPエラーの数と、どれですか。理解し、許し、迅速に修正します。
- - 24 , /?
- ( C PHP), ? segfaults?
- PHP? : «out of memory»? .
具体的な例を示します。徹底的かつマルチレベルのテストにもかかわらず、非常に非標準的なケースと破損した入力データを持つクライアントに、迷惑で予期しないエラーが発生し、サイレンが鳴り、クイックフィックスのプロセスが開始されました。
さらに、kibanaを使用すると、指定されたイベントの通知を整理でき、短時間で会社のツールになりました。技術サポートや開発からQAまで、さまざまな部門の数十人の従業員を使用します。
社内のあらゆる部門の活動を監視および測定することが便利になりました。サーバー上のログを手動で分析する代わりに、ログの解析を設定してエラスティッククラスターに一度送信するだけで、たとえば、キバナダッシュボードで、3次元で印刷された双頭の子猫の販売数を調べることができます。先月のプリンター。
基本的なビジネスインテリジェンス
企業のビジネスインテリジェンスは、Excelを非常に積極的に使用することから始まることが多いことは誰もが知っています。しかし、重要なことはそれがそこで終わらないということです。Cloud Google Analyticsは、火に燃料を追加します-あなたはすぐに良いことに慣れます。
私たちの調和のとれた発展途上の会社では、より大きなデータを使ったより集中的な仕事の「預言者」があちこちに現れ始めました。より深く、より多面的なレポートの必要性が定期的に現れ始め、さまざまな部門の人々の努力のおかげで、ClickHouseとPowerBIの組み合わせであるシンプルで実用的なソリューションが少し前に組織されました。
かなり長い間、この柔軟なソリューションは大いに役立ちましたが、ClickHouseはゴムではなく、そのようにモックすることはできないということが徐々に理解されるようになりました。
ここで重要なのは、ClickHouse、Druid、Vertica、Amazon RedShift（postgresに基づく）のようなものが、かなり便利な分析（合計、集計、列ごとの最小-最大、および少しの結合）用に最適化された分析エンジンであることをよく理解することです。 ）、なぜなら MySQLやその他の（行指向の）データベースとは異なり、リレーショナルテーブルに列を効率的に格納するように編成されています。
実際、ClickHouseは、データのより容量の大きい「データベース」であり、ポイントの挿入はあまり便利ではありませんが（意図したとおり、すべて問題ありません）、優れた分析機能と、データを操作するための一連の興味深い強力な機能を備えています。はい、クラスターを作成することもできますが、顕微鏡で釘を打つことは完全に正しいわけではないことを理解しており、他の解決策を探し始めました。
パイソンとアナリストの需要
当社には、PHP、JavaScript、C＃、C / C ++、Java、Go、Rust、Python、Bashでほぼ毎日10〜20年間コードを書く開発者がたくさんいます。また、統計の法則に適合しない、複数の絶対に信じられないほどの災害を生き延びた経験豊富なシステム管理者もたくさんいます（たとえば、raid-10のほとんどのディスクが強い落雷によって破壊された場合）。そのような状況では、長い間、「パイソンアナリスト」が何であるかは明確ではありませんでした。 PythonはPHPに似ていますが、通訳者のソースコードでは、名前だけが少し長く、精神を変える物質の痕跡が少し小さくなっています。ただし、ますます多くの分析レポートが作成されるにつれて、経験豊富な開発者は、numpy、pandas、matplotlib、seabornなどのツールの狭い専門分野の重要性をますます認識しています。
決定的な役割は、「ロジスティック回帰」という言葉の組み合わせによる従業員の突然の失踪と、yes、yes、pysparkを使用した大規模データに関する効果的なレポートのデモンストレーションによっておそらく果たされました。
Apache Spark、その機能パラダイム、リレーショナル代数、および機能は、MySQLに慣れている開発者に感銘を与えたため、経験豊富なアナリストとの戦いのランクを強化する必要性が日ごとに明らかになりました。
Apache Spark / Hadoopによる離陸のさらなる試みと、何が悪かったのか
しかし、Sparkを使用すると、明らかに、体系的に何かが正しくないか、手をよく洗う必要があることがすぐに明らかになりました。 Hadoop / MapReduce / Luceneスタックがかなり経験豊富なプログラマーによって作成された場合（LuceneでJavaソースコードまたはDoug Cuttingのアイデアを情熱を持って見ると明らかです）、Sparkは突然、実用性の観点から非常に物議を醸すように書かれ、現在はエキゾチックなScala言語を開発していません。そして、削減操作のためにメモリを割り当てるという非論理的であまり透過的でない作業（多くのキーが一度に到着する）によるSparkクラスターの計算の定期的な低下は、成長する余地のある何かのハローをその周りに作成しました。さらに、この状況は、多数の奇妙な開いているポート、一時ファイル、最も理解しにくい場所と瓶依存の地獄で成長している-それはシステム管理者に子供時代からの1つのそしてよく知られた感情を引き起こしました：激しい憎悪（または石鹸と水で手を洗う必要があったかもしれません）。
その結果、Apache Spark（Spark Streaming、Spark SQLを含む）およびHadoopエコシステム（およびその他など）を積極的に使用するいくつかの内部分析プロジェクトを「存続」させました。データの性質の変化と均一なRDDハッシュの不均衡により、時間の経過とともに「それ」をうまく調理して監視することを学び、「それ」が突然落ちるのを実際に止めたという事実にもかかわらず、雲はどんどん強くなっていきました。このとき、Amazon Web Servicesの既製のクラウドベースのアセンブリであるEMRを使用しようとし、その後、問題の解決を試みました。 EMRは、Cloudera / Hortonworksビルドと同様に、エコシステムからの追加ソフトウェアを使用してAmazonが作成したApacheSparkです。
分析用のラバーファイルストレージ-緊急の必要性
体のさまざまな部分に火傷を負わせたHadoop / Sparkの「調理」の経験は無駄ではありませんでした。ハードウェア障害に耐性があり、さまざまなシステムからさまざまな形式でファイルを保存でき、効率的かつ合理的な時間でレポートの選択を行うことができる、単一の安価で信頼性の高いファイルストレージを作成する必要性がますます明確になり始めました。
また、このプラットフォームのソフトウェアアップデートが、20ページのJavaトレースを読み取り、Spark History Serverとバックライト付き拡大鏡を使用してキロメートル長の詳細なクラスターログを分析することで、新年の悪夢にならないようにしたかったのです。初期データ用に適切に選択されていないパーティショニングアルゴリズムを使用してreduceデータワーカーがメモリからドロップしたときに開発者が標準のMapReduceリクエストの実行を停止した場合、内部で定期的なダイビングを必要としないシンプルで透過的なツールが必要でした。
Amazon S3はDataLake候補ですか？
Hadoop / MapReduceの経験から、スケーラブルで信頼性の高いファイルシステムとその上にスケーラブルなワーカーが必要であり、ネットワークを介してデータを駆動しないように、データに「近づく」ことがわかりました。作業者はさまざまな形式でデータを読み取ることができる必要がありますが、不要な情報を読み取らないようにし、作業者にとって便利な形式でデータを事前に保存できるようにすることが望ましいです。
もう一度、主なアイデア。ビッグデータを単一のクラスター分析エンジンに「アップロード」する必要はありません。これは遅かれ早かれ溺れ、醜い破片でなければなりません。ファイルだけをわかりやすい形式で保存し、さまざまなツールを使用して効果的な分析クエリを実行したいと思います。そして、さまざまな形式のファイルがますます増えるでしょう。また、エンジンではなく初期データをシャーディングすることをお勧めします。拡張可能で用途の広いDataLakeが必要だ
と判断しました... Hadoopから独自のチョップを作成せずに、使い慣れた有名なスケーラブルなAmazonS3クラウドストレージにファイルを保存するとどうなるでしょうか。
データが「ボトム」であることは明らかですが、それを取り出して「効果的に駆動」すると他のデータはありますか？
AmazonWebサービスのクラスター-bigdata-分析エコシステム-非常に簡単な言葉で
AWSでの経験から判断すると、DataPipelineサービスなどのさまざまなApache Hadoop / MapReduceソースの下で長い間積極的に使用されてきました（同僚がうらやましいですが、正しく調理する方法を学びました）。ここでは、DynamoDBテーブルのさまざまなサービスからのバックアップを構成しました。
これらは、時計仕掛けのような組み込みのHadoop / MapReduceクラスターで数年間定期的に実行されています。設定して忘れる：
クラウドでアナリスト向けにJupiterラップトップを調達し、AWS SageMakerを使用してAIモデルをトレーニングし、戦闘に展開することで、データサタニズムに効果的に取り組むこともできます。これが私たちの見た目
です：はい、あなたは自分自身または分析のためにクラウドでラップトップを拾い上げ、それをHadoop / Sparkクラスターに接続し、計算してすべてを「ネイル」することができます：
個々の分析プロジェクトに非常に便利であり、大規模な計算と分析にEMRサービスを使用することに成功したものもあります。DataLakeのシステムソリューションはどうですか？それは機能しますか？その瞬間、私たちは希望と絶望の危機に瀕しており、捜索を続けました。
AWSGlue-「ステロイドで」きちんとパッケージ化されたApacheSpark
AWSには独自のバージョンのHive / Pig / Sparkスタックがあることが判明しました。ハイブの役割、すなわち DataLakeのファイルとそのタイプのカタログは、ApacheHive形式との互換性を隠さない「データカタログ」サービスを実行します。このサービスでは、ファイルの場所と形式に関する情報を追加する必要があります。データはs3だけでなくデータベースにもある可能性がありますが、これはこの投稿の内容ではありません。DataLakeデータディレクトリの構成は次のとおりです。
ファイルは登録されています。ファイルが更新されている場合は、手動で起動するか、クローラーがスケジュールに従って起動します。クローラーは、湖からファイルに関する情報を更新して保存します。さらに、湖からのデータを処理して、結果をどこかにアンロードすることができます。最も単純なケースでは、s3にもアップロードします。データ処理はどこでも実行できますが、AWS GlueAPIの高度な機能を使用してApacheSparkクラスターで処理をセットアップすることをお勧めします。実際、pysparkライブラリを使用して古き良き使い慣れたpythonコードを取得し、Hadoopの内臓を掘り下げたり、docker-mockerコンテナをドラッグしたり、依存関係の競合を排除したりすることなく、監視機能を備えたある程度の容量のクラスタのNノードで実行するように構成できます。
もう一度、簡単なアイデア。Apache Sparkを構成する必要はありません。pysparkのpythonコードを記述し、デスクトップでローカルにテストしてから、クラウド内の大規模なクラスターで実行して、ソースデータの場所と結果の配置場所を指定するだけです。時々それは必要で便利です、そしてこれはそれが私たちと一緒に設定される方法です：
したがって、s3のデータでSparkクラスターで何かを計算する必要がある場合-python / pysparkでコードを書いて、それをテストしてクラウドへの良い旅行をしてください。
オーケストレーションはどうですか？タスクが落ちて消えた場合はどうなりますか？はい、Apache Pigのスタイルで美しいパイプラインを作成することが提案されており、それらも試してみましたが、今のところPHPとJavaScriptで深くカスタマイズされたオーケストレーションを使用することにしました（認識の不一致があることは理解していますが、何年もエラーなしで機能します）。
Lakeファイル形式はパフォーマンスの鍵です
さらに2つの重要なポイントを理解することは非常に重要です。湖のファイルデータに対するクエリを可能な限り迅速に実行し、新しい情報が追加されてもパフォーマンスが低下しないようにするには、次のものが必要です。
- ファイルの列を個別に保存します（列の内容を理解するためにすべての行を読み取る必要がないようにするため）。このために、圧縮を使用した寄木細工の形式を採用しました
- 言語、年、月、日、週などの精神でパパがファイルをシャーディングすることは非常に重要です。このタイプのシャーディングを理解するエンジンは、すべてのデータを自分自身に押し付けることなく、適切なパパだけを調べます。
実際、このようにして、上に吊るされた分析エンジンの初期データを最も効率的な形式でレイアウトします。これにより、必要な列のみをファイルからシャーディングされたパパに選択的に入力および読み取ることができます。どこにでも行く必要はありません。データを「埋める」ことがわかります（ストレージは単にバーストします）。すぐに正しい形式でファイルシステムに適切に配置するだけです。もちろん、ここで、巨大なcsvファイルをDataLakeに保存することは、列を抽出するためにクラスターが最初に1行ずつ読み取る必要があることはあまりお勧めできません。なぜそうなのかまだはっきりしない場合は、上記の2つの点についてもう一度考えてみてください。
AWSAthena-スナッフボックスから「地獄」
そして、湖を作って、どういうわけか、私たちはアマゾンアテナに出くわしました。突然、shards-daddiesによって巨大なログファイルを正しい（寄木細工の）列形式できちんと折りたたむことで、Apache Spark / Glueクラスターなしで、非常に有益な選択をすばやく行い、レポートを作成できることがわかりました。
Athena s3データエンジンは、MPP（大規模並列処理）ファミリーのデータ処理アプローチのメンバーである伝説的なPrestoに基づいており、s3やHadoopからCassandraやプレーンテキストファイルまで、データをその場所に取り込みます。 AthenaにSQLクエリを実行するように依頼するだけで、すべてが「迅速かつ単独で機能」します。アテナは「賢く」、必要なシャーディングされたパパだけに行き、リクエストに必要な列だけを読み取ることに注意することが重要です。
アテナへのリクエストも興味深いことに請求されます。スキャンしたデータの量を支払います。それら。 1分あたりのクラスター内のマシンの数ではなく、... 100〜500台のマシンで実際にスキャンされたデータの場合、要求を満たすために必要なデータのみ。
そして、適切にシャーディングされたパパに必要な列だけを要求することによって、アテナサービスは私たちに月に数十ドルかかることがわかりました。クラスターの分析と比較すると、すばらしい、ほぼ無料です。
ちなみに、これがs3でデータを分割する方法です。
その結果、短期間で、情報セキュリティから分析まで、社内のまったく異なる部門が積極的にAthenaにリクエストを送信し始め、数秒で「ビッグ」から有用な回答を受け取りました。かなり長い期間のデータ：月、半年など。
しかし、さらに進んで、ODBCドライバーを介して回答を求めてクラウドにアクセスし始めました。アナリストは使い慣れたコンソールでSQLクエリを作成します。これは、100〜500台のマシンで、s3の「1ペニーの」ウールデータであり、通常は数秒で回答を返します。便利です。そして速い。私はまだそれを信じることができません。
その結果、データをs3に、効率的な列形式で、パパによる妥当なデータシャーディングで保存することを決定しました... DataLakeと高速で安価な分析エンジンを無料で入手しました。そして彼は会社に非常に人気がありましたSQLを理解し、クラスターの開始/停止/構成よりも数桁速く実行します。 「そして、結果が同じなら、なぜもっと支払うのですか？」
アテナへのリクエストはこんな感じ。もちろん、必要に応じて、十分に形成することができます複雑で複数ページのSQLクエリですが、単純なグループ化に限定します。クライアントが数週間前にWebサーバーのログにどのような応答コードを持っていたかを確認し、エラーがないことを確認しましょう。
結論
長いが苦痛な道のりは言うまでもなく、リスクと複雑さのレベル、サポートのコストを常に適切に評価してきた私たちは、スピードと所有コストの両方で私たちを喜ばせ続けるDataLakeと分析のソリューションを見つけました。
アーキテクトとして働くことはなく、矢印の付いた正方形に正方形を描くことができず、Hadoopエコシステムから50の用語を知っている経験豊富な開発者でさえ、会社のまったく異なる部門のニーズに合わせて効率的で高速かつ安価なDataLakeを構築できることがわかりました。
旅の初めに、私の頭は、オープンソフトウェアとクローズドソフトウェアの最もワイルドな動物園のセットと、子孫への責任の負担の理解から離れていました。nagios / munin-> elastic / kibana-> Hadoop / Spark / s3 ...という単純なツールからDataLakeの構築を開始するだけで、フィードバックを収集し、発生するプロセスの物理を深く理解できます。複雑で泥だらけのすべて-敵や競争相手にそれを与えてください。
クラウドにアクセスしたくない場合や、オープンソースプロジェクトの保守、更新、パッチ適用を希望する場合は、HadoopとPrestoを搭載した低コストのオフィスマシンで、ローカルで同様のスキームを構築できます。重要なことは、立ち止まって前進し、数え、単純で明確な解決策を探すことではなく、すべてが確実にうまくいくでしょう！皆さん、頑張ってください。またお会いしましょう！