今天本來想寫scala的 後來感覺今天沒有摸到門道與核心 明天再去集群裡試試。
近20年來在td的幫助（剝削下）銀行資訊系統的資訊化儲存水平有一定的提高。
近5年來大資料的技術逐漸穩定，書中總結如下：
大資料的應用與之前資料的應用的不同點在於 規模、速度、多樣性、價值密度。
就我行而言，規模上系統儲存勉強達到tb級的資料，原始檔的保留策略是刪除而不是存檔，有利於節省空間。
未來的hadoop資料倉儲發展邏輯在於以下幾點：
1、歷史源資料的儲存策略－－－不僅可以選擇將可結構化的資料結構化進入倉庫報表、也可以選擇直接將不可結構化的原始檔儲存進入集群hdfs，待後續技術發展到一定階段進行應用。（比如很多文字資料，目前沒有結構化方案的）
2、資料的分割槽查詢功能是作為倉庫對外介面的保證。也是穩定執行的保證。這裡邊的要求就應當包括速度上的要求。最近業務經常反應的sas與hadoop通過libname方式直連緩慢的問題如何徹底解決？因為sas本身就並非分布式、對應大資料集的處理能力不夠，然而impala能夠處理這些但是不能夠很方便的進行匯入匯出（比如二進位制檔案和大檔案），未來的趨勢一定是建立在hadoop集群上完成現有sas分析功能的元件。
3、基於資料倉儲級別的建模，之前已經思考過。無論是星型也好雪花也好，維度主題更重要的是反應全域性，集市層的資料應當保留所有從貼源層錄入資訊，而不是和現在一樣進行拆解後需要使用時再復原。這也是符合分析角度多樣性的基本要求的。同時跨表、跨庫的多種資料維度的關聯分析是集市層面最主要的分析方式之一
4、價值密度是針對大資料才會有的新鮮詞彙，大範圍的資料中以發現資料間的關聯為主，以理論解釋為輔。
我們如何從海量的資料中挑選出有意義的資料並用之來分析一件事情？是做資料分析需要考慮的最直接的內容。
大資料的金融資料探勘思維
第一步就是
通過取樣，告別取樣
。我們之前的所有對資料的要求都是先取樣再分析，再應用到全集，現在不合適，就如同沒有人願意被代表一樣，沒有一條資料希望自己被其他資料代表。（不然就是重複資料咯）
第二步是允許錯誤資料的加入。如同大資料平台對冗餘的容忍一樣，我們也需要在分析階段容許錯誤資料的加入。
這邊特別說明一下（資料沒有對錯之分，只是如果在不恰當的場景出現，並且會影響我們對於整體的把控的內容，姑且稱之為錯誤資料）。
第三步 就是
關聯，為何一再強調關聯，就是因為資料體量提公升，不僅僅是2-3張表幾十萬條資料之間的相互關係，而是需要整合多個系統的所有相關表的最少千萬級別的資料關聯。一旦無法把控關聯邏輯，就意味著需要花超過百倍的時間進行相關處理。
晚點開始寫架構上的內容。
《大資料的衝擊》讀後感 總結
大資料難以管理的原因，可以用 3v 來描述，即volume 容量 variety 多樣性 velocity 產生頻率 更新頻率 從廣義上來說，大資料可以定義為包括因具備 3v 特徵而難以進行管理的資料，對這些資料進行儲存 處理 分析的技術，以及能夠通過分析這些資料獲得實用意義和觀點的人才和組織的綜合...
《寫給大家看的大資料》讀後感
這是第一次看 達人迷 系列的書，基本屬於科普類的，不涉及深入的技術，主要是普及概念，以及介紹業界生態。讓讀者對 大資料 有乙個比較直觀的認識。it相關人員都可以讀一讀。書中介紹了大資料的演化過程，大資料技術的架構方式，各個元件的功能，整體大資料技術的運作方式，以及未來的趨勢。書中提及的大資料各個方面...
《決戰大資料（公升級版） 大資料的關鍵思考》讀後感
這是一本車品覺先生在電商領域多年大資料 資料分析的實戰經驗總結，可以說是資料系統頂層設計的精髓，這本書通篇全是幹活，乾到從閱讀前言起，就需要不斷地思考，二十萬字的一本書，前前後後讀了乙個月才讀完，幾乎每頁都要做筆記寫思考結果，每頁都有值得反覆琢磨的點，推薦每位工作中涉及大資料 資料分析工作的人都應該...