实践和感悟

工作中的问题总结：

问题一：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", "1")  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 }}

执行结果

helloteaching语文学习

成功转型，这个解决方法是很有用的，工厂生产有很多模型，数据不一样，类型就不一样，但是数据源不确定，所以我们就需要一接口类型，去实现这个接口的子类做为相近数据的类型，这样自动获取对应的数据，是不是很方便、很好用。

问题二：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次方）

直接降一个数量级的执行次数,当然这些都是假设，是不太准的

但是思路就一样，就是将发生概率高的事件统计优先处理，这既符合生活规律，又符合事务发展的客观规律。

应用场景就太多了，例子：

       例子一：话说网络运营商想分析用户的上网行为分析。他不会将网络上的各种资源都先收集一份，然后再去匹配每个用户的某时的上网行为　

那样做机器也会累的。所以先样本调查，然后分析大部分的用户行为特征，根据样本获取统计资源，然后这样以最小的资源消费最大的数据，剩下的小概率事件。

      例子二：百度搜索词条的建立，也会寻找样本，统计大概率数据精准处理，作为频繁搜索词缓存，让搜索快速而精准，当然那其他的陌生词条利用机器学再处理。每天计算词条的权重，这样以权重排列，这样就会让大概率更加大概率，再次节约速度。

      总而言之,事务的发展规律都是一样的，总会有大概率事件，事物的发展规律都是一样的。符合二八定律。用做小的资源去解决大量数据。

原标题：实践和感悟

关键词：