實踐和感悟 - scala向下轉型和減少窮舉

工作中的問題總結：

問題一：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
  }
}

執行結果

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次方）

直接降一個數量級的執行次數,當然這些都是假設，是不太準的

但是思路就一樣，就是將發生概率高的事件統計優先處理，這既符合生活規律，又符合事務發展的客觀規律。

應用場景就太多了，例子：

       例子一：話說網路運營商想分析用戶的上網行為分析。他不會將網路上的各種資源都先收集一份，然後再去匹配每個用戶的某時的上網行為　

那樣做機器也會累的。所以先樣本調查，然後分析大部分的用戶行為特征，根據樣本獲取統計資源，然後這樣以最小的資源消費最大的數據，剩下的小概率事件。

      例子二：百度搜索詞條的建立，也會尋找樣本，統計大概率數據精準處理，作為頻繁搜索詞緩存，讓搜索快速而精準，當然那其他的陌生詞條利用機器學再處理。每天計算詞條的權重，這樣以權重排列，這樣就會讓大概率更加大概率，再次節約速度。

      總而言之,事務的發展規律都是一樣的，總會有大概率事件，事物的發展規律都是一樣的。符合二八定律。用做小的資源去解決大量數據。