Hive-如何基于分区优化

2011年5月5日 由 hongmen 没有评论 »

Hive优化 – 如何基于分区优化 最近一直做系统优化,但从建模的角度今天有个小优化,原理比较简单,效果可能不是很大,但很有意思。 这种优化的好处是不用改变sql代码,对用户是透明的。 所以分享下。 – 由于hive在文件基础上,而会全部扫一个分区里面的内容。 hive表的概念是基于hadoop的文件系统hdfs,表其实是分布式文件里面的一个文件目录。 再加上没有索引,如果要取的表里面的某些字段就必须全部扫描该表对应的文件目录 – 如:建表way1: create table if not exists t_hm_0501_test_01 ( uid string, nick string ) PARTITIONED BY (pt STRING , bc_seller string ) row format delimited fields terminated by ‘\t’ lines terminated by ‘\n’ stored as textfile; – 在hadoop的hdfs中其实是这样的目录 – t_hm_0501_test_01表对应hdfs里的如下文件目录。 /t_hm_0501_test_01 —- 一级分区 /t_hm_0501_test_01/pt=20110501000000 /t_hm_0501_test_01/pt=20110502000000

提升磁盘IO性能的几个技巧

2011年5月5日 由 庄远 没有评论 »

  目前磁盘都是机械方式运作的,主要体现在磁盘读写前寻找磁道的过程。磁盘自带的读写缓存大小,对于磁盘读写速度至关重要。读写速度快的磁盘,通常都带有较大的读写缓存。磁盘的…

Redis内存存储结构分析

2011年5月5日 由 五竹 没有评论 »

五竹,20110418

Redis: A persistent key-value database with built-in net interface written in ANSI-C for Posix systems

1 Redis 内存存储结构

本文是基于 Redis-v2.2.4 版本进行分析.

1.1 Redis 内存存储总体结构

Redis 是支持多key-value数据库(表)的,并用 RedisDb 来表示一个key-value数据库(表). redisServer 中有一个 redisDb *db; 成员变量, RedisServer 在初始化时,会根据配置文件的 db 数量来创建一个 redisDb 数组.…

Hive源码解析-之-语法解析器

2011年5月3日 由 hongmen 没有评论 »

hive 源码 解析

你的数据服务 OUT 了吗

2011年4月29日 由 hongmen 没有评论 »

你的数据服务OUT了吗 数据服务,三种阶段 用户要数据,被动的勉强提供 用户要数据,可以便捷、准确、及时、个性化的获取 用户不知道,主动地个性化地推送给他们可以帮助他们工作、生活的数据。 用户:(是你公司的运营、员工、业务人员、甚至技术人员、老板等) 不同阶段提供不同的服务,最终目的都是让数据产生价值!! — 当你公司(几乎很多创业者公司)的数据本身就是不是很多,数据的代表性、支持判断的能力肯定是有限的,很难推动所有的人大面积的利用数据,因为人们很难尝到数据分析的甜头。 这个时候你可以勉强、被动的给某一部分人提供一些数据。这个时候你基本上可以达到第一个境界。 同时,这样也是可以忍受、比较合理的。 服务模式需要革命了 随着时间推移,业务变化很快,数据量膨胀,面对业务、运营人员也会越来越多,报表的数据也越来越多,进入第二个阶段时机比较成熟了。 被迫的需求,数据产生价值的机会。因为业务越来越庞大,越来越多的问题不能靠经验靠人力精准解决所有问题。 数据量级越来越大,经过统计分析得到的数据肯定会越来越来具有代表性、价值、准确性,更好定位和解决问题。数据意识可以改变了,是可以大规模推广数据化运作的绝佳机会。各路人应用数据的态度要改变了,数据分析支持决策再也不是辅助手段,应该成为重要手段。 在这个阶段,我们应该广泛的传播数据理念,传授数据分析方法,鼓励使用数据,让运营人员尝到数据的甜头,从而数据产生实实在在的商业价值。 – 相应的数据服务模式也要满足这几点,如果满足不了,说明我们的方式过时了,相应的技术架构和方向也偏了。我们不能通过遏制用户的需求来维持现有的状况,服务方式不能给很多人创造价值,反而成为数据产生价值的瓶颈。 — 这个阶段,如何判断一个数据服务好不好? 最核心的判断标准:   能不能最便捷准确的让用户拿到他想要的数据 — 可能我们心里都期盼着给用户那样的服务,但在实际操作中会或多或少的走到这样那样的误区,甚至还没有发现已经陷了进去。这种负面影响是慢性的,不会突发,温水煮青蛙,很难发现,看看一下情况,是不是我们也在犯这样的问题呢? 1.  给一堆数据上让用户去找,用户比较难的去找到。 尤其是常见的报表服务:用户需要看某些数据,经ETL人员开发出数据报表,让用户去看,这个看起来蛮好,但随着报表的数量增多,达到一定量级,还要考虑报表分享性,其他用户就需要在一堆报表数据中去找他关心的数据指标。 2. 提数据需求流程周期长、响应低,实时性低。灵活性低。 不是每个都是那么的具有前瞻性,可能很多人是遇到问题才需要数据解决。经常反映慢,很多人开始潜意识的避免用数据,因为他要考虑到获取数据的代价。 3. 给用户一个数额的限制。这是个两面性的东西,一方面让用户不能乱提,一方面让遏制了用户获得数据,缺少灵活性。这个也是一个至少需要给出一个科学的限度值的事情。限制太多了,降低数据使用机会,当然减少了数据产生价值的机会,限制的太少,ETL人员开发是压力太大,搞不定!! 这个时候你想跳出这种恶性循环,唯一的办法就是让用户随心所欲的拿到数据。 数据产生决不能再靠人力(ETL开发人员),你不可能不断的加人来解决所有问题。 开始需要比较强大的系统(内功)来做很多事情,让普通用户可以自己直接获得数据。 一帮人去维护这样的系统就可以了。 ——- 第三个阶段,提供数据服务是主动的!! 第二阶段需要一帮人维护系统,这个阶段需要再加另一帮人:需要不断地总结和传播数据分析方法,让每个普通员工都能不仅拿得到数据,而且懂得该拿什么样的数据!! 这个阶段一定还需要有真正的高层倡导、推动利用数据、产生利用数据的文化。这个时候,全面推动数据产生价值,整个公司的能力肯定是无可比拟!! 为什么要转型,因为现有的东西(方式、模式、架构等)满足不了未来的发展, 这种事情是堆雪球的效用,连锁反应。 不转,方向全部错了,很多东西的负面营销是成倍迭代的。 如:技术积累利用率应该是不高的;消耗了人力物力,事倍功半!!; 尤其对于架构反思更为重要,因为现在的服务模式不会满足将来的需求,技术沉淀方向出现偏差,迟早会出现瓶颈,这种瓶颈只能 转成功了:方向对了,赢得了未来,很多事情都是指数性的增长。 转不成功:信心大损,死的更快!! 所以转型一定要成功。 数据服务,需要站在一个影响公司命运的战略高度去看。 欢迎分享交流^_^ 微博:www.weibo.com/xiaodongdata @ 淘宝数据红门-马晓东 QQ :