Dong Guo's Blog

数据驱动的核心:Controlled Experiments

| Comments

越来越多人和公司认同data-drivern决策的必要性,不仅是滴滴、Google、Microsoft、Linkedin、Amazon这些科技公司,也包括传统意义上的非技术公司。Data-drivern的核心是Controlled experiment(即大家常说的A/B Testing),按照字面理解就是将其它影响因素都control住,保持一致,实验结果只由预设的不同方案影响。

在滴滴算法团队,很多时间和精力都在做各种策略和算法实验,比如我们比较不同的订单分配策略哪个可以让接驾时间更短,比如评估新的动态定价策略对乘客的留存和活跃度有什么样的影响。基于近期在做实验方面遇到的一些挑战思考,以及上个周末看的几篇文章写一个小结在这里。先介绍几个controlled experiment相关的基础而重要的点,总结做controlled experiment中的一些遇到的难点和挑战,最后是一些实验方案和架构的构想。

ArchSummit2016干货分享

| Comments

上周去参加了ArchSummit 2016,是一个偏架构技术的会,也有一些talk结合了架构和算法一起介绍。我听了十几个和大数据架构和算法比较相关的talk,做了一点小结分享给大家。

Highlights

  1. 订单分配:美团和菜鸟物流(阿里旗下)都简单介绍了自己的订单分配算法,和滴滴分单场景有近似之处。美团的外卖配送在某些方面比滴滴的分单问题更有挑战性,有一些思想可以借鉴,比如权衡体验和效率的“压单”;

  2. 热门的机器学习算法:

    GBDT + LR:腾讯微信的用户相似度预估、广告点击率预估,阿里推荐算法的点击率预估都在用。具体可以看Facebook在2014年的文章;

    FTRL:这个算法是google在2011年左右publish的,被国内各大公司作为online learning的重要选择,我之前实验中做过评估,其显著的几个优点:样本只需要过一遍,预测效果top,稀疏模型

  3. 大规模分布式机器学习框架:

    Parameter Server:若干公司提及,包括一些规模不太大的公司(第四范式、一点咨询),目前来看parameter server还是大规模特征下的分布式机器学习框架的首选

    Spark:spark简单易用,当特征规模在千万之内还是很不多,ThinkData给出自己开源的分布式机器学习算法库,据称在预测效果和训练速度上都显著优于MLlib

  4. 图算法:微信在做定向广告时,需要构造用户在朋友网络上的“社交相似度”特征,其使用了KDD2016最新的node2vec算法,类似Random walk + Word2vec,据称效果显著,有兴趣的可以去看paper;

  5. 知识图谱(Knowledge graph):Facebook的knowledge graph将这块带的很火,在需要理解用户意图给出用户想要的结果的场景下大多会涉及。 本次有2个talk涉及:阿里的自动问答系统,一点咨询(类似今日头条)的新闻搜索;

  6. 深度学习:这次几个talk上提到,不过都还是在尝试,感觉没有DL在其应用中还没发挥核心作用。包括阿里的自动问答,第四范式

  7. 架构引擎相关,有2个talk影响较深刻,一个是阿里双十一的流量规划和压测实践(流量隔离压测 + 配比拉平可以减少直接在线上做压测的风险和人员投入成本),另一个是百度的大数据系统技术栈(百度文件系统BFS,分布式数据库Tera都已在github开源,值得学习一下)

slides 下载

出行的未来

| Comments

在滴滴待了16个月了,这一篇说说我理解的未来的智能出行:

  1. 整个城市的车辆都由一个中枢系统控制,车辆的路径规划和控制可以最大化整体城市居民的出行效率,交通拥堵从此消失;

  2. 车辆是自动驾驶的,所以非常安全,车内变成真正的生活空间,交通标识和信号灯也不需要了;

  3. 人们不再购买车,车也不再属于个人,因为在城市的任何区域任何时间1分钟内就可以呼叫到车;

  4. 车辆都是电动的,会自己选择合适时机去电池站更换电池。由于车辆没有驾驶室,且车辆之间可以像积木一样拼接,车辆的外形也会发生变化;

归纳起来就是几个关键字:共享出行、电气化、汽车网联、自动驾驶

