有时我们会进行数据分析或数据抽取,并且需求是来自于产品经理(或运营小妹或市场推广人员),基于他们的经验差异和对技术的理解程度可能会描述不清楚他们到底需要怎样的数据
这时就需要协助他们,并且当面将需求翻译成简明的描述性语言(以便后面翻译成各种操作),并且一定要再三确认有无遗漏和调整
如果这一步偷懒省略掉了,极有可能产生这样的情况,在一个极大的表里你花费了一整天导出来结果,他看到后,他会说 “我不是这个意思,其实当时我说的是balabala……” ,这时就能感受到有一种状态叫蹉跎,有一种情绪叫懊恼~~~ 之所以可能花费一天这么久(还可能会更久),有时是因为某些特征列没有索引,并且数据量真的非常大,而不加索引也是为了考虑业务中写操作的性能,这时一个独立于业务的数据仓库就太有必要了
总之最后要形成如下的一张任务和条件列表:
task1
需要: userid , QQ号
task2
需要:userid,手机号
有了上面的列表后,就可以最大程度的理解和明确需求,节省时间
分析完任务列表后我们要将目标锁定在可以提供数据的表上
最好可以将 show create table xxx
的结果放在一边,以便随时参阅
Tip: 主要留意其索引列
test_qa.users (`id`) (`user_key`) (`user_name`) (`nick_name`)
cheshi_qa.cks (`id`) (`user_id`,`the_date`) (`the_date`)
之所以要这么做是为了在生成结果的过程中,尽量提醒自己使用索引来完成,否则大表的数据选取过程会非常难熬
create table tmp_1 (select id,qq from test_qa.users where unix_timestamp(regsitered_at) >= unix_timestamp(date_sub(now(),interval 60 day)) and unix_timestamp(regsitered_at) < unix_timestamp(date_sub(now(),interval 30 day)) and qq is not null);
Tip: 根据个人对 SQL 的掌控程序,其实很有必要生成一些简单的中间结果来拆解和简化整个过程,这样也可以步步为营,有效避免一个语句失败又得整个重头再来,这些中间结果也最好放在自己创建的临时数据库中,为了一定程度上隔离锁域,尽量不波及无辜
由于 regsitered_at 并没有索引,所以可以使用函数对其进行加工,如果有索引,就不要这样使用,否则索引就浪费了
create table tmp_2 (select distinct(user_id),count(user_id) as ct from cheshi_qa.cks where the_date >= '2016-03-
本文系转载,前往查看
如有侵权,请联系?cloudcommunity@tencent.com 删除。
本文系转载,前往查看
如有侵权,请联系?cloudcommunity@tencent.com 删除。