一文覽盡HBaseCon Asia 2018大會精華內(nèi)容

文末部分給出了8月18號圓桌會議討論的幾點(diǎn)關(guān)鍵信息。

大會演講議題與演講者信息，請參考下圖中的會議議程。文中內(nèi)容聚焦于技術(shù)本身，將不再單獨(dú)列出每一個議題的演講者信息：

CCSMap的原理，在阿里已經(jīng)公開的一篇文章中詳細(xì)公開過了。我們知道，MemStore的核心數(shù)據(jù)，存放在一個ConcurrentSkipListMap中(通常縮寫為CSLM)，但這個結(jié)構(gòu)包含大量的冗余對象，也導(dǎo)致冗余的內(nèi)存占用，對于Heap區(qū)的GC壓力極大，因此，CCSMap的核心設(shè)計(jì)包括：自管理內(nèi)存，采用內(nèi)存分頁的技術(shù)，顯著改善內(nèi)存碎片問題；采用無鎖技術(shù)；去掉海量結(jié)構(gòu)化JVM對象，減少冗余內(nèi)存占用，從源頭上有效控制GC問題。CCSMap再結(jié)合定制的JDK/GC算法，YGC/CMS的GC時間與發(fā)生頻率均有了顯著降低，而長達(dá)數(shù)十秒的Full GC問題已被基本消除。

第二部分內(nèi)容，與SLA改進(jìn)相關(guān)，包括：分離Client與Server端的ZooKeeper，分離Client與Server端的Meta訪問請求隊(duì)列，來有效避免Client過多的連接/訪問而影響RegionServer正常服務(wù)；盡可能減少RegionServer Abort；加強(qiáng)RegionServer的健康自檢能力；對于寬行(包含多列數(shù)據(jù)的行)數(shù)據(jù)的寫入加以限制，否則對Handler的過長占用會影響整體的吞吐量等等。

隨著3D XPoint的不斷普及，現(xiàn)有的軟件棧也將會發(fā)生較大的變化，這已經(jīng)進(jìn)入了一個硬件倒逼軟件演進(jìn)的時代。LSM-Tree的架構(gòu)可以說是基于Disk的IO模型設(shè)計(jì)的，3D XPoint硬件技術(shù)的接入，可以說會顛覆現(xiàn)有的LSM-Tree架構(gòu)，這個演講的內(nèi)容就介紹了HBase基于AEP之上所做的一些工作。

我之前曾經(jīng)寫過一篇文章《從HBase中移除WAL? 3D XPoint技術(shù)帶來的變革》，里面有更加詳細(xì)的闡述，這里不再過多展開。

HBase在小米的應(yīng)用現(xiàn)狀：

數(shù)十個HBase集群，以在線集群為主，大部分集群被部署在公有云環(huán)境中。

數(shù)據(jù)可靠性方面，結(jié)合采用了容災(zāi)+備份能力，而且支持基于WAL的增量備份能力。

多租戶實(shí)踐：為HBase設(shè)置獨(dú)立的HDFS集群；為重要的業(yè)務(wù)設(shè)置獨(dú)占的HBase集群。

RPC消息流控機(jī)制：支持RCU與WCU的設(shè)置，同時考慮了請求的數(shù)據(jù)大小與請求數(shù)量。支持Hard Limit與Soft Limit兩種模式，在Soft模式下，如果RegionServer的總體Quota沒有超出，允許個別用戶的請求超出Quota限制。關(guān)于流控，依然是DynamoDB的設(shè)計(jì)最為經(jīng)典，但這兩種情形有所不同，DynamoDB并不允許任意的超出Quota限制，它的機(jī)制是用戶如果在上一個時間窗內(nèi)的Quota有余留，可以補(bǔ)償給下一個時間窗用來應(yīng)對一些陡增的流量需求，也就是DynamoDB的Burst能力。

Synchronous Replication：?核心設(shè)計(jì)思想為，寫Master Cluster WAL時，同時將這部分?jǐn)?shù)據(jù)寫到一個Standby Cluster的RemoteWAL中，現(xiàn)有的異步復(fù)制流程依然存在，數(shù)據(jù)復(fù)制過去后，將Standby Cluster中對應(yīng)的RemoteWAL刪除。如果Master Cluster集群故障，可能有部分?jǐn)?shù)據(jù)沒有通過異步復(fù)制流程復(fù)制過去，這部分?jǐn)?shù)據(jù)在Standby Cluster中可以通過Replay RemoteWAL來回滾這部分?jǐn)?shù)據(jù)。但這里的復(fù)雜之處在于如何應(yīng)對各種故障場景。

