この記事は、NetEaseのビッグデータ教師であるHongxiang Jiang DataFunTalkが共有する「Impalaプラットフォームに基づくインタラクティブクエリシステムの構築」-「プロセスの底からデータ駆動型ビジネスへのビッグデータ」に基づいて編集されています。変更されていない当初の意図に基づいて分類されました。
本日共有したコンテンツの概要を以下に示します。1つ目はインタラクティブクエリの特徴、ビッグデータプラットフォームから選択できるクエリプラットフォームは多数、2つ目はプロジェクトに基づいたプラットフォームの選択方法について説明しています。そして、選択要因は何ですか。3つ目は、Impalaの基本的な導入とImpalaの改善について説明します。次はimpalaのアプリケーションシナリオであり、最後にImpalaの基礎となるデータフロー、アプリケーションシナリオ分析、およびいくつかの既存の問題を紹介します。
インタラクティブクエリの最初の機能は大量のデータです。2番目のリレーショナルモデルは比較的複雑です。設計によっては、多くの種類のリレーショナルモデルがあります。高い応答時間の要件もあります。ほとんどの場合、クエリの戻り時間は10秒未満である必要があります。データの量に応じて、さまざまなストレージオプションが選択されます。数百万のデータには、MySQLとPostgreSQLが使用され、数百万から数百億レベルの場合、従来のデータベースでは対応できず、分析データウェアハウスを使用してImpala 、 Presto 、 Green Plum 、 Apache Drillを実現します。オフラインを使用して、数百億レベルを超えるビッグデータ分析を行うことは困難です。ハイブ、スパークを使用したデータウェアハウス。
BEシステム、多くの実用的な広いテーブルがある。理由は、その多くの次元で、利用者は徐々に情報を蓄積した後、寸法の数百を持っていることがあります。あなたは50次元をフィルタリングする場合は、このように反転行などの一部の特殊なデータ構造を結合するワイド・テーブルを使用します。簡単に実現できます。Elastic Search 、 Solrは検索エンジン、 Click Houseはロシアで開発されたより優れたパフォーマンスのシステムですが、参加サポートは制限されており、 Druidは広告プラットフォームでより多く使用されています。以下のような組み合わせのモデルもあり、弾性Searchは、 Solrには、より多くの使用一般的に、グリーンプラム、プレスト、インパラ。
次に、プラットフォームの選択を決定する要因について説明しましょう。1つ目は、私たち自身のプロジェクトに精通していることです。プロジェクトリーダーがこのプラットフォームに精通している場合は、このプラットフォームを選択します。プロジェクトに精通していない場合は、大企業を選択して、大企業と同じアプリケーションを承認して使用します。前の2つが利用できない場合は、パフォーマンスと長所と短所から、このシステムに適しているかどうかを評価します。
3番目のポイントに焦点を当てると、最初のポイントはデータボリュームです。システムのデータボリューム容量によると、プラットフォームは少なくとも私の最小パフォーマンスインデックスに到達する必要があります。アーキテクチャの複雑さもあります。システムを最終的に起動し、 CLAを保証する必要があります。アーキテクチャが複雑な場合、より多くの問題が発生するため、アーキテクチャの選択は比較的簡単です。最後は運用・保守・諸経費です。運用・保守のコストが非常に高いため、頻繁に変更することはできません。何かを変更したい場合は、プラットフォームに慣れておく必要があり、選択に影響します。 。
次に、主にImpala、Presto、Greenplumを考慮して、選択がどのように行われるかについて説明しましょう。最初に考慮すべきことはデータソースです。私たちのデータの多くはHDFS上にあるため、Greenplumは完全に閉じられており、独自に作成されたストレージアーキテクチャであるため、絶対に適していません。コミュニティ環境とアーキテクチャは類似しており、アーキテクチャにほとんど違いはありません。パフォーマンスの面では、インパラはプレストよりもわずかに優れています。プログラミング言語などの他の機能もありますが、C ++はJavaよりも少し高速に実行されるため、C ++で記述されたプラットフォームを選択する傾向があります。最後に、私はImpalaを選びました。
これら3つはすべてMPPアーキテクチャであり、Impalaの実行ノード全体がステートレスであるため、ノードを停止して再起動しても問題ありません。Impalaはハイブストレージと互換性があり、上位のApacheプロジェクト、成熟したコミュニティ、複数のデータソース形式の互換性、効率的なクエリパフォーマンスなどのいくつかのポイントは、すべて私たちが検討する独自の選択要素です。
次に、複数のデータソースと互換性のあるImpalaアーキテクチャについて説明します。つまり、メタストアはさまざまなDBに直接接続し、カタログを使用してメタデータサービスを提供します。通常、ハイブのメタストアを使用してデータを取得することにより、直接またはカタログを介してDBに接続できます。Impalaが効率的である理由は、元のデータをキャッシュし、 catalogedがキャッシュを参照してデータを取得し始めるためです。パブリッシュおよびサブスクライブサービスであるstatestoredサービスがあり、すべての状態とローテーションはstatestoredサービスで実行されます。左側はimpalaの実行ノードです。すべてのクエリはこれらのノードに送信されます。ノードが実行されると、関連するすべてのノードに送信されます。impala全体はステートレスであり、すべての接続はコーディネーターのようです。
Catalogd是元数据服务，其主要的问题是你做select时，impala也会缓存一部分数据，它不会进入catalogd服务，但是做DDL操作会应用catalogd服务。Statestored(sub/pub )有很多topic，所有的impala节点去订阅这些topic上的相关消息，Statestored实际是在很多topic上做了一个消息订阅。Impala节点有SQL解析、执行计划生成，还有是数据查询、聚合、结果返回。
上图是一个查询进来，各个节点是一个怎么样的协调方式。如一个查询进入这个节点，这个节点就是Query Planner，负责生成执行计划，将计划向周边节点传输，最后将结果返回Query Planner，如果有聚合，先聚合然后返回总的Query Planner上，然后进行相关聚合将结果返回。
Impala性能优势有元数据缓存，而且impala会缓存HDFS上相应表数据在blog里的信息，因此查询时会有一个本地读，判断元数据是否在本地，通过本地转读方式，log才能连接数据。第二点并行计算，Query Planner生成执行计划将其发往周边节点，然后汇聚。第三个利用codegen技术，有些依据执行环境生成执行代码，会对性能提升很大。再一个就是很多算子下推，如果追求高性能不许实现算子下推，将存储层与计算层交互变得更小，在底层过滤而不是在计算层，这样对平台整体性能提升较大。
broadcast join在大表关联时，将小表缓存到所有节点上，然后返回数据做聚合。partition join应对两张表都是大数据表，如一个事件表积累上百亿数据，而用户有五亿，那么就不能通过broadcast join绑定到所有节点上，因此在每个节点做一些分区join操作然后在到上面去。还有一个CBO，目前来说还不是很准，有时会偏差很大。有并行计算就有并行聚合，数据生成前提前聚合，依据group by 的column 进行聚合的合并操作。
接下来介绍下impala支持哪些存储引擎，常用的有hdfs，还有kudu，为了解决HDFS和HBASE进行交互而产生的一个产品。Hbase主要是一个kb查询，但是如果有大量扫描时性能很差，而大批量扫描是HDFS的强项，但是做不了kb查询。Alluxio是一个文件记录换缓存，底层也可以对接HDFS，支持多级缓存。我们做Alluxio主要是应对热力数据，以前使用缓存解决这个问题。
如果要使用impala平台如何实现对接呢，首先它有整个授权和认证机制。认证可以对接kerberos、LDAP、Audit log，只有身份认证了才能访问系统。授权通过Apache Sentry，粒度有：database、table、column，权限：select、insert、all配置开启(authorization_policy_provider_class=org.apache.sentry.provider.file.Local G roup R esource A uthorization P rovider)。这些是你如果要上线必须要做的一些事情。
对于一个平台有很多用户在上面做一些任务，需要进行资源管理。目前采用Admission Control机制，他能保证每一个impala节点上都有直接用户配置，每一个队列可以设置资源总量，也可以设置每一个SQL的资源大小。这个配置是针对impala节点，如给一个用户设置300G，有100个节点，那么每个节点只分配2-3G，超过这个限额也是要被禁止的。资源隔离既要考虑总的也要考虑单独的，Impala节点是通过statestored的impalad-statistics topic项同步信息，由于statestored通过心跳与impalad 保持通信，这个资源信息实际上有些延迟;目前配置中，只有内存项有实际效果，vcore没有实现隔离，队列名配置如果与认证用户名相同，该用户提交的SQL自动分配到该队列。
Impala有个web端，虽然简单但很有用，整个问题解决、定位经常用到。每一个组件都会提供一个web端，分配相应的端口，基本信息有集群节点、Catalog信息、内存信息、Query信息。Web端能使此案节点内存消耗查看（每个对垒内存消耗、每个查询在该点内存消耗），该节点查询分析（查询分析、SQL诊断、异常查询终止），还有就是Metrics信息查看。上图是我们配的一些队列，每一个队列消耗资源情况等。用impala做join分析，将每个SQL中执行计划都具体化了，界面上的标签如query、summary、memory等都可以做SQL分析。
讲了impala的优点、特点、如何用，但是基于开源平台，也是有很多缺陷。第一个Catalogd&statestored服务单点，但是好在对查询不受影响，如果Catalogd挂掉，元数据更新就不会同步到整个impala节点。Statestored挂掉，对于更新也不会同步，只会保挂掉之前的信息。第二个就是web信息不持久，显示的信息都是存在历史信息中，如果impala重启后信息就会没有了。资源隔离不精准，还有就是底层存储不能区分用户，还有就是负载均衡，每一个impala都可以对接SQL，但是有100个impala如何接入不好解决，因此对impala实现haproxy。还有与hive元数据同步需要手动操作，impala是缓存元数据，通过HDFS操作是不会感知这种操作的。
有缺陷就有改进，首先基于ZK的load balance，因为impala是和hive绑在一起，hive的server是基于ZK，将你需要访问的impala的uri写入一个维度中去，hive原生就是基于ZK的多维节点访问。第二个就是管理服务器，因为impala页面的信息不会保存，利用管理服务器保存这些东西，排查时在管理服务器上查，不会因为你impala节点多而信息不保存。细粒度权限&代理，通过impala访问HDFS实现底层权限控制。Json格式，这个就是偏应用需求。兼容ranger权限管理，因为我们整个项目权限管理是基于ranger的。批量元数据刷新，也是实际应用中出现的问题，有时会一次改好几十个表，如果每次都刷新会很麻烦。元数据同步，改造hive和impala，每次hive改变，将改变写入中间层，impala去获取中间层实现同步。元数据过滤，数据量很庞大时，其实交互式查询很大一部分表是用不到的，而impala只对某一部分有需求，因此通过正则表达式过滤掉不必要的数据。对接ElasticSearch查询，将ES涉及的算子下推过去，如多维过滤查询，根据倒排属性比hash将数据聚合要快。
Impala应用场景介绍，上图是一个部门大数据平台架构，从kafka数据到HDFS，结构化到半结构化这是数据的接入。经过数据清洗，再接入到上层，上层应用了ES存储，最上面就直接用impala来进行查询，这基本就是分析系统的框架。
上記は、Youshuと呼ばれる当社のBI製品の1つです。最下層は、チャートとマップ上のデータを接続するデータ分析レポートプラットフォームであるimpalaプラットフォームにも接続されています。構造化データまたは非構造化データを直接ハイブに書き込み、 impalaを使用してメタデータの同期を認識、実現し、ユーザーはimpalaを介して直接クエリを実行します。考慮する必要のある問題には、メタデータの同期が含まれます。ETLは、認識せずにデータインパラを書き込み、メタデータの同期に依存します。リアルタイムのデータの問題により、NNの不安定性を引き起こす多数の小さなファイルを回避し、毎回書き込まれるファイルのバッチはできません。小さすぎます。もう1つの解決策は、kuduを使用して小さなファイルの問題を解決し、リアルタイムデータをkuduに書き込み、kuduとhdfsの共同チェックを実装することです。impalaでkuduテーブルとhdfsテーブルの両方を確認できます（詳細を知りたい場合） 「NeteaseBigData」を検索できます）。
著者について
2011年にNetEaseに入社したJiangHongxiangは、NetEaseデータベースカーネルとデータウェアハウスプラットフォームの責任者である「MySQLKernel：InnoDB Storage Engine Volume 1」の著者の一人である、シニアデータベースカーネルとNetEaseマンモスビッグデータプラットフォームテクニカルエキスパートです。データベースカーネルテクノロジーとビッグデータプラットフォームの基盤となるテクノロジーの開発に従事し、NetEaseデータベースコアの全体的な技術ソリューションとビッグデータプラットフォームの高度なテクノロジーの研究と実装を主導し、内部MySQLを主導してきました。ブランチInnoSQL、HBase、自己開発の時系列データベース、自己開発のリアルタイムデータウェアハウスおよびその他のさまざまなプラットフォーム。データベースカーネルおよびビッグデータプラットフォームで豊富な経験があります。
- 終わり -
あなたがそれを好きなら、それを共有しましょう~~
他の記事を見ますか？
レビュー・ビッグデータプレシジョンマーケティングにおけるビットマップの適用
レビュー・ビッグデータプラットフォームのモデル思考とユーザー成長の実践
