1. 首頁 > 生活百科 > >

挑戰海量數據：基于Apache DolphinScheduler對千億級數據應用實踐( 二 )

生活百科


需要使用Python進行DAG圖的繪制，無法做到低代碼任務調度 。
Oozie
是集成在Hadoop中的大數據任務調度框架，其對任務的編寫是需要通過xml語言進行的 。
04 選擇DolphinScheduler的理由1、部署簡單，Master、Worker各司其職，可線性擴展，不依賴于大數據集群
2、對任務及節點有直觀的監控，失敗還是成功能夠一目了然
3、任務類型支持多，DAG圖決定了可視化配置及可視化任務血緣
4、甘特圖和版本控制 ， 對于大量任務來說，非常好用
5、能夠很好滿足工作需求
大數據平臺架構

挑戰海量數據：基于Apache DolphinScheduler對千億級數據應用實踐

文章插圖
?
數據流圖
挑戰海量數據：基于Apache DolphinScheduler對千億級數據應用實踐

文章插圖
?
海量數據處理01 數據需求數據量：每天上千億條
字段數：上百個字段，String類型居多
數據流程：在數據倉庫中進行加工 ， 加工完成的數據放入CK，應用直接查詢CK的數據
存儲周期：21天~60天
查詢響應：對于部分字段需要秒級響應
02 數據同步選型
挑戰海量數據：基于Apache DolphinScheduler對千億級數據應用實踐

文章插圖
?
Sqoop
Sqoop是一款開源的工具，主要用于在Hadoop(Hive)與傳統的數據庫(mysql、postgresql…)間進行數據的傳遞 ， 在DolphinScheduler上也集成了Sqoop的任務調度 ， 但是對于從Hive到ClickHouse的需求，Sqoop是無法支持的 。
Flink
通過DS調度Flink任務進行或者直接構建一套以Flink為主的實時流計算框架，對于這個需求，不僅要搭建一套計算框架，還要加上Kafka做消息隊列 ， 除此之外有增加額外的資源開銷 。
其次需要編寫程序，這對于后面的運維團隊是不方便的 。
最后我們主要的場景是離線，單比較吞吐量的話，不如考慮使用Spark 。
Spark&SparkSQL
在不考慮環境及資源的情況下，Spark確實是最優選擇，因為我們的數據加工也是用的SparkSQL ， 那現在的情況就是對于數據同步來說有兩種方式去做 。
第一種是加工出來的數據不持久化存儲 ， 直接通過網絡IO往ClickHouse里面去寫，這一種方式對于服務器資源的開銷是最小的，但是其風險也是最大的，因為加工出來的數據不落盤，在數據同步或者是ClickHouse存儲中發現異常，就必須要進行重新加工 ， 但是下面dws、dwd的數據是14天清理一次，所以不落盤這種方式就需要再進行考慮 。
第二種方式是加工出來的數據放到Hive中，再使用SparkSQL進行同步，只是這種的話，需要耗費更多的Yarn資源量，所以在一期工程中，因為資源量的限制，我們并沒有使用SparkSQL來作為數據同步方案，但是在二期工程中 ， 得到了擴容的集群是完全足夠的，我們就將數據加工和數據同步全部更換為了SparkSQL 。
SeaTunnel
SeaTunnel是Spark和Flink上做了一層包裝，將自身的配置文件轉換為Spark和Flink的任務在Yarn上跑，實現的話也是通過各種配置文件去做 。
對于這個場景來說 ， SeaTunnel需要耗費Yarn資源 。
DataX
所以經過多方面的調研，最終選擇一期工程使用DataX來作為數據通過工具，并使用DolphinScheduler來進行周期調度 。
03 ClickHouse優化在搞定數據加工和數據同步架構之后，就需要進行ClickHouse的優化 。
寫入本地表
在整個集群中最開始是用的Nginx負載均衡寫 ， 這個過程中我們發現效果不理想，也嘗試了用分布式表寫，效果提升也不明顯 ， 后面的話我們的解決方案就是調整寫入本地表，整個集群有多臺設備 ， 分別寫到各個CK節點的本地表，然后查詢的時候就查分布式表 。
使用MergeTree表引擎家族
ClickHouse的一大核心就是MergeTree表引擎，社區也是將基于MergeTree表引擎的優化作為一個重點工作 。
我們在CK中是使用的ReplicatedMergeTree作為數據表的本地表引擎，使用的ReplicatedReplacingMergeTree作為從MySQL遷移過來的數據字典的表引擎 。
二級索引優化
第一個的優化點是二級索引的優化 ， 我們把二級索引從minmax替換到了bloom_filter，并將索引粒度更改到了32768 。
在二級索引方面的話我們嘗試過minmax、intHash64、halfMD5、farmHash64等，但是對于我們的數據而言的話，要么就是查詢慢，要么就是入數據慢 ， 后來改為了bloom_filter之后寫入才平衡了 。
小文件優化
在數據加工后，出現的小文件非常多，加工出來的小文件都是5M左右，所以在SparkSQL中添加了參數，重新加工的文件就是在60M~100M左右了 。

推薦閱讀