impala怎么判断从hive里刷新那部分元数据

一、impala怎么判断从hive里刷新那部分元数据

1、 Impala通常和Hive共用同一个metadata数据库(通常是MySQL/PostgreSQL),所以Impala能够读取到Hive的元数据信息.如果Impala需要访问Hive表,需要将Hive metadata刷新到impala中.

2、在Hive中Create/Drop表后,或者HDFS rebalance,或者手工删除HDFS的文件后,则需要在impala中执行下面两行命令:

3、INVALIDATE METADATA table_name;

4、第一行命令 INVALIDATE METADATA告诉impala指定的 table元数据已经过期, impala将在下一次使用到该表时自动刷新元数据,第二行命令即触发impala去更新元数据,以免将来真正使用该表耗时太久.

5、如果Impala已经知道了Hive表的存在后,又通过Hive增加或删除分区或alter table,使用 refresh命令即可更新元数据. refresh是对元数据进行增量更新,和INVALIDATE METADATA相比, refresh命令使用成本低很多.

6、利用catalogd提供元数据服务。可以直接连DB也可以通过catalogd，一般是利用hive里的metastore获取数据。Impala高效的原因是其将原始数据缓存下来，catalogd启动会浏览缓存获取数据

7、因为impla默认catalogd会缓存，因此如果你重启的后，catalogd会将缓存数据存入到内存中，

二、数据仓库与数据库的区别

简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。

数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。

数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。

数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。

单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。

显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。

数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。

“面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。

“与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。

“不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。

数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。

补充一下，数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库必须有如下几点优点，否则是失败的数据仓库方案。

1.效率足够高。客户要求的分析数据一般分为日、周、月、季、年等，可以看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，设计不好的数据仓库经常会出问题，延迟1-3日才能给出数据，显然不行的。

2.数据质量。客户要看各种信息，肯定要准确的数据，但由于数据仓库流程至少分为3步，2次ETL，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不是效益。

3.扩展性。之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，客户不用太快花钱去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。

三、大数据时代:大数据是什么