滴滴內(nèi)部關(guān)于HBase的應(yīng)用類型，可以說非常豐富，包含了Phoenix，GeoMesa等等。

Replication方面，能夠支持RS Group級別的數(shù)據(jù)復(fù)制；安全方面，結(jié)合現(xiàn)有的ACL框架，融入了用戶管理能力，直接將用戶信息存儲在一個名為userinfo的系統(tǒng)表中。

滴滴在歷史訂單查詢上，使用了Phoenix。在Phoenix的實(shí)踐上，有幾點(diǎn)關(guān)鍵分享：使用Covered Index，將一些關(guān)鍵數(shù)據(jù)存儲在Index Table中，這樣可以加速關(guān)鍵路徑的查詢；跨Coprocessor共享Connection，減輕對ZooKeeper的壓力；采用Reverse RowKey + Pre-Split的設(shè)計(jì)避免數(shù)據(jù)熱點(diǎn)。

GeoMesa部分，主要應(yīng)用于Road Detection與Trajectory場景中。最后一部分是關(guān)于監(jiān)控與運(yùn)維方面的經(jīng)驗(yàn)分享，涉及一些具體的監(jiān)控指標(biāo)項(xiàng)建議，這里不展開過于細(xì)節(jié)的內(nèi)容。

HBase實(shí)踐部分：

1. HMaster啟動時間優(yōu)化：HMaster啟動較慢的原因包括：加載Region的Data Locality信息非常耗時；因Namespace信息初始化失敗導(dǎo)致Abort；TableInfo信息加載耗時過長。該問題在一個大集群中尤為明顯。基于這幾點(diǎn)原因做了針對性優(yōu)化以后使得啟動時間縮短至原來的1/3左右。

2. Replication增強(qiáng)：超時時間可自適應(yīng)/自調(diào)整；支持Kerberos跨域互信；

3. Region Assignment可靠性增強(qiáng)，應(yīng)對多種RIT場景以及Region雙重部署問題。

4. MOB數(shù)據(jù)丟失案例分享：因Compaction時設(shè)置了Ignore MVCC，Compaction后的HFile中的Sequence ID被置為0，導(dǎo)致大量的數(shù)據(jù)行中的MOB File指針信息失效，讀取時遇到FileNotFound Error。最后只能通過臨時開發(fā)的工具來重建 MOB File的索引信息。

OpenTSDB實(shí)踐部分：

先簡單普及了OpenTSDB的基礎(chǔ)概念以及基礎(chǔ)流程，而后重點(diǎn)介紹了針對OpenTSDB的優(yōu)化：

1. OpenTSDB Compaction下移：原來的OpenTSDB Compaction流程需要將數(shù)據(jù)從服務(wù)端讀取到Client側(cè)的TSD進(jìn)程中，將一個時間線的過去一小時的數(shù)據(jù)合并后再覆蓋原來的一行數(shù)據(jù)，這過程涉及嚴(yán)重的寫放大問題。新的流程是在HBase Compaction執(zhí)行的時候同步執(zhí)行OpenTSDB Compaction，使得OpenTSDB寫吞吐有數(shù)倍提升。

2. 線程模型優(yōu)化：將原來的兩層線程模型修改為三層線程模型，使得查詢并發(fā)度有3倍以上的提升。

3. 支持Metric級別的數(shù)據(jù)生命周期管理。

HBase在Pinterest的應(yīng)用現(xiàn)狀：

2013年開始在在線應(yīng)用中使用HBase。

近50個HBase集群，采用1.2版本。

內(nèi)部版本中包含的關(guān)鍵特性包括ZSTD, CCSMAP, Bucket Cache等等。

