eBay搜索引擎如何优化
本文目录
ebay在中国面临那方面的挑战
眼下，ebay对各种在线数据的分析无所不至，就像在每个顾客前面安装了摄像头一般。
毫无疑问，ebay拥有的数据量是惊人的。其每天都要处理100pb的数据，其中包括50tb的机器数据。可以说，ebay每天都面临着天文数字般的大数据挑战。
早在2006年，ebay就成立了大数据分析平台。为了准确分析用户的购物行为，ebay定义了成百上千种类型的数据，并以此对顾客的行为进行跟踪分析。然而，这同时也为ebay带来了新的挑战。要知道，公司的数据量多到难以想象，没有人能分析消化这么多的数据，也没有人能基于所有数据建立起模型。
事实上，ebay真正应用到的，只是其收集的数据中的一小部分。“剩余的数据，ebay或是将其丢弃，或是将其存储起来。因为说不定哪天，科技实现了突破，这些数据就会变得有用。”ebay大中华区ceo林奕彰指出。
那么目前，ebay是如何利用这些数据，来促进业务创新和利润增长的呢？
为用户“画像”
ebay拥有近2亿的用户，网站的商品清单项目则有3万多类。在平台的日常交易中，ebay几乎每秒都要处理数千美元。而这些交易数据，其实只是ebay全站数据信息总量的“冰山一角”。
基于大数据分析，ebay每天要回答的问题有很多，比如，“昨天最热门的搜索商品是什么？”而即便是这样的简单问题，都需要涉及处理五十亿的页面浏览量。从这个角度看，任何一个基本的业务问题，对公司来说都是一个相当巨大的问题。
就ebay如何利用大数据来增加在线交易，林奕彰举了一个典型的例子。譬如，一位年轻的女性早上10点在星巴克浏览ebay网站，ebay应该推送给她什么样的商品呢？
“就这几个信息点，我们其实已经做了不少研究。”林奕彰说，“事实上，用户早晨10点、中午12点，或是晚上7点，她浏览的商品是不同的；在餐厅或是在家里，同样会对浏览和搜索产生影响；此外，还有用户的年龄、当时的天气等等，都会对购物产生影响。ebay要做的，就是学习不同情景下的不同购物模式，并推送给用户最想要的商品。”
据悉，ebay可以从用户以往的浏览记录里“猜”她想要什么样的商品，也可以从设定的成百上千种情景模型中计算出用户可能的需求；或是对照另一位有着相似特点的女性用户，看她当时买过什么样的商品，从而推断出这位用户潜在的需求。在综合各种考量因素后，ebay的后台需要在短短几秒内将商品页面推送给用户。这意味着，ebay的系统需要有非常快的运算速度。
这种运算模型，有相当一部分人为的因素。比如，机器可以搜集用户的上万个数据，但ebay的工程师可以定义其中的100个数据为有效数据，而模型则建立在这些有效数据之上。此外，当计算机自动“学习”分析各种数据形成的趋势时，ebay需要将机器学习的逻辑设定在与商品交易相关的行为上。
除了通过大数据为用户“画像”而向其推送有针对性的商品，ebay此前还尝试利用大数据进行搜索引擎的优化。
具体说来，ebay可以把握用户的行为模式，使搜索引擎更加“直觉化”。如果时间倒退几年，用户在使用ebay的搜索引擎时，会发现它只能理解字面的意思，并按照字面意思寻找。很多时候，搜索引擎并不能理解用户的真实意图。但现在，ebay正试着改变或重写用户的搜索请求，增加同义词或替换语句，从而给出更相关性的内容，并由此增加在线交易量。而这背后，统统离不开大数据的支持。
为商家提供“情报”
基于用户购物的数据，ebay同样会给商家提供各式各样的“情报”。比如，ebay会告诉制造商用户正在网上搜索什么商品，或是各种出口行业的数据，制造商会立刻对此做出反应。
很多时候，ebay会根据自身或其他电商网站的交易情况，向商家建议其应该销售的品类。“这也是ebay大中华区正在做的工作，”林奕彰称，“比如，一个中国的商家希望将产品卖到澳洲，我们通过数据分析可以告诉他，他一个月大约可以卖出多少产品，定价应该在什么范围内，市面上还有多少商家在卖同样的产品，他的市场占有率大概是多少。”
在此基础上，ebay还试图算出商家的补货频率。事实上，海外仓储是商家非常头痛的问题，一旦计算失误，便可能造成库存积压或缺货。而在ebay，一旦用户下单后发现商家缺货，将是非常严重的问题。这种情况下，ebay可以通过过往的数据分析，得出商家第一批货的大概销量，以及按照过去销货的速度什么时候应该补货，物流的时间又是多久。通过这些数据的计算，ebay可以测算出商家补货的逻辑。
这些数据分析，对于商家开拓新的销售品类非常管用。因为通常情况下，商家需要四五个月，才能摸清楚一种货物的淡旺季销量，及其在各个地区的受欢迎程度。
如何给eBay/Amazon做站外引流
要理解站外引流，先要理解一个核心问题：eBay和Amazon的流量从何而来？其实说白了，他们的流量也就是从Google Facebook等网站和平台上引过来的。
说到Google，很多刚了解引流的朋友可能只能够想到谷歌关键字，如果你不是自建站，只是为了给亚马逊店铺引流，我不建议用谷歌关键字推广。原因很简单，既然价格同样贵，我为什么不直接用站内推广？所以我认为真正适合站外引流的就是Google网盟广告和Facebook。
原因也很简单：1.图片广告的形式 2.尽量避免在同一纬度竞价 3.一定要比站内引流便宜很多。（平均单次引流成本在1-2元人民币）
下面就将具体操作分享给大家：
1.在不同的review站内投放文字、图片广告。比如 fivver，elance，freelancer
2.在国外的视频站进行引流：视频站点有： Youtube, Vimeo，Dailymotion.com等
3.在社交平台引流，Facebook， Twitter, Pinterest,Quora, VK，但是你在这社交平台要引流务必得现有一群你自己的粉丝和认同你的群体。
最开始，粗暴的做法有在facebook，可以使用群组功能加入群，发促销，在竞争对手的留言下面留链接。后期可以根据你成交的粉丝作为定位，进行同质人群粉丝营销。
4.博客引流：分为免费和付费.
免费就是自建博客。几个或者多个都没有问题，软件直接读取slickdeal的数据， slickdeal更新你也就同步更新，慢慢的就会吸引不少人，然后50%的产品还是放自己的产品但是也有50%放别人的产品，因为其实还挺多人是这么干的。
付费就是在不同的博客站内投放文字、图片广告，按点击付费。
5. Lifehacker引流
为什么要提这个Lifehacker？Lifehacker排名300多全球，你想想流量有多猛。上百万一天你信不信。Lifehacker站内投放文字、图片广告，按点击付费。
6.论坛站引流
论坛有2个方法，其实有些论坛的确可以自己发，虽然流量不大，但是转化还可以。
另外一个方法就是付费进去给点钱，起个自己品牌的分论坛，但是试过一下，不一定有很流量。比如英国比较知名的yell.com
只要中国品牌在的论坛，你也就可以在里面发，只是方式要自己摸透。
7. Coupon站
Coupon站影响不大，大家都说，但是品牌做得好的coupon站也还不错.在各大coupon站内投放文字、图片广告，按点击付费。
Retailmenot站排名很高，是允许免费提交coupon的，效果还好。还有部分coupon站也可以。
大多数情况下应该是你要加入Amazon联盟才能进入更多的coupon站。
8. Deal站引流
Reddit流量杠杠的，可惜转化率不能保证。但是有deal的情况下绝对也不吃亏。
在选择不同国家的deal站投放你的文字或者图片广告。
每个国家都有每个国家的Deal站，加拿大有 Redflagdeal，法国有dealabs，英国有hotukdeal,Wowcher,Kgbdeals，西班牙有tringa,LetsBonus,俄罗斯有mysku.美国就更多一堆： dealnews，woot.com
日本有：racoupon.rakuten.co.jp/，ponpare.jp/,kakaku.com/等
9.行业站引流
你是卖相机的，就在Google联盟的相机网站投放你的Listing广告。
以上内容来源于论坛，请参考！
亿级Elasticsearch 性能优化
最近一年使用 Elasticsearch完成亿级别日志搜索平台「ELK」，亿级别的分布式跟踪系统。在设计这些系统的过程中，底层都是采用 Elasticsearch来做数据的存储，并且数据量都超过亿级别，甚至达到百亿级别。
所以趁着有空，就花点时间整理一下具体怎么做 Elasticsearch性能优化，希望能对 Elasticsearch感兴趣的同学有所帮助。
Elasticsearch是一个基于 Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于 RESTful web接口。Elasticsearch是用 Java开发的，并作为 Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
作为一个开箱即用的产品，在生产环境上线之后，我们其实不一定能确保其的性能和稳定性。如何根据实际情况提高服务的性能，其实有很多技巧。
下面我就从三个方面分别来讲解下优化服务的性能：
索引优化主要是在 Elasticsearch插入层面优化，如果瓶颈不在这块，而是在产生数据部分，比如 DB或者 Hadoop上，那么优化方向就需要改变下。同时，Elasticsearch本身索引速度其实还是蛮快的，具体数据，我们可以参考官方的 benchmark数据。
当有大量数据提交的时候，建议采用批量提交。
比如在做 ELK过程中，Logstash indexer提交数据到 Elasticsearch中，batch size就可以作为一个优化功能点。但是优化 size大小需要根据文档大小和服务器性能而定。
像 Logstash中提交文档大小超过 20MB，Logstash会请一个批量请求切分为多个批量请求。
如果在提交过程中，遇到 EsRejectedExecutionException异常的话，则说明集群的索引性能已经达到极限了。这种情况，要么提高服务器集群的资源，要么根据业务规则，减少数据收集速度，比如只收集 Warn、Error级别以上的日志。
优化硬件设备一直是最快速有效的手段。
为了提高索引性能，Elasticsearch在写入数据时候，采用延迟写入的策略，即数据先写到内存中，当超过默认 1秒（index.refresh_interval）会进行一次写入操作，就是将内存中 segment数据刷新到操作系统中，此时我们才能将数据搜索出来，所以这就是为什么 Elasticsearch提供的是近实时搜索功能，而不是实时搜索功能。
当然像我们的内部系统对数据延迟要求不高的话，我们可以通过延长 refresh时间间隔，可以有效的减少 segment合并压力，提供索引速度。在做全链路跟踪的过程中，我们就将 index.refresh_interval设置为 30s，减少 refresh次数。
同时，在进行全量索引时，可以将 refresh次数临时关闭，即 index.refresh_interval设置为-1，数据导入成功后再打开到正常模式，比如 30s。
Elasticsearch默认副本数量为 3个，虽然这样会提高集群的可用性，增加搜索的并发数，但是同时也会影响写入索引的效率。
在索引过程中，需要把更新的文档发到副本节点上，等副本节点生效后在进行返回结束。使用 Elasticsearch做业务搜索的时候，建议副本数目还是设置为 3个，但是像内部 ELK日志系统、分布式跟踪系统中，完全可以将副本数目设置为 1个。
当我们查询文档的时候，Elasticsearch如何知道一个文档应该存放到哪个分片中呢？它其实是通过下面这个公式来计算出来
routing默认值是文档的 id，也可以采用自定义值，比如用户 id。
在查询的时候因为不知道要查询的数据具体在哪个分片上，所以整个过程分为 2个步骤
查询的时候，可以直接根据 routing信息定位到某个分配查询，不需要查询所有的分配，经过协调节点排序。
向上面自定义的用户查询，如果 routing设置为 userid的话，就可以直接查询出数据来，效率提升很多。
Ebay曾经分享过他们使用 Elasticsearch的经验中说到：
Elasticsearch针对 Filter查询只需要回答「是」或者「否」，不需要像 Query查询一下计算相关性分数，同时 Filter结果可以缓存。
在使用 Elasticsearch过程中，应尽量避免大翻页的出现。
正常翻页查询都是从 From开始 Size条数据，这样就需要在每个分片中查询打分排名在前面的 From+ Size条数据。协同节点收集每个分配的前 From+ Size条数据。协同节点一共会受到 N*（ From+ Size）条数据，然后进行排序，再将其中 From到 From+ Size条数据返回出去。
如果 From或者 Size很大的话，导致参加排序的数量会同步扩大很多，最终会导致 CPU资源消耗增大。
可以通过使用 Elasticsearch scroll和 scroll-scan高效滚动的方式来解决这样的问题。具体写法，可以参考 Elasticsearch:权威指南- scroll查询
Elasticsearch默认安装后设置的堆内存是 1 GB。对于任何一个业务部署来说，这个设置都太小了。
比如机器有 64G内存，那么我们是不是设置的越大越好呢？
其实不是的。
主要 Elasticsearch底层使用 Lucene。Lucene被设计为可以利用操作系统底层机制来缓存内存数据结构。 Lucene的段是分别存储到单个文件中的。因为段是不可变的，这些文件也都不会变化，这是对缓存友好的，同时操作系统也会把这些段文件缓存起来，以便更快的访问。
如果你把所有的内存都分配给 Elasticsearch的堆内存，那将不会有剩余的内存交给 Lucene。这将严重地影响全文检索的性能。
标准的建议是把 50％的可用内存作为 Elasticsearch的堆内存，保留剩下的 50％。当然它也不会被浪费，Lucene会很乐意利用起余下的内存。
同时了解过 ES的同学都听过过「不要超过 32G」的说法吧。
其实主要原因是：JVM在内存小于 32 GB的时候会采用一个内存对象指针压缩技术。
在 Java中，所有的对象都分配在堆上，并通过一个指针进行引用。普通对象指针（OOP）指向这些对象，通常为 CPU字长的大小：32位或 64位，取决于你的处理器。指针引用的就是这个 OOP值的字节位置。
对于 32位的系统，意味着堆内存大小最大为 4 GB。对于 64位的系统，可以使用更大的内存，但是 64位的指针意味着更大的浪费，因为你的指针本身大了。更糟糕的是，更大的指针在主内存和各级缓存（例如 LLC，L1等）之间移动数据的时候，会占用更多的带宽.
所以最终我们都会采用 31 G设置
假设你有个机器有 128 GB的内存，你可以创建两个节点，每个节点内存分配不超过 32 GB。也就是说不超过 64 GB内存给 ES的堆内存，剩下的超过 64 GB的内存给 Lucene
