1.hbase京東集團級儲存
hbase的軟體，它的實現思想與google bigtable相似（也可以理解為是bigtable的開源實現），是乙個高可靠、分布式，面向列的開源資料庫。直到今天hbase經歷了十幾個年頭的發展，已經被應用在各種資料儲存場景，成為大資料處理中不可缺少的一種解決方案。
京東hbase平台作為集團級的儲存服務，從**前端到物流儲存、從訂單明細到金融分析等系統都有hbase的身影。它的穩定性和效能如果出現問題會直接影響到上層應用。可以說hbase是京東的核心服務之一。在長達幾年的迭代過程中，hbase團隊推動多次架構公升級與優化，從最初的「裸奔」到後面擁有了豐富的降級與災備手段，如：分組管理，限速&配額，跨機房智慧型災備等功能。
2.應用場景
2.1 京東的典型業務有：
金融：風控、白條、支援、資管
物流：訂單追蹤、物流倉庫、銷量**
監控：統一監控、伺服器監控、容器監控、大資料監控、大屏監控
pop是賣家在京東銷售商品，賣家每日將消費者訂單打包送京東分揀中心，京東完成購物訂單配送和收款，賣家開發票給消費者。
sop是賣家在京東銷售商品，賣家每日將消費者訂單打包並自行或採用快遞完成購物訂單配送，賣家開發票給消費者（賣家可在眾多快遞中，選擇京東快遞做貨到付款業務並享受專業的配送服務體驗）
2.2 通過抽象與歸納hbase在京東的主要應用方向圍繞在以下三個場景：
（1）超大規模毫秒級讀場景
hbase需對上層終端使用者提供批量查詢和聚合的報表服務，，典型的如京東對千萬商家提供的智慧型分析應用，在這種場景下業務使用者的查詢很容易就會穿透快取到最底下的hbase儲存層獲取資料。
（2）離線資料t+1日批量儲存
每天晚上將會有大量的資料被加工出來，然後這些加工好的資料會被推入hbase供上層系統使用。在每天凌晨1點到5點是hbase寫入最高峰，各個系統都在這個階段進行資料入庫處理。
（3）實時資料毫秒級讀和寫
在這種生產者消費者的模式下，實時處理程式負責生產並存入hbase，再下游的應用直接使用新入庫的資料。從而要求資料入庫的時效與延遲必須達到毫秒級，同樣的查詢延遲也要求必須做到毫秒級。
2.3 hbase中京東資料規模如下：
在2023年京東hbase集群規模增長到了7000多台，儲存容量達到了90pb。（硬碟有ssd和hdd兩種規格）支撐了京東700多個業務系統。
3.平台架構
整個jd-hbase平台邏輯拆分成儲存層、核心層、中介軟體層、使用者層和乙個輔助系統。
底層部署上我們支援將hdfs和hbase分開部署，同時可以利用容器技術k8s快速擴容和建立新的hbase集群。滿足各種場景的讀寫需求。
在hbase核心部分我們通過修改原始碼讓hbase regionserver能夠依據執行的硬體型別根據預設值自適應到最佳效能狀態，支援多種硬體混合部署集群。
在中介軟體部分我們通過介面的方式提供了多個子系統和服務向外圍系統提供支援，如主備容災、資料治理服務、集群分組管理服務、許可權管控服務、配額&限速管理服務，多語言支援元件等。
在使用者層我們向終端使用者提供多種可選的資料載入方式和查詢引擎滿足不同業務場景和需求。
4.多活災備
hbase提供了主備replication的方案。此方案的原理也比較簡單，就是寫向主的資料會非同步的流向備集群。如果主集群出現問題可以讓業務切換到備集群。但需要讓每個業務自行進行切換，人工成本很高而且不具備實時性，對於低延遲的業務稍微乙個抖動都無法接受，更別說重啟應用。
4.1 智慧型主備切換
自主研發了一套基於策略的多集群切換機制。在集群拓撲上每個集群都會有備份集群，來保證跨機房的資料備份。從安全維度上我們分別做到了，集群級、namespace、表級的支援，可以針對每個級別設定不同的容災切換策略。如：手動、自動、強制等。通過這種方式我們可以隨時調整策略將部分業務分批、分級切換，如：隔離、降級、防雪崩等場景。
工作元件由客戶端、hbase policyserver、servicecenter三部分構成：
在極端情況下，如果主集群徹底癱瘓，我們可以通過強制切換的方式把所有業務快速切換到從集群。同時觸發主備資料同步校驗機制，後台會自動在主集群狀態恢復後把資料對齊。保證資料一致性。
4.2主備一致性
因為主備集群間資料以非同步的方式進行傳輸同步（雖然可以做成同步，但效能很差），假如跨機房或集群之間的網路有問題，那麼資料將積壓在主集群。很不幸如果我們在這個時間業務發生了切換那麼最新的資料在備集群將讀取不到。這也是不可接受的。現在階段我們採用了比較簡單的壓縮併發傳輸wal，然後備份集群解壓回放的機制進行解決。
5.hbase多租戶資源隔離
5.1物理資源隔離（分組管理）
（1）痛點
hbase早期的使用方式是乙個業務乙個集群，但是資源利用率低，維護成本高。雖然也可以多個業務共用乙個集群，但是會有資源競爭和故障擴散等問題，乙個業務出現異常可能會影響整個集群的可用性。
（2）方案
hbase2.0以後引入分組功能，實現了將hbase集群動態切分成多個分組，每個分組中有多台物理伺服器。可以按不同的資源配置進行分組，然後把效能要求高業務放在高配的分組中增加讀寫吞吐。
這樣既能將業務進行物理隔離防止資源競爭和故障擴散，還能在618和11.11大促時期動態調整集群資源，提公升硬體資源利用率。
5.2 限速&配額
（1）痛點
有個別業務出於某些原因占用較多的集群資源，就會導致關鍵的業務無法得到及時反饋，產生更嚴重的影響。
另一方面，假如有些異常**併發不停的讀寫乙個表，並且這個表有區域性region熱點，這種操作對集群的效能是致命的，它極有可能將regionserver的效能耗盡，造成這台regionserver的請求大面積堆積。
（2）方案
為了讓業務更合理的利用資源，我們增加了配額與限速功能（backport from 2.0）。並在這些功能基礎上增加了使用者級、表級、namspace級的異常流量訪問報警。幫助運維人員更加快速的定位問題。
6.phoneix sql& oltp
原生的hbase只提供key-value查詢和範圍掃瞄。這種方式只能通過編碼呼叫api的方式進行讀寫，很不友好。通過調研我們引入了開源的phoenix元件，這個元件支援以sql的方式查詢hbase，讓業務可以使用sql的方式快速查詢hbase獲取資料。
京東hbase平台進化與演進（吳怡燃，京東大資料平台資深研發工程師，hbase平台負責人）
大資料元件 HBASE
1 hbase是乙個非關係型分布式資料庫 nosql bigtable 參考的是谷歌 2 高可靠 採用主從架構，使用zookeeper管理 高效能 分布式並行處理 面向列 可伸縮 可新增子節點 3 採用hdfs作為檔案儲存系統 也可以採用其它的檔案儲存系統，沒整合mr計算的功能 4 hbase擅長查...
大資料儲存HBase
這兩天要寫乙個方案，某單位想建乙個中心資料庫，匯聚各業務系統資料，以及各種網上抓取的預報資料。我設想是用hbase。主要考慮點是 1 開源 2 支援海量資料 該單位的資料量增長按規劃還是很大的，大約每天20gb 關係型資料庫就不考慮了。rdbms本質上是單機系統，拿mysql來說吧，主從複製，讀寫分...
大資料 Hive與HBase
hive hive是基於hadoop的乙個資料倉儲工具，可以將結構化的資料檔案對映為一張資料庫表，並提供簡單的sql查詢功能。hbase hbase是hadoop的資料庫，乙個分布式 可擴充套件 大資料的儲存。hbase和hive在大資料架構中處在不同位置，hbase主要解決實時資料查詢問題，hiv...