第一部分內(nèi)容，主要是雙活/容災(zāi)方面的實(shí)踐，值得關(guān)注的一個能力為：為多個Source Cluster設(shè)置了一個共享的Replication Proxy，所有的數(shù)據(jù)都匯聚在這個Proxy中，數(shù)據(jù)本身帶有Annotation信息用來標(biāo)注數(shù)據(jù)的目標(biāo)地址，這個Proxy的數(shù)據(jù)都發(fā)布到Kafka中，Annotation信息會被寫到WAL中但在MemStore中會被移除。Pinterest使用HBase存儲了一些關(guān)鍵的業(yè)務(wù)數(shù)據(jù)，因此，對高可用性的要求很高。日常備份數(shù)據(jù)存放在S3中，具體的備份方式按Snapshot + WAL備份結(jié)合，備份數(shù)據(jù)可被應(yīng)用在離線數(shù)據(jù)分析中。HBase本身不支持直接將數(shù)據(jù)導(dǎo)出到S3中，只能通過HDFS周轉(zhuǎn)，所以 Pinterest內(nèi)部開發(fā)了將HBase數(shù)據(jù)直接備份到S3中的方案，HFile在上傳到S3之前被預(yù)先切塊。在備份HFile時，可能涉及到大量的重復(fù)文件，如第一天的備份中包含了HFile1，在第二天的備份中也同樣包含了HFile1，因此，在Pinterest的方案中，實(shí)現(xiàn)了HFile去重能力。

基于Compaction機(jī)制實(shí)現(xiàn)的冷熱數(shù)據(jù)分級存儲方案，來降低冷數(shù)據(jù)的存儲成本，提升熱數(shù)據(jù)的查詢性能。該方案在具體實(shí)現(xiàn)上參考了DateTieredCompaction機(jī)制，但在窗口劃分上有所變化。數(shù)據(jù)RowKey中帶有數(shù)據(jù)的業(yè)務(wù)時間戳信息，Compaction執(zhí)行時，參考該業(yè)務(wù)時間戳區(qū)分Hot/Warm/Cold數(shù)據(jù)，而后將不同熱度的數(shù)據(jù)寫到不同的HFile中，不同熱度的HFile文件還可以選擇不同的壓縮編碼/存儲策略。在查詢上，盡量在查詢之初根據(jù)業(yè)務(wù)時間戳將冷數(shù)據(jù)HFile過濾掉，結(jié)合(Prefix) Bloom Filter以及Lazy Seek特性，來對一些具體的查詢場景進(jìn)行優(yōu)化。

值得一提的是，在HBaseCon Asia 2017烽火的演講中，也曾介紹過一個簡潔的基于Compaction的分級存儲方案。

介紹了HBase在使用HDFS時的幾點(diǎn)優(yōu)化，包含Short Circuit Read的幾點(diǎn)細(xì)節(jié)優(yōu)化（Domain Socket連接重用加速Slot Releaser；Preallocate Shm等），HDFS配置優(yōu)化(增大Backlog，Peer Cache Bucket Adjustment，降低超時等待時間從而可以快速響應(yīng))，提前發(fā)現(xiàn)Dead Datanode能力。

Hadoop/HBase的現(xiàn)有安全機(jī)制都是基于Kerberos實(shí)現(xiàn)的，而Kerberos無法與企業(yè)自身的身份認(rèn)證系統(tǒng)進(jìn)行集成，例如在公有云服務(wù)中，每家公有云廠商都有自己的身份認(rèn)證服務(wù)，該服務(wù)就無法與Kerberos進(jìn)行對接。Intel提出的HAS的方案，允許企業(yè)的第三方認(rèn)證服務(wù)以插件化的形式接入，具體思路為：用戶提交認(rèn)證請求后，可以通過定制的插件連接企業(yè)的用戶身份系統(tǒng)進(jìn)行用戶合法性校驗(yàn)，校驗(yàn)成功后為用戶返回一個Kerberos TGT，用戶基于TGT可正常訪問現(xiàn)有的Hadoop系統(tǒng)。

該方案可以說是在不改動現(xiàn)有Hadoop安全框架的基礎(chǔ)上，提出的一種”曲線救國”的策略，但Hadoop的現(xiàn)有安全框架仍然需要進(jìn)一步演進(jìn)。

大家可能都已經(jīng)比較了解Kylin，它是一個基于Cube的ms級OLAP分析引擎，Kylin選擇了基于HBase作為它的后端存儲系統(tǒng)，這個演講主要介紹了Kylin選擇HBase作為后端存儲系統(tǒng)的初衷，以及基于HBase的表設(shè)計(jì)細(xì)節(jié)。