滴滴、Uber、Google以及一众高校正在推进这一科幻版的未来场景:

共享出行:其是滴滴和Uber们的原始出发点,目前中国每天有10~20M乘客通过共享的方式出行。

电气化:电动车的成本显著低于汽油车,滴滴正在推动更多电动车加入车主行列;

自动驾驶:这一块已经非常火了,一方便有望大大降低交通事故发生率,对于滴滴和Uber来说可以省掉司机支出极大地降低成本;

Automated and Connected Vehicles技术目前是研究热点,有一篇科普文章

日记2016/02/13:周志华老师的新书

| Comments

明天是2016春节后的第一个工作日,新年要有新气象,其中一件就是要多写博客,将每天的想法和收获总结下来。

今天在石家庄家里翻了翻周志华老师的新书《机器学习》,ML基础的内容基本都包括了,讲得比较通俗易懂,公式推导比比李航的《统计学习方法》更少一些。个人还是比较推荐的。

重点翻了翻半监督学习和强化学习这2章。做一些笔记如下

半监督学习

基于“相似的样本有相似的label”的合理假设,未标记样本为样本分布提供了信息,故可以提高有监督学习的效果。

一种典型的半监督学习模型是TSVM(Transductive SVM),其在目标函数中包含了未标注样本的松弛向量,求解方法类似于EM思想,E步对未标注样本进行预测,M步调整分类面;一个要点是未标注样本的预测结果通常是显然不如有标注样本的label靠谱的,所以在目标函数中这2类样本的松弛向量的权重有差别,且未标注样本的权重随着多轮迭代不断上升。

强化学习

强化学习的应用场景很广,比如曾经很火的Flappy Bird和最近很火的Google的AlphaGo(围棋AI)。

明天补充细节,碎觉

滴滴出行-大数据策略组请你加入

| Comments

滴滴是一家飞速成长的公司,业务线从最初的出租车,扩展到专车,快车,顺风车,巴士,代价等越来越多样的出行方式,业务也从国内扩展到了国内外,正在改变越来越多人的出行方式。

大数据策略组在何晓飞叶杰平两位知名机器学习人工智能方向教授的带领下,正在打造智能的出行平台闭环,包括各业务线的订单分配,订单价值调节,多业务线运力和需求整合,等等。这里诚意邀请在策略算法,机器学习,数据挖掘等方向有经验的朋友加入,和世界级的大牛一起解决世界性的难题。

要做的事

参与最核心的订单分配项目,从数据和用户反馈中获得灵感,设计更优的订单分配策略,更准更快地匹配乘客和车辆。

希望你是这样的 (实习或全职都okay的):

1.  扎实的计算机基本,熟悉几门常用的编程语言(C++, Scala, Python等),动手能力强,数据结构和算法基础好。
2.  在机器学习、数据挖掘或相关方向有不错的理论和实践积累
3.  能够承担压力,快速上手,适应较快的项目节奏

待遇

滴滴今年的待遇我了解是高于BAT的,对大牛更是不手软,欢迎来聊。

有兴趣欢迎联系我:guodong@didichuxing.com

我在滴滴遇到的技术挑战

| Comments

加入滴滴打车3个半月,感觉遇到和解决的技术问题超过之前1年的。写在这里给大家分享。

滴滴这边负责所有策略算法设计的是“策略组”,大概有20几个员工。由于滴滴的业务线越来越多(出租车,专车,快车,顺风车拼车,大巴),项目上线时间紧,没有时间对策略算法做最好的设计和优化。于是,新成立了一个通用模型组,目标是抽取出不同业务线的共同点,在一个更高的角度设计更好的策略算法,特别是提供通用的大规模机器学习支持。我是这个team第一个员工。

订单分配:

