工作中的问题总结：
问题一：scala 之向下转型
引言:假如在复杂的业务逻辑中，变量的类型不能确认，只能给个接口类型，这样数据类型推导不会错误，但是后面要使用实现类的类型时，你却发现转不过来了？
对于这样的一个问题，scala可以这样解决：
首先建造一个接口，People：
trait People {
def toData[T](people:People):T
}
这样定义了一个接口，接着我们实现他的实现类Students和Teacher：
class Students(name: String) extends People {
var level:String="语文"
override def toData[Students](people: People): Students = {
people.asInstanceOf[Students]
}
def work() {
println("学习")
}
}
object Students {
def apply(name: String): Students = {
new Students(name)
}
}
class Teacher(name: String, age: Int) extends People {
var work: String = "hello"
override def toData[Teacher](people: People): Teacher = {
people.asInstanceOf[Teacher]
}
def teach() {
println("teaching")
}
}
object Teacher {
def apply(name: String, age: Int): Teacher = {
new Teacher(name, age)
}
}
这样我们的前奏做完了，接下来就测试向下转型：
object Test {
def main(args: Array[String]): Unit = {
val a = ("tom", "")
val b = ("jim")
val people:People = test(a)
if (people != null) {
val peo:Teacher=people.toData[Teacher](people)
println(peo.work)
peo.teach()
}
val peo:People = test(b)
if (peo != null) {
val p:Students=peo.toData[Students](peo)
println(p.level)
p.work()
}
}
def test(x: Any): People = {
val people = x match {
case (name, age) => Teacher(name.toString(), age.toString().toInt)
case (name) => Students(name.toString())
case _ => null
}
people
}
}
执行结果
hello
teaching
语文
学习
成功转型，这个解决方法是很有用的，工厂生产有很多模型，数据不一样，类型就不一样，但是数据源不确定，所以我们就需要一接口类型，去实现这个接口的子类做为相近数据的类型，这样自动获取对应的数据，是不是很方便、很好用。
问题二：spark Streaming连接kafka
引言：在工作中遇到streaming连接kafka时报错，说找不到topic的末偏移量？
我首先看了看是不是话题没有创建好，用命令接收数据，能收到，说明集群没问题。再测，还是偏移量的问题，这我就犯愁，连接我自己的环境，没问题，这就更蒙了，
第二次尝试：看API，源码手动设置偏移量，尝试一圈之后，问题依然没有解决。
第三次尝试：重新搭环境，结果还是不行
最后,思考我的环境和生产环境的唯一区别就是hosts文件，我将本地的hosts文件配的和生产环境一样，好了。（困扰我两天的问题啊）
总结，应用程序中最好不要填写IP，写映射（而映射和环境必须一致），这个streamingkafkaUtil的类有关。
问题三：生产中减少穷举
引言：在生产环境下面对纷繁的业务处理场景，我们知道要处理很多逻辑代码，其中有个叫枚举（也称穷举），当处理这类事务时，会产生大量的循环执行，而循环是最耗CPU的，大量的迭代计算，可直接拉低计算速度，怎么处理这类问题呢？
对于事务的不定项的选择几率，都会有一定的规律，比如说事件的概率发生，根据概率论的知识，我们可以去统计穷举各项的频率，按其大小依次排列，这样前面的枚举项就可消费大部分数据，剩下的低概率枚举项就会以最小的执行次数执行。
比如说有1000000条数据，枚举项有50个，假如平均25次能找到匹配项，就需要运行25000000次（2.5*10的7次方）
换种思路：假如第一枚举项是是30%，2是25%，3是20%这样前三项就消费750000*3+250000*25=8500000（8.5*10的6次方）
直接降一个数量级的执行次数,当然这些都是假设，是不太准的
但是思路就一样，就是将发生概率高的事件统计优先处理，这既符合生活规律，又符合事务发展的客观规律。
应用场景就太多了，例子：
例子一：话说网络运营商想分析用户的上网行为分析。他不会将网络上的各种资源都先收集一份，然后再去匹配每个用户的某时的上网行为
那样做机器也会累的。所以先样本调查，然后分析大部分的用户行为特征，根据样本获取统计资源，然后这样以最小的资源消费最大的数据，剩下的小概率事件。
例子二：百度搜索词条的建立，也会寻找样本，统计大概率数据精准处理，作为频繁搜索词缓存，让搜索快速而精准，当然那其他的陌生词条利用机器学再处理。每天计算词条的权重，这样以权重排列，这样就会让大概率更加大概率，再次节约速度。
总而言之,事务的发展规律都是一样的，总会有大概率事件，事物的发展规律都是一样的。符合二八定律。用做小的资源去解决大量数据。