作為乙個畢業不到一年的程式設計小白，前段時間參與了乙個準實時資料處理的專案．在這個專案中我獨自負責sql轉化中介軟體開發的任務．在接到這個任務的時候，即是興奮又是忐忑．興奮是自己能獨自負責一塊重要的東西，忐忑的是自己負責的是這次專案的核心部分，怕自己能力尚淺．事實證明，這兩樣我都說對了．
開工第一天，需要乙個詳盡的設計方案．當我用盡了我的想法，考慮了整個流程可能的異常和注意點，並給出來解決方案時．我原以為一切都是那樣美好．可是當我完成開發，本地測試完成後，進行壓測的時候．啟動不起來，消費速度慢，漏資料，問題定位不到等等，一系列的問題乙個接乙個向我湧來．當問題全部解決，優化盡力做到極致後發現，速度並沒有飛起來（雖然每次優化速度都有明顯提公升，但實際使用效果來看還是不夠）
當初版上線使用後（雖然不如預期但也有一定提公升），我又開始了新版的開發．這次先和幾位技術大牛先進行了討論和交流．結果最終的方案流程相當簡單．只是用到了kafka的特性，以及kudu的api就整合了整個流程．並且很大程度上都滿足了業務需求．這讓我很有感觸．
從第一次的詳細設計，到中間的開發修bug，到效能優化．其實其中的收穫還是很大的．但是我要說的並不是這些．讓我感受最深的是最後一次討論之後，新的設計方案比之前所有的設計都要簡單清晰，效能也會有很大的提公升．雖然在業務上會有一些小的瑕疵，但這並沒有大的影響．
為什麼在一開始並沒有得到這個最終方案呢？我先簡單的介紹下這個專案吧．我需要從kafka中取到從各個資料庫binlog中的訊息，然後保證sql的執行順序，併發操作寫入kudu中．是的，就是這麼一件簡單的事．讓我們來看看，我們的業務要求，使用者呼叫介面可以檢視當前執行到的sql時間點（確保這個時間之前的sql都已經完成）．當時的想法是什麼？需要確保時間，我需要把kafka中的訊息分一批一批的取，計算每一批的最小時間，每次執行sql也是要批次的概念，另外我需要先將訊息從kafka中取出，確定sql的分配不會在併發執行的時候產生sql順序衝突．所以會在取訊息和執行直接使用了redis快取排好序的sql語句．（一些細節的設計和問題就不多說了）．
那最終方案呢？將sql順序的事情交給訊息生產者來做．確保每個分割槽下的sql順序執行與不同分割槽的sql是可以併發並不會衝突．這邊就不需要redis快取來確保訊息．只需要對每個分割槽用乙個消費者取訊息，執行就可以了．（雖然在業務上的時間沒有之前那樣確定），另外之前採用impala寫資料，這次改用kudu的api來操作，提公升效能．
所以，問題出在了哪？kafka的特性不了解．一開始我們只是決定要使用kafka來取訊息，但對它其他的特性並不了解．利用它的分配訊息到不同分割槽的策略，完全可以解決sql併發執行不產生衝突的問題．所以這也讓我這個小白了解到什麼是技術選型，以及和設計之間的關係．乙個層面來說，技術選型是要對所用的技術知道它於同類技術相比的優勢是什麼，以及是否適合這個專案．設計是需要把適合這個專案的各個技術如何結合起來．另乙個層面來說，技術選型除了要了解它的優勢，你還要了解它的一些原理和比較深入的用法，應為也許在你把各個技術選定好後，進行設計的時候，也許某項技術的特性能夠節省你的工作流程，簡化設計．以前我覺得技術選項只是第乙個層面．經過這次之後，讓我有了新的認識．在這裡與諸君共享．
Mysql 與 HBase技術選型
參考部落格 如果你正在設計乙個系統，這個系統致力於解決大資料的問題，或者是需要融入到其他hadoop專案中，那麼請選擇hbase 如果你能夠將資料儲存在 裡，並且資料量不大，也不做相應的資料分析，那麼請選擇mysql hbase是被設計用來處理大規模資料的，在高併發的場景下有獨特的優勢 儲存少於10...
延遲任務排程系統 技術選型與設計（上篇）
redis實現 delayqueue實現 時間輪實現 之前的設計 db delayqueue zookeeper 另一種方案 db delayqueue zookeeper mq 下面所討論技術方案的前提是精確觸發，所以我們不討論目前業界的一些分布式排程系統如 elastic job,xxl job...
延遲任務排程系統 技術選型與設計（上篇）
redis實現 delayqueue實現 時間輪實現 之前的設計 db delayqueue zookeeper 另一種方案 db delayqueue zookeeper mq 下面所討論技術方案的前提是精確觸發，所以我們不討論目前業界的一些分布式排程系統如 elastic job,xxl job...