我:最近剛學了scala,而且就有scala版本的WordCount,恰好學以至用了一下:html
補:至於java版本,蝦皮博主的一篇文章講解的很是細緻:
Hadoop集羣(第6期)_WordCount運行詳解java
http://www.cnblogs.com/xia520pi/archive/2012/05/16/2504205.htmlnode
我:經過flatMap將其扁平化,而.map((_,1)) 則是每一個出現單詞,1這樣的形式展示,此時還沒歸併。git
我:基於某個字段——決定了要用group By,頻次要用count聚合,倒序天然少不了desc。
補:框架搭好就是往裏塞了:面試
我:先拆分紅若干小的,而後再排(思路是從希爾排序出發的)
補:內部排序算法:希爾排序算法
http://www.xiapistudio.com/archives/291.html數據庫
我:初始化,資源,數據源,並行化,rdd轉化,action算子打印輸出結果或者也能夠存至相應的數據存儲介質
補:具體的可看下圖:編程
我:Transformation(轉化)算子和Action(執行)算子。設計模式
我:submit。
面試官:spark-submit?
我:嗯,spark-submit。api
我:aggeragate
面試官:還有呢?
我:記不清了。。。
面試官:還有你剛剛寫的那個groupByKey哈
補:
在咱們的開發過程當中,能避免則儘量避免使用reduceByKey、join、distinct、repartition等會進行shuffle的算子,儘可能使用map類的非shuffle算子。這樣的話,沒有shuffle操做或者僅有較少shuffle操做的Spark做業,能夠大大減小性能開銷。
我:spark shuffle處於一個寬依賴,能夠實現相似混洗的功能,將相同的Key分發至同一個Reducer上進行處理。
補:詳細探究Spark的shuffle實現
http://blog.csdn.net/johnny_lee/article/details/22619585
我:topic
補:分佈式消息系統:Kafka
我:能夠先分析基數大形成數據傾斜的維度,將其適當的拆分。
補:Spark性能優化指南:高級篇
我:list(set(list1).intersection(set(list2))),經過set 的intersection取交集的函數實現相同元素的提取。
我:由於以前也在作一些leetcode上的題目,多多少少重溫了下數據結構,當時腦海裏呈現的是數組方便查找,隊列和棧方便插入刪除,因此一聽到較快獲取果斷數組了。
面試官:dict(字典)
我:厲害!!
面試官:那它的時間複雜度你曉得嘛?
我:不是特別瞭解,O(1),常數時間複雜度?
面試官:嗯,那你知道它的缺陷嗎?
我:(中午吃撐了,TradeOff哈)不曉得
面試官:空間複雜度較高哈
補:
反思了一下,之因此說錯,可能和之前學習算法時,起承轉合的過分,並未將棧、隊列和map,或者dict直接比較,而是從數組切換到隊列和棧,因此就和以前的那個PUT和POST差很少,訓練邏輯正確,確實數組查詢記錄方便,但訓練廣度有些多樣性不夠。
算法備忘錄——基礎數據結構與複雜度
經常使用數據結構和算法操做效率的對比總結
恢復IP地址
Given a string containing only digits, restore it by returning all possible valid IP address combinations.
Example
Given 「25525511135」, return
[
「255.255.11.135」,
「255.255.111.35」
]
Order does not matter.
我:思考了一下子,沒想出來,只能想出個不通用的思路。
面試官:給你個提示,嘗試用樹這個數據結構。
補:此處埋一個坑,學完樹的數據結構再回來解決。
快樂數
Write an algorithm to determine if a number is happy.
A happy number is a number defined by the following process: Starting with any positive integer, replace the number by the sum of the squares of its digits, and repeat the process until the number equals 1 (where it will stay), or it loops endlessly in a cycle which does not include 1. Those numbers for which this process ends in 1 are happy numbers.
Example
19 is a happy number
1^2 + 9^2 = 82
8^2 + 2^2 = 68
6^2 + 8^2 = 100
1^2 + 0^2 + 0^2 = 1
我:思路是模擬過程法,即按照它驗證一個數是不是快樂數的方式進行模擬,固然也有些取巧的方式,若是某個中間結果曾出現過,妥妥滴死循環嘛,即刻跳出。
面試官:思路是對的
我:我以爲這會TLE,確定有取巧的方法(這道題目以前好像接觸過)
補:回去搜了一下,發現以前一直求助的一個大神的博客經過模擬過程用Python實現的:
Happy Number (以前的懷疑有更巧方法在於時常保持偷懶的思惟也是必要的)
我:Java:Eclipse;Python:PyCharm;Scala:IntelliJ IDEA;Shell:VIM
我:不瞭解,但之後回去買本O’Really的《設計模式》
補:封面以下:
我:因爲對Restful的瞭解只停留在使用層面,給個人感受像是一種資源的提交獲取,GET獲取,POST/DELETE/PUT均可以看做是一種提交操做
補:
【專業定義】:一種軟件架構風格,設計風格而不是標準,只是提供了一組設計原則和約束條件。它主要用於客戶端和服務器交互類的軟件。基於這個風格設計的軟件能夠更簡潔,更有層次,更易於實現緩存等機制。
RESTful百度百科
我:①減輕負載;②權限控制
補:讀寫分離的做用
看了上面的文章,減輕負載是首要目的,至於權限控制,更像是一種實現方式,不像目的。
我:ZooKeeper是分佈式協調組件,非大數據領域,能夠用ZooKeeper來作HA或者存儲數據,好比配置信息啥的。(Znode)
補:ZooKeeper 典型應用場景一覽