本文將介紹 OceanBase 在紅象雲騰大資料場景下的落地實踐與思考，希望幫助正在探索 OceanBase 的企業使用者快速實現 OceanBase 選型與落地。
紅象雲騰 (REDOOP) 公司董事長兼 CTO，中國首位 Cloudera CCDH 認證工程師，曾任 China Hadoop Summit 聯合主席。
紅象雲騰是一家專注於 Apache Hadoop 生態的大資料軟體廠商，主要產品是紅象雲騰大資料基礎平臺(Redoop Enterprise V9.0)，產品由 CRF 資料接入，CRH 資料儲存，CRS 資料分析三大部分構成。紅象的核心產品是圍繞以 Hadoop 為核心，打造一系列的解決方案，服務中國客戶。Hadoop 是 Apache 基金會下面沒有提供商業支援和服務的軟體，紅象基於此提供面向使用者的商業解決方案。Hadoop 分散式是紅象的起點，也是我們的事業，一直以來我們都在做大資料 Hadoop 推廣和普及工作。在這方面，Hadoop 和 OceanBase 有很多可以互相補充的地方，我們也發現在大資料 Hadoop 生態裡，缺少一個能支援分散式事務，支援跨兩地多中心的解決方案。
一、為什麼選擇 OceanBase？
我們參與到 OceanBase 社群裡面，是抱著積極參與，勇於嘗試的態度，因為我們是最早吃 Hadoop 螃蟹的一批人。Hadoop 剛誕生的時候，架構非常簡單，使用起來不方便。但是在 Hadoop 處於零點幾的版本時，因業務及資料規模的需要，我們就開始去嘗試使用。這次 OceanBase 開源之後，我覺得是驚豔四座，如果用四個字總結，就是“簡潔又美”。我個人覺得技術人員是有立場的。什麼叫立場？我們的時間是寶貴的，我們得把寶貴的時間用在真正優秀的作品上面。
“OceanBase 作為一個分散式資料庫，在架構上卻展現出了簡潔美，這讓我們看到了新的機會。”
—— 紅象雲騰 CTO 童小軍
我們為什麼選擇 OceanBase？有以下五個原因：
第一 身份轉變。OceanBase 是在今年6月1日開始走開源開放的路線，這讓我們有了參與感。如果不開源，首先，我們是沒有機會拿到這個版本的；其次，我們不知道怎麼參與貢獻；另外，我們貢獻的價值也不能得到社群的認可。所以說開源開放讓我們從一個旁觀者，或者說是使用者，變成一個參與者，這是很重要的身份轉變。另一方面我們可能確實拿不出特別充足的預算去支援商業版，但是我們也希望能用上 OceanBase 的技術，開源路線出來之後我們就大膽的去用了。
第二 技術選型。我們對於資料庫是有要求的，首先，Hadoop 是原生分散式，高可用的系統，天生的設計就是多副本，但是在跨資料中心這一塊比較弱。所以，我們在選擇資料庫時，不但要求具備分散式、高可用特點，而且還要線性可擴充套件，這是我們對於選型資料庫的要求，OceanBase 符合我們的需求。
第三 相容性，這是一個很關鍵的特性。OceanBase 對 MySQL 的相容性很好，我們很多應用程式可以直接移植到 OceanBase 環境而不需要改太多程式碼。我們有一個應用程式遷移到 OceanBase 環境之後一行程式碼都沒有修改，直接遷移使用，所以高相容性是我們選擇 OceanBase 的一個關鍵點。
第四 技術支援。雖然在阿里、螞蟻內部 OceanBase 方案已經非常成熟，但是對於我們來說 OceanBase 是一個新產品，因此在選型和測試時會擔心遇到業務不能正常訪問或者出現異常等我們無法搞定的技術問題，對我們的客戶不好交代。在我們使用 OceanBase 過程中，OceanBase 社群團隊對我們的支援力度很大，遇到問題時，我們技術同學把情況反饋到使用者群裡，社群技術團隊能夠及時的響應和解答，使我們能放心使用。
選擇 OceanBase 還有一個最關鍵的點：
部署方便、簡潔易用。
一開始看到 OceanBase 的時候，發現它只有一個主要元件 OBServer，當然周邊元件也是有的，但是核心只有一個元件。而 Hadoop 元件實在太多了，作為一個入門使用者，要掌握一套 Hadoop 系統需要花很長時間搞明白一堆元件的功能。而 OceanBase 實現了 Hadoop 裡面的很多特性，也實現了很多 Hadoop 裡面沒有的特性，所以說簡潔就是美。
紅象主要是做分散式大資料業務場景，這個場景有兩條路線，分別是批處理路線和流處理路線。Hadoop 更擅長後端處理，做大規模資料量的處理（比如 ETL 清洗），並不是很擅長面向使用者端。當我們面向使用者端的時候，比如說報表，當應用程式連上來的時候，Hadoop 就顯得力不從心，Hadoop 更多的是面向一個大規模資料做批處理業務。
針對面向實時的場景，雖然也有解決方案（比如 HBase 等），但是這些解決方案還是偏重，因此我們需要一款輕量級的解決方案。以前我們用的是 MySQL，現在用 OceanBase 來替代 MySQL 叢集承擔業務報表。當資料運算完成後把結果存到一個結果資料庫裡面，OceanBase 承擔面向應用端來提供服務的角色。所以在一些大資料場景下，比如資料海量儲存的線上服務、ETL 清洗結果的儲存、輕量級 OLAP 分析報表以及後設資料庫服務等都可以考慮使用 OceanBase 方案來提供服務。分散式資料庫在大資料業務主要使用場景如下：
當前 Hadoop 生態依賴的一些 hive 後設資料是儲存在 MySQL 裡面，在業務量大的時候，hive metadata 也沒有特別好的儲存方案。比如客戶說我們 hive metadata 的 MySQL 也得高可用，這是客戶在我們業務線現場提的需求，怎麼辦？我們做一個 MySQL 叢集嗎？又掉進去了是吧？如果做主備的話，又不具備高可用能力。所以說在我們整個 Hadoop 技術棧裡面有很多場景，比如第一個替代 MySQL 的場景，第二個是承擔多種前端業務查詢請求的場景。
「新能源電力大資料上線 OceanBase 」
用 OceanBase 的長處補 Hadoop 的短板是紅象要努力嘗試去做的，把這兩個生態結合起來以更好的服務客戶。可以看一下紅象的 Hadoop 和 OceanBase 組合的電力行業的新能源案例：這是一個大資料平臺，包含了 Hadoop、 Hive、Druid 、Spark、Flink 等元件。
大家可能從市場上看到的發行版本都很大，我們紅象的目標是把我們的發行版做小。我個人曾經思考過：小到極致，砍到極致，能留下什麼？我們核心圍繞著 Hadoop ，把其餘的做成外掛，外圍的找合作伙伴來做。這是我想給創業者的一個建議：當你把一堆開源元件集合起來，還不如你做好一個元件，反倒更能凸顯價值，這也是我們的一個路線。把 Hadoop 做好，剩下的我們與合作伙伴一起完成商業解決方案。
在能源大資料的場景裡面有一條業務流。光伏感測器的資料會源源不斷的錄到 kafka 裡，Flink 程式去消費 kafka 的資料，消費完資料又會重新錄到 kafka 裡，然後 Apache Druid 去消費 kafka 資料，再對外提供服務，這是一條工業時序資料的處理場景。
這個過程在什麼地方用到 OceanBase？我們的點表資料傳過來的時候是 CSV 一樣的逗號分割的流，這個流的每一個欄位會變化，我們就需要一個資料庫來儲存這些變化。我們需要在 Flink 裡面拿到 matadate 欄位描述資訊，然後把表結構的資訊補充上去。因此從原始 kafka 資料到我們的 DRUID 要消費的這個資料中間是要有一個資料補齊的工作。對於指標的描述資訊就存在 OceanBase 裡面。
我們還有一些使用了各種資料庫的業務。以前，我們會把這些資料錄到 Hadoop 裡面建個 hive 表，再供業務使用，整個流程非常複雜，使用者使用起來也很累。現在，直接把資料直接錄到 OceanBase 裡面，再對外提供服務。架構非常簡單，可以很方便解決客戶問題。
以前紅象做事情喜歡做加法，把一個系統搞得好複雜，現在做事情都做減法。我們在新疆有個通訊管理局專案，專案資料有600個Hadoop 節點。首先把電信和聯通的資料載入到 kafak 裡面，再透過 Spark 進行計算，計算完之後錄到 hive 裡面，處理流程太長了。經過簡化，我們直接把資料推到 Hadoop 裡面就搞定了。有的時候做減法感覺更好，我們現在做事情做架構都是做減法。
這一套 Hadoop 叢集的部署架構上面有4個管理節點，下面是資料節點，其中 OceanBase 由6個節點構成，每個節點是36核128G ，有1個2T 的資料盤，一個日誌盤，這個是經過 OceanBase 的團隊 check 以後目前在執行的方案。
我們的叢集部署結構有3個 zone，每個 zone 有兩臺機器，總共6臺機器的基礎架構，支撐的業務由 OceanBase 加 PGSQL，還有 HDMS 這些元件共同來支撐各種業務，業務場景有資料介面、系統應用、報表視覺化等等這些應用場景。
「Hadoop + OceanBase 點亮新能源大資料 」
這個是我們現在叢集情況，目前只是個小叢集：3個 kafka，8個Hadoop 管理節點加資料節點，6個 OceanBase節點，支撐10萬個點位資料。每天有10萬個點位需要收集，新增資料0.5個 TB 左右，雖然資料量還不是很大，但是我們後面有 600個 Hadoop 節點的叢集，隨著資料量會越來越大，OceanBase 在該業務扮演的角色會越來越重要，核心功能會體現的淋漓盡致，比如彈性擴縮容，HTAP 能力等。
這個專案的投資額很大，是我們國家能源部佈局的光伏儲能的時政平臺，是一個很有意義的專案，它是代表著我們在光伏產業的新技術新產品。
從紅象雲騰的實踐中，基於使用者角度，想對 OceanBase 提出五點建議供參考。
1. JBOD （just a bunch of disks）多磁碟機代號掛載支援。
Hadoop 的機器都是 JBOD 很多盤，一臺機器可能有12個盤，每個盤4個 T 的架構。但是 OceanBase 指向的是一個盤，這個時候剩下的11塊盤怎麼辦？要是做成 raid 模式又跟我們混合部署架構不大一樣。如果可以做到 JBOD 多磁碟機代號掛載支援，那麼 Hadoop 的業務往 OceanBase 遷移更方便，同時機器資源複用更加友好。目前 OceanBase 團隊反饋內部正在評估該需求。
2. 初始檔案磁碟佔用率問題。
在部署完 OceanBase 之後，我們發現磁碟佔用率達到90%。這是因為 OceanBase 在部署完會建立一個大檔案，先把這個空間佔著方便讀寫，我也能理解這個事，當然運維理解不了。所以我們把 OceanBase 部署起來之後，我們運維工程師說“童老師，系統資料還沒寫進去，這個盤怎麼滿了。”後來我們透過從 OceanBase 內部提取一些指標資料告訴運維同學實際的磁碟使用情況，同時我們也希望初始檔案可以增量設定。目前 OceanBase 團隊反饋內部正在評估該需求。
3. 單個元件的啟動、配置管理以及監控問題。
之前我們使用 OceanBase 開源第一個版本，需要用命令列方式安裝部署環境，透過配置檔案的方式去配置，對於單個元件的啟動和關閉不是特別方便，需要對整個叢集操作。在一些場景下我們需要對某一臺機器的某個元件進行啟動和關閉，這樣可以精準的對某臺機器啟停，而不是去改配置檔案，或者更復雜的操作，能不能針對單個機器，單個元件做配置管理，其實對於管理工具是個挑戰。目前在最新的 OceanBase 社群版3.1.2版本中，OceanBase 雲平臺（OceanBase Cloud Platform，OCP）支援開源。OCP 是一款以 OceanBase 為核心的企業級資料庫管理平臺，可以輕鬆的解決以上提到的問題，同時 OCP 不僅提供對 OceanBase 叢集和租戶等元件的全生命週期管理服務，同時也對 OceanBase 相關的資源（主機、網路和軟體包等）提供管理服務，能夠更加高效地管理 OceanBase 叢集，降低企業的 IT 運維成本，對使用者來說非常友好。
4. ODBC 驅
動的支援。
我們的業務現場還有一個叫 odbc，已知 OceanBase 是支援 jdbc，不支援 odbc，但是 MySQL 可以適配 odbc，所以在實際業務場景中需要把資料寫回到 MySQL 。odbc 在工業場景有很多 windows 機器或者一些原因使用 odbc 驅動，我們希望 OceanBase 不僅要支援 jdbc，odbc 也需要考慮支援。目前 OceanBase 團隊反饋該需求已經在排期規劃中。
5. Latin1 字符集的支援。
我們想把 hive 的 metadata 遷移上去，發現該字符集不支援，目前是透過改應用來適配，如果 OceanBase 後面能支援就更好了。目前 OceanBase 團隊反饋內部正在評估該需求。
1. Hive Metadata On OceanBase。
當前我們的 Hadoop metadata 解決方案還是基於 MySQL，因此存在單點、容量受限的問題。我們計劃使用 OceanBase 替換 MySQL 方案並應用在通訊管理的管理局專案上，目前該方案還是測試階段。
2. OceanBase BackUp To NFS On HDFS。
這個問題是關於 Oceanbase 的 Backup。OceanBase 本身有備份和恢復的功能，大家也都可以使用，同時資料預設是三副本（即資料會儲存三份），透過 Paxos 協議保證資料的強一致性，天然保證業務的高可用。不過我們想的是 OceanBase 在幫我們解決問題的同時能不能也用上 Hadoop？這樣兩個產品的優勢會整合起來，形成一個非常好的解決方案。
在下面這個場景裡大家可以感受下：我們公司最大的客戶是中國航天，在 Hadoop 上儲存、管理的資料達到幾十個 PB，管理了幾十顆衛星的資料，因此我們的責任很大，不能掉以輕心的。這套系統上線之後，這十幾年來我們沒有出現過一次因為機器故障導致大規模資料丟失的問題，有時候哪怕是丟了幾個小塊，我們都可以從檔案系統把這個塊資料找回，所以 Hadoop 給了我們一個很好的備份機制，大家可以放心的把資料存在上面，而不用擔心資料丟失。因此，可以嘗試把 Hadoop 當作 OceanBase 的備份元件使用，這是我的小建議。
寫在最後
從開源中來，到開源中去，這是我給大家的一個建議。有很多同學都是用開源產品的，可能也是開源軟體的創立者，我們是開源軟體的受益者，所以我們也要為開源做出我們的貢獻。
分享一下我對開源的理解：
第一，開源是一個建立標準的過程，一流的公司是做標準的。第二，開源是一個建立連線的過程。你的軟體被大量的使用，你和各個公司建立起了連線，自然有商業機會。紅象雲騰使我們參與到 Hadoop 的開源社群裡面，去普及和推廣 Hadoop，這是我們成長起來的關鍵原因。我們希望能夠跟著 OceanBase 開源社群共同成長，為 OceanBase 開源貢獻我們的力量。
參與更多技術交流，請至 OceanBase 社群版
。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69909943/viewspace-2853173/，如需轉載，請註明出處，否則將追究法律責任。
