SmartData常見問題

阿里雲OSS是Object Storage Service系統，提供基於對象語義的REST API和各種語言SDK封裝。JindoFS主要是對阿里雲OSS提供HCFS（Hadoop Compatible FileSystem）介面封裝，並且在此基礎上提供緩衝加速能力和進階最佳化定製的功能。因為Hadoop和Spark生態組件依賴HCFS的抽象介面，所以需要使用JindoFS。

JindoFS有哪些使用方式？使用情境是什嗎？

JindoFS使用方式包括JindoFS SDK（jindo-sdk_xxx.jar）、緩衝和Block模式。

針對三種方式，使用情境如下：

JindoFS SDK模式：簡單情況下，您可以使用此模式，上傳JindoFS SDK的JAR包至組件的classpath目錄。
緩衝模式：當計算效能受限於IO和儲存吞吐時，您可以使用此模式，在計算叢集的Core節點上增加或擴容磁碟，以開啟資料緩衝。
Block模式：特殊情境，例如對中繼資料操作效能和一致性要求高時，使用此模式。

JindoFS SDK和緩衝模式的區別是什嗎？

JindoFS SDK和緩衝模式完全相容阿里雲OSS，通過這兩種方式您可以通過OSS產品提供的API和SDK，直接讀取寫入OSS的檔案。

緩衝模式需要部署和配置Jindo分布式快取服務，開啟資料緩衝開關，而JindoFS SDK則不需要。如果快取服務出現故障，系統自動切換至JindoFS SDK方式，直接讀寫OSS檔案。

JindoFS緩衝模式和Block模式的區別是怎嗎？

Block模式可以管理檔案的中繼資料，組織資料的塊，把OSS作為磁碟來使用，類似HDFS。讀寫Block模式的資料需要通過JindoFS SDK 用戶端。

緩衝模式相容OSS，可以直接讀寫資料。例如，您通過緩衝模式寫一個大檔案，可以在OSS控制台對應目錄下找到這個大檔案。如果是塊緩衝模式時，您只能找到很多檔案塊，這些塊只能通過JindoFS SDK 用戶端拼接成大檔案。

如果更新了OSS上的資料，如何保證JindoFS快取資料的一致性？

如果OSS對象被修改、覆蓋或刪除，JindoFS在讀取OSS對象的時候，首先會檢查OSS對象的Meta資訊和MD5，然後對比本機快取的資訊，檢查是否發生了變化。如果發生了變化，本次讀取放棄本機快取直接讀取OSS，並更新緩衝。

JindoFS Block模式可以通過OSS API讀取資料嗎？

不可以。只能通過JindoFS SDK用戶端讀取資料。

Object Storage Service不支援Rename操作，那JindoFS支援Rename操作嗎？

支援。因為JindoFS支援HCFS檔案系統介面，所以支援檔案和目錄的Rename操作。

Object Storage Service因為沒有檔案和目錄的概念，所以不支援檔案和目錄的Rename操作，需要通過類比檔案系統的方式來實現Rename操作（先拷貝對象至新位置，再刪除舊的對象）。

JindoFS的Rename效能如何？

JindoFS的Rename效能優於社區版本。如果是檔案，OSS支援大對象 Fast Copy 最佳化，JindoFS 利用該最佳化做到比社區版本快很多；如果是目錄，涉及到很多檔案，JindoFS通過充分並發最佳化，也比社區版本快多倍。

JindoFS支援類似於Hadoop S3A的Magic Committer嗎？

JindoFS支援無需Rename操作的Magic Committer。

JindoFS對百萬千萬級檔案數目錄的支援情況如何？

針對百萬千萬級檔案數的大目錄，JindoFS支援並發訪問和記憶體最佳化，不會出現OOM（Out Of Memory）或者掛起。

JindoFS是如何保證資料可靠性的？

因為JindoFS無論使用哪種方式，資料都存放在OSS上，本地磁碟只快取資料，所以資料可靠性是由OSS來保證的。

JindoFS支援檔案和目錄操作的一致性嗎？

支援。JindoFS Block模式實現HDFS檔案系統語義，支援強一致性。

JindoFS支援檔案和目錄操作的原子性嗎？

JindoFS Cache模式不支援原子性。JindoFS Cache模式因為要相容OSS，受限於OSSObject Storage Service限制，不支援跨對象操作的原子性。例如Rename操作，至少涉及到源和目標兩個對象，如果是目錄的Rename，涉及的對象更多。

JindoFS Block模式嚴格實現HDFS檔案系統語義，支援原子性，包括Rename操作。

JindoFS Block模式如何保證HA？

JindoFS Block模式基於Raft分布式一致性協議可以部署多個Jindo NamespaceService節點，並且中繼資料的更新支援非同步備份至阿里雲Tablestore資料庫上。

