SDCC杭州站Day1的简单记录

VIPSHOP的全链路监控

LOGVIEW的问题

1. 没有调用关系
2. Nginx accesslog只能根据自身的一些metrics来判断是否出问题

MERCURY PEAK

1. 100 million message / second
2. 15 billion message / day
3. 15T / day
4. 1T index / day

我觉得我当时做LOGVIEW/TELESCOPE做的不好的地方

1. 数据的采样
2. 服务的治理，包括对于系统组件本身的监控，版本的管理。这个很有感触，比如手游中的sdk的升级
3. 服务的降级，对于不同计算指标，和Spark计算任务（这里是否需要job之间的关系？not sure）
4. 敏感信息的脱敏，比如用户的身份信息等

REMARK

1. wall time / event time，wall time就是接收到这个event的事件，而event time就是event里面的时间戳
2. shift_to_metric的metric name，比如response_time_osp_cart，这样做的目的，其实是为了降低tag的数目。因为OpenTSDB在tag数目很多的情况下，性能会非常的差。

小米广告平台

不是很懂具体的算法，以一些数据为主。
baseline-LR（+38%）-FTRL天级别（+47%）-FTRL小时级别（+52%）

搜索关键字广告

日收入提升20倍，发展，文本相关性 - 行为相关（协同过滤）-CTR（FTRL）

导航，千人千面以后，收入+82%

蘑菇街

计算的三要素

1. 海量
2. 实时
3. 计算灵活性

• 满足1和2的是类似storm的流式计算
• 满足2和3的是的是MySQL
• 满足1和3的是Hive

未来方向

1. 用Apache Flink，实现Google的DataFlow
2. 华为开源的StreamCQL，需要看看。上次听携程的张翼也讲过

REMARKS

蘑菇街利用DSL构造的实时计算job，非常惊艳，做的很棒，有时间要仔细研究。

饿了么

一些业务数据
日均2亿，订单500w+，城市1000+，员工15000+。技术1000+。
需要关注的是关于Cassandra的应用，Cassandra不依赖于Hadoop的组件，数据对等，没有中心节点。虽然有二级索引，但每个节点只有自己本地数据的一份二级索引。可以尝试下将二级索引写入其他集群，比如ES的做法。其实这个HBase+ES的方案在唯品会时候我就提过了，貌似大家都不感冒，so sad:(

关于Kafka跨机房，和我们公司业务不同，游族有非常大量的海外业务，有跨国家，跨大洲的数据传输需求，这个国内的公司经验似乎不多。

其他

早上为了赶7点30的火车，5点就起床了，下午结束自己的分享以后，已经基本在打瞌睡状态了。下午Echo的陈健分享的，太干货了，全是音频技术方面的一些算法，让人有点懵啊。万达的呈祥分享了关于Apache Flink的实践，当时对于Apache Flink的了解不多，在选型的时候希望能用比较熟悉的工具来搞，所以还是选择了Spark。听呈祥说，Flink又能保证实时性，又能保证准确性，这点直接研究，而且Flink和CEP有着天生的集成（如果没记错的话）。

最后附上几张照片

图片发自App

图片发自App

图片发自App