摘要：
2018第九屆中國資料庫技術大會，阿里雲高階技術專家、架構師封神（曹龍）帶來題為大資料時代資料庫-雲hbase架構&生態&實踐的演講。主要內容有三個方面：首先介紹了業務挑戰帶來的架構演進，其次分析了apsaradb hbase及生態，最後分享了大資料資料庫的實際案例。
現如今大量的中小型公司並沒有大規模的資料，如果一家公司的資料量超過100t，且能通過資料產生新的價值，基本可以說是大資料公司了 。起初，乙個創業公司的基本思路就是首先架構乙個或者幾個ecs，後面加入mysql,如果有需求還可加入磁碟，該架構的基本能力包括事務、儲存、索引和計算力。隨著公司的慢慢發展，資料量在不斷地增大，其通過mysql及磁碟基本無法滿足需求，只有分布式化。 這個時候mysql變成了hbase,檢索變成了solr/es，再ecs提供的計算力變成了spark。但這也會面臨儲存量大且儲存成本高等問題。
另外乙個趨勢就是非結構化的資料越來越多，資料結構的模式不僅僅是sql，時序、時空、graph模式也越來越多，需要一些新的儲存結構或新的演算法去解決這類問題，也意味著所需要做的工程量就會相對較高。
對於資料處理大致可歸類為四個方面，分別是複雜性、靈活性、延遲《讀,寫》和分布式，其中分布式肯定是不可少的，一旦缺少分布式就無法解決大規模問題 。靈活性的意思是業務可以任意改變的；複雜性就是執行一條sql能夠訪問多少資料或者說sql是否複雜；延遲也可分為讀與寫的延遲。hadoop & spark可以解決計算複雜性和靈活性，但是解決不了延遲的問題；hbase&分布式索引、分布式資料庫可以解決靈活性與延遲的問題，但由於它沒有很多計算節點，所以解決不了計算複雜性的問題。kylin(滿足讀延遲)在計算複雜性與延遲之間找了乙個平衡點，這個平衡點就是怎樣快速出報表，但對於這個結果的輸入時間我們並不關心，對於大部分的報表類的需求就是這樣的。每個引擎都是一定的側重，沒有銀彈！
我們也不能解決所有的問題，我們只是解決其中大部分的問題。如何找到乙個在工程上能夠解決大部分問題的方案至關重要，應對辦法：
首先包含了兩個分離
對於解決成本的方案簡單介紹如下：
假設在北京有三個機房可用區a、b和c,我們會在可用區a中部署乙個熱的儲存集群，在北京整體區域部乙個冷的儲存集群，實際上有幾個可用區就可以有幾個熱集群，主要是保障延遲的；冷集群對延遲相對不敏感，可以地域單獨部署，只要交換機滿足冷集群所需的頻寬即可。這樣的好處是三個區共享乙個冷集群，就意味著可以共享庫存。
我們提供兩個版本，一是單節點版，其特點是給開發測試用或者可用性不高，資料量不大的場景。二是集群版本其特點是高至5000w qps，多達10p儲存與高可靠低延遲等。
備份分為全量備份hfile與 增量量備份hlog；恢復分為hlog轉化為hfile和bulkload載入。阿里雲集團迄今為止已經有一萬兩千多台的hbase,大部分都是主備集群的，在雲上由於客戶成本的原因，大部分不選擇主備，所以需要對資料進行備份。其難點在於備份需要引入計算資源，我們需要引入彈性的計算資源來處理備份的相關計算任務
我們在內部研究如何通fpga對compaction進行加速，這會使得集群執行比較平緩，特別是對計算資源少，儲存量大的情況下，可以通過離線的作業處理compaction。
我們有5中元件，newsql(phoenix)、時序opentsdb、時空geomesa、圖janusgraph及cube的kylin，及提供htap能力的spark。這裡簡單描述幾個，如下：
客戶還是比較喜歡用sql的,phoenix會支援sql及二級索引，在超過1t的資料量的情況下，對事務的需求就很少（所以我們並沒有支援事務）；二級索引是通過再新建一張hbase表來實現的。在命中索引的情況下，萬億級別的訪問基本在毫秒級別，但由於phoenix聚合點在乙個節點，所以不能做shuffle類似的事情，同時也就不能處理複雜的計算，所以任何說我是htap架構的，如果不能做shuffle，就基本不能做複雜的計算。
在htap-spark這部分主要介紹一下rdd api、 sql、直接訪問hfile，它們的特點如下：
tsd沒有狀態，可以動態加減節點，並按照時序資料的特點設計表結構，其內建針對浮點的高壓縮比的演算法，我們雲上專業版的hitsdb增加倒排等能力，並能夠針對時序增加插值、降精度等優化。
以下簡單介紹幾個客戶的案例，目前已經在雲上apsaradb hbase執行，資料量基本在10t以上：
這是乙個車聯網的客戶，有100萬車，每輛車每10秒上傳一次，每次1kb，這樣一年就有300t資料，六個月以上是資料低頻訪問，所以他要做分級儲存，把冷資料放到低介質上
社交會有大量的推薦，所以sla要求高達99.99，並採用雙集群保障，單集群讀寫高峰qps 可以達到1000w+，資料量在30t左右。
這是乙個金融公司，它有10000億以上的交易資料，目前用多個二級索引支援毫秒級別的查詢，資料量在100t左右
先離線建好cube再把資料同步到hbase中，實時資料通過blink對接進行更新，資料量在可達20t左右。
大資料時代 資料該如何保護？
隨著資料發掘的不斷深入和在各行業應用的不斷推進，大資料安全的 脆弱性 逐漸凸顯，國內外資料洩露事件頻發，使用者隱私受到極大挑戰。而且在大資料環境下隱私洩露的危險，不僅僅在於洩露本身，還在於基於資料對下一步行動的 和判斷，因此大資料時代的隱私保護儼然成為大資料應用發展的一項重要課題。目前隱私資料洩露的...
大資料時代 雲架構
關於大資料的資訊鋪天蓋地而來，讓大家看得眼花繚亂。雖然資訊很精彩，我們也看到了大資料背後的價值，但普遍不知道如何下手。yonghong認為，在乙個企業中，超出現有計算機系統處理能力的資料，就是大資料。作為領軍企業，應本著務實的態度，利用較低的成本，通過對大資料進行高速捕獲和實時的分析，以獲取核心業務...
大資料時代，資料資訊的無處遁形
作者 小天 資料探勘，英文名叫data mining，一般是指從大型資料庫中將隱藏的 資訊抽取出來的過程，而更為精確的解釋則是 從資料中挖掘知識 這個概念乍眼一看有點懵，小天舉個栗子解釋，相信就比較容易理解 假如某東需要 使用者在未來5天內的購買需求，以達到精準營銷的目的，那麼此時完全可以借助資料探...