JindoFS Block模式在叢集上儲存檔案中繼資料，重建叢集時資料怎麼處理？

JindoFS Block模式的中繼資料的更新支援非同步備份至阿里雲Tablestore資料庫上，在確保生產叢集停止更新，所有修改同步至Tablestore後，可以停掉JindoFS叢集，此時，所有資料在OSS和Tablestore上。重建叢集時，恢複OSS和Tablestore上資料至重建叢集。

說明重建叢集時，需要考慮版本的相容性。例如，EMR-2.7.x版本之間都是相容的，但EMR-2.7.x和EMR-2.6.x之間則不一定。如果是升級到不相容的大版本時，建議通過Jindo DistCp同步Block模式資料至OSS。

EMR已經支援HDFS，為什麼還要有JindoFS Block模式？

JindoFS Block模式從技術架構和功能上確實和HDFS相似，都是自訂管理檔案中繼資料並組織資料，具有強一致性。

JindoFS Block模式的優勢在於，資料備份至OSS上，支援彈性擴充、低成本且無需維護磁碟。

JindoFS和Alluxio相比有什麼技術差異和優勢？

對比項	JindoFS	Alluxio
相同點	JindoFS緩衝模式在技術架構上與Alluxio類似，都提供對OSS的緩衝加速能力，支援Master + Workers形式，Master維護緩衝塊的位置資訊，Workers提供緩衝塊的管理和讀寫能力。
不同點	JindoFS不需要掛載，可以直接存取oss://路徑，只需開啟資料緩衝開關即可。	Alluxio需要先掛載OSS Bucket位置至名字空間，再使用alluxio://訪問
	JindoFS核心支援的是OSS，效能最佳化。	Alluxio支援資料來源很多，可以同時掛載到統一的名字空間。
	JindoFS提供基礎的SDK模式支援訪問適配 OSS，全面對接各種開源引擎。	無

跟HDFS相比，使用JindoFS和OSS能節省成本嗎？

HDFS儲存時，不能Auto Scaling，預算不足就會面臨儲存空間不足，或者存在空間浪費的情況。

阿里雲OSS是海量Object Storage Service，支援Auto Scaling，具有Archive Storage功能，可以備份冷資料。JindoFS基於OSS，支援資料冷熱分層和資料Archive Storage策略，使用得當，整體上可以降低成本。

Hadoop社區版本也提供OSS支援，JindoFS有什麼優勢？

Hadoop社區版本支援的OSS，受到社區整體約束，只具備OSS基本適配功能。

JindoFS對OSS的支援優勢如下：

更全面：對接各種開源引擎。
更活躍：對OSS的新功能提供同步更新和升級。
更進階：具有高階緩衝加速能力和進階定製功能Block模式。
更快：效能更優。JindoFS核心代碼採用C++ native代碼開發，各種基本操作效能優於社區版本。

JindoFS提供Fuse支援嗎？和OSS內建的Fuse有什麼優勢？

提供。JindoFS提供的Fuse優勢在於能夠利用JindoFS分布式緩衝和Block模式功能。

JindoFS支援哪些開源組件？

支援按照HCFS介面讀寫資料的組件，例如，Hadoop、Hive、Spark、Flink、Presto、HBase、Impala、Druid、Kafka和Flume。

JindoFS吞吐如何？會不會影響Spark或Hive大規模分析計算？

JindoFS在適配上充分發揮OSS並發吞吐能力，實現非同步並發讀取，利用Concurrent Multipart Upload特性進行並發分塊寫入，在讀寫吞吐上面比社區版本具有較大優勢。

JindoFS緩衝模式和Block模式可以利用叢集本地磁碟或記憶體來快取資料，對於新寫入的資料和重複讀取的資料具有顯著加速效果。在同樣叢集條件下，對於Spark或Hive分析計算，跟HDFS相比叢集吞吐是相當的，甚至優於HDFS。

JindoFS寫效能如何？

因為HDFS需要寫三備份才算寫入成功，JindoFS只需寫入OSS一備份就算寫入成功，所以通常情況下，JindoFS寫效能優於HDFS。

JindoFS支援FlinkRealtime Compute情境嗎？

支援。JindoFS支援Flink讀OSS source，checkpoint和sink到OSS以及Exactly-Once語義。

JindoFS和OSS情境下，可以使用Presto做互動式分析嗎？

可以。JindoFS緩衝模式和Block模式都支援Presto互動式分析，且效能穩定。

使用Impala時，可以通過JindoFS查詢OSS上的資料嗎？

可以。Impala 3.4及後續版本支援JindoFS，可以讀寫OSS。

JindoFS支援使用Delta Lake，或者Hudi和IceBerg時，存放資料在OSS上嗎？

支援。

資料存放在OSS上，JindoFS支援機器學習訓練嗎？

