Azure HDInsight 商務持續性架構
本文提供一些您可能考慮用於 Azure HDInsight 的商務持續性架構範例。 災害期間降低功能的容錯是一項商務決策,從一個應用程式到下一個應用程式不等。 某些應用程式可能無法使用,或因功能降低或延遲處理一段時間而部分可用,可能是可以接受的。 對於其他應用程式,任何縮減的功能都可能無法接受。
注意
本文所呈現的架構絕不詳盡。 當您針對預期的商務持續性、作業複雜度和擁有成本做出客觀判斷之後,您應該設計自己的獨特架構。
Apache Hive 和互動式查詢
針對 HDInsight Hive 和互動式查詢叢集中的商務持續性,建議使用 Hive 複寫 V2 。 需要復寫的獨立Hive叢集持續性區段是 儲存體層和Hive中繼存放區。 具有企業安全性套件的多使用者案例中的Hive叢集需要 Microsoft Entra Domain Services 和 Ranger 中繼存放區。
Hive 事件型復寫是在主要和次要叢集之間設定。 這包含兩個不同的階段:啟動載入和累加執行:
啟動載入會復寫整個Hive倉儲,包括從主要到次要的Hive中繼存放區資訊。
累加執行會在主要叢集上自動化,而累加執行期間所產生的事件會在次要叢集上播放。 次要叢集會趕上從主要叢集產生的事件,確保次要叢集與復寫執行後的主要叢集事件一致。
只有在復寫執行分散式複本時,才需要次要叢集, DistCp
但記憶體和中繼存放區必須持續存在。 您可以選擇在複寫之前依需求啟動已編寫腳本的次要叢集、在複寫上執行複寫腳本,然後在成功復寫之後將其卸除。
次要叢集通常是唯讀的。 您可以建立次要叢集讀寫,但這會增加額外的複雜度,涉及將次要叢集的變更復寫到主要叢集。
Hive 事件型復寫 RPO 和 RTO
RPO:數據遺失僅限於從主要複寫到次要復寫的最後一個成功事件。
RTO:失敗與使用次要的上游和下游交易繼續之間的時間。
Apache Hive 和互動式查詢架構
具有隨選次要複本的Hive作用中主要複本
在具有隨選次要架構的作用中主要複本中,應用程式會在正常作業期間未在次要區域中布建叢集時寫入使用中主要區域。 次要區域中的 SQL 中繼存放區和 儲存體 是持續性的,而 HDInsight 叢集只有在排程的 Hive 複寫執行之前,才會編寫腳本並隨選部署。
具有待命次要複本的Hive作用中主要複本
在具有待命次要複本的作用中主要區域中,應用程式會寫入使用中主要區域,而待命在唯讀模式中的次要叢集會在正常作業期間執行。 在一般作業期間,您可以選擇將區域特定的讀取作業卸除至次要。
如需Hive複寫和程式碼範例的詳細資訊,請參閱 Azure HDInsight 叢集中的Apache Hive 複寫
Apache Spark
Spark 工作負載可能或可能未涉及Hive元件。 若要讓Spark SQL工作負載從Hive讀取和寫入數據,HDInsight Spark 叢集會從相同區域中的Hive/互動式查詢叢集共用 Hive 自定義中繼存放區。 在這種情況下,Spark 工作負載的跨區域複寫也必須隨附 Hive 中繼存放區和記憶體的複寫。 本節中的故障轉移案例適用於下列兩者:
- 使用HIVe Warehouse 連線 or(HWC) 設定使用 HDInsight 互動式查詢叢集的 ACID 資料表上的 Spark SQL。
- 使用 HDInsight Hadoop 叢集的非 ACID 數據表上 Spark SQL 工作負載。
針對Spark在獨立模式中運作的案例,必須使用 Azure Data Factory 的 DistCP
,定期將策展數據和預存的Spark Jars(適用於 Livy 作業)從主要區域復寫到次要區域。
建議您使用版本控制系統來儲存 Spark 筆記本和連結庫,以便輕鬆地部署在主要或次要叢集上。 確定筆記本型和非筆記本型解決方案已準備好在主要或次要工作區中載入正確的數據掛接。
如果有超出 HDInsight 原生提供的專屬客戶連結庫,則必須追蹤並定期載入待命次要叢集。
Apache Spark 複寫 RPO 和 RTO
RPO:數據遺失僅限於從主要複寫到次要復寫的最後一次成功增量複寫(Spark 和 Hive)。
RTO:失敗與使用次要的上游和下游交易繼續之間的時間。
Apache Spark 架構
具有隨選次要的Spark使用中主要複本
應用程式會在主要區域中讀取和寫入 Spark 和 Hive 叢集,而一般作業期間不會在次要區域中布建任何叢集。 SQL 中繼存放區、Hive 儲存體 和 Spark 儲存體 在次要區域中是持續性的。 Spark 和Hive叢集會依需求編寫腳本並部署。 Hive 複寫可用來復寫 Hive 儲存體 和 Hive 中繼存放區,而 Azure Data Factory DistCP
可用來複製獨立 Spark 記憶體。 Hive 叢集必須先部署,才能執行每個Hive複寫,因為相依性 DistCp
計算。
具有待命次要的Spark作用中主要複本
應用程式在主要區域中讀取和寫入 Spark 和 Hive 叢集,而待命相應減少 Hive 和 Spark 叢集則以唯讀模式在正常作業期間於次要區域中執行。 在一般作業期間,您可以選擇將區域特定的 Hive 和 Spark 讀取作業卸除至次要。
Apache HBase
HBase 導出和 HBase 複寫是啟用 HDInsight HBase 叢集之間商務持續性的常見方式。
HBase 導出是使用 HBase 匯出公用程式將數據表從主要 HBase 叢集匯出至其基礎 Azure Data Lake 儲存體 Gen 2 記憶體的批次復寫程式。 然後,您可以從次要 HBase 叢集存取匯出的數據,並匯入至必須預先存在於次要的數據表中。 雖然 HBase 匯出確實提供數據表層級數據粒度,但在累加更新的情況下,匯出自動化引擎會控制每個執行中要包含的累加數據列範圍。 如需詳細資訊,請參閱 HDInsight HBase 備份和複寫。
HBase 複寫會以完全自動化的方式,在 HBase 叢集之間使用近乎即時的複寫。 復寫是在數據表層級完成。 所有數據表或特定數據表都可以以復寫為目標。 HBase 複寫最終會保持一致,這表示主要區域中數據表的最新編輯可能無法立即提供給所有次要複寫。 輔助資料庫保證最終會與主要複本保持一致。 如果下列條件,可以在兩個或多個 HDInsight HBase 叢集之間設定 HBase 複寫:
- 主要和次要位於相同的虛擬網路中。
- 主要和次要位於相同區域中的不同對等互連 VNet 中。
- 主要和次要位於不同區域中的不同對等互連 VNet 中。
如需詳細資訊,請參閱 在 Azure 虛擬網路中設定 Apache HBase 叢集復寫。
有一些其他方式可以執行 HBase 叢集的備份,例如 複製 hbase 資料夾、 複製數據表 和 快照集。
HBase RPO 和 RTO
HBase 導出
- RPO:數據遺失僅限於次要從主要複本成功批次累加匯入。
- RTO:主要作業失敗與次要復寫 I/O 作業之間的時間。
HBase 複寫
- RPO:數據遺失僅限於在次要端收到的最後一批 WalEdit 出貨。
- RTO:主要作業失敗與次要復寫 I/O 作業之間的時間。
HBase 架構
HBase 複寫可以設定為三種模式:領導者-追蹤者、領導者和迴圈。
HBase 複寫:領導者 – 追蹤者模型
在此跨區域設定中,複寫是從主要區域到次要區域的單向複寫。 主要復寫上的所有數據表或特定數據表都可以識別為單向複寫。 在正常作業期間,次要叢集可用來在自己的區域中提供讀取要求。
次要叢集會以一般 HBase 叢集的形式運作,可裝載自己的數據表,並且可從區域應用程式提供讀取和寫入。 不過,復寫數據表或原生至次要數據表的寫入不會復寫回主要複寫。
HBase 複寫:領導者 – 領導者模型
此跨區域設定與單向設定非常類似,不同之處在於主要區域與次要區域之間雙向進行複寫。 應用程式可以在讀寫模式中使用這兩個叢集,而更新會在兩者之間以異步方式交換。
HBase 複寫:多區域或迴圈
多區域/迴圈復寫模型是 HBase 複寫的延伸模組,可用來建立具有多個應用程式的全域備援 HBase 架構,以讀取和寫入區域特定的 HBase 叢集。 叢集可以根據業務需求,以領導者/領導者或領導者/追蹤程序的各種組合來設定。
Apache Kafka
若要啟用跨區域可用性 HDInsight 4.0 支援 Kafka MirrorMaker,可用來維護不同區域中主要 Kafka 叢集的次要複本。 MirrorMaker 會做為高階取用者產生者配對,從主要叢集中的特定主題取用,併產生至在次要中具有相同名稱的主題。 使用 MirrorMaker 進行高可用性災害復原的跨叢集復寫隨附於生產者和取用者需要故障轉移至複本叢集的假設。 如需詳細資訊,請參閱 使用 MirrorMaker 在 HDInsight 上使用 Kafka 複寫 Apache Kafka 主題
視復寫開始時的主題存留期而定,MirrorMaker 主題複寫可能會導致來源和複本主題之間的不同位移。 HDInsight Kafka 叢集也支援主題分割複寫,這是個別叢集層級的高可用性功能。
Apache Kafka 架構
Kafka 複寫:主動 – 被動
主動-被動設定可啟用從主動到被動的異步單向鏡像。 生產者和取用者必須注意主動和被動叢集的存在,而且必須準備好在主動失敗時故障轉移至被動。 以下是主動-被動設定的一些優點和缺點。
優點:
- 叢集之間的網路等待時間不會影響作用中叢集的效能。
- 單向復寫的簡單性。
缺點:
- 被動叢集可能仍然使用量過低。
- 在應用程式產生者和取用者中納入故障轉移感知的設計複雜度。
- 作用中叢集失敗期間可能發生的數據遺失。
- 主動與被動叢集之間主題之間的最終一致性。
- 容錯回復至主要伺服器可能會導致主題中的訊息不一致。
Kafka 複寫:主動 - 主動
主動-主動設定牽涉到兩個區域分隔的 VNet 對等互連 HDInsight Kafka 叢集與 MirrorMaker 的雙向異步復寫。 在此設計中,主要取用者取用的訊息也會提供給次要取用者使用,反之亦然。 以下是 Active-Active 設定的一些優點和缺點。
優點:
- 由於其重複狀態,故障轉移和容錯回復更容易執行。
缺點:
- 設定、管理和監視比主動-被動更為複雜。
- 必須解決迴圈復寫的問題。
- 雙向復寫會導致較高的區域數據輸出成本。
HDInsight 企業安全性套件
此設定可用來啟用主要和次要中的多使用者功能,以及 Microsoft Entra Domain Services 複本集 ,以確保使用者可以向這兩個叢集進行驗證。 在一般作業期間,必須在次要環境中設定 Ranger 原則,以確保使用者受限於讀取作業。 下列架構說明啟用 ESP 的 Hive Active Primary – 待命次要設定看起來如何。
Ranger 中繼存放區複寫:
Ranger 中繼存放區可用來持續儲存及提供 Ranger 原則,以控制數據授權。 建議您在主要和次要中維護獨立的 Ranger 原則,並以讀取複本的形式維護次要複本。
如果需求是讓 Ranger 原則在主要和次要之間保持同步,請使用 Ranger 匯入/匯出 定期備份 Ranger 原則,並將 Ranger 原則從主要備份匯入次要伺服器。
在主要和次要之間復寫 Ranger 原則可能會導致次要復寫啟用寫入功能,這可能會導致次要復寫造成數據不一致。
下一步
若要深入瞭解本文所討論的專案,請參閱: