你的位置:首页 > 数据库

[数据库]实践和感悟


工作中的问题总结:

问题一: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次方)

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

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

应用场景就太多了,例子:

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

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

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

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