本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 常見的擴展挑戰
<a name="common-scaling-challenges"></a>

當資料在初始部署之後增長時，資料湖會經歷幾個階段。如果您未使用可擴展的架構來設計資料湖，您的組織可能會遇到挑戰，並可能因資料湖的成長而不利。

下列各節說明典型資料湖的成長如何造成擴展挑戰。

## 初始資料湖部署
<a name="initial-deployment"></a>

下圖顯示 A 業務線初始部署之後的資料湖架構。

![由業務單位 A 初始部署後的資料湖架構](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/data-lake-for-growth-scale/images/datalakescaling-diagram-1.png)


圖表顯示下列元件：
+ 資料生產者帳戶會收集和處理資料、存放已處理的資料，並準備供取用。
+ 資料生產者帳戶中的資料存放在 [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com//AmazonS3/latest/userguide/Welcome.html) 儲存貯體中，該儲存貯體可以有多個資料層。
+ 您可以使用 AWS 服務進行資料處理 （例如， [AWS Glue](https://docs.aws.amazon.com//glue/latest/dg/what-is-glue.html)和 [Amazon EMR](https://docs.aws.amazon.com//emr/latest/ManagementGuide/emr-what-is-emr.html))。
+ 資料生產者不僅在資料湖中產生和存放資料，還需要決定要與資料取用者共用哪些資料，以及如何共用。除了管理資料生產者與資料取用者之間的跨帳戶資料共用之外， 還 AWS Lake Formation 管理資料生產者帳戶中的資料湖。
+ 資料消費者帳戶會針對特定商業使用案例使用來自資料生產者帳戶的共用資料。

## 資料取用者增加
<a name="data-consumer-growth"></a>

下圖顯示當 A 業務線的資料增長時，將更多資料帶入資料湖。然後，資料湖會吸引更多資料消費者，以利用資料並從中獲取價值。

![當資料湖的資料生產者增長其資料時，資料取用者的數量也會增長。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/data-lake-for-growth-scale/images/datalakescaling-diagram-2.png)


圖表顯示組織如何從現有資料資產產生近乎連續的值，這吸引了更多的資料消費者。不過，當資料消費者增加時，資料生產者只有下列兩個選項來適應此成長：
+ 手動管理個別資料消費者的資料共用和存取，這不是可擴展的方法。
+ 開發用於資料共用和管理資料存取的自動化或半自動化程序。雖然這可能是可擴展的選項，但由於內部和外部資料消費者有不同的安全控制要求，因此需要大量的時間和精力來設計和建置。未來，任何解決方案改進也需要額外的時間和精力。

## 資料生產者增加
<a name="data-producer-growth"></a>

下圖顯示多行業務以資料生產者身分加入時的資料湖架構。

![當多行業務將其加入為資料生產者時，資料湖的架構。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/data-lake-for-growth-scale/images/datalakescaling-diagram-3.png)


資料湖的架構變得越來越複雜，即使只有三個資料生產者和三個資料消費者。

每個資料生產者都需要處理多個資料消費者的資料共用和資料存取管理。期望所有資料生產者為資料共用和資料存取管理開發自動化或半自動化程序是不切實際的。有些資料生產者可能會選擇不共用其資料，因此可避免負擔不起的管理開銷。同樣地，每個資料消費者都需要與多個資料生產者互動，以了解其不同的資料消耗程序。這表示個別資料消費者面臨處理不同資料共用模式的管理開銷增加。

在許多組織中，此資料湖會導致瓶頸，且無法成長或擴展。這可能表示您的組織必須重新設計和重建其資料湖，以消除瓶頸，這可能會耗費大量時間、資源和金錢。