滴滴一个技术重点是订单分配,全国每天有几百万的乘客通过滴滴叫车出行,有近百万司机接滴滴的订单,如何将订单分配给司机使得更多的人更快地打到车?至少有如下问题需要考虑:

  1. 从大的层面,如何设计一套分配策略,能够保证目标最大?
  2. 从小的层面,分配订单时应该考虑到哪些因素?(距离?是否顺路?司机习惯偏好?天气?供求关系) 这些因素如何组合?
  3. 如何在更长的时间维度上做更优的分配?(比如,当前时刻将乘客A分给司机B是最优的,但几秒之后司机C出现了,司机C离乘客A要近得多)
  4. 拼车更环保也能帮乘客省钱,如何在订单分配中让尽可能多的人在保证体验的同时拼上车?TRB中有非常多的文献
  5. 乘客加价如何影响订单分配?
  6. 我们应该学习Uber的一些策略吗?(比如播单不告诉司机乘客的目的地)

在创业初期,可以用规则快速简单地实现,现在滴滴已经初步有了一套理论上保证收益的分配策略,需要我们进一步去优化效果和效率。

透露一下,在整体策略中,有一个部分是涉及到大规模机器学习:样本是几十亿级别,特征是亿级别(这是我进来的第一个项目)

动态调价:

设想在周五的傍晚,下班高峰,又开始下大雨。在国贸商圈有1000个用户通过滴滴叫车,而附近只有100辆车。如何做订单分配?应该把有限的车给谁?

首先,我们需要定义一个目标:动态调价的目的是什么?最大化成交量?最大化流水?最大化(愿加价)乘客打车的成功率?还是这几个目标的组合最合理?

选定目标之后,每个乘客应该加多少钱?一个优质订单是不是应该少加点?

滴米:

为了促进订单成交,除了给司机补贴和要求乘客加价,是不是还有别的激励方案?

于是滴滴牛逼的PM们推出了滴米这个牛逼的产品。滴米是一种虚拟货币,对于优质订单,一堆司机挤破头来抢,我们就扣他们虚拟货币,对于没人要的订单,我们就奖励滴米。这样就调节了优质劣质订单冰火两重天的不和谐局面。关键是,乘客和滴滴不用花一分钱!

产品很牛逼,策略上如何支持?一个订单发出前,如何确定其是扣滴米还是奖励滴米?扣多少奖多少?每个司机一样吗?整个策略会导致通货膨胀或者紧缩吗?

到达时间预估

预估司机从A点到B点的时间消耗,对滴滴挺重要。如果准确地预估?基于哪些数据和因素?这是一个机器学习问题吗?有更巧妙的预估方法吗?

工作感受

说了来滴滴3各月参与和了解的几个项目,我觉得都非常有意思,也非常有意义。说下来之后的几点体验:

第一,最大的体会是中国互联网行业,特别是滴滴,生机勃勃,有太多有挑战的事情等着做。产品和策略迭代非常快,基本上每天线上的策略设计和架构都会有一次优化上线,你每次改动就会影响每天几百万人的出行体验。

第二,相比我之前的工作,在滴滴工作会和不同岗位的同学紧密合作,每天和靠谱的策略组小伙伴一起做策略设计和讨论;和90后PM mm们讨论进度和策略设计;和QA团队合作测试,保证上线风险可控;和OP同学配合上线;

第三,滴滴的招聘质量提升非常快,3个月前我刚入职,周边同学大概还是百度同学的平均水平,现在我参与的面试,发的offer的质量基本和hulu差不多了。

最后,昨天滴滴大巴上线了,现在可供出行的产品线有出租车,专车,快车,顺风车,大巴。欢迎加入滴滴,在滴滴最美好的阶段,和牛逼的人做牛逼的事情,一起改变中国人的出行体验。有兴趣的联系我: guodong@diditaxi.com.cn

使用Shadowsocks科学上网

| Comments

离开了墙外的Hulu,以后科学上网需要自力更生了。昨天尝试了Shadowsocks,确实稳定易用价格低,推荐给有需求的同学。

Shadowsocks的介绍和安装过程(windows/MacOs/ios/Android)在这篇经典的文章中有详细的介绍:ShadowSocks—科学上网之瑞士军刀。亲测可靠。

Shadowsocks客户端启动之后,是一个三角箭头,需要在“Open Server Preference”里设置账号(包括IP, 端口,加密方式和账号密码)。

Shadowsocks账号设置

