Apache Iceberg在小紅書的探索與實(shí)踐
發(fā)布人：數(shù)據(jù)派THU
時(shí)間：2022-08-20
來(lái)源：工程師
發(fā)布文章
加入技術(shù)交流群
掃碼加入
和技術(shù)大咖面對(duì)面交流
海量資料庫(kù)查詢
以下文章來(lái)源于DataFunTalk ，作者孫超
目前小紅書對(duì)數(shù)據(jù)湖技術(shù)的探索主要分為三個(gè)方向，第一個(gè)方向是在小紅書云原生架構(gòu)下，對(duì)于大規(guī)模日志實(shí)時(shí)入湖的實(shí)踐，第二個(gè)方向是業(yè)務(wù)數(shù)據(jù)的CDC實(shí)時(shí)入湖實(shí)踐，第三個(gè)方向是對(duì)實(shí)時(shí)數(shù)據(jù)湖分析的探索。
今天的分享也主要圍繞這三個(gè)方向展開，并在最后介紹我們對(duì)未來(lái)工作的規(guī)劃：
- 日志數(shù)據(jù)入湖
- CDC實(shí)時(shí)入湖
- 實(shí)時(shí)湖分析探索
- 未來(lái)規(guī)劃
01 日志數(shù)據(jù)入湖
1. 小紅書數(shù)據(jù)平臺(tái)架構(gòu)
在進(jìn)入主題之前先介紹一下小紅書數(shù)據(jù)平臺(tái)的基本架構(gòu)。
總體來(lái)說(shuō)，小紅書數(shù)據(jù)平臺(tái)與其他互聯(lián)網(wǎng)公司大同小異，主要不同在于小紅書的基礎(chǔ)架構(gòu)是“長(zhǎng)”在多朵公有云之上的。在數(shù)據(jù)采集層，日志和RDBMS的數(shù)據(jù)源來(lái)自不同的公有云；在數(shù)據(jù)存儲(chǔ)加工層，絕大多數(shù)數(shù)據(jù)會(huì)存儲(chǔ)于AWS S3對(duì)象存儲(chǔ)；同時(shí)，數(shù)倉(cāng)體系也是圍繞著S3來(lái)建設(shè)的，實(shí)時(shí)ETL鏈路基于Kafka、Flink，離線分析鏈路基于AWS EMR上的Spark、Hive、Presto等；在數(shù)據(jù)共享層，諸如Clickhouse、StarRocks、TiDB等OLAP引擎，為上層報(bào)表提供一些近實(shí)時(shí)的查詢。以上就是小紅書數(shù)據(jù)平臺(tái)整體的架構(gòu)組成。
2. APM日志數(shù)據(jù)入湖
接下來(lái)我們用APM（Application Performance Monitor）的例子來(lái)介紹Iceberg如何在當(dāng)前架構(gòu)體系下運(yùn)轉(zhuǎn)。
（1）使用Iceberg之前的APM鏈路
APM主要記錄小紅書APP前端和客戶端性能相關(guān)的埋點(diǎn)日志，可以達(dá)到百萬(wàn)每秒的RPS。以前的離線鏈路是先將埋點(diǎn)數(shù)據(jù)發(fā)送到阿里云的Kafka，通過(guò)Flink作業(yè)落到阿里云的OSS對(duì)象存儲(chǔ)，然后通過(guò)Distcp搬到AWS S3上，之后通過(guò)Add Partition落地到Hive表里，接下來(lái)下游的EMR集群會(huì)對(duì)落地的數(shù)據(jù)做一些離線的ETL作業(yè)調(diào)度和Adhoc的查詢。整條鏈路中，數(shù)倉(cāng)同學(xué)的痛點(diǎn)是Flink ETL作業(yè)上數(shù)據(jù)需要按業(yè)務(wù)分區(qū)動(dòng)態(tài)寫入，但是各點(diǎn)位分區(qū)之間的流量非常不均勻。這就涉及到動(dòng)態(tài)寫分區(qū)時(shí)候是否要加Keyby，如果加Keyby就會(huì)發(fā)生數(shù)據(jù)傾斜，不加Keyby每個(gè)寫算子的Subtask都會(huì)為每個(gè)分區(qū)創(chuàng)建一個(gè)Writer，而分區(qū)Writer又至少創(chuàng)建一個(gè)文件，同時(shí) Flink Checkpoint 又會(huì)放大這個(gè)寫放大，最終導(dǎo)致小文件數(shù)爆炸。
小文件數(shù)多后會(huì)導(dǎo)致以下幾個(gè)后果：
- Distcp會(huì)變得非常慢，導(dǎo)致數(shù)據(jù)延遲在小時(shí)級(jí)以上。
- 流量小的很多文件集中在一個(gè)Task，導(dǎo)致查詢性能差。
（2）基于Iceberg的改良鏈路
Iceberg支持事務(wù)，我們可以利用這個(gè)特性來(lái)異步合并小文件，這樣既不影響主流的寫入又可以保障一致性，基于此想法我們可以得到以上的架構(gòu)圖。
該架構(gòu)簡(jiǎn)化了落OSS 的步驟，Kafka數(shù)據(jù)可以直接通過(guò)Flink落到S3的Iceberg，之后異步執(zhí)行合并小文件作業(yè)，此后下游就可以直接基于Iceberg做ETL調(diào)度。這個(gè)鏈路的問(wèn)題在于：
- 異步的小文件合并為周期調(diào)度，但是Iceberg在commit之后，下游ETL讀文件作業(yè)會(huì)立即執(zhí)行，在這之后再掛異步合并作業(yè)的意義就不大了。
- 如果同步合并小文件，即在Flink入湖作業(yè)中掛一個(gè)合并算子，這樣會(huì)引入跨云IO，并增加Flink作業(yè)的OOM風(fēng)險(xiǎn)。
所以我們還是決定通過(guò)加入Shuffle，從源頭解決數(shù)據(jù)傾斜的問(wèn)題。我們自主設(shè)計(jì)了一個(gè)EvenPartitionShuffle的算法做數(shù)據(jù)Shuffle。Iceberg支持將分區(qū)級(jí)別的統(tǒng)計(jì)信息寫入到元數(shù)據(jù)中，這樣就可以拿到不同分區(qū)的流量分布，再根據(jù)下游的并行度，就可以將問(wèn)題轉(zhuǎn)化為一個(gè)類背包問(wèn)題，類似于Spark的AQE。
對(duì)于評(píng)估這個(gè)算法可以抽象出以下兩個(gè)指標(biāo)：
- Fanout：下游Subtask的分區(qū)個(gè)數(shù)。
- Residual：下游Subtask的分配流量和與目標(biāo)流量差距。
這兩個(gè)指標(biāo)反映出小文件的個(gè)數(shù)以及數(shù)據(jù)傾斜的均勻程度，我們也在這兩個(gè)指標(biāo)的評(píng)估下來(lái)不斷調(diào)整背包算法。從最終的效果來(lái)看，線上作業(yè)IcebergStreamWriter各Subtask數(shù)據(jù)負(fù)載還是比較均勻的，也極大減少了小文件數(shù)。
以上方案的優(yōu)缺點(diǎn)如下：
優(yōu)點(diǎn)：
- 小文件的問(wèn)題得到了解決。
- Writer算子內(nèi)存占用減少。
缺點(diǎn)：
- 引入了Shuffle。
- 流量動(dòng)態(tài)變化。暫時(shí)還不能根據(jù)流量變化動(dòng)態(tài)調(diào)整分區(qū)分布，因?yàn)楫?dāng)前是在Flink 作業(yè)啟動(dòng)的時(shí)候讀取Iceberg的元數(shù)據(jù)。
（3）將基于Iceberg的鏈路應(yīng)用于小紅書多云架構(gòu)
當(dāng)解決以上問(wèn)題之后，讓我們來(lái)看看如何將以上鏈路應(yīng)用在小紅書的多云架構(gòu)上。有兩個(gè)問(wèn)題需要解決：跨云流式讀寫的問(wèn)題，以及Iceberg與下游系統(tǒng)的集成。
①跨云流式讀寫
關(guān)于Iceberg多云架構(gòu)下讀寫的問(wèn)題，我們先來(lái)看以上架構(gòu)圖的組件與數(shù)據(jù)流。在上面的架構(gòu)圖中高亮標(biāo)出了Iceberg兩個(gè)比較重要的抽象：Catalog與FileIO。
Catalog保存了Iceberg最新的元數(shù)據(jù)的指針，并且需要保證指針變更的原子性。Iceberg提供了HiveCatalog和HadoopCatalog兩種實(shí)現(xiàn)。HadoopCatalog依賴于文件系統(tǒng)rename接口的原子性，而rename在對(duì)象存儲(chǔ)上并不是原子操作（對(duì)于最新版本的HadoopCatalog，加一個(gè)顯式的鎖可以保證原子性，但是當(dāng)時(shí)還沒(méi)有這方面的實(shí)現(xiàn)）。所以我們選用了HiveCatalog，對(duì)于HiveMetastore，離線數(shù)倉(cāng)包括Iceberg都是讀寫一個(gè)RDS庫(kù)，所以通過(guò)EMR集群的HMS也能直接訪問(wèn)到Flink寫進(jìn)來(lái)的Iceberg表。
FileIO是Iceberg讀寫存儲(chǔ)系統(tǒng)的接口。HiveCatalog默認(rèn)是HadoopFileIO，我們可以在中間封裝一層S3AFileSystem來(lái)讀寫S3。當(dāng)我們走完這條鏈路時(shí)發(fā)現(xiàn)Flink讀寫都是正常的，但是離線所依賴的EMRFS不支持S3A的Schema。于是我們調(diào)研了Iceberg原生的S3FileIO，發(fā)現(xiàn)它的實(shí)現(xiàn)非常簡(jiǎn)單直接，且可控性非常高，于是在經(jīng)過(guò)了一些大規(guī)模的壓測(cè)，并解決了一些問(wèn)題后就選擇了S3FileIO。
首先Flink TaskWriter在接收數(shù)據(jù)向下游寫到S3OutputStream。用戶可設(shè)置一個(gè)MPU閾值，當(dāng)大于閾值時(shí)，會(huì)有一個(gè)線程池異步地使用MPU上傳文件到S3，否則就會(huì)走另一條路徑，將StagingFiles串在一起，通過(guò)PutObject請(qǐng)求寫到S3。
對(duì)于以上鏈路，我們也對(duì)S3FileIO做了一些優(yōu)化以支持大流量的作業(yè)。
（1）S3Client上的優(yōu)化：
- HttpsClients，我們將S3原生的HttpsClients（Java8自帶的HTTP URL Connection）更換為了Apache HttpClient，其在Socket鏈接以及易用性上有一些提升。在寫的過(guò)程中我們也遇到了一些問(wèn)題，多云機(jī)器帶來(lái)的問(wèn)題是每個(gè)廠商機(jī)器的內(nèi)核是不太一樣的，例如在某云上發(fā)現(xiàn)有寫S3超時(shí)的問(wèn)題，我們與廠商一起抓包發(fā)現(xiàn)是內(nèi)核參數(shù)的問(wèn)題。
- API Call Timeout，將S3的Timeout配置項(xiàng)暴露給Iceberg。
- Credential Provider，S3 SDK從FlinkConf中讀取密鑰。
（2）MPU Threshold
Flink做Checkpoint的時(shí)候，所有的Writer都會(huì)將數(shù)據(jù)刷到S3，這時(shí)候的毛刺會(huì)非常大。我們的方案是降低MPU的閾值以及ParquetWriter的RowGroup。降低Parquet的RowGroup就意味著它刷到S3OutputStream可以更早一點(diǎn)，降低MPU閾值就可以更早地上傳StagingFile。通過(guò)以上優(yōu)化我們把CheckPoint在上傳到S3的延遲中從2分鐘降到了幾十秒。
（3）ResetException
當(dāng)S3OutputStream通過(guò)BufferedInputStream把兩個(gè)StagingFile合并到一起并上傳時(shí)，當(dāng)遇到諸如網(wǎng)絡(luò)問(wèn)題時(shí)會(huì)重試，它重試的機(jī)制是通過(guò)InputStreaming的mark和reset來(lái)做的，但是默認(rèn)的mark limit是128KB，BufferedInputStream超過(guò)128KB之后就會(huì)丟數(shù)據(jù)，重試時(shí)就會(huì)出現(xiàn)ResetException。我們將mark limit改成 StagingFiles Size +1，保證所有的數(shù)據(jù)都會(huì)緩存避免以上問(wèn)題。
②下游系統(tǒng)集成
接下來(lái)要解決的是跟下游生態(tài)系統(tǒng)集成的問(wèn)題。
- 第一個(gè)問(wèn)題是Batch Read
Iceberg與Hive最明顯的區(qū)別就是分區(qū)的可見(jiàn)性語(yǔ)義，Hive在整個(gè)分區(qū)寫完后可見(jiàn)，而Iceberg在commit后就立即可見(jiàn)。但是下游離線調(diào)度的小時(shí)級(jí)任務(wù)比較依賴于HivePartition的可見(jiàn)性。
在此我們做了一個(gè)Sensor，其原理是Flink在寫的時(shí)候?qū)atermark寫進(jìn)Iceberg表的Table Property。下游的離線調(diào)度就可以使用我們基于Airflow的Watermark Sensor去定期的輪詢HMS，查詢Watermark是否已經(jīng)達(dá)到分區(qū)時(shí)間，條件滿足之后就會(huì)觸發(fā)Spark的調(diào)度。
- 第二個(gè)問(wèn)題是Adhoc查詢
Adhoc查詢使用了Kyuubi這樣一個(gè)多租戶的SQL Gateway通過(guò)Spark去讀Iceberg表。用戶可以直接通過(guò)三段式的表名去查詢Iceberg 表，例如：
hive_prod.Iceberg_test.table
總結(jié)：
我們目前在生產(chǎn)環(huán)境已經(jīng)落地了幾個(gè)比較大的作業(yè)，單作業(yè)的吞吐達(dá)到了GB/S以及百萬(wàn)級(jí)別的RPS，數(shù)據(jù)的就緒時(shí)間大概在五分鐘左右，由Flink Checkpoint來(lái)控制。下游的讀耗時(shí)得益于小文件問(wèn)題的解決以及Iceberg基于文件的Planning，使下游讀耗時(shí)減少了30%~50%。
02 CDC實(shí)時(shí)入湖
1. Mysql全量入倉(cāng)
小紅書數(shù)倉(cāng)數(shù)據(jù)的另一重要來(lái)源是MySQL，目前的Mysql2Hive鏈路是全量入倉(cāng)這種比較傳統(tǒng)的模式，主要通過(guò)Airflow定時(shí)調(diào)度，使用Sqoop去小時(shí)級(jí)別或天級(jí)別從MySQL拉數(shù)據(jù)寫到Hive表相應(yīng)的分區(qū)里面。
其中比較特殊的一點(diǎn)是為了解決Schema Evolution，每次拉取數(shù)據(jù)的時(shí)候都會(huì)生成一個(gè)Avro Shema，對(duì)應(yīng)的Hive表選用了行存儲(chǔ)的Avro表，而不是通常會(huì)使用的基于列存的Parquet文件的表。它的缺點(diǎn)是不如列存高效，但是它解決了一個(gè)問(wèn)題——下游的用戶不需要考慮schema變化的情況。這條鏈路的好處是簡(jiǎn)單實(shí)用直接，缺點(diǎn)是MySQL壓力大，下游查詢不夠高效。
2. CDC增量入倉(cāng)
關(guān)于CDC如何增量入離線數(shù)倉(cāng)的問(wèn)題，大廠都有一些比較成熟穩(wěn)定的方案。
如上圖， ODS一般有兩張表，一張?jiān)隽勘硪粡埲勘?，開始會(huì)有一個(gè)全量表的導(dǎo)入，之后會(huì)通過(guò)實(shí)時(shí)流進(jìn)增量表，然后通過(guò)Merge任務(wù)進(jìn)行周期性的合并操作。這個(gè)鏈路已經(jīng)在很多廠都有了成熟穩(wěn)定的實(shí)踐，缺點(diǎn)是鏈路比較長(zhǎng)。
3. CDC實(shí)時(shí)入湖
我們最終的鏈路如上圖，將MySQL的上游數(shù)據(jù)庫(kù)通過(guò)全增量數(shù)據(jù)發(fā)送到Kafka，然后使用Flink將數(shù)據(jù)Upsert到Iceberg里面，同時(shí)會(huì)處理一些Schema Evolution的情況，這條鏈路就非常簡(jiǎn)潔。
整條鏈路中我們需要特別注意，同?主鍵（業(yè)務(wù)主鍵+ Shard Key）的Binlog應(yīng)該保序。以下是在整條鏈路中保持Exactly-Once語(yǔ)義所做的事情：
①Binlog
- 全增量，先發(fā)全量再發(fā)增量。
- At-Least-Once，保證重復(fù)發(fā)送時(shí)保證有序（最終?致性）。
- MQ Producer根據(jù)主鍵Hash（且分桶數(shù)固定，不受擴(kuò)容影響）。
②Flink
- Shuffle Key 只能是主鍵的?集 + Immutable Columns。
③ Iceberg sink
- Upsert Mode。
（1）Merge on Read
這個(gè)方案我們?cè)趯?shí)踐中也發(fā)現(xiàn)一些問(wèn)題，最核心的就是DeleteFile多導(dǎo)致的MOR查詢性能差。
Iceberg查詢時(shí)，每個(gè)DataFile都需要讀取相應(yīng)的DeleteFile進(jìn)內(nèi)存進(jìn)行過(guò)濾，會(huì)使得Task的IO負(fù)載很重，這樣我們的優(yōu)化思路就轉(zhuǎn)換為如何減少DeleteFile。而出現(xiàn)DeleteFile過(guò)多的原因是，Update的實(shí)現(xiàn)要先把當(dāng)前行刪掉再Insert，刪掉這行就至少會(huì)生成一個(gè)DeleteFile。我們對(duì)此所作的優(yōu)化是去除重復(fù)的Insert事件，這樣只需要對(duì)Update做Delete。當(dāng)下游Insert很多，Update很少的時(shí)候就會(huì)有比較大的收益。
（2）Hidden Partition
Iceberg的分區(qū)與Hive不同的是它的分區(qū)信息可以被隱藏起來(lái)，不需要用戶去感知，在建表或者修改分區(qū)策略之后，新插入的數(shù)據(jù)自動(dòng)計(jì)算所屬分區(qū)。
利用隱藏分區(qū)我們可以做到以下優(yōu)化：
- 在讀數(shù)據(jù)時(shí)可以只查詢關(guān)聯(lián)分區(qū)，忽略其他分區(qū)。
- 錯(cuò)峰做File Compaction，減少?zèng)_突。例如在寫當(dāng)前小時(shí)分區(qū)時(shí)我們可以對(duì)之前的分區(qū)做File Compaction。
對(duì)于FlinkSQL原生不支持隱藏分區(qū)的問(wèn)題，我們通過(guò)Table Property去定義隱藏分區(qū)，在建表的時(shí)候去建相應(yīng)的分區(qū)。
（3）Auto Schema Evolution
在實(shí)時(shí)流處理Binlog，一個(gè)繞不開的問(wèn)題是上游的Schema變更了下游怎么及時(shí)的檢測(cè)到，再去做相應(yīng)的Writer的變更，下游表的變更。有一種解決方案是當(dāng)消費(fèi)到上游變更的Event事件時(shí)，我們會(huì)在平臺(tái)把作業(yè)重新改掉重啟，也就是先變更下游的Iceberg的Table Schema，再變更Flink SQL，之后重新啟動(dòng)作業(yè)。但在平臺(tái)化之前，對(duì)于一些常用的場(chǎng)景，比如加列，已經(jīng)能覆蓋線上很多Schema Evolution的場(chǎng)景。為了讓Flink作業(yè)能自動(dòng)監(jiān)測(cè)到加列并且有序的正確的提交到Iceberg，我們將Binlog中的Schema隨著每條數(shù)據(jù)記錄一起發(fā)送，當(dāng)數(shù)據(jù)往下發(fā)到Iceberg的Dynamic Streaming Writer時(shí)，就可以和Writer里面保存的上一個(gè)Schema去做比較，假設(shè)只是加列，那么我們就會(huì)做兩件事情：
- 關(guān)掉當(dāng)前的Writer，以新的Schema去建立新的Writer寫數(shù)據(jù)。
- 以Schema變更的時(shí)間點(diǎn)為分割，對(duì)Schema變更前的數(shù)據(jù)先提交，再對(duì)Schema 進(jìn)行Update，之后再提交 Schema變更后的文件。
（4）CDC實(shí)時(shí)入湖其他工作
除此之外，CDC與實(shí)時(shí)鏈路我們還做了其它一些工作：
- Binlog Format。支持解析Canal PB格式。
- Progressive Compaction。Compaction是我們接下來(lái)工作的重點(diǎn)，尤其在MySQL的量比較小的時(shí)候，如果想維持五分鐘級(jí)別的CheckPoint，小文件問(wèn)題就會(huì)非常突出。如何避開流式任務(wù)正在寫的Partition去做Compaction 也是目前在做的事情。
以上就是我們目前正在做的CDC入湖的一些工作。
03 實(shí)時(shí)湖分析探索
我們想用Iceberg 來(lái)做一些更面向未來(lái)的事情。
1. 實(shí)時(shí)分析鏈路
首先介紹一下目前分析的實(shí)時(shí)鏈路。
Kafka通過(guò)Flink做一些Join和聚合操作之后，最后會(huì)生成一張大寬表存儲(chǔ)到ClickHouse中以提供秒級(jí)或者毫秒級(jí)的返回功能，Kafka在其中也用做了事實(shí)表的存儲(chǔ)。以上架構(gòu)圖來(lái)自FLIP-188，F(xiàn)LIP-188要做的事情就是如何實(shí)現(xiàn)流批一體的存儲(chǔ)。我們數(shù)倉(cāng)同學(xué)的需求是要對(duì)中間結(jié)果進(jìn)行一些查詢操作或者利用其進(jìn)一步生成下游的表，這些操作只利用Kafka是做不了的。常見(jiàn)的做法是利用Kafka再接一個(gè)任務(wù)，將中間結(jié)果寫到Iceberg或者Hudi表里面。
2. 流批一體存儲(chǔ)
我們實(shí)現(xiàn)流批一體存儲(chǔ)是通過(guò)直接在Kafka里雙寫一份數(shù)據(jù)到Iceberg的列存儲(chǔ)上。這除了讓Kafka做擴(kuò)容更簡(jiǎn)單，更重要的是支持一些離線數(shù)倉(cāng)的用法，我們不必再啟動(dòng)一個(gè)Flink的作業(yè)去寫到S3。要實(shí)現(xiàn)這樣的功能首先需要一個(gè)Schema的概念，也就是如何把Kafka的Schema映射到下游表的Schema，對(duì)此我們讓用戶在我們的平臺(tái)上來(lái)自定義，同時(shí)有一個(gè)Remote Fetcher模塊來(lái)拿到這個(gè)Schema，之后通過(guò)Iceberg寫到下游。真正的寫線程是在Broker里面，可以根據(jù)Leader去動(dòng)態(tài)遷移。之后集群中的Controller節(jié)點(diǎn)上啟動(dòng)一個(gè)單獨(dú)的Commiter進(jìn)程，接受Fetcher傳來(lái)的數(shù)據(jù)文件列表，定期commit。
3. Iceberg外表
ClickHouse社區(qū)版是存算耦合的，離線數(shù)倉(cāng)想用這部分的數(shù)據(jù)就比較困難。我們公司內(nèi)部的ClickHouse已經(jīng)實(shí)現(xiàn)了存算分離的架構(gòu)，數(shù)據(jù)是存儲(chǔ)于對(duì)象存儲(chǔ)的。在此基礎(chǔ)上，我們和ClickHouse團(tuán)隊(duì)合作做了Iceberg的外表。Iceberg外表沒(méi)有使用Paruqet這種開放式的文件格式，而是使用了MergeTree的格式。上圖是一張Iceberg傳統(tǒng)的數(shù)據(jù)文件組織形式圖，它的Metadata層分成了Manifest List和Manifest File，之后會(huì)指向一些DataFile。這些DataFile與ClickHouse里面的part概念很像，所以我們就將Manifest File指向了一個(gè)part.ck文件，part.ck其實(shí)也是一層衍生的元數(shù)據(jù)文件，它的下游會(huì)再去讀一些bin/mark的文件，這樣就可以完成對(duì)ClickHouse數(shù)據(jù)的讀取。
04 未來(lái)規(guī)劃
未來(lái)規(guī)劃主要有存、算、管三個(gè)方向。
- 首先在存儲(chǔ)方面，我們需要對(duì)CloudNative FileIO持續(xù)優(yōu)化，比如進(jìn)一步減少Checkpoint的毛刺、進(jìn)一步提高吞吐、提高跨云讀寫的穩(wěn)定性。
- 關(guān)于計(jì)算，我們會(huì)跟更多引擎去集成，目前已經(jīng)集成了Spark引擎，同時(shí)正在集成ClickHouse。另外StarRocks社區(qū)已經(jīng)集成了Iceberg外表的Connector，我們以后也會(huì)在上面做一些應(yīng)用。在查詢方面，計(jì)劃通過(guò)改變數(shù)據(jù)的組織形式，或者添加一些二級(jí)索引來(lái)做Data Skipping去加速查詢。
- 管理方面，讓Iceberg持續(xù)穩(wěn)定的運(yùn)行下去還是需要外掛表維護(hù)作業(yè)的，這對(duì)下游數(shù)倉(cāng)同學(xué)來(lái)說(shuō)還是引入了運(yùn)維壓力。我們接下來(lái)會(huì)將其服務(wù)化，思考如何智能地拉起一些作業(yè)，以及運(yùn)用什么策略可以減少?zèng)_突的概率。
這就是我們正在做的和將來(lái)準(zhǔn)備做的一些事情。
編輯：王菁
*博客內(nèi)容為網(wǎng)友個(gè)人發(fā)布，僅代表博主個(gè)人觀點(diǎn)，如有侵權(quán)請(qǐng)聯(lián)系工作人員刪除。
linux操作系統(tǒng)文章專題:linux操作系統(tǒng)詳解（linux不再難懂）
