1、明確技術與業務的關係 （1）知識和發明來自實踐和生產的實際需要，OSI的7層模型再美、再學院化也沒有乾過TCP/IP； （2）切莫強求技術驅動，技術職責第一要務是做好深度服務業務； （3）數據產品不同於一般業務系統。隔行如隔山，跨部門項目往往對雙方團隊的時間管理、利益妥協、溝通協作和交付提出了很 ...
1、明確技術與業務的關係
（1）知識和發明來自實踐和生產的實際需要，OSI的7層模型再美、再學院化也沒有乾過TCP/IP；
（2）切莫強求技術驅動，技術職責第一要務是做好深度服務業務；
（3）數據產品不同於一般業務系統。隔行如隔山，跨部門項目往往對雙方團隊的時間管理、利益妥協、溝通協作和交付提出了很高很難的要求，數據產品要有價值，必須獲取足量、高質的數據，建立跨部門、跨業務的統一數據視圖前景美妙但步履維艱，保持持久熱情、對數據產品的價值心裡有數並儘可能地獲取資源上的支持，是技術之外的重要話題。
2、價值導向，數據平臺架構的策略、哲學與全局意識很重要
（1）成本意識——只用合適的。深入理解業務和數據規模，不走冤枉路，不用牛刀去殺機，牛刀的維護成本很高很高；不輕視MySQL、不高估Hadoop，不盲目崇拜Storm和Samza的流計算；
（2）專業意識——不過分給離線計算強調效率，不過分給準實時計算強調規模（優勢火力學說）；
（3）產品意識——不是最牛逼的技術就是最牛逼的產品（比如企查查，碼農要重視產品、市場及領域知識）；
（4）機動意識——靈活處理業務場景的技術需求。空間換時間（緩存）、時間換空間（大規模數據的分散式存儲、比如HDFS和MongoDB的Sharding）；
（5）歷史意識——不是所有的技術債都要大肆批評，為公司歷史業務作出貢獻的代碼應該保持尊敬，其中的一些問題更應該歷史地看待，自己做得不一定比前人更好。計算跑向數據——比如傳統的存儲過程，免去了數據傳輸性能好，但擴展性很差，跨資料庫的DB-Link技術可以看做分散式計算的早期手段；數據跑向計算——如Hadoop的MR，有不可忽視的數據運輸代價，但計算和業務邏輯處理更加自由靈活；
（6）戰略意識——正確認識數據產品的特點：周期長、開發難、低反饋、弱可控，客戶與業務需求總是迫切的。將冗長切分，局部和階段性反饋並測試尤為重要，重視一點可視化往往有奇效。沒有客戶的數據產品沒有價值，從立項開始，就要有生存、競爭、運營的綜合考慮。讓現有數據產生價值是數據團隊的第一使命，而逐步產生價值、釋放數據活力、融通部門利益則是一種全局運營意識。
3、分而治之
（測試大數據處理手段有效與否的基本方法就是去求個和、排個序、分個組。如同1+1=2，這是基本所有大數據處理場景的最小化抽象。那麼就會體會到——分開了求和排序難，不分卻治不了大數據）
4、存儲與索引分離、冷熱分離、讀寫分離、二八原理、分級實施
（1）讀寫混合的通常可以上溯業務進行梳理，找出重點、降級實施；
（2）有時候分散式演算法想破天，不如將伺服器記憶體升級到512G來得簡單和高效，分散式的同時不要忘了集中式的簡單帶來的收益；
（3）存儲與索引在一起，既有傳統關係型資料庫作為代表，也有華為為HBase拓展本地二級索引的例子，但通常分離之後可以同時享受專業的分散式存儲和專業的索引技術帶來的雙重好處，缺點是可能需要一個觸發器或協程，但是同步與計算的地位是同等重要的，可以從Storm的ACK機制及Kafka的Log機制獲取處理此類嚴峻問題的靈感；這不僅僅是ETL和微服務的需求，也是一致性的挑戰。
5、專業的乾專業的事、學習但不重覆造輪子
（1）每個框架都有自己的原語、有限的服務能力和缺點，這是極為正常的，整合和有限改造是普遍存在的；
（2）剋服追求技術唯美的碼農心理障礙，不輕信自己可以做得比別人更好，以可控交付和快速反饋為首要原則；
（3）項目的死亡通常是因為產品需求和碼農的認知圖像不一致造成，這需要產品瞭解一定技術特點，更需要技術瞭解產品的真正目的；
（4）輕視產品或者領域專家，是技術的狹隘而不是別人的無知。
6、分散式鎖，真的很難
（1）鎖與分散式事務永遠是前沿技術；
（2）即使是電話通訊這種鏈路型的也會中斷，何況電腦網路還是分包為基礎；
（3）腦裂是自然的，我們要做的是局部可控、提前預案、降低損失、快速維護；
（4）同步並非最差，非同步並非最佳，任何優勢背後都有先天劣勢；
（5）高性能和簡約架構是一對矛盾，吸氣量太大還容易爆缸，但一旦認識到代價是正常和必不可缺之後，往往可以柳暗花明；
（6）不死磕，compromise是工程意義上的折衷而不是碼農心理上的妥協。
7、推和拉（Push&Pull）
（1）都是常用手段，難點都在於狀態同步與可靠交付，相對來講拉更簡單一些，但為了一致性和狀態的到達往往會浪費計算資源
（2）有時候耗費某些資源換取更簡單平坦的架構，收穫更低的維護代價比死磕高性能收益更大。比如全雙工通訊很美，但WebSocket技術對Socket、進程、記憶體資源的占用讓Web服務更加複雜；
（3）函數計算的優點之一就是不可變的數據結構，狀態的不可變意味著失敗的計算環節可以被重放，看似浪費資源，但實際是用簡單的變換迭代換取思維上的簡潔性，讓業務邏輯與計算環節更明顯地浮現出來，這就是更有價值的收益。
8、可靠性與高性能是一對矛盾
P2P還是Master-Slave，要視業務特點決定，P2P更適合高性能、硬實時系統，MS架構相對簡單、易於理解和操作、但有著主節點宕機導致服務可靠性下降的危險（Hadoop為此升級了雙NameNode節點、MySQL生態也有雙主節點的成熟策略）。
9、重視函數式思想，不死磕面向對象，生態很關鍵
（1）並行處理的難點之一就是狀態的改變、到達、回退與追蹤的複雜，這一點不僅在框架和代碼級別，在流服務體系中也很重要。Storm採用Clojure作為編程語言的目的除了這種語言很酷之外，更重要的是其對不可變的數據結構和函數計算的支持很到位；
（2）Spark牛逼的地方就是深入貫徹函數計算，並提供了完善的RDD操作原語與多語言支持，對關係型資料庫、HDFS等也有很好的支持，特色鮮明而且瞄準Hadoop生態，它的戰略眼光及架構值得反覆學習；
HyperTable瞄準了HBase的某些性能瓶頸以此來打造同樣的列式資料庫，但在市場上它失敗了。C++實現底層帶來了高性能的同時也帶來了生態疏離。
