大資料應用正在從概念走向現實，而企業在大資料應用開發時，軟體的彈性（resilient）正在成為決定大資料應用成敗的關鍵因素。彈性差的應用無法應對大規模的資料集，在測試和運營中也缺乏透明度，而且也不安全。
· 避免大資料應用在生產環境中掉鍊子的最佳辦法就是在開發階段就開發彈性應用，例如：健壯性、經過測試、可改變、可審計、高安全、可監控。
· 可以說，開發出彈性大資料應用既是乙個技術工作，也是乙個哲學問題。concurrent的supreetoberoi近日撰文提出大資料應用開發八大基本原則:
·一、為彈性大資料應用描繪乙個藍圖
· 第一步是為企業大資料應用建立乙個系統的架構和方法，要處理什麼資料？那些型別的分析最重要？軟體架構需要承載那些指標、審計、安全和運營功能？
· 另外一些需要考慮的問題：那些技術最關鍵？哪些技術只是圖一時之便？你的藍圖需要準確評估當前架構的問題所在。
·二、資料規模不再是問題
· 如果應用無法處理更大規模的資料集，那麼它就缺乏彈性，彈性應用應當能夠處理任意規模的資料集（包括資料深度、廣度、頻度等），資料彈性還只對新技術的相容，缺乏彈性的應用需要不斷配置修改應用來適應不斷更新的大資料技術，對於企業來說是時間、資源和金錢上的無底洞。
·三、透明度
· 對於複雜應用來說，查詢擴充套件性等彈性相關問題還很難實現自動化。關鍵是鎖定問題的根源所在：是**、資料還是架構抑或網路問題？並非每個應用都要具備這種透明度，但大一些的平台應當具備足夠的透明度，讓所有開發者和運營人員都能在問題發生時立刻找到根源並採取措施。
· 一旦發現問題，最為關鍵的是將找到應用行為對應的**——最好是通過發現問題的監控應用。大多數情況下，訪問**會涉及到多個開發人員，執行起來流程將非常曲折。
·四、抽象，事關高效和簡潔
· 彈性應用總是面向未來的，通常採用抽象層來簡化開發、提公升效率，允許採用不同的技術實現。作為架構的一部分，彈性開發的抽象層能夠避免開發者陷入技術實現的細節泥潭中。簡潔性則能方便資料科學家使用應用訪問所有型別的資料來源。如果沒有抽象技術，產品的生產力會大打折扣，修改成本增高，而使用者則為複雜性所困擾。
·五、安全：審計與合規
· 彈性應用能自我審計，能夠顯示誰使用了應用，誰有許可權使用，訪問了哪些資料以及政策如何實施。在應用開發階段就將這些功能考慮進去是應對日益增長的大資料隱私、安全、治理和控制挑戰的關鍵所在。
·六、完整度與測試驅動的開發
· 彈性應用的乙個基本要求就是不能遺失任何資料，資料完整性的喪失往往會導致嚴重的後果，例如金融企業會因為程式**弄丟了一兩行交易資料而在反洗錢或金融欺詐調查中遭受處罰。
·七、資料便攜性
· 不斷發展的業務需求驅動技術不斷做出改變，因此，大資料應用也應當能夠在多個平台和產品上執行。最終的目標是讓終端使用者能夠通過sql和標準api訪問資料（無論是否實時）。例如，乙個先進的大資料平台應當允許原本由hadoop儲存mapreduce處理的資料，轉移到spark或tez中進進行處理，而且這個過程不需要或盡可能少地改動**。
·八、不要搞個人主義
· 大資料應用的開發不應當依賴某個高手的個人才華，**應當在多個開發者之間分享、評估和保有。這個策略讓整個團隊，而不是個人，對應用質量負責。
java開發設計六大基本原則
設計模式的六大原則 總原則 開閉原則 對擴充套件開放，對修改封閉。在程式需要進行拓展的時候，不能去修改原有的 而是要擴充套件原有 實現乙個熱插拔的效果。所以一句話概括就是 為了使程式的擴充套件性好，易於維護和公升級。想要達到這樣的效果，我們需要使用介面和抽象類等，後面的具體設計中我們會提到這點。1 ...
設計模式之開發 基本原則
下面的幾個設計模式，我認為是乙個設計模式中的規則，一 開放封閉原則 1 對這個原則有兩個特徵 對擴充套件是開放的 open for extension 另乙個是說 對於更改是封閉的 closed for modification 2 開放封閉原則的目的是，讓軟體對於新的需求的改變可以保持相對的穩定。...
維度建模的10大基本原則
遵循這些原則進行維度建模可以保證資料粒度合理，模型靈活，能夠適應未來的資訊資源，違反這些原則你將會把使用者弄糊塗，並且會遇到資料倉儲障礙。原則1 載入詳細的原子資料到維度結構中 維度建模應該使用最基礎的原子資料進行填充，以支援不可預知的來自使用者查詢的過濾和分組請求，使用者通常不希望每次只看到乙個單...