Shadowsocks的账号网上有机会找到一些免费的,不过都是和很多人共享,且不稳定(比如密码改变),靠谱的方式是在VPS(虚拟专用服务器)上部署自己的Shadowsocks服务。我用了这家:http://it-player.com/(非广告)的服务,一年几十块,很划算了。(如果你难得需要科学上网一次,你甚至可以使用它的半小时有效的临时账号)

这家的VPS里已经配置好了Shadowsocks服务的安装程序,只需要在网页操作鼠标操作就可以安装好,复制端口号,密码,和VPS的ip配置到本地Shadowsocks客户端。截图如下: 在VPS中安装配置Shadowsocks服务

配置好账号,就可以愉快地切换了,考虑到每个月有上百G的流量,默认一直科学上网好了。下载和youtube的速度都是刚刚的。

在VPS中安装配置Shadowsocks服务

我在第一份工作中学到了什么

| Comments

Hulu是我的第一份工作。从2011年1月开始实习,7月毕业后正式加入,到15年春天,正好是本科4年的长度,在这里对这4年作个总结。

1. 定位自己的技术领域

互联网行业太大了,从技术角度来说至少包含了硬件研发,前端,后端service,基础架构,数据平台,策略算法等领域。大部分人都不能做到在每一个领域精耕细作,可行的方式就是一段时间内聚焦在自己有激情(最好也有基础)的1个领域发力,关注另外1-2个领域的技术发展,同时follow整个行业的大的趋势和变化。

第一份工作的一个收获就是我确定了自己未来几年的技术定位:聚焦在策略算法(包括机器学习,数据挖掘,优化问题,策略设计等)上,关注数据平台和后端service的技术发展,了解整个行业大的趋势和变化。

2. 规划职业发展路线

规划规划就是在问:十年后你想做什么,成为什么样的人?这是比给自己技术领域定位更大更长远的问题。想明白这个问题可以让自己更有目标,在做选择的时候看得更远。

我的技术发展路线目前在大数据这块,从下面的基础架构,数据平台,到上面的策略算法,业务逻辑。大数据现在比较热,但是和每一次技术浪潮一样,这波浪潮也会过去,我的判断是大概5到10年。不是说5-10年后大数据没有用武之地,而是说这块的技术会越来越成熟,越来越工具化。

开源社区和一些相关的技术公司正在以风卷残云的速度推进基础架构和数据平台的稳定性和工具化:Clourdea和Hortonworks提供的工具让Hadoop的安装变得一键傻瓜式;Spark以飞快的速度变成稳定,可以部署在上千台机器在P级别的内存里计算;YARN集群的管理和维护可以通过图形界面方便地操作;Hbase发布了1.0版本,可以搞定T到P级别的数据存储访问;越来越丰富的内存数据库和列存储数据库可供选择。

上层的策略和算法也越来越成熟,特别是有丰富的lib来使用,大部分公司使用工业界经典的算法和经验,加上尝试学术界新的研究成果就可以解决大部分问题了(比如spark的mllib,在最新的1.3版本里实现了大部分经典的机器学习,推荐系统和数据挖掘算法)。我相信几年之内开源社区就会提供好用(相比weka)的工具让你在图形界面里通过鼠标拖拽和简单输入解决大部分ML和DM问题。对于很多优化算法,也有现成的实现,不需要自己去推导实现。

最终大数据这块在未来有挑战性的是业务逻辑,每个公司都有自己相对独特的业务,理清业务,分清主次,平衡商业和技术,利用大数据技术给公司创造最大价值是个人价值最大化的方式。这背后需要的是对大数据领域全面的了解,架构能力,商业思维和团队管理。这也是我目前的职业发展目标。

3. 个人技术发展 vs. 带团队

我身边有不少技术流同事(大多工作2-3年左右)比较排斥带团队,想要100%的精力放在技术钻研上,我非常理解,有一段时间我也这么想。现在我开始思考一个更好的平衡,身边也有同事作出了很好的榜样。

带团队对个人成长的益处是明显的:让自己有更高的视野,培养商业思维,锻炼leadership,更大地发挥自己影响力和价值的机会,在承担更多责任的同时也会获得更多的回报。

