前言
19年，在一些技術思維上形成了幾點套路，不過目前還沒有成體系，所以想到啥就寫啥了，算是一個記錄，避免自己以後忘了。
技術調研不要交給新手
技術調研是個技術上很有【挑戰】，同時也是一個比較【艱苦】，也考驗一個人的技術【品味】的任務。所以讓一個新手去調研，這明顯屬於爲難新手，並且大概率會得到一個不甚“真實”的調研結果。當然了，讓新手調研也有其背後的“隱情”，因爲新手畢竟能幹的事比較少，而對於調研是一件重要不緊急，長期重要短期還好的任務，老手必須得拼命幹活，所以對於領導而言，讓新手調研也就變得順理成章了。但是，爲了一個大概率會有偏差的結果，同時還浪費了一個新手時間，是不是真的划算那就另外說了。有的時候錯過一個技術，或者選型了一個錯誤的技術，都會給團隊帶來比較大的技術債務。
比如我調研Ray,爲了獲得一個較爲全面的認知，我翻看了它多篇論文（它也在發展），看了大部分文檔，同時結合我已有的知識，然後經過多次總結，最後才獲得了一定的認知，而且即使如此，可能依然膚淺。所以，對技術調研保持一顆敬畏的心。
不要覺得中臺是騙你的，白貓黑貓能賣萌纔是好貓
無論別人心中的數據中臺是怎麼樣的，我心中的數據中臺核心就是掩蓋複雜性，提供極簡的交互手段，降低用戶門檻，提升用戶人效，讓數據觸手可及。所以我之前解釋說，中臺的思想很簡單，就是冰山模式，水面上漏出來的就幾個API，一個Web控制檯。但是底下可能是成千上萬的機器，各種流，批跑在特定的分佈式引擎上，權限，調度，預警監控，元數據體系進行配套，是一個非常複雜的體系。那和以前的數據平臺的區別是什麼呢？數據平臺是讓你可以DIY，降低業務侵入性，而中臺則是包含了數據平臺，同時帶有業務，讓業務放拎包入住，提升效益。
從我個人的實踐來看，我們19年其實是按雲的思路去發展我們的數據中臺的。那爲什麼我們以前不提中臺呢？因爲以前技術上不允許，需要大量人力物力，而隨着技術的發展，中臺的冰山模式其實已經可行了，甚至小公司也能做到。可惜的是，還有很多企業在大數據和AI領域還處於刀耕火種的階段，他們以爲他們獲得了穩定，其實是穩定和效率都沒有得到提升，唯一帶來的好處可能是996吧。中臺極大的降低了大數據/AI的使用門檻，可以囊括基本上公司的各個工種，讓他們都能夠在中臺上玩，各取所取。算法，研發，分析師，搜索，推薦，運維，運營，產品經理，設計，商業，銷售，包括老闆。
多組合已有特性，而不是去開發新的特性
使用MLSQL的同學，經常會問到的一個問題是，有沒有if/else,或者while循環的語法。我會說有基於現有的語法，有很多變相的實現。一聽到這話，大家都會心裏沒底，會說出自己的疑惑：
有一些可以
有些可能變相實現比較麻煩或者很難做到，
後續我有這塊需求解決不了
的時候看來是要找你給方案了
我通常會懟回去：
你都不知道我說的變相實現方案是啥
你就覺得變相的方案會麻煩了？
之後我會詳解引入if/else和while循環的壞處，畢竟即使寫程序，我們也是很努力的避免去使用他們，比如我之前還專門寫了一篇文章：如何優雅的消解[If/Else森林]
現在如果加上了他，面對千行的腳本，閱讀和維護就會變成巨大的災難，而用戶往往會因爲引入了特性，又會引入新特性去解決新引入特性的不足，最後結果就是：
這個系統太重了，
我們需要去找一個輕量一點的
我們似乎會在這個循環中進入永生。
所以我們應該通過加深對一個系統的瞭解，從而通過組合已有的特性來完成需求而不是要求新特性去解決一個需求。當然了，我們不是說不進步，而是多嘗試阻止自己，能用已有的特性解決這個問題麼？確實解決不了，我們是不是能夠重構已有的特性？最後確實不行，我們才考慮增加新的特性。保持身材，控制攝入卡路里是需要的。
痛點驅動結合效率驅動
在我們的內心世界，我們認爲痛點驅動是一個理所當然的事情。只有有了痛，我們纔有動力去解決它。奈何能感受到痛點的是人，而人基因裏就包含了一件事，就是會忍受，會適應。比如你一開始覺得房間有異味，但是隨着時間推移，也就會忘卻異味的存在。所以，人們可能痛着，卻意識不到痛的存在。大部分人害怕的意見事情就是“改變”，改變現有的模式。所以當用戶已經感知不到痛，而你看到了，並且要去改變這個痛，人們就會抵觸，因爲他們已經感覺不到，但是你卻要盡心改變，改變已有的工作模式。所以，從人性角度來看，光有“痛點”，是難以持續推動一個團隊或者公司前行的。
這個時候，我們需要有一個新的“高階”驅動，就是效率驅動，效率源於老闆或者資本家對利潤的追求。效率提升意味着成本降低，同時產量提升的空間也會變得更大，賣出更多的產品。這意味着這個驅動纔是和老闆的終極目標是一致的，並且效率也確實應該是我們“工人階級”需要追求的東西，有限的人生不應該浪費在重複的事情上。所以，無論團隊有沒有痛點，我們核心看效率，這包括人效，團隊總體效率。如果低了，我們就要思考，能通過新的技術手段提升麼？能通過新的管理手段提升麼？能通過新的流程提升麼？
這兩年，尤其是今年，我核心的工作之一，就是“巡視”，查看每個人的效率，每個環節的效率，如果發現不滿意，我會整合各方面資源去解決這個問題。可以參考我18年的一篇文章：爲什麼需要效率督查團隊
關心技術趨勢
很多對技術持有保守心態人，總是希望某項技術爛大街以後再買入，但是技術本身並不是憑空而來的，而是實際的需求驅動的。這意味着，當它爛大街的時候，其實可能已經不能支撐現階段公司業務的訴求了。比如現在已經進入數據湖階段了，意味着業界對數據的需求也只有數據湖才能更好的支撐了，因爲人們對於實時，增量，更新等等，對於AI有了更多的需求。你這個時候還在守着傳統的數倉，意味着你嚴重的限制了公司的業務需求，使得公司的業務是落後於其他公司的。當其他的公司能夠實時跟蹤某個宣傳活動的效果時，你還停留在一天以後才能知道，當其他公司的運營查看一個數據只需要一分鐘，你們公司還需要研發配合，一週才能交付一個數據結果，公司還能和其他公司競爭麼？但求無錯，但無錯可能最後導致了公司積重難返。及時看清技術發展方向，少走彎路，儘快引入明顯是未來趨勢的技術，在跟進的過程中讓團隊慢慢掌握這些技術，等它爛大街的時候，我們也已經吃透，並且讓其產生了最大的價值，這個時候我們纔有精力進一步引進新的技術。及時引入，也能讓我們從容不迫小步迭代使用，現在不重要的業務線嘗試，慢慢積累經驗，然後漸漸引入更多的業務。
關心技術趨勢，擁抱新的技術。只要用正確的方式和態度去做，並不會給“穩”帶來隱患。
插件化也是中臺的必要特徵
MLSQL不斷在的擁抱新的技術，包括數據湖，Ray, Apache Arrow，同時也在產生一些新的創新，包括增量同步相關的項目，大家可參考我之前的文章：是時候改變你數倉的增量同步方案了
這必然會導致項目異乎尋常的龐大，加上MLSQL本身也能作爲數據中臺，必然帶有大量業務開箱即用的功能，這又會進一步龐大項目。所以插件的引入是非常必要的。所以數據中臺還具有一個很重要的特點，就是有優秀的插件體系，插件可以是針對進程的，也是可以進程的。比如我提供了一個符合中臺標準的API，這我們也可以看做插件。從而使得中臺可以快速的迭代。所以我們不要把插件就看成率屬於某個進程，而是要把它作爲一個大體系的一環去設計。所以中臺本質是一個大的架構體系，他以某一個平臺爲中心，衍生了一大批周邊輔助系統，最後完成中臺。
總結
暫時就想到這些，下次還想到別的，到時再補充到文章裏。????