AntsDB中提供了基于MySQL Driver來訪問HBase數(shù)據(jù)的方案，這很容易被拿來與TiDB對比，但兩者的定位有顯著不同：TiDB是一個完整的數(shù)據(jù)庫產(chǎn)品，早期版本基于HBase，但現(xiàn)在已經(jīng)基于自己實(shí)現(xiàn)的分布式LSM-Tree引擎，而AntsDB則緊抱HBase的大腿，充分利用HBase能力來提供MySQL的兼容性。AntsDB充分利用了Caching能力來加速查詢，將分布式事務(wù)轉(zhuǎn)換為本地事務(wù)，將Distributed Joins轉(zhuǎn)換為Local Joins。AntsDB針對HBase的GC問題，也做了不少工作：大量使用Unsafe來改進(jìn)Skip List, Cache, WAL以及Row Locking，盡量使用小于4G的Heap等等，改進(jìn)后的性能數(shù)據(jù)：Scan 100萬行/線程/秒，Insert 20萬行/線程/秒。AntsDB的寫入性能約為MySQL的9.3倍。

Phoenix為HBase提供了SQL能力，但它所擅長的，其實(shí)只是一些簡單的OLTP類型的查詢，但疲于應(yīng)對復(fù)雜的分析型查詢?nèi)蝿?wù)，而復(fù)雜查詢恰恰是SparkSQL擅長的。這個演講的內(nèi)容，就是基于Phoenix與SparkSQL來提供的一套統(tǒng)一的在線SQL分析引擎解決方案，這個架構(gòu)可以說是一個典型的Lambda架構(gòu)：Batch Layer基于Spark SQL實(shí)現(xiàn)，Serving Layer依賴于HBase/Phoenix來提供低時延查詢能力，Speed Layer則基于Kafka/Spark Streaming。

關(guān)于Phoenix的最佳實(shí)踐建議，包括：建表時配置UPDATE_CACHE_FREQUENCY；推薦使用Pre-splitting Keys而不是Salted Table，不要將SALT_BUCKETS誤認(rèn)為Pre-Splitting Regions；為Index Table指定Pre-Splitting信息；大表關(guān)聯(lián)查詢時要采用USE_SORT_MERGE_JOIN等等，另外，設(shè)計(jì)組合RowKey時要充分考慮查詢條件字段信息，大表中應(yīng)該使用Global Index，應(yīng)控制索引的數(shù)量避免對寫入吞吐量帶來較大的影響。

SparkSQL On HBase部分，可以直接讀取HFile文件，其它優(yōu)化手段則是比較常見的Partition Pruning, Column Pruning, Predicate Pushdown等。

圖數(shù)據(jù)庫技術(shù)目前已經(jīng)越來越火熱，JanusGraph是一個分布式圖數(shù)據(jù)庫技術(shù)，后端可以支持多種存儲系統(tǒng)，這個演講介紹了JanusGraph on HBase的設(shè)計(jì)細(xì)節(jié)。

在公眾號“NoSQL漫談”中，我們也曾寫過兩篇文章，詳細(xì)剖析了JanusGraph的Property Graph在HBase表中的設(shè)計(jì)細(xì)節(jié)，以及關(guān)于JanusGraph/Titan的待改進(jìn)點(diǎn)，供參考：

圖解JanusGraph內(nèi)部數(shù)據(jù)存儲結(jié)構(gòu)

從擴(kuò)線查詢能力分析分布式圖數(shù)據(jù)庫Titan的設(shè)計(jì)改進(jìn)點(diǎn)

這個演講圍繞零售分析案例展開, 介紹了他們的數(shù)據(jù)湖處理平臺。零售分析業(yè)務(wù)定義如下：

Explain the who, what, when, where, why and how they are doing Retailing.

典型的業(yè)務(wù)場景舉例：

1. 在合適的地點(diǎn)與合適的時間進(jìn)行合適的推銷

2. 一個消費(fèi)者在這個商店中購買了什么樣的香煙？從而基于該信息為未來的購買進(jìn)行預(yù)測

3. 消費(fèi)者的購買模式是什么，有哪些商品通常會一起購買

4. 商品的時序特點(diǎn)，按年/月/周/日區(qū)分不同的商品應(yīng)該適合在什么樣的商店銷售

零售分析案例的業(yè)務(wù)挑戰(zhàn)有：

