背景
舜飛的各個業(yè)務(wù)線對接全網(wǎng)的各大媒體及APP，從而產(chǎn)生大量數(shù)據(jù)，實時分析這些數(shù)據(jù)不僅僅用于監(jiān)控業(yè)務(wù)的發(fā)展，還會影響產(chǎn)品的服務(wù)質(zhì)量，直接創(chuàng)造價值。比如優(yōu)化師要時刻關(guān)注活動的投放質(zhì)量，競價算法會根據(jù)投放數(shù)據(jù)實時調(diào)整策略，網(wǎng)站主會進行流量分析和快速事故反饋等等。
這些分析需求的特點：
超大量- 數(shù)據(jù)流達到1m/s，一天入庫幾百億條消息。
準(zhǔn)實時- 全部數(shù)據(jù)要實時處理、入庫、分析、展現(xiàn)，從產(chǎn)生到體現(xiàn)在分析結(jié)果里延時幾秒以內(nèi)。傳統(tǒng)的批處理根本無法滿足需求。
全量、準(zhǔn)確、可靠- 不能采用抽樣、近似計算等方式，數(shù)據(jù)就是流動的金錢，可靠性要求非常高。
多維分析、Ad-hoc查詢- 大部分的查詢結(jié)果是基于一個或多個維度組合的匯總，并且要求短時間內(nèi)響應(yīng)，最好全面支持SQL和UDF。
先來看看目前有哪些解決方案：
MySQL，PostgreSQL等關(guān)系型數(shù)據(jù)庫，它們一般都有非常完整的功能支持，但無法支持超大量數(shù)據(jù)，統(tǒng)計分析的性能也不好，一般作為T+1架構(gòu)的實時庫。
Hbase，或者Redis等K-V數(shù)據(jù)庫，上層一般有一個SQL查詢層，比如Phoenix，上游由Spark、Storm等流式框架預(yù)聚合數(shù)據(jù)。這類架構(gòu)限制非常多，很難支持復(fù)雜及頻繁修改的業(yè)務(wù)。Kylin也屬于這一類，離線預(yù)聚合。
Infobright，Greenplum，MemSQL等各有特點的數(shù)據(jù)庫，有開源社區(qū)版本。在一定條件、數(shù)據(jù)量下能滿足特定需求，但是缺點較多，有些不支持更新，或者運維困難，數(shù)據(jù)量支持小等。
Hana, Vertica，以及云服務(wù)等收費數(shù)據(jù)庫。我們沒有選擇這個方向，認為把分析系統(tǒng)構(gòu)建在這類第三方封閉系統(tǒng)上，與目前現(xiàn)有數(shù)據(jù)工具的整合相對困難，擔(dān)心對后續(xù)擴展、遷移的影響。
最近幾年較火的所謂時間序列數(shù)據(jù)庫，代表為Druid，Pinot，Influxdb等。筆者曾經(jīng)比較深入的研究過，甚至在項目中有過部署，但最終認為都不適合。有些項目并不成熟，或者對硬件要求極高，缺少彈性，有些架構(gòu)上有比較大的問題，實際應(yīng)用時表現(xiàn)的非常不穩(wěn)定。
其他開源分析工具，如Impala，Drill，或者SparkSQL。它們一般專注于計算層，缺少一個合適的數(shù)據(jù)格式，并且它們通常是分析靜態(tài)文件的，沒法做到分析實時數(shù)據(jù)。目前的Parquet，ORC等數(shù)據(jù)格式通常有不錯的掃描、壓縮性能，但缺少有效的索引和必要的靈活性。
既然現(xiàn)有方案都不能解決問題，我們最終決定自己做一個合適的數(shù)據(jù)庫系統(tǒng)，叫做 IndexR 。并在一年之后，成功部署于生產(chǎn)環(huán)境。
IndexR簡介
IndexR是一個基于HDFS的分布式關(guān)系型列式數(shù)據(jù)庫，擅長海量歷史、實時數(shù)據(jù)的快速統(tǒng)計分析。
快速統(tǒng)計分析查詢- IndexR使用列式存儲，對于超大量數(shù)據(jù)集，它提供高效的索引，通過過濾掉無關(guān)數(shù)據(jù)，快速定位有效數(shù)據(jù)，減少IO。它使用了優(yōu)秀的Apach Drill作為上層查詢引擎。特別適合于ad-hoc的OLAP查詢。
數(shù)據(jù)實時導(dǎo)入- IndexR支持超高速實時導(dǎo)入數(shù)據(jù)。數(shù)據(jù)一到達IndexR節(jié)點，立刻可以被查詢到。實時數(shù)據(jù)和歷史數(shù)據(jù)可以一起查，再也不需要考慮所謂T+1架構(gòu)。且區(qū)分于其他有類似功能的系統(tǒng)，IndexR永遠不會主動丟棄任何數(shù)據(jù)。
高效硬件利用率- 相較于其他系統(tǒng)，IndexR可以跑在廉價的機器上。不需要昂貴的SSD硬盤，高端CPU，甚至小型機，你就可以獲得非常好的性能，雖然在上面跑會更加快。雖然跑在JVM上，它手動管理幾乎所有的內(nèi)存，使用經(jīng)過高度設(shè)計、緊湊的數(shù)據(jù)結(jié)構(gòu)。
集群高可用，易擴展，易管理，簡單- 分布式系統(tǒng)發(fā)展到現(xiàn)在，高可用和擴展性已經(jīng)是標(biāo)配了。IndexR的特點是結(jié)構(gòu)非常簡單可靠，且只有極少的必須配置項。
與Hadoop生態(tài)的深度整合- IndexR把數(shù)據(jù)存放于HDFS。這意味著你可以使用MapReduce，或者任何Hadoop工具處理這些文件。我們目前提供了Hive插件，用于各種ETL相關(guān)工作，或者跑離線任務(wù)。對接Spark的工作正在進行，將被使用于數(shù)據(jù)挖掘以及機器學(xué)習(xí)。
高度壓縮的數(shù)據(jù)格式- IndexR以列式存儲，并提供超高的壓縮率，可以顯著的減少IO以及網(wǎng)絡(luò)開銷。
方便的數(shù)據(jù)管理- IndexR可以方便的導(dǎo)入、刪除數(shù)據(jù)，并且支持修改表Schema，如對列的添加、刪除、修改等。