带团队一定会占用一定的精力:为团队制订目标,项目规划,团队建设,与团队成员定期沟通,为team负责,做一些没人愿意干的活。解决的方法有2个,第一是delegate工作,比如设立一个PM的角色负责项目规划和对外沟通,将TB的安排分配给某个细心热心的同事;第二个是更努力勤奋,在承担更多的责任带领团队奔向目标的同时还要提高技术的深度和广度,只能更加努力,这是职业生涯必须要经历的阶段。

4. 做一个积极的学习者

视野局限在手头的工作是不够的,跟住技术圈和行业的发展很有必要。下面的一些点有些是我在关注的,有些是需要加强的:

  • 和同事,特别是别的组的同事多多交流,了解公司各个部门和team在做什么,他们关注什么,有什么值得学习和合作的;
  • 积极参加公司内部的技术分享,特别是别的组的,用1个小时了解别人几个月做的事实在是很划算;
  • 订阅阅读,我在用feedly,比较好用,如果你关注大数据,可以订阅“Hadoop Weekly”, “Databricks”以及一些技术公司的技术博客;
  • 关注top conferences(ICML, KDD, AAAI, WSDM…), 90%的文章只需要看下标题,剩下的读读摘要和实验,需要精读或者实现的很少;
  • 关注github trend;
  • 微信的部分公众帐号
  • 重视动手实践,动手去试过,我才会认为自己真的了解;

每天保持阅读,follow技术进展和业界变化目前我做得还不够好,其实做了会发现也就是每天花半个小时,做与不做长期下来差别应该会很大。

5. 时间和效率管理

在Hulu的几年,时间管理上有一些心得,有些点执行得不够好,下一份工作要做到。

  • 每天早上的第一件事情就是做计划(前一天晚上应该更好),精确到半小时。按照优先级排序,每完成一项就标注,比较有成就感。注意尽力让自己不要被打断;
  • 给邮件分类,取消邮件提醒,避免被邮件打断,集中午饭后和晚饭后2个时间段阅读回复邮件;
  • 早上的时间最高效,我很享受很早到办公司,一个人把重要的事情先处理完,这样晚上甚至下午的时间可以用来读文章或者尝试新的东西;

6. 高质量带来高效率

质量体现在工作的每个细节中,在Hulu的几年深有体会,比如说发邮件,你的邮件有语法错误吗?你的邮件组织清晰吗?你的邮件里的每句话对方都关心吗(不关心的就要删除)?有把核心结论放在头部吗?你的观点有充分的数据支持吗?数据支持的图表美观易懂吗?我很感谢对我作出指点的前辈同事。质量还体现在你做的技术分享的质量,开会前的准备,代码的质量和效率,code review时的认真度等等。

高质量和高效率有一些不可调和的地方,这就需要依据事情的优先级来,比如code review需要的细致程度取决于代码的重要性,有没有别的高质量reviewers帮忙。但是很多时候高质量保证了长期的高效率,比如:

  • 如果代码比较烂或者跑得太慢,请务必集中时间立刻彻底改进它,否则这些代码以后会成为你的时间黑洞。

    实例:我曾经有半年的陷入在开发一个项目的某个模块(一个逻辑略复杂的spark应用),3个月开发完之后开始在集群上测试,跑得很慢,内存消耗也很大,但是勉强还能接受。虽然负责集群管理的team有所抱怨,自己一次完整的测试也要花4个小时,但是我还是没有足够重视。后来代码需要引入新的逻辑,由于之前代码质量不高,新逻辑的引入很痛苦,调试的时间也比较长。由于在spark集群中跑得时间太长内存消耗太大,经常会突然挂掉。挣扎了一段时间的小修小补后,终于下定决心梳理逻辑,重构代码,彻底修改了spark程序的并行逻辑,执行时间下降到了半个小时,内存使用大大减少,代码逻辑也简单很多了,这个改变要是在早期就做,肯定能节省很多时间。

  • 在动手进行正式编码开发前,确保对数据做细致的分析,否则可能浪费掉一周的编码时间(不要假设任何来源的数据是没有问题的);

  • 你可以先用某个新语言或者工具,但是有时间了请务必搞透它,否则以后会付出代价;

    实例:一直有一个坏习惯:每次遇到问题去google,而不是把东西研究透。在1年多前开始接触scala,草草地看了一本书,也写了一些比较小的应用,一直没有细致研究它。后来趟了无数坑。

  • 将能自动化的一切自动化(一个典型的例子是机器学习的实验,从数据准备到测试到发实验报告整个过程在自动化后可以节约大量时间,提高了后续实验的效率)

