デプスインタビュー：Huawei社のオープンソースのデータ形式CarbonDataプロジェクト、アドホッククエリ、大規模なデータ秒の応答
読み込み：14601 19:00 2016年7月に13日に
Huawei社は、Apacheコミュニティで6月3日の投票で、成功したApacheのインキュベーターに入っCarbonDataオープンソースプロジェクトを発表しました。CarbonDataは、低レイテンシクエリ、ストレージ、コンピューティング、別の軽量のファイル保存形式です。だから、Hadoopのプログラム上のSQLに比べ、伝統的なNoSQLのか相対ElasticSearch他の検索システム、CarbonDataどのような利点の？以下のようなCarbonData技術アーキテクチャを見て？今後の計画はどのような？我々は、技術的なプロジェクトCarbonDataみんなの疑問の担当者にインタビューしました。
InfoQでは：ウィルCarbonDataは、プロジェクトが行われたときに開始するのですか？行うには、なぜ、オープンソースのApacheインキュベータ？オープンソース開発とプロジェクトの現在の状況はどのようにのようなものでしょうか？
CarbonData：CarbonDataプロジェクトは、長年の経験から、処理し、徐々に2015年に構築し、業界の理解Huawei社のデータであり、我々はそれがHDFS上の柱状ストレージの共通セットに進化し、システムアーキテクチャの再構築を持っていた、とサポートスパークエンジンをドッキングした後、分散OLAP分析の溶液を形成します。
Huawei社は、多くの顧客シナリオからビッグデータプラットフォーム・ソリューション・プロバイダーとの通信、金融、IT企業や他のユーザーは、我々はデータの特性を改良し続けるために、してビッグデータ分析の代表的な需要の一部を総括し、徐々にCarbonData形成されていますこのアーキテクチャ。
IT分野では、唯一のオープンソースが開いているので、ために最終的にデータをより多くの顧客やパートナーがより大きなビジネス価値を生成するために一緒に参加します。オープンソースは、完全な生態系の実際の遊びの価値を形成するために一緒に積分値、必要と計算層、効果的な層の問い合わせを最大化するためにE2E生態学、CarbonDataデータ記憶層の技術を構築することです。
そして、Apacheは、大規模なデータの最も権威がHadoopのは、スパークは、主要なデータ、オープンデファクトスタンダードとなっている、我々はまた、我々は、Apacheに入ることを選んだので、コミュニティ駆動技術の進歩にはApacheの概念を認識し、コミュニティ一緒に、オープンソース組織を、フィールドであるため、構築する能力、CarbonData大きな生態系のデータに統合します。
現在、ApacheのコミュニティによってCarbonDataオープンソースプロジェクトは、6月3日に投票した、成功したApacheのインキュベーターに入りました。
次のようにコミュニティの関連情報は、次のとおりです。ApacheのCarbonData githubの住所： https://github.com/apache/incubator-carbondata
ApacheのCarbonDataコミュニティに参加するようこそ皆： https://github.com/apache/incubator-carbondata/blob/master/docs/How-to-contribute-to-Apache-CarbonData.md
InfoQでは：あなたはこのプロジェクトのCarbonDataを生成するためにしなければならないという考えを促進する理由や機会は何ですか？どのような以前のプロジェクトで直面する困難の？
CarbonData：私たちは、高性能データ分析、伝統的なアプローチ、一般的には文は、ダッシュボードやインタラクティブなクエリや他のサービスを実現するために、データベースの追加BIツールを使用している需要の多くを直面されているが、企業データの増加、ビジネス主導型の分析と伝統的な方法は、徐々に顧客のニーズを満たすことができないので、一部の顧客は、より強力な分析をしたいと徐々にだけでなく、柔軟性の要件を増やすと、私たちはCarbonDataこのプロジェクトのアイデアをしなければならなかったのでことを、SQLに加えています。
いくつかの観点から一般の需要。
まず、前回のスタンドアロンシステムとは異なる展開には、分散型企業顧客は、データの増加に対処するためのプログラムを持つようにしたい、あなたは常に汎用サーバのファッションスケールを追加することでスケールアウトすることができます。
第二に、ビジネス機能は、多くの企業がビジネスで徐々に従来のデータベースの移行プロセスから主に構成されての古いビジネスビッグデータプラットフォーム、との高い互換性を持っている能力を必要とするビッグデータプラットフォームを、シフトされ、標準SQLのサポート、および分析シナリオのさまざまなフルサポート。一方、コストを節約するために、企業はこのような大規模なバッチスキャンおよびコンピューティングのシーンなど、OLAP多次元のインタラクティブ分析シナリオ、詳細なデータアドホッククエリ、主キー、調査の低レイテンシーのポイントだけでなく、「データのコピーが使用シナリオ、さまざまなサポート」にしたいですこのようなシーンのようなリアルタイムアクセスリアルタイムデータは、プラットフォームをサポートし、第二レベルのクエリ応答を達成することができるようにしたいです。
第三に、使いやすさ、企業顧客は、以前にBIツールを使用し、ビジネスモデルのOLAP分析は、いくつかのシナリオの柔軟性と分析ツールの下でデータモデルにつながるBIツール、で確立されている制限されており、ビッグデータの時代に、ビッグデータのオープンソースのエコシステムは、企業顧客がコミュニティをたどることができるようにしたいので、多くの場合、独自のデータに自分のシステムをアップグレードし続け、新しい分析ツールの数に現れる、いつでも進行中のコミュニティを形成していますファーストレーンは、新しい分析ツール、より大きなビジネス価値を過ごすために。
ビッグデータプラットフォームの要件を満たしながら、アピールするには、間違いなく大きな課題です。これらの要件を満たすために、我々は、実際のプロジェクトの経験で蓄積し始め、だけでなく、さまざまなソリューションを試みたが、彼らはすべての問題への解決策を見つけることができません。
私たちは最初の分散低レイテンシクエリでストレージに来る思考、KVタイプは、一般的に（例えばHBaseの、カサンドラなど）のNoSQLデータベースを使用している、主キーは、低レイテンシクエリの問題を解決することができますが、クエリのビジネスであればこうした多次元クエリの柔軟な組み合わせのようなモードのマイナーな変更は、列挙は劇的に全表スキャンのパフォーマンスになります。いくつかのシナリオの下では、あなたはセカンダリインデックスを追加することによってこの問題を軽減することができますが、KV型のストレージ・ソリューションは、一般的なビジネス上の問題を解決していないので、これは、保守管理と同期の問題セカンダリインデックスをもたらします。
あなたは一般的な多次元の問い合わせを解決したいのであれば、時には我々は（例えばLinkedInのピノなど）方式の多次元配列データベースを考える、彼らはので、事前に集約し、インデックス化システムへとデータによって時系列的にデータを特徴としていますので、非常に高速なマルチ次元ルックを扱う際に、事前に計算するだけでなく、多次元分析やリアルタイム処理の利点と一緒に非常にタイムリーなデータは、パフォーマンス監視中のシーンは、リアルタイムのメトリックは、より多くのアプリケーションで解析されます。しかし、それはまた、一定の制限へのクエリの種類のサポートを持っている、など間違いなく特定のシーンを使用して企業にもたらす相関分析を、参加このアーキテクチャは、詳細なデータクエリに対処することが一般的にできないので、事前に計算されたデータの操作を行い、マルチテーブルをサポートしていません。制限。
もう一つは、（そのようにApache Solrの、ElasticSearchなど）の検索システムで、検索システムは、多次元の要約を行うことができますまた、詳細なデータを確認することができ、それはまた、インデックスベースの高速ブールクエリを反転した、同時性も高く、我々が探しているもののようですプログラム。しかし、実際には、我々は二つの問題が見つかりました：検索システムは、一般に非構造化データのために設計されているので、まず、データの拡張システムは、その結果、企業は、一般的により高い少ないコンパクト下で保存リレーショナルデータモデルのデータであります大量のデータを、第二は密接にデータストレージにのみ順番に一定の広がりを破った適切な検索エンジンで処理することができます後に導いたデータ編成と計算エンジンの検索システムに関連して、企業のクライアントは、コミュニティ分析のさまざまなを適用したいです検索システムはまた、彼自身のアプリケーションシナリオを持っているので、ツールを気に。
コミュニティはハイブは、SparkSQLは、FLINKは、これらのシステムの特性を表現するHadoopのプログラム上のSQLの多くに現在ある最後のカテゴリ・システムは、相分離およびストレージを計算することであるHDFSに保存されたファイルのための標準的なSQL機能を提供し、彼らは企業顧客の展開とユーザビリティニーズに応える、ビジネスシナリオはまた、彼らは、ソリューションの一般的なクラスとみなすことができることを示し、1つのシーンのスキャン、集約、およびその他の詳細をカバーすることができます。連続コンピューティング性能を向上させるために、それらのアーキテクチャを最適化することにより、パフォーマンス、スパーク、FLINKおよび他のオープンソースプロジェクトを改善するために、しかし、ストレージ及びデータ構成に焦点を当てていないを改善するために、計算エンジンとSQLオプティマイザの両方を向上させるに焦点を高めるため。
だから、あなたは、多くの大規模データのクエリは、さまざまなシナリオをサポートすることができますが、現在のシステムを見ることができますが、それらはシーンデザインの特定のタイプに偏っている、いない対象シーンは、ケースのいずれかで全表スキャンにいずれかの縮退をサポートしていません。バッチ、多次元分析、データのクエリの詳細なシナリオに対応するために企業で、その結果、顧客は多くの場合、データのセットを維持するために、各シーンのデータの複数のコピーを必要とします。
CarbonDataは、使用シナリオの様々なサポートするために最適化され、データのコピーは1つだけ保存されたように、この限界を打破するために精密に設計されています。
InfoQでは：技術アーキテクチャCarbonDataについて、具体的話？それの特徴と利点は何ですか？
CarbonData：ビッグデータの時代を通じてオープンは、GoogleのMapReduceの紙に由来すると言うことができる、彼はHadoopのオープンソースプロジェクトと生態系の開発のその後のシリーズを導きました。大幅に必要な事業展開を強化するよう彼の「偉大な」は、コンピューティングとストレージは建築、伝統的な縦型のソリューションから解放されたビジネス企業（主にバッチ）の一部を切り離さことで、コンピューティングおよびストレージを拡張することができます敏捷性は、非常に多くの企業は、それから、利益を計算するモデルを普及しました。
MapReduceのは、ビッグデータの時代を開いたが、それは、バッチスキャン+パフォーマンスを分散コンピューティングによって、純粋な暴力を強化することであるがゆえ、低レイテンシーのアドレス顧客の要求は、すべてのクエリシーンを照会することはできません。
現在の生態学的には、顧客に最も近いが実際に検索エンジンのようなプログラムです。良いデータ編成とインデックスを通じ、「シーンの様々な企業のデータと一致していない高速検索機能の様々な、まだ検索エンジンとストレージ層と緊密に結合された計算エンジンを提供することができます検索エンジン期待。
これは、私たちが会うの顧客に、汎用コンピューティングエンジンのためにデータのより効率的な組織を作成しない理由インスピレーションを与えるコンピューティングの利用とストレージデカップリングアーキテクチャの両方が、高性能なクエリを提供できるようにすることを、それを必要とします。このことを念頭に置いて、我々はCarbonDataプロジェクトを立ち上げました。CarbonDataの建築設計となっているより多くのビジネス、コンピューティングとストレージ相分離について。
このアーキテクチャは、能力のうち、優れたスケールを提供することができるので、この概念を確立した、我々は当然、HDFS +汎用コンピューティングエンジンのアーキテクチャに基づいて選択します。次は、我々はまだ、この枠組みの中で欠けているものを自分自身に尋ねますか？このアーキテクチャ、複製、およびHDFSはファイルを読み書きする能力を提供し、計算エンジンは、ファイルや労働力の分散コンピューティング、明確な区分を読み込むための責任がある、それは彼らがストレージ管理と問題解決の計算に位置していたということができます。見ることは困難ではない、より多くのシナリオを満たすために、HDFSは「犠牲」の多くを行う、それはファイルの内容の理解を犠牲しかし、それは唯一のフルスキャンによって計算への道をリードし、ファイルの内容の理解が放棄するからこそです実行するために、最終的にストレージにつながり、コンピューティング、データの最適化機能を有効に利用することができないということができます。
アドレスだからこの問題は、我々CarbonData開発努力は、データ編成の最適化に焦点を当てた、究極の目標を介してデータの編成は、IO性能とコンピューティング性能を向上させることです。この目的のために、我々は次の作業を行うCarbonData。
CarbonData基本機能
- 多次元データ集合：保存時のデータの次元の複数として再編成、そうストレージ上のよりよい圧縮率、データ「より凝集多次元空間」という、より良いデータ計算上効率的な濾過。
- インデックスのシーンのデザイン複数のレベルの多くの種類のように、まず、CarbonData、および検索の機能の一部を組み込んだ、多次元クロスインデックス付きファイル、多次元インデックスファイル内に存在し、各列のMINMAXインデックス、：ファイル構造をインデックス化列の預金そして、カラムなど内のインデックスを反転。第二に、HDFSストレージの特性に適合させるために、CarbonDataインデックスとデータファイルが一緒に保存され、データ自体は、インデックスの一部で、インデックスは、ファイルのメタデータ構造の別の部分に格納され、彼らはHDFSとローカルアクセス機能を提供することができます。
- 列グループ：とき、詳細なデータクエリデータの削減コストの問題列に対応して全体的に、CarbonData列預金構造が、行が預金を基準とし、預金構造は、それほど大幅にクエリのパフォーマンスデータを高めるために、CarbonDataサポート高くなりますストレージ列グループ、一部のユーザーができないことが多いフィルタとしてではなく、フィールドは、これらのフィールドのCarbonDataは、パフォーマンスを向上させるためにストアクエリにラインメモリを使用して符号化された後、結果セットは、列グループとして格納されている返すために必要に応じて。
- データタイプ：CarbonDataは現在、すべての共通の基本的なタイプのデータベースだけでなく、配列、構造体の複雑なネストされたタイプをサポートしています。同時にそれは、コミュニティ支援地図データ型、我々は地図データ・タイプを追加することを計画し、将来のことが示唆されました。
- 圧縮：列メモリ機能は非常に効率的な圧縮を行うため、スナッピー現在CarbonDataサポート圧縮、圧縮は、列ごとに別々に行われます。典型的には2-8の間の異なるアプリケーションシナリオに基づいて、データ圧縮率。
- Hadoopの統合は：のInputFormat / OUTPUTFORMATインタフェースをサポートすることによって、CarbonData Hadoopの分散の利点を利用することができる、また、生態系に基づいて、すべてのHadoopで使用することができます。
CarbonData高度な機能
- 計算エンコーディング：デルタ、RLEをコード共通に加えて、辞書のようBitPacking、CarbonDataはまた、符号化多列関節をサポートする辞書コーディング、およびグローバルコンピューティングフリーを達成するために適用されるフレームは、計算した後に直接使用することができる復号化重合は、多くのシャッフルは、パフォーマンスが非常に明白であることを照会する必要があり、計算を、ソート、データをエンコードします。
- 同時最適化と計算エンジン：効率的なデータ編成の最適化の後CarbonDataを利用するために、CarbonDataが遅れ、現在CarbonDataコミュニティは最初に作られたスパークと圧力フィルターの下SparkSQLに基づくフレームワークを強化し、深い統合、目標と最適化戦略を提供すべてのデータフレームのAPIをサポートしながら、ストレージ、およびその他の機能の増分、マテリアライズド。私は、データ編成の価値を最大化、コミュニティの努力を通じて、今後は、より多くの計算フレームワークCarbonDataとそこに統合されると信じています。
現在、これらのプロパティは、使用することを歓迎し、ApacheのCarbonDataトランクに統合されています。
InfoQでは：推奨シナリオは何ですか？どのようにパフォーマンステスト結果に？国内の使用状況やユーザー規模で、何のアプリケーション例がありませんか？
CarbonData：シーン推奨は：クイックスキャン、多次元分析、シーンのデータクエリの詳細を満たしながら店をしたいです。Huawei社の顧客のユースケースは、業界の既存の列預金方式に比べて、CarbonDataは5〜30倍の性能向上をもたらすことができます。
そのような場合などのパフォーマンステストやデータアプリケーションの詳細については、してください有料マイクロチャンネル公衆番号への注意ApacheCarbonData、およびコミュニティ https://github.com/apache/incubator-carbondata
InfoQでは：CarbonDataエネルギーとそれの完璧な組み合わせを正規化する現在のスパーク？メインフレームワークはまた、それに対応している何ですか？
CarbonData：現在CarbonDataは、Spark、高度な機能上記の特定の参照との緊密な統合を行っています。
InfoQでは：あなたはどのような開発計画の、将来のプロジェクトを持っていますか？どのような機能性を高めるだろうか？それの後のオープンソースプロジェクトの継続的なメンテナンスを確保するには？
CarbonData：次のコミュニティの焦点は（：FLINK、カフカや他のリアルタイムデータのインポートCarbonDataとの統合など）生態系の統合を改善し、システムの使いやすさを向上させることです。
CarbonData最初の月、関係するオープンソースのコミットの提出数百人、および20以上の貢献者たちはアクティブなプロジェクトを追跡していきます、があります。10の以上のコア貢献者はまた、まちづくりに参加していきます。
InfoQでは：でCarbonDataの設計と段階を経たプロセスで開発し、Apacheインキュベーターに、最大の困難が経験されているもの？感情や経験、どのようなあなたはそれを共有することができますか？
CarbonData：CarbonDataチームほとんどの人は、Apache Hadoopの、スパークの開発におけるコミュニティの参加の経験を持っている、と私たちは、地域社会や仕事のプロセスに精通しています。最大の困難は、新しい高性能ビッグデータ生態学データ形式CarbonDataを受け入れるようにApacheのコミュニティを説得するために、インキュベーターの段階に入ることです。月を通してオースティン、米国ではOSCONオープンソースのイベントで、CarbonData技術DEMO基調講演と実演を行い、優れたインフラと優れたパフォーマンスを示すことCarbonData結果。
InfoQでは：あなたはチームを持っていますか？あなたは良い成長のチームを持っていることを確認するには？
CarbonData：CarbonDataはグローバルチーム（エンジニアから中国、米国、インド）のチームで、我々はすぐにApacheのオープンソースコミュニティの作業モードに対応できるように、グローバル化のこのモードを体験。
インタビューゲスト：PMCのApacheのCarbonData、コミッタ李くん、陳梁。