數(shù)據(jù)按周更新，每周有46億條事件數(shù)據(jù)。

歷史數(shù)據(jù)處理：一次Bulkload共導(dǎo)入約30TB/近170億條事務(wù)記錄。

關(guān)聯(lián)查詢約涉及170億條事務(wù)記錄，而且數(shù)據(jù)帶有偏態(tài)分布特征。

有數(shù)據(jù)去重的需求。

在這個數(shù)據(jù)庫處理平臺中，以HBase(0.98.12)作為主存儲系統(tǒng)，結(jié)合了Kafka、Spark Streaming、Elasticsearch、Spark、Presto、Hive等技術(shù)。最后還介紹了Spark HBase Connector，專門為Spark訪問HBase定義了強(qiáng)大的DSL語法。

一個獨(dú)立于HBase進(jìn)程之外部署的實(shí)時冷數(shù)據(jù)備份方案，全量備份基于HFile的Copy，而增量備份則基于HLog。

基于HFile的復(fù)制，一個最基本的問題就是HFile時常發(fā)生變化，如Compaction，Region Split等等，解決這個問題的思路為：當(dāng)要復(fù)制的HFile不存在時，則刷新列表然后進(jìn)行重試（如果復(fù)制了一半，是否意味著要全部重做？為何不嘗試去歸檔路徑中尋找不存在的HFile文件？）。增量數(shù)據(jù)基于HLog進(jìn)行，在一個外部的Log Tracker中跟蹤所有新產(chǎn)生的日志（HLog老化被刪除如何應(yīng)對？），新產(chǎn)生的HLog全部記錄在ZooKeeper中，然后由多個Worker進(jìn)程執(zhí)行HLog復(fù)制操作。

Serving Billions of Queries In Millisecond Latency

來自Bloomberg的Niju Nair為大家分享了關(guān)于HBase的理解，主要是一些的基礎(chǔ)內(nèi)容，涉及HBase數(shù)據(jù)模型介紹，數(shù)據(jù)分片與數(shù)據(jù)排序，Table/Versioning/ACIDity，Cache，Compaction，Short Circuit Read，GC，Region Replica，Monitoring等等。

值得關(guān)注的地方在于，演講中提供了一些有價值的參考數(shù)據(jù)：不同的HFile Block Size的讀取時延的差異(16KB Block Vs 64 KB Block)以及Bloom Filter數(shù)據(jù)與Index數(shù)據(jù)所占用的大小信息；61GB Cache與93 GB Cache在查詢時延上帶來的差異；啟用Region Replica時，將Primary Call設(shè)置不同的超時時間對Stale Calls數(shù)量的影響等等，限于篇幅這里不貼出具體的圖片內(nèi)容，感興趣的同學(xué)可以查看本文附件中的內(nèi)容。

HBase在中國電信的應(yīng)用現(xiàn)狀：

HDFS集群擁有322臺物理機(jī)，32 Cores, 256GB Memory, 3.6 T * 12 Disk。

共有6個HBase集群來應(yīng)對不同的應(yīng)用類型，包含在線應(yīng)用，Kylin，Streaming任務(wù)的持久化等等。

共有520TB數(shù)據(jù)，每天的增量數(shù)據(jù)為1TB。

HBase版本為1.2.0。

演講中介紹了數(shù)據(jù)采集系統(tǒng)到核心系統(tǒng)的架構(gòu)方案，涉及Kafka，Spark Streaming，HBase，Hive等組件，而后圍繞DPI Data Service以及基于位置的數(shù)據(jù)服務(wù)介紹了基于HBase的在線讀寫應(yīng)用。基礎(chǔ)Metrics監(jiān)控信息，基于Ganglia來提供，告警則基于Zabbix。在HBase優(yōu)化方面，從CMS算法切換到了G1，并且采用了讀寫分離策略，這里的方案未見具體的細(xì)節(jié)。

HBase在中國人壽的應(yīng)用現(xiàn)狀：

3 Clusters，200+ Nodes。

HBase數(shù)量總量在300TB+；最大的表的數(shù)據(jù)量為30TB+，共有2500個Region。

數(shù)據(jù)處理：每天有數(shù)百個MR/Hive/Spark任務(wù)，每天的增量數(shù)據(jù)有50TB+。

每天共有數(shù)千萬查詢請求。