7. 做技术总结和分享

技术总结和分享可以梳理加深自己对知识的理解,纪录自己的成长,同时还是很好的提升自己影响力的机会。如果是通过演讲的方式分享,由于自己理解了和让别人理解不是一个难度,可以进一步加深自己的理解。锻炼自己成为一个好的演讲者(这非常重要)。

技术分享不仅仅是给大家讲调研了什么新的技术,读了什么nb的papers,还包括推动新技术,算法,代码库,工具在team和公司的使用。

8. 成为让别人和公司信赖的人

2013年一帮老朋友离开Hulu,都是和我合作比较多,对我帮助比较大的,第一份工作中遇到这种情况对我的影响还是比较大的。公司做了组织结构的调整,有一些别的组的同事调整到广告组来,在这个特殊阶段,我还算不错地扮演了team核心的角色,帮助公司让这个team稳定并一步步壮大起来。

在努力成为让公司信赖让别人可依赖的人的过程中,我成长了。这边总结下自己做得不够好的地方:1). 从心态上更好地调整好leader的心态; 2). 做判断需要更果断; 3). 更积极地协调大家的工作,特别是实习生的工作,让大家的效率更高; 4). 更好地和PM协调好工作分配

9. 扮演好自己的角色

在工作中,你需要相处的角色有4类,第1类是自己的下属,第2类是组内的PM(programe manager以及product manager),第3类是其他组需要合作的同事,第4类是自己的老板。过去4年有很多心得,也有不少教训。

  • 和自己的下属:需要明确自信地宣称你是老大,你为这个team以及大家的成长和发展负责,定期的沟通,及时指出问题,保证每个人有正确的方向,做的事情符合优先级顺序,有产出,帮忙解决block issue。当然为team制定中长期计划,争取资源和项目也是非常重要的;
  • 和组内的PM:需要一开始就划清职责边界,什么事情由谁负责决定,避免以后工作中出现职责不清或非良性得竞争。要敢于将工作delegate出去,当然要做到放得出去收得回来;
  • 和其他组合作的同事:平时要注意建设好关系,不能需要支援的时候才联系对方。合作的过程中要多从对方的角度思考,对方为什么要合我合作这件事?对方关注什么?对方能得到什么?不能suppose对方有义务积极配合自己;
  • 和自己老大:多沟通,争取主动权和控制权,学会向上manage;

Druid Cluster Setup

| Comments

本文介绍如何搭建Druid cluster,Druid的介绍与应用见另一篇文章

Druid的官网也有详细的文档,建议浏览一遍。本文对关键部分做一些梳理,总结一些比较坑的点。

机器准备

Druid包含若干个services和nodes,我的配置如下(如果没有多个机器,当然可以将所有模块都起在一台机器上)

  • services/nodes on machine1: Mysql server, Zookepper server, coordinator node, overlord node (indexing service)
  • services/nodes on machine2: Historical node, Realtime node
  • services/nodes on machine3: Broker node

3台机器都安装配置好java (how)

安装配置依赖

mysql配置

按照Druid的文档安装mysql并创建一个新的用户druid/diurd。理论上Druid在后续步骤会在database druid中创建3张表druid_config, druid_rules和druid_segments。如果最终你发现没有这3张表,可以手动创建。

安装Zookeeper

安装启动,无坑

Deep storage

如果是local模式(全部都在一台机器上),使用本地磁盘作为deep storage是最简单的,对于cluster,较简单的方式是大家(indexing services, historical node, realtime node)挂载一块公共的磁盘(比如nfs方式),这样historical node就可以同步deep storage上的segments,realtime node也可以将segments同步到deep storage上来。

在实际应用中数据量通常比较大,常常会使用hdfs作为deep storage,为了能够将segments写入到hdfs中,

配置启动Druid各个nodes

