ビッグデータ-最初のED IBエクスペリエンス

みなさんこんにちは! 今日は、ビッグデータのトピックの人気の波がまだ市場をカバーしていない2012年に始まったビッグデータとの知り合いについてお話したいと思います。







その時までに、データウェアハウスの構築の分野ですでに専門知識を獲得していました。 お客様は、短時間で、限られた予算で大量のデータを処理したいため、標準のHDアーキテクチャを改善するさまざまな方法を検討しました。 標準ストレージの大量のデータはMPPプラットフォームで完全に処理されることを理解していましたが、実際には高価です。 したがって、安価な分散システムが必要です。 彼女はHadoopであることが判明しました。 初期投資は最小限で済み、最初の結果は非常に迅速に得られます。 将来的には、水平でほぼ線形のスケーリング、オープンプラットフォーム、および多くの興味深い追加機能(たとえば、NoSQL、クイックデータ検索、SQLデータアクセス言語の一種)が提供される予定です。



テストタスクは、Hadoopでのデータの強化を調査することでした。標準データの結合にどれだけ時間がかかるかを測定しました。 たとえば、リレーショナルデータベースの標準による100 GBと10 GBの共通部分は重大な量です(フルスキャンにインデックスを使用するのは不合理です)。 テストサーバーでは、リレーショナルストレージでは数十分でしたが、同様のタスクは数分で完了しました。 リレーショナルストレージに費やされたお金とHDのミッドレンジアレイのコスト(平均でローカルアレイのコストを1桁上回る)を考えると、そのような計算とデータストレージの手段の選択は明らかでした。



問題を解決するためのアプローチをテストするには、次のものが必要でした。





Hadoopスタックでパイロットプロジェクトを行い、読んだ本「 Hadoop:The Definitive Guide 」と「 MapReduce Design Patterns 」を活用しました 。 私たちのチームはすでにJavaの専門知識を持っていたため、MapReduceパラダイムへの移行は、Oracle Databaseから来た人にとっても問題になりませんでした。 それから始めるには、数冊の本を読んで学ぶのに十分でした。



テストを高速化するために、Amazon EC2のクラウドサービスを使用して、ハードウェアを遅滞なく取得し、ClouderaからHadoopスタックのインストールを開始できるようにしました。 2日でスタンドの準備が整いました。 8 GBのRAMと2つのCPUを搭載した10個のインスタンスをアイロンとして使用しました。 トリプルデータレプリケーション(デフォルト)を考慮した各マシンの50 GBディスクは、パイロットの問題を解決するのに十分な余裕を持って十分でした。 10個のインスタンスが経験的に受信されました。 インスタンスの数が減少すると、生産性が大幅に低下しました。 現在、ベンダーからのアセンブリの開発により、クラスタは「数回クリックする」だけで配置されます。



ただし、Hadoopの主な呼び出しは参加ではありません。 彼の強みは分析能力にあります。 これを完全に理解して、最初の実際のケースを得ました。 パイロットタスクは、モスクワ空港の出発ゾーンを訪れる加入者を追跡し、モバイル通信で関連するオファーを送信することでした。 入力データからは、サブスクライバートラフィックと、空港の出発ゾーンにサービスを提供するタワーのリストのみがありました。 しかし、これはビッグデータではありません。



タスクの2番目の要件の時点で、ビッグデータが表示されます:最終サンプルからすべての会葬者、挨拶、タクシー運転手、店員などを特定し、除外します。 セルタワーの範囲は、出発ゾーンの条件付き境界だけに限定されないため、空港ビルの外を含め、近くのすべての加入者もここに到着できます。



すべてが素晴らしく、これに使用できるのはAmazonクラスターだけです。モバイルオペレーターの個人データを扱っています。 ビッグデータの実装は時間の問題であることが明らかになり、顧客は最初のクラスターを購入することにしました。 クラスターのサイジングは、ビッグデータ開発戦略を考慮に入れて今後1年間に計算され、20台のHP 380 G8マシン(2 CPU / 48 G RAM / 12x3 Tbディスク)を購入しました。



ビッグデータでの作業を開始してから6か月後に、最大5人の従業員からなるチームを編成し、2013年末までにすでに14人の従業員を抱えていました。 Hadoopスタックに関するすべてを完全に理解する必要がありました。 当社の従業員は、Clouderaの認定コースを受講しました。クラスター管理トレーニング、MapReduce、HBaseでの開発です。 この背景により、Hadoopのすべての複雑さをすばやく理解し、MapReduceの最適な開発手法を理解し、ビジネスに取りかかることができました。 ところで、今では多くの優れたオンラインコースがあります(たとえば、Coureraで)。



最初のビジネスタスクの実装には、トリガーとしての一定の作業が含まれていました。着信データストリームから基地局の必要なパラメーターを使用して、必要なレコードを検索します。 Hadoopでは、加入者プロファイルは毎日考慮されました。最初は手動で、次に機械学習を使用しました。 サブスクライバープロファイルデータは、Redisのメモリ内のキー/値ストレージにオーバーロードされていました。 着信データストリームは、Apache Stormを使用して処理されました。 この段階で、加入者のプロファイル、セルタワー、および当社にとって関心のあるセクターが考慮されました。 さらに、このストリームはサブスクライバーの連絡ポリシーを介して処理され(たとえば、サブスクライバーが規定の回数を超えてSMSを受信しないように)、SMS送信キューに入りました。



実験のために、MapReduceのみで問題を解決しようとしましたが、ひどく判明しました。クラスターの負荷が高く、毎回Javaマシンが長時間初期化されていました。 そうしないでください。



現在、顧客企業には独自の産業クラスターがあり、仮想マシンでテクノロジーをテストし、実際のタスクでのアプリケーションの可能性を評価しています。



それが私たちの知り合いがどういうわけか始まった方法です。



そうそう-私の名前はBednov Alexeyで、コメントであなたの質問に答える準備ができています。



All Articles