記一次scala的隱含問題

現(xiàn)象

在運行[spark][1]程序期間,在針對 [dataFrame][2] 的map操作中,產(chǎn)生了類似[HashMap][3] key重復(fù)的現(xiàn)象,如圖所示

有兩個重復(fù)健

這個問題導(dǎo)致了后續(xù)統(tǒng)計上的一系列問題

分析

起初我們是實際跟蹤代碼進行分析的,但是發(fā)現(xiàn)scala代碼中沒有任何問題,各種處理也非常合理

代碼羅列如下,想看就看看,不看也能理解

    // 目標是針對businessid進行聚合,然后輸出各個業(yè)務(wù)id下,銷售天數(shù)
    // 獲取數(shù)據(jù)的代碼
    val dataframe = spark.sql("select businessid,date,money from table1")

    case class Stat() {
      // 針對每一個businessid的統(tǒng)計
      var moneyByDay: HashMap[String, Double] = HashMap[String, Double]()


      // 針對每一條記錄的id進行相加
      def moneyByDayOp(data: (String, Double)) = {
        if (this.moneyByDay.contains(data._1)) {
          val tmpMoney = this.moneyByDay.get(data._1)
          val finalMoney = tmpMoney.getOrElse[Double](0) + data._2
          this.moneyByDay.remove(data._1)
          this.moneyByDay.put(data._1, finalMoney)
        } else {
          if (data._2 > 0)
            this.moneyByDay.put(data._1, data._2)
        }
      }
    }
    /**
      * 歸并多條記錄的結(jié)果
      **/
    def reduceStatModel(one: Stat, another: Stat): Stat = {
      one.moneyByDay ++= another.moneyByDay
      one
    }

    /**
      * 針對每條記錄生成一個統(tǒng)計值
      **/
    import org.apache.spark.sql.Row
    def parseProductDay(data: Row): (Long, Stat) = {
      val result: Stat = new Stat
      val a: String = data.getAs[String]("date")
      result.moneyByDayOp(a, data.getAs[Long]("money"))
      (data.getAs[Long]("product_id"), result)
    }

    // 核心流程
    val finalRs = dataframe.rdd
      .map(line => parseProductDay(line))
      .reduceByKey(reduceStatModel(_, _))

    val hashMp = finalRs.collect()(0)._2.moneyByDay
    hashMp.put("20170727",1)
    

針對的存儲,其實就是Stat類中的 moneyByDay對象,本質(zhì)上是一個HashMap,并且通過泛型控制,key類型為String,value的類型為Double

放到集群上執(zhí)行,是可以通過的,并且得到類似上圖的結(jié)論

hashMap中包含重復(fù)的key,只能是兩個可能

  1. key類型相同,但是可能原始字符串中有空格,或者不可見字符
  2. key類型不同,一個是字符串,另一個是其他數(shù)據(jù)類型

經(jīng)過檢查,1的可能性排除

問題原因是2,居然是2,排除了所有不可能之后,最后的真相即使再不可能,也是真的

原因

其實這種結(jié)論是意料之外,情理之中

眾所周知,java的泛型檢查是編譯時的檢查,實際運行時,容器類存儲和運算都是將對象看做object進行處理的

對于基于jvm的scala,泛型本質(zhì)上也是一個靜態(tài)編譯檢查

上述代碼,如果table1表中的字段date,其類型是string,那么萬事ok,運算和結(jié)論都會正常

但是如果date是其他類型,比如int,那么就會產(chǎn)生問題

問題出現(xiàn)在上述代碼的37行

 val a: String = data.getAs[String]("date")
// 這行代碼是org.apache.spark.sql.Row對象的一個調(diào)用,目的是獲取指定類型的字段,并且轉(zhuǎn)化為指定類型

// 源碼如下:


  /**
   * Returns the value at position i.
   * For primitive types if value is null it returns 'zero value' specific for primitive
   * ie. 0 for Int - use isNullAt to ensure that value is not null
   *
   * @throws ClassCastException when data type does not match.
   */
  def getAs[T](i: Int): T = get(i).asInstanceOf[T] // 此處是進行強制轉(zhuǎn)化

  /**
   * Returns the value of a given fieldName.
   * For primitive types if value is null it returns 'zero value' specific for primitive
   * ie. 0 for Int - use isNullAt to ensure that value is not null
   *
   * @throws UnsupportedOperationException when schema is not defined.
   * @throws IllegalArgumentException when fieldName do not exist.
   * @throws ClassCastException when data type does not match.
   */
  def getAs[T](fieldName: String): T = getAs[T](fieldIndex(fieldName))

解決方案

  1. 將table1表的字段設(shè)計成string,代碼可以運行通過

  2. 37行代碼改為如下,轉(zhuǎn)化string即可

     val a: String = String.valueOf(data.getAs[String]("date"))
    

    ?

疑問

在spark-shell中調(diào)用這段代碼,其實是會報錯的

val a = data.getAs[String]("date")
異常截圖

但是為什么集群執(zhí)行會通過?

并且返回了一個HashMap[String,Double],其中的key都是Int。。。每次調(diào)用foreach方法都會報錯

普通的foreach操作,拋出了強轉(zhuǎn)異常

  1. https://spark.apache.org/ "apache基于內(nèi)存的分布式計算框架" ?

  2. https://spark.apache.org/docs/latest/sql-programming-guide.html "spark-dataframe, 與pandas的Dataframe相似,是針對分布式計算的抽象和實現(xiàn)" ?

  3. http://www.scala-lang.org/api/current/scala/collection/mutable/HashMap.html " "scala.mutable.hashmap scala中的map分為可變和不可變的" ?

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 229,117評論 6 537
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 98,860評論 3 423
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 177,128評論 0 381
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,291評論 1 315
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 72,025評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 55,421評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,477評論 3 444
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 42,642評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 49,177評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 40,970評論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,157評論 1 371
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,717評論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 44,410評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,821評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,053評論 1 289
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,896評論 3 395
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 48,157評論 2 375

推薦閱讀更多精彩內(nèi)容