■ 易華錄示范湖項目數據總存儲容量達到600PB，其中藍光存儲達到560PB
■ 藍光存儲可降低能耗80%，且安全性高，保存時間可達50年以上
1PB數據有多大？北京易華錄總裁林擁軍解釋，它是2的50次方個Byte（字節）。如果一部高清電影按2GB計算，那么1PB的存儲空間大約能存52萬部。如果換成軟盤保存，1PB數據需要用掉7.46億張軟盤，總重大約1.34萬噸。
日前，位于姜堰高新區揚帆創業園二期內的易華錄示范湖項目，用于藍光存儲的342臺套設備和196臺套磁存儲先進設備已全部安裝到位，即將開機運營。此舉標志著國內首個藍光光盤數據庫在姜堰建成。
易華錄華東數據湖產業園項目總投資39.79億元，規劃占地189.5畝，是2018年江蘇省重大產業項目，包括智慧姜堰和城市數據湖兩部分，建成后將成為全球最大的大數據基礎設施。投資6億元的易華錄示范湖項目是易華錄數據湖產業園的先行項目，包括數據湖數據中心機房、數據湖雙創中心及展示中心。
易華錄示范湖項目由北京易華錄信息技術有限公司投資建設，去年2月落戶姜堰高新區。該項目目前采用有磁存儲和藍光存儲兩種方式，擁有國內唯一的藍光光盤庫。光盤庫的每一個光盤可以存儲300G的數據，一整個機柜可以存儲1.64PB數據，容量相當大，在全球范圍內都處于領先水平。數據湖數據中心機房目前安裝538臺機柜，數據總存儲容量達到600PB。其中，藍光存儲機柜為342臺，冷存儲能力為560PB；熱磁存儲機柜196臺，熱存儲能力為40PB。
1PB數據有多大？北京易華錄總裁林擁軍解釋，它是2的50次方個Byte（字節）。如果一部高清電影按2GB計算，那么1PB的存儲空間大約能存52萬部。如果換成軟盤保存，1PB數據需要用掉7.46億張軟盤，總重大約1.34萬噸。
6月22日上午，記者來到姜堰高新區，看到易華錄示范湖項目所有嶄新設備整齊排放，擺滿了500平方米的控制室。現場技術人員告訴記者，數據湖通俗地講，是大型數據存儲庫和處理引擎，擁有大數據存儲和分析能力。在數據存儲方式上，易華錄利用了長效光盤庫存儲技術。該技術被收錄在2016年12月工信部發布的《綠色數據中心先進適用技術目錄（第一批）》里。其核心是藍光存儲的運用，具有存儲容量大、存儲空間擴展靈活、安全性高（可抗核磁攻擊）等特點，保存時間可達50年以上，并且對環境沒有特殊要求，無需恒溫恒濕，無需長期在線存儲，可降低能耗80%。藍光存儲有效降低數據遷移成本，是新一代存儲尤其是冷存儲的未來方案。
林擁軍說，數據早已成為重要的生產要素，城市數據湖將是未來城市主要的信息基礎設施，應該像圖書館一樣成為城市的標配。易華錄城市數據湖依托中國華錄集團，具有全球領先的光磁一體存儲核心技術，具有安全、綠色、海量、生態四大特點。易華錄示范湖項目運用光磁融合技術緊密銜接硬盤陣列存儲系統，單張光盤存儲容量達300GB ，其能耗僅為磁存儲的千分之三。
建好數據湖，必須引入各方面的數據，即“引水入湖”。目前，很多政府機關和企事業單位都有自己的數據中心，然而彼此孤立，形成一個個數據孤島?！皵祿切畔a業的命脈，目前80%的大數據來源于政府。政府有權利、有義務收集這些數據，讓數據取之于民，用之于民?，F在來看，政府各部門已經逐漸有了數據融合的理念和意識。”林擁軍說，數據湖作為基礎設施，最大的意義在于帶動產業升級，同時幫助政府實現高效管理、服務和技術創新，通過數據驅動城市發展。
林擁軍表示，下一步，易華錄示范湖將助力建設智慧姜堰，以大數據平臺、人工智能引擎等為支撐，輔之各類行業子湖、數據分析與展示、模型訓練等增值要件，為姜堰區政府、企業、市民提供公共服務，成為支撐城市經濟社會轉型發展的戰略基石。
（中國江蘇網）
]]>
現如今大量的中小型公司并沒有大規模的數據，如果一家公司的數據量超過100T，且能通過數據產生新的價值，基本可以說是大數據公司了 。起初，一個創業公司的基本思路就是首先架構一個或者幾個ECS，后面加入MySQL,如果有圖片需求還可加入磁盤，該架構的基本能力包括事務、存儲、索引和計算力。隨著公司的慢慢發展，數據量在不斷地增大，其通過MySQL及磁盤基本無法滿足需求，只有分布式化。 這個時候MySQL變成了HBase,檢索變成了Solr/ES，再ECS提供的計算力變成了Spark。但這也會面臨存儲量大且存儲成本高等問題。
非結構化業務增多
另外一個趨勢就是非結構化的數據越來越多，數據結構的模式不僅僅是SQL，時序、時空、graph模式也越來越多，需要一些新的存儲結構或新的算法去解決這類問題，也意味著所需要做的工程量就會相對較高。
引入更多的數據
對于數據處理大致可歸類為四個方面，分別是復雜性、靈活性、延遲<讀,寫>和分布式，其中分布式肯定是不可少的，一旦缺少分布式就無法解決大規模問題 。靈活性的意思是業務可以任意改變的;復雜性就是運行一條SQL能夠訪問多少數據或者說SQL是否復雜;延遲也可分為讀與寫的延遲。hadoop?& Spark可以解決計算復雜性和靈活性，但是解決不了延遲的問題;HBase&分布式索引、分布式數據庫可以解決靈活性與延遲的問題，但由于它沒有很多計算節點，所以解決不了計算復雜性的問題。Kylin(滿足讀延遲)在計算復雜性與延遲之間找了一個平衡點，這個平衡點就是怎樣快速出報表，但對于這個結果的輸入時間我們并不關心，對于大部分的報表類的需求就是這樣的。每個引擎都是一定的側重，沒有銀彈!
ApsaraDB HBase產品架構及改進
應對的辦法
我們也不能解決所有的問題，我們只是解決其中大部分的問題。如何找到一個在工程上能夠解決大部分問題的方案至關重要，應對辦法：
分布式：提供擴展性
計算力延伸：算子+SQL，從ECS到Spark其本質其實就是一種計算力的延伸
分層設計：降低復雜性，提供多模式的存儲模型
云化：復用資源&彈性，降低成本
基本構架
首先包含了兩個分離
分別是HDFS與分布式Region分布式檢索分離
SQL時空圖時序Cube與分布式Region檢索分離
大致的分層機構如下：
第一層：介質層，熱SSD介質、溫SSD&SATA 混合、冷純SATA(做EC)
第二層：分布式文件系統，也就是盤古。事實上越是底層越容易做封裝優化。
第三層：分布式安全隔離保障層QOS，如果我們做存儲計算分離，就意味著底層的三個集群需要布三套，這樣每個集群就會有幾十臺甚至幾百臺的節點，此時存儲力是由大家來均攤的，這就意味著分布式安全隔離保障層要做好隔離性，引入QOS就意味著會增加延遲，此時會引入一些新的硬件(比如RDMA)去盡可能的減小延遲。
第四層：分布式文件接口：HDFS & API(此層看情況可有可無)
第五層：我們提供了兩個組件，分布式Region-HBase與分布式檢索-Solr，在研究分布索引的時候發現單機索引是相對簡單的，我們提供針對二級索引采取內置的分布式Region的分布式架構，針對全文索引采取外置Solr分布式索引方案
第六層：建設在分布式KV之上，有NewSQL套件、時空套件、時序套件、圖套件及Cube套件
另外，可以引入spark來分析，這個也是社區目前通用的方案
解決成本的方案
對于解決成本的方案簡單介紹如下：
分級存儲：SSD與SATA的價格相差很多，在冷數據上，我們建議直接采取冷存儲的方式 ，可以節約500%的成本
高壓縮比：在分級存儲上有一個較好的壓縮，尤其是在冷數據，我們可以提高壓縮比例，另外分布式文件系統可以采取EC進一步降低存儲成本，節約100%的成本
基礎設施共享：庫存壓力分擔，云平臺可以釋放紅利給客戶
存儲與計算分離：按需計費
優化性能：再把性能提升1倍左右
云數據庫基本部署結構
假設在北京有三個機房可用區A、B和C,我們會在可用區A中部署一個熱的存儲集群，在北京整體區域部一個冷的存儲集群，實際上有幾個可用區就可以有幾個熱集群，主要是保障延遲的;冷集群對延遲相對不敏感，可以地域單獨部署，只要交換機滿足冷集群所需的帶寬即可。這樣的好處是三個區共享一個冷集群，就意味著可以共享庫存。
ApsaraDB HBase產品能力
我們提供兩個版本，一是單節點版，其特點是給開發測試用或者可用性不高，數據量不大的場景。二是集群版本其特點是高至5000w QPS，多達10P存儲與高可靠低延遲等。
? 數據可靠性：99.99999999%：之所以可靠性可以達到如此之高，其核心的原因就是存儲集群是單獨部署的，其會根據機架等進行副本放置優化
服務可用性：單集群99.9% 雙集群99.99%。
服務保障：服務未滿足SLA賠付。
數據備份及恢復。
數據熱冷分離分級存儲。
企業級安全：認證授權及加密。
提供檢索及二級索引及NewSQL能力。
提供時序/圖/時空/Cube相關能力。
與Spark無縫集成，提供AP能力。
數據備份及恢復
備份分為全量備份HFile與 增量量備份HLog;恢復分為HLog轉化為HFile和BulkLoad加載。阿里云集團迄今為止已經有一萬兩千多臺的HBase,大部分都是主備集群的，在云上由于客戶成本的原因，大部分不選擇主備，所以需要對數據進行備份。其難點在于備份需要引入計算資源，我們需要引入彈性的計算資源來處理備份的相關計算任務
Compaction 離線Compaction(研究中)
我們在內部研究如何通FPGA對Compaction進行加速，這會使得集群運行比較平緩，特別是對計算資源少，存儲量大的情況下，可以通過離線的作業處理Compaction。
組件層
我們有5中組件，NewSQL(Phoenix)、時序OpenTSDB、時空GeoMesa、圖JanusGraph及Cube的Kylin，及提供HTAP能力的Spark。這里簡單描述幾個，如下：
NewSQL-Phoenix
客戶還是比較喜歡用SQL的,Phoenix會支持SQL及二級索引，在超過1T的數據量的情況下，對事務的需求就很少(所以我們并沒有支持事務);二級索引是通過再新建一張HBase表來實現的。在命中索引的情況下，萬億級別的訪問基本在毫秒級別，但由于Phoenix聚合點在一個節點，所以不能做Shuffle類似的事情，同時也就不能處理復雜的計算，所以任何說我是HTAP架構的，如果不能做Shuffle，就基本不能做復雜的計算。
HTAP-Spark
在HTAP-Spark這部分主要介紹一下RDD API、 SQL、直接訪問HFile，它們的特點如下：
RDD API具有簡單方便，默認支持的特點，但高并發scan大表會影響穩定性;
SQL支持算子下推、schema映射、各種參數調優，高并發scan大表會影響穩定性;
直接訪問HFile，直接訪問存儲不經過計算，大批量量訪問性能最好，需要snapshot對齊數據。
時序-OpenTSDB & HiTSDB
TSD沒有狀態，可以動態加減節點，并按照時序數據的特點設計表結構，其內置針對浮點的高壓縮比的算法，我們云上專業版的HiTSDB增加倒排等能力，并能夠針對時序增加插值、降精度等優化。
大數據數據庫的實際案例
以下簡單介紹幾個客戶的案例，目前已經在云上ApsaraDB HBase運行，數據量基本在10T以上：
某車聯網公司
這是一個車聯網的客戶，有100萬車，每輛車每10秒上傳一次，每次1KB，這樣一年就有300T數據，六個月以上是數據低頻訪問，所以他要做分級存儲，把冷數據放到低介質上
某大數據控公司
這是一個大數據控公司，它大約有200T+的數據量，將HBase數據 (在線實時大數據存儲)作為主數據庫，先用HBase做算法訓練，再用HBase SQL出報表，另外做了一套ECS進行實時查以便與客戶之間進行數據交換。
某社交公司
社交會有大量的推薦，所以SLA要求高達99.99，并采用雙集群保障，單集群讀寫高峰QPS 可以達到1000w+，數據量在30T左右。
某基金公司
這是一個金融公司，它有10000億以上的交易數據，目前用多個二級索引支持毫秒級別的查詢，數據量在100T左右
某公司報表系統
先離線建好Cube再把數據同步到HBase中，實時數據通過Blink對接進行更新，數據量在可達20T左右。
封神：真名曹龍，09年加入阿里，現任阿里云高級技術專家、架構師，專注于大數據分布式計算、數據庫、存儲領域，先后研發上萬臺Hadoop、ODPS集群，負責阿里YARN、Spark及自主研發內存計算引擎，目前為廣大公共云用戶提供專業的云HBase數據庫及計算服務。
（云棲團隊）
]]>
隨著企業收集的數據量以每年 40% 到 60% 的速率持續增長，IT 團隊面臨管理海量信息的挑戰。
為了應對數據的容量、速度、類別等方面的爆發性增長，眾多企業正準備轉向 NoSQL 數據庫來代替傳統的關系數據，以實現更好的性能、伸縮性和易于開發。
大數據時代3個重要的數據庫策略技巧
傳統的關系型數據庫需要提前構造好整張表的數據類型和模式。而另一方面，NoSQL 數據庫更加靈活，允許新類型的數據快速插入，而且能讓不同類型的數據存儲在一起。這個特性對對期待分析大量非結構化數據的公司特別有幫助。非結構化數據是指不適合預定義的數據模型，例如 tweet、視頻或者從傳感器采集的數據等。
這僅僅是 NoSQL 數據庫流行起來的一個原因。2015 年到 2020 年期間，NoSQL 數據庫的使用有望達到 21% 綜合年增長率。
”企業正在處理與分析越來越多的數據，需要能夠高效可靠的處理一定規模的數據“，NoSQL 數據庫提供商 Couchbase 的 CEO Bob Wiederhold 說到?！盀榱藢崿F這個目標，他們拋棄了關系型數據庫?！?/p>
大約 80% 的企業現在仍然在使用關系型數據庫，Wiederhold 預測這個比例在接下來的 10 到 15 年將會降至不到 50%，企業遷移到 NoSQL 數據庫，尤其是 Web應用，移動應用以及物聯網(IoT)應用。
不過采用 NoSQL 數據庫也需要做出一些取舍。
“你需要兩種類型的數據庫做不同的事，有時甚至需要結合兩者一起使用，” 大數據分析初創公司 Metanautix 的 CEO Theo Vassilakis 說到。
在計劃如何存儲和處理大數據時，有三個因素需要考慮。
1.針對應用程序的考慮
兩種類型的數據庫都有其用武之地，Vassilakis 表示。
傳統的關系數據庫的好處之一是它們跑 ACID 事務，這保證了數據庫的變化能夠得到可靠準確地處理。
“銀行結算原型，一個賬戶出賬而另一個賬戶入賬，” 在這種形式下應用程序需要更多的事務處理，這時使用傳統的關系型數據庫更適合。Vassilakis 解釋說。
但這使關系型數據庫橫向擴展非常困難，增加了計算成本而且降低了數據檢索速度。
NoSQL 能夠輕松通過提升硬件性能花相對低的成本擴展服務性能。再加上，NoSQL 能夠處理不適合傳統關系型數據庫的非結構化數據。
“這種形式的數據庫架構對于存儲非結構化數據，縮放多數據庫實例和為那些同時通過 Web 和手機應用的迅速增加的大量用戶提供服務是最理想的。所以，如果那正是需求所在，NoSQL 是個更好的選擇，” Wiederhold 說到。
2.考慮兩者的優點
“隨著數據的爆炸性增長，企業正在抱怨他們現有的數據庫性能不佳，而且維護越來越昂貴。企業需要擴展商用硬件提供能力去維護同等級的服務，“ Splice Machine 的 CEO Monte Zweben 說到。
他補充：“但在遷移到 NoSQL 過程中，他們不分好壞，將以前的把寶貴的東西也一起丟掉了”。
關系型數據庫善于事務處理，使用許多技術員工已經熟悉的語言(SQL)，并與現有的業務集成應用程序編寫 SQL，但是關系型數據庫性能不足，NoSQL 提供了擴展和收集的非結構化數據的能力。
所以一些企業橋接了這個兩種類型的數據。例如，Splice Machine 使用 Hadoop，將 NoSQL 數據庫作為它系統中的一部分，并在基于 NoSQL 優點的基礎上建立了一個兩全其美的數據庫。
3.更新和擴展方面的考慮
除了對數據庫基本結構做出重大改變，企業還可能會考慮第三種選擇：舍棄他們原有的數據庫架構，在頂層安置一個計算引擎，來跨多種數據庫(無論是關系型數據庫，還是NoSQL)查詢和組合數據。
Vassilakis 說道：“你可能想要獲取 NoSQL 數據庫中已經被廢棄的購物車數據，并且將那些數據和關系型數據庫中的關于銷售的結構化數據進行比較”。
企業同時使用兩種類型的數據庫更有意義，這樣分析師就可以專注于他們的業務分析了。它還可以防止你將需要分析的數據從一個數據庫移到另一個數據庫，轉移過程可能緩慢并且有風險。
由 Metanautix 創建的工具 Quest，可以讓分析師能夠使用熟悉的 SQL 語言查詢關系數據庫和 NoSQL 數據庫。
“考慮到你需要兩種類型的數據庫，我們想幫助那些使用數據的人，不需要關注底層的復雜性，并使用標準的邏輯模型和工具，” Vassilakis 解釋道。“我們還想讓 CIO 和 IT 部門協調系統底層而不打亂系統上層?！?/p>
雖然你的組織可能不知道哪種路徑是最好的，但重要的是，開始評估并準備應對大數據對數據庫帶來的各種巨大變化。
本文來源：伯樂在線
]]>