原创 對互聯網海量數據實時計算的理解

本來也想寫一個實時計算相關概要的,大圓那些事已經寫了一份,就不有必要了,只是補充下我想說的一些事就完了。 轉自:對互聯網海量數據實時計算的理解 1. 實時計算的概念 互聯網領域的實時計算一般都是針對海量數據進行的,除了像非實時計算的需求

原创 Kryo、msgpack、protobuf、Hessian、Avro、Thrift等序列化框架比較

最近一直在想如果讓我自己來做一個服務化框架出來,該實現些什麼功能,具體該怎麼去做這樣的問題,數據序列化是一個重要的模塊,故此有意對常見的一些開源序列化框架做一個比較! 我個人對Hessian、Java、protobuf、Thrift這幾種

原创 Rsync服務搭建小結

最近由於業務上的考慮,把內容的點擊數、播放數等變化頻換(每日1000W-2000w次)但是對於業務沒有太大實時意義的計數,由實時操作DB變更爲只記錄

原创 Centos iptables配置筆記

最近在防火牆的配置上吃了一大虧,清除預先配置之後,直接就把SSH給拒絕了! 這裏把今天看到用到的一些點給記錄下來,便於下次使用。 (一)防火牆常見命令 (1)防火牆規則配置文件 vi /etc/sysconfig/iptables (2)

原创 Tidb試用的小結

        長期以來一直使用MySQL作爲核心存儲,特別穩定可靠,有問題多半就是自己使用不當,違背了最基本的原則,否則的話真的是遇不到什麼特別故障。好用,靠譜,不作死就不會死,這個就是MySQL。雖說MySQL也有單點故障,常規的Ma

原创 Python+Request+Allure進行API接口測試自動化(一)

(一)python環境準備 1、安裝Python3; https://www.python.org/downloads/ 2、下載Python開發IDE工具pycharm; http://www.jetbrains.com/pycharm

原创 用eclispe來調試Kafka源代碼

我是看好Scala的,畢竟Kafka、Spark這兩個大招太牛了,你想不用它都不行,所以Scala肯定會紅火起來的! 看了2周的Scala了,Kafka也用了好幾年了,終於可以把Kafka的源代碼下下來,看看到底是何方聖神了! 環境: W

原创 記一次Redis的異常分析

最近線上環境偶爾在零點過後的時候就會報Redis的異常,出現好幾種錯誤,並且持續時間在1-3分鐘之間,並不固定,報的錯誤也有3種,表現各不相同,很是詭異。 (1)錯誤一 redis.clients.jedis.exceptions.Je

原创 Kylin中Segments overlap的解決辦法

        我們公司的有初具規模的Hadoop、Spark集羣,用來做離線數據統計與分析。今年初引入Kylin來進行成熟業務的與計算,當然用Hbase來存儲Kylin的結果數據了。由於業務數據規模增長較快,處理日誌的時候越來越慢了,於

原创 Sqoop1.4.5+hadoop2.2.0進行Mysql到HDFS的數據轉換

正如上一篇記錄的那樣,採用sqoop1.99.4 + hadoop2.2.0來將mysql的表數據導入到HDFS的時候,死活沒有找到如何制定字段分隔符號,這纔有了試用sqoop1.4.5這番折騰。從架構上

原创 用Sqoop2在Mysql和hadoop導入導出數據

        最近在做用戶刷贊排除邏輯的時候,需要結合nginx的access.log日誌和Mysql中的部分記錄聯合查詢才能做到,之前的nginx日誌一直存放在hadoop中,mysql的數據則沒有導入到hadoop中去過,要搞定這事

原创 使用elasticsearch與kibana來分析nginx日誌小結

         最近由於項目中有很多業務功能需要藉助搜索引擎才能實現(比如有業務是按照User_ID分表,但是又需要在部分地方採用entity_id的維度查詢,爲了避免同一業務數據需要存儲兩份導致一序列的問題,這樣的問題就用搜索引擎來實

原创 Cassandra,我又回來了

         早在2010年中的時候,我就對Casandra特別感興趣,那時候還是0.7版本,累計2個月每天晚上都花2小時來啃源代碼,讀寫流程都調試N遍了,也整出來幾篇小文,不過後臺工作方向上最終沒有它的用武之地,後面就慢慢沒有再持續

原创 hive使用案例

用hive來進行日誌分析有一段時間了,這裏簡要記錄下我使用UDF和存儲與導出hsql結果的實現方式,以供參考。 (一)UDF 開發與使用案例  1、創建Maven工程,開發UDF(基於hadoop2.2.0+hive-0.12.0)。

原创 jmap的幾個操作要慎用

最近中大招了,前一週開始偶爾在線上發現一些請求時長竟長達7秒,甚至在部分時段系統存在週期性的請求失敗或者超時,各種招式都使用了還是不知道確切的原因,百思不得其解,頭大的很!昨日晚上發現這個問題簡直太嚴重了,必須要馬上處理掉,一會都耽誤不