支援。您可以使用JindoFS緩衝模式，通過預先載入將OSS資料提前寫入記憶體或者SSD做緩衝，然後訓練引擎可以通過JindoFuse支援直接讀取。

基於MaxCompute數倉上的資料，JindoFS如何協助機器學習訓練？

有如下兩種方式：

MaxCompute數倉作業將資料通過MaxCompute外表方式寫入至OSS，然後在訓練叢集通過JindoFS緩衝模式和JindoFuse來載入訓練。
通過JindoTable從MaxCompute拉取資料寫入至JindoFS緩衝模式，然後使用JindoFuse來載入訓練。

基於Hive數倉上的資料，JindoFS如何協助機器學習訓練？

類似於MaxCompute數倉上的資料處理方式，方式詳情請參見基於MaxCompute數倉上的資料，JindoFS如何協助機器學習訓練？。

如果使用JindoFS，如何遷移HDFS上的資料？

您可以使用Jindo DistCp同步HDFS資料至JindoFS或OSS。Jindo DistCp比Hadoop DistCp效能高，且支援OSS歸檔。

JindoFS在新版本才有，如果需要在EMR叢集上使用JindoFS，該如何處理？

如果叢集規模不大，建議重建叢集來使用JindoFS和EMR新版本。

JindoFS支援哪些Hadoop版本和發行廠商？

JindoFS SDK提供OSS適配功能，明確支援Hadoop 2.7後續版本和Hadoop 3.x版本。

Hortonworks版本（Hortonworks Data Platform，簡稱HDP）和Cloudera版本（Cloudera’s Distribution Including Apache Hadoop，簡稱CDH）都可以使用，但可能會存在衝突，需要修改配置fs.oss.impl = JindoOssFileSystem。

JindoFS可以在ECS自建叢集上使用嗎？

可以。需要您下載JindoFS SDK手工部署即可。如果您需要使用JindoFS緩衝模式和Block模式功能，建議您登入阿里雲E-MapReduce控制台，直接使用E-MapReduce產品。

JindoFS可以在阿里雲ACK環境上使用嗎？

可以。

使用JindoFS會被阿里雲E-MapReduce綁定嗎？

不會。JindoFS遵循標準HCFS介面，相容和支援全面開源生態，不會綁定。

JindoFS可以在IDC機房的Hadoop叢集使用嗎？

可以。您可以直接下載開源JindoFS SDK按照文檔部署使用即可。

如何查看JindoFS上的資料量？

您可以直接使用如下命令查看統計情況。

hadoop dfs -du/count

什麼情況下建議開啟OSS Bucket的多版本控制？

對於重要的資料建議開啟OSS Bucket多版本，防止誤刪時資料不丟失。

開啟OSS Bucket多版本控制對EMR和JindoFS的影響是什嗎？

對於Hive或Spark中間結果存放的資料以及頻繁修改的資料，不建議使用多版本Bucket，會影響計算效能。

OSSArchive Storage可以大量節省儲存成本，JindoFS提供相應的支援嗎？

JindoFS支援相應的OSSArchive Storage。Block模式上，提供專門的儲存策略與OSS歸檔匹配。

使用JindoFS，會泄露AccessKey嗎？

JindoFS支援在叢集上配置使用AccessKey，但存在泄漏AccessKey的風險。在EMR叢集裡或者在ECS環境，如果節點綁定了ECS role，您可以使用許可權管理，不使用AccessKey。

什麼是AccessKey免密？

EMR叢集提供AccessKey免密，該功能通過EMR管控得到使用者授權，方便使用者拿到具有許可權的阿里雲STS (Security Token Service) ，然後使用該 Token訪問阿里雲資源，例如OSS。

如果支援AccessKey免密，那如何區分不同的使用者和許可權限制？

AccessKey免密不是適用於所有的情境。

如果有多個使用者需要區分許可權，有如下兩種方式：

您可以通過RAM使用者權限控制，每個使用者使用RAM使用者來訪問OSS。
您可以使用JindoFS許可權控制，通過Ranger來授權。
重要 JindoFS僅能在Namespace上設定許可權控制。

如何使用不同的AccessKey，通過JindoFS訪問不同的OSS Bucket？

您可以使用JindoFS multi namespace，每個Namespace配置不同的OSS bucket和對應的AccessKey資訊。

在無EMR管控支援情況下，想使用自建的IDC叢集，又不想在叢集節點上配置AccessKey，該如何處理？

您可以使用Hadoop Crendential Provider機制，詳情請參見Credential Provider使用說明。

JindoFS支援Auditlog嗎？

支援。JindoFS支援Multi Namespaces，每個Namespace上可以設定Auditlog，預設不開啟。

JindoFS支援Ranger整合嗎？

支援。JindoFS支援Multi Namespaces，每個Namespace上可以設定支援Ranger，預設不開啟。

EMR中的SmartData和JindoFS是什麼關係？