演講重點(diǎn)涉及三部分內(nèi)容：應(yīng)用場景介紹；HBase應(yīng)用優(yōu)化實(shí)踐；遇到的幾個典型問題。重點(diǎn)提一下人壽在應(yīng)用場景：采用寬表設(shè)計(jì)，在一行數(shù)據(jù)中盡可能存放所有信息；數(shù)據(jù)從RDBMS導(dǎo)入HBase的方式為：RDMBS -> TextFile -> HFile -> BulkLoad；數(shù)據(jù)處理階段，構(gòu)建索引信息；構(gòu)建了一個以Entity為中心的統(tǒng)一查詢服務(wù)，提供類SQL查詢接口；存放與HBase中的數(shù)據(jù)導(dǎo)出到Hive中以供批量查詢與分析。

貝殼使用HBase主要是因?yàn)樵跇I(yè)務(wù)中廣泛使用了Kylin。Kylin的應(yīng)用現(xiàn)狀：

800+ Cube、16+業(yè)務(wù)應(yīng)用

數(shù)據(jù)總量為200TB，1600億條數(shù)據(jù)，每一個Cube中關(guān)聯(lián)60億數(shù)據(jù)

查詢請求100萬次每天，95%的查詢請求時延在500ms以下，99%的查詢時延小于1秒

使用HBase時所用到的優(yōu)化舉措包括：利用HDFS Short-circuit Read；Data Hedged Read；利用MultiWAL提升寫入吞吐量。

在美團(tuán)的分享中，共涉及三個方面：

1.?多租戶實(shí)踐：利用RS Group/DN Group特性來支持異構(gòu)集群環(huán)境，不同的RS Group/DN Group可能涉及不同的資源配置類型。Replication能夠支持按RS Group級別進(jìn)行同步，同樣的實(shí)踐在前面滴滴的分享中也提到了。

2.?對象存儲：涉及HBase MOB特性的應(yīng)用。

3.?大查詢隔離：大查詢可能會過長時間占用Handler線程資源，如果與Get/Small Scan使用相同的Queue/Handlers，這將會導(dǎo)致所有的Handlers變的擁堵，因此，為大查詢設(shè)置了獨(dú)立的Queue/Handler來有效解決該問題。

在新能源汽車監(jiān)控系統(tǒng)中選型HBase的初衷以及所遇到的挑戰(zhàn)。

選擇HBase的初衷為：高寫入性能；低查詢時延；易橫向擴(kuò)展；基于Phoenix能提供SQL訪問接口等。

使用HBase所遇到的挑戰(zhàn)/痛點(diǎn)：RowKey設(shè)計(jì)門檻過高；HBase自身不支持二級索引，只能依賴于Phoenix；表設(shè)計(jì)需要認(rèn)真理解業(yè)務(wù)需求；復(fù)雜查詢很慢，即使Phoenix提供了SQL與索引能力，查詢在未命中任何索引是時延過高。

圓桌會議討論

1. 會議開始，Stack主動征詢大家關(guān)于版本可靠性/性能測試的方法。

2. 將基于JIRA的work-flow遷移到Github的可能性，因?yàn)榱?xí)慣使用Github的用戶更多。

3. 關(guān)于HBase易用性提升的幾點(diǎn)建議，可以允許用戶基于WebUI進(jìn)行建表，查詢等基本操作。

4. 3.0版本關(guān)鍵特性的幾點(diǎn)暢想：

1) Native SQL的支持。這次大會中，可以說聽到了諸多關(guān)于Phoenix的吐槽，所以希望HBase能提供一些簡單的SQL查詢能力。

2) Secondary Index的支持。

個人觀點(diǎn)：HBase的SQL與Secondary Index的確已經(jīng)是越來越普遍的需求，但是否應(yīng)該將這些內(nèi)容在HBase Kernel中，卻是值得商榷的。HBase Kernel部分本應(yīng)該保持它的精簡性，Kernel就應(yīng)該聚焦于提供簡單的基于KeyValue模型的接口即可，但現(xiàn)在已經(jīng)變得越來越”臃腫”。個人更希望將Secondary Index與SQL放在一個外部項(xiàng)目中實(shí)現(xiàn)，如果可以基于Phoenix改進(jìn)自然最好，但復(fù)雜度太高。

hbase

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。