对于如下每个node/service,Druid都有一个配置文件runtime.properties(较新的版本将一些公共的配置提取了出来),每个node/service都配置下druid.zk.service.host为zookeeper的地址。

  • coordinator node: 无坑,在machine1上启动
  • historical node: Druid默认Deep storage数据路径为/tmp/druid/localStorage, 可通过配置druid.storage.storageDirectory=XXX来覆盖。

    druid.storage.type=local druid.storage.storageDirectory=/mnt/data/druid/localStorage druid.segmentCache.locations=[{"path": "/mnt/data/druid/indexCache", "maxSize"\: 10000000000}] 如果deep storage是hdfs,则修改druid.storage.type=hdfs,druid.storage.storageDirectory为hdfs上的路径

  • broker node: 无坑,在machine3上启动;

  • indexing service:

    druid.indexer.task.hadoopWorkingPath=hdfs://elsaudnn001.prod.hulu.com/user/guodong/druid druid.storage.type=hdfs druid.storage.storageDirectory=hdfs://elsaudnn001.prod.hulu.com/user/guodong/druid 对应deep storage是hdfs

  • realtime node: 需要使用kafka,参考官网文档即可;

数据导入

使用indexing services是Druid推荐的数据导入方式,数据的input和output都可以是本地/挂载磁盘或者hdfs。 如果要读写hdfs,需要保证druid引用的hadoop版本和你使用的版本一致。

另外Druid引用了2.5.0版本的protobuf,而2.1.0之前版本的hadoop使用的是更老的protobuf版本(如2.4.0a),如果你遇到protobuf版本冲突的问题,需要修改druid的pom.xml重新打包

参考

  1. 官方文档
  2. google groups讨论区

在线广告中的cookie Matching

| Comments

用户定向是在线广告的核心优势之一,数据是用户定向的基础,而cookie matching技术可以将用户在各个站点上的数据关联在一起,使得re-targeting成为可能。

cookie matching有很多的应用场景,典型的有2种,一种是在DMP(Data Management Platform)生态中,另一种是在RTB(Real-time bidding)中。下面介绍下在这2种场景中cookie matching是如何实现的。

  1. 用户U访问jd.com, jd从用户browser中获取jd_cookie_id(jd.com的cookies id);
  2. jd的页面中预先嵌入了BlueKai的js脚本,会有一个302重定向请求转发给BlueKai, 用户的browser中会生成BlueKai的cookies,同时用户的jd_cookie_id会被发送给BlueKai;
  3. BlueKai在其后端service中纪录下BlueKai_cookie_id和jd_cookie_id的映射关系
  4. 用户U某一次去了yahoo.com浏览新闻,假设事先yahoo和jd签了一笔重定向的广告订单
  5. yahoo的ad server在给用户U挑选广告前,访问BlueKai server,BlueKai会在其数据库中检索Bluekai_cookie_id对应了哪些站点的cookie_id
  6. BlueKai给yahoo ad server返回用户U的tags(包含了哪些站点的cookie_id),如果其中包含了jd_cookie_id,则jd的广告可能会播放给该用户看

  1. 用户U访问jd.com, jd用从户browser中获取jd_cookie_id(jd.com的cookies id);
  2. jd的页面预先嵌入了PinYou的脚本,同样的会为BlueKai生成cookie,同时请求Pinyou分配cookie mapping任务;
  3. Pinyou给jd返回一个beacon,其中包含ad exchange地址,和用户U的Pinyou_cookie_id;
  4. jd会通过该beacon向DoubleClick发送cookie matching请求,包含了pinyou_cookie_id;
  5. doubleclick通过302重定向向Pinyou发送doubleclick_cookie_id;
  6. Pinyou在其数据库中存储doubleclick_cookie_id和pinyou_cookie_id的映射关系;
  7. 用户U某一次去yahoo.com浏览新闻,yahoo事先接入了double click广告平台售卖广告;
  8. yahoo的ad server会向double click发送广告请求,double click会将用户U的doubleclick_cookie_id发送给Pinyou等DSP, Pinyou通过cookie matching数据库找到pinyou_cookie_id, 再检查其对应了哪些站点的cookie_id,如果包含了jd_cookie_id,Pinyou就可能会为jd的广告竞争该广告位
  9. double click返回挑中的广告让yahoo播放