SmartData是產品組件，該組件包括JindoFS服務。

EMR中的Bigboot和JindoFS是什麼關係？

Bigboot是SmartData組件的基礎設施，對該組件所包含服務提供毫秒級進程監測和日誌清理等功能。

如何處理Bigboot日誌佔用過大的問題？

EMR-3.36.1或EMR-5.2.1之前的版本，會出現Bigboot日誌佔用過大的問題。當您覺得Bigboot佔用日誌過大時，針對已有的記錄檔需要您手動刪除，後續您可以參照以下步驟新增配置，將記錄層級由INFO修改為WARN，以減少列印過多的日誌資訊。

在EMR控制台新增配置。
1. 在SmartData服務的配置頁面，單擊namespace頁簽。
2. 單擊自定义配置。
3. 在新增配置项對話方塊中，添加參數名為logger.level，參數值為1的配置項。
  說明此處的記錄層級預設為0表示INFO，修改為1表示WARN。
4. 單擊确定。
儲存配置。
1. 單擊保存。
2. 在确认修改對話方塊中，輸入执行原因，單擊确定。
重啟Jindo Namespace Service。
1. 在右上方選擇操作 > 重啟Jindo Namespace Service。
2. 在執行叢集操作對話方塊中，輸入执行原因，單擊确定。
3. 在确认對話方塊中，單擊确定。

/opt/bignode目錄佔用巨大並持續增長，該如何處理？

問題現象：通常情況下，/opt/bignode目錄正常大小應該是幾個GB，但SmartData 2.x版本，/opt/bignode目錄佔用巨大，並且出現磁碟佔用過大並持續增長的情況。
問題原因：可能是由於監控進程異常退出，導致對Jindo Storage Service進程狀態監控異常，從而不斷重複拉起進程導致的。
處理方法：您可以通過以下步驟排查並處理。
在出現問題的節點上，以root使用者執行以下命令，查看進程資訊。
```
ps -aux | grep b2-storageservice | grep -v grep
```
通常情況下應該有兩個進程，分別是xxxx/services/b2-storageservice.spec和xxxx/bin/b2-storageservice。如果缺少xxxx/services/b2-storageservice.spec進程，則可以確認是監控進程異常退出導致的，需手動終止xxxx/bin/b2-storageservice進程。
```
kill -9 <PID of b2-storageservice>
```
說明 <PID of b2-storageservice>為您查看進程資訊時，查詢到的xxxx/bin/b2-storageservice進程的進程ID。
執行以上命令後，監控進程會自動拉起新的Storage Service服務，目錄佔用會自動回復正常。

讀緩衝時資料出錯，該如何處理？

問題現象：SmartData 3.0至SmartData 3.7版本，使用JindoFS Block模式（Block模式預設啟用緩衝），或者使用Cache模式並開啟了緩衝的情況下，產生資料時沒有問題，但讀取資料時出現內容汙染的現象，例如，作業對格式來源資料（ORC或Parquet）報格式錯誤、HBase報HFile格式錯誤等。
問題原因：可能是遇到了快取資料塊讀取流程上的程式已知缺陷，誤讀了錯誤的快取資料塊導致的。
處理方法：您可以通過以下方式進行快速恢複處理，並聯絡EMR對歷史版本程式進行升級修複。
請根據實際需求選擇以下方式，快速規避該缺陷，避免對業務產生持續影響。
- 方式一：關閉緩衝。
  通常該缺陷是快取資料導致的，通過關閉緩衝可以徹底避免該問題。您可以在SmartData服務的client配置頁面通過配置關閉緩衝，Block模式配置jfs.data-cache.enable為false，Cache模式配置jfs.cache.data-cache.enable為false。
- 方式二：對報錯檔案進行緩衝清理。
  如果出於效能等方面考慮，不適合關閉緩衝，可以選擇此方式。
  1. 執行以下命令，提交緩衝清理任務。
```
jindo jfs -uncache <報錯檔案全路徑>
```
  2. 執行以下命令，查看任務狀態，並且確定報錯檔案的緩衝已清理完成。
```
jindo jfs -status <報錯檔案全路徑>
```
  3. 在SmartData服務的client配置頁面，添加自訂配置項storage.compaction.enable為false。
    添加參數的詳情，請參見添加組件參數。
  4. 重啟Jindo Storage Service服務。
    重啟Jindo Storage Service服務的詳情，請參見重啟服務。

JindoFS如何手動下線節點？

手動下線節點的命令格式如下。

jindo jfs -decommission <excludeFile>

說明命令中的<excludeFile>為建立的檔案，檔案中的內容是待下線節點的主機名稱，每行代表一個待下線的節點，節點主機名稱您可以通過hostname命令擷取。檔案內容格式如下。

emr-worker-1.cluster-29****
emr-worker-2.cluster-29****