大数据是什么？是一种运营模式，是一种能力，还是一种技术，或是一种数据集合的统称？今天我们所说的“大数据”和过去传统意义上的“数据”的区别又在哪里？大数据的来源又有哪些？等等。当然，我不是专家学者，我无法给出一个权威的，让所有人信服的定义，以下所谈只是我根据自己的理解进行小结归纳，只求表达出我个人的理解，并不求全面权威。先从“大数据”与“数据”的区别说起吧，过去我们说的“数据”很大程度上是指“数字”，如我们所说的客户量，业务量，营业收入额，利润额等等，都是一个个数字或者是可以进行编码的简单文本，这些数据分析起来相对简单，过去传统的数据解决方案（如数据库或商业智能技术）就能轻松应对；而今天我们所说的“大数据”则不单纯指“数字”，可能还包括“文本，图片，音频，视频……”等多种格式，其涵括的内容十分丰富，如我们的博客，微博，轻博客，我们的音频视频分享，我们的通话录音，我们位置信息，我们的点评信息，我们的交易信息，互动信息等等，包罗万象。用正规的语句来概括就是，“数据”是结构化的，而“大数据”则包括了“结构化数据”“半结构化数据”和“非结构化数据”。关于“结构化”“半结构化”“非结构化”可能从字面上比较难理解，在此我试着用我的语言看能否形象点地表达出来：由于数据是结构化的，数据分析可以遵循一定现有规律的，如通过简单的线性相关，数据分析可以大致预测下个月的营业收入额；而大数据是半结构化和非结构化的，其在分析过程中遵循的规律则是未知的，它通过综合方方面面的信息进行模拟，它以分析形式评估证据，假设应答结果，并计算每种可能性的可信度，通过大数据分析我们可以准确找到下一个市场热点。基于此，或许我们可以给“大数据”这样一个定义，“大数据”指的是收集和分析大量信息的能力，而这些信息涉及到人类生活的方方面面，目的在于从复杂的数据里找到过去不容易昭示的规律。相比“数据”，“大数据”有两个明显的特征：第一，上文已经提到，数据的属性是包括结构化、非结构化和半结构化数据；第二，数据之间频繁产生交互，大规模进行数据分析，并实时与业务结合进行数据挖掘。解决了大数据是什么，接下来还有一个问题，大数据的来源有哪些？或者这个问题这样来表达会更清晰“大数据的数据来源有哪些？”对于企业而言，大数据的数据来源主要有两部分，一部分来自于企业内部自身的信息系统中产生的运营数据，这些数据大多是标准化、结构化的。（若继续细化，企业内部信息系统又可分两类，一类是“基干类系统”，用来提高人事、财会处理、接发订单等日常业务的效率；另一类是“信息类系统”，用于支持经营战略、开展市场分析、开拓客户等。）传统的商业智能系统中所用到的数据基本上数据该部分。而另外一部分则来自于外部，包括广泛存在于社交网络、物联网、电子商务等之中的非结构化数据。这些非结构化数据由源于 Facebook、Twitter、LinkedIn及其它来源的社交媒体数据构成，其产生往往伴随着社交网络、移动计算和传感器等新的渠道和技术的不断涌现和应用。具体包括了：如，呼叫详细记录、设备和传感器信息、GPS和地理定位映射数据、通过管理文件传输协议传送的海量图像文件、Web文本和点击流数据、科学信息、电子邮件等等。由于来源不同，类型不同的数据透视的是同一个事物的不同的方面，以消费客户为例，消费记录信息能透视客户的消费能力，消费频率，消费兴趣点等，渠道信息能透视客户的渠道偏好，消费支付信息能透视客户的支付渠道情况，还有很多，如，客户会否在社交网站上分享消费情况，消费前后有否在搜索引擎上搜索过相关的关键词等等，这些信息（或说数据）从不同的方面表达了客户的消费过程的方方面面。因此，一般来说，企业用以分析的数据来源越广越全面，其分析的结果就越立体，越接近于真实。因此，大数据分析意味着企业能够从不同来源的数据中获取新的洞察力，并将其与企业业务体系的各个细节相融合，以助力企业在创新或者市场拓展上有所突破。针对“数据量”这个话题，亚马逊CTO Vogels曾经说过，“在运用大数据时，你会发现数据越大，结果越好。为什么有的企业在商业上不断犯错？那是因为他们没有足够的数据对运营和决策提供支持。一旦进入大数据的世界，企业的手中将握有无限可能。”可以预料，在不远的未来，企业如何通过抓住用户获取源源不断的数据资产将会是一个新的兵家必争之地。在这个层面上，Facebook、Twitter、Google、Amazon，包括电信运营商等领先企业具有无可比拟的优势。在大数据的领域里是否数据量越大越好？很多时候我们写文章，并不是想要去重复某一个众所周知的事实，而更多的是想从另外一个角度试图去质疑那些已成事实的事实，并不是想要去推翻，而只是去看这个事实是否存在另外的可能性，虽然很多时候我的那些质疑会漏洞百出，并显得幼稚可笑，但我觉得一个事物的健康发展需要不同的声音，而这正是我们写文章的意义所在。所以，我现在问题是，在大数据的领域里是否数据量越大越好？对于这个问题，我觉得应该分两个层面来看，第一个层面是，对大数据这个整体而言，数据肯定是越大越好的，多元的数据能让不同行业，不同组织都可以从大数据中寻找到解决问题的方法，也是基于此，现在越来越多的企业组织通过不同的终端、应用或者其他手段去疯狂地收集多元的数据，大数据让人们能有足够的能力和视野将地球（包括地球上的一切）作为一个整体去看待，这是在从前无法想象的。第二个层面是，对于大数据的具体应用而言，数据量是否越大越好，我却有不同的看法。我的理解是，在大数据的实际应用中你用以分析的数据量越大，你能得到的东西就越多，而至于得到的那些东西是否是你所需要的，或者对你是否有价值的，没有人能保证。就如同树林里有100条路，每条路上都有一些你觉得有意思的东西，如果你有足够的时间，你可以走遍这100条路，收获很多有意思的小东西，但不是每一条路都会让你得到真正有价值的东西。经常做数据分析的朋友应该会有同感，在分析的过程中你会发现不同的数据通过不同的组合导入不同的分析模型会得到很多不同的结果，有时候会有一些很新鲜的结果被发现，这会让你很惊喜，但大部分这些新鲜的结果最后只会出现在你的微博里，而不会出现在正式的分析报告中，因为分析报告是为解决某一具体问题而存在的，旁枝末节太多会显得臃肿且容易混淆。所以，我认为，在大数据的具体应用面前，我们先要做的是把“大数据”这个概念忘掉，我们必须弄清楚到底想从大数据中得到什么，然后带着目的去收集有用的数据，输入至分析模型中，直接导向我们想要的结果。否则你将花费大量时间、资源成本去获取数据，分析数据。我们需要大数据应用是能够帮助解决问题的行为洞察，而不是试图研究每一条能够得到的信息。不得不说，大数据的世界太魔幻了，里面的诱惑很多，如果你不是带着明确的目标去应用，你很有可能被陷入在五光十色的诱惑中无法自拔。即使你走进了一座金山，最后你能带走的最多也只是你能提动的一小口袋。另外，这同时也揭示，为了避免应用者困在“大数据的金山”，大数据必须往下细化，针对不同行业不同领域的特定问题制定不同的解决工具，未来大数据将会遵循消费化模式，核心基础设施将作为服务或应用程序来提供。