1. Athena 查詢長時間無反應，也不掃描數(shù)據(jù)

Athena是serverless服務，因此會使用公用的資源池，提供不同的使用者所提交的各個查詢一同使用資源。當一個查詢被提交時，Athena系統(tǒng)會估算該查詢需要用到的資源數(shù)量，并向資源池申請資源，成功獲得資源后，會將相關的Stage與Task派發(fā)在這些資源的Presto worker上運行。在這一系列的工作流程中，若資源池的資源較為稀缺時，則從申請資源到成功獲得資源所耗費的時間就會比較長。
通常資源相關的問題，可以借由重試（將完全相同的查詢命令重跑一次）來解決。因為Athena會自動彈性維護資源池，重試操作會發(fā)出新的查詢，重新發(fā)出申請資源的請求，提高申請到底層資源的機率。在大多數(shù)情況下，資源相關的問題都能夠借由重試來解決。
為什么我的 Amazon Athena 查詢運行時間很長

2.elasticache 創(chuàng)建后連接不上

外網(wǎng)是要開傳輸加密后才能連的，先看內(nèi)網(wǎng)連接。
創(chuàng)建時不選傳輸加密內(nèi)網(wǎng)時可以直接連的，不需要特殊設置。
不能連的話，先檢查集群的安全組有沒有對內(nèi)網(wǎng)測試的ec2放開6379的權限，
telnet 測試下主終端節(jié)點通不通。
通的話說明網(wǎng)絡正常，看下開了傳輸加密沒有，開的話要加 --tls 參數(shù)才能連。
連接到集群節(jié)點

3. vpc 內(nèi)無法解析內(nèi)網(wǎng)域名地址

看下你的vpc屬性那里，開了 dns 解析沒有，開了當前 vpc 內(nèi)的地址肯定是可以解析的。
還有種情況是跨 vpc的，開了vpc peering的，一個vpc內(nèi)的機器沒法解析另一端的vpc的內(nèi)網(wǎng)域名地址，
這個需要特殊設置dns的域名解析，具體參考下面的文檔
實現(xiàn)對對等連接的 DNS 解析

4. rds mysql 中的 rdsadmin

在 rds mysql 中查 user 表，能發(fā)現(xiàn)一個用戶叫 rdsadmin，這個是 aws 自己建的，用于管理集群升級備份等操作的。不要去刪除，修改這個用戶和它的權限，會導致集群出錯的。

18f1e835934892f1f74b8dcb11d5590.png

5. GA 詳細日志和監(jiān)控分析

如果想要查 ga 的日志和監(jiān)控信息，比如網(wǎng)絡波動或者用戶連接情況，只能用 aws cli 開 ga 的 flow log 。 之后用 athena 去查。查詢 AWS Global Accelerator 流日志 。

6. glue 表版本的配額限制

glue 中的表在沒修改一次表設置（表結(jié)構，名稱，路徑等）都會生成一個歷史記錄，每個歷史記錄都有一個版本號，是從0開始的自增序列。默認的上限是10萬。雖然看著很多，但是如果你的代碼里有經(jīng)常修改表設置的，還是有可能刷滿配額的，這個時候就不能再修改了。你可以開 case 提升這個配額，不過有上限總會打滿的，可以使用 aws 的接口批量刪除舊的版本。

7. lambda vpc 內(nèi)訪問其他賬號的 S3

有些服務在 vpc 私有子網(wǎng)，為了訪問這些服務，lamda 也要搭在 vpc 內(nèi)，這時 lambda 需要 nat 才能訪問到公網(wǎng)的資源，但是如果訪問的是 aws 的服務的話，可以創(chuàng)建對應服務的終端節(jié)點，讓 lambda 直接在內(nèi)網(wǎng)訪問到這些服務。因此也可以通過終端節(jié)點訪問 s3，不過終端節(jié)點是建在 vpc 上的，你的 vpc 和你的 s3 桶必須在同一 region，否則 lambda 會直接報 time out。
同一 region 下的 s3 其實都是在同一個地方，即使賬號不同。所以建了終端節(jié)點后，內(nèi)網(wǎng)訪問其他賬號的 s3 桶也是可以的。

8. EMR 中 yarn 可調(diào)度的內(nèi)存很少

啟動了2臺 m5.xlarge 的 emr 集群，總的內(nèi)存 32GB，但是在 yarn 的 web 頁面看到總內(nèi)存才12GB。這應該是個bug，根據(jù)文檔，單臺 m5.xlarge 的 yarn 可用內(nèi)存應該是 12GB 多點。試了其他機型，都是和文檔相符的。不過這個參數(shù)也可以在控制臺修改，調(diào)整到文檔給出的值就好。
yarn.nodemanager.resource.memory-mb
yarn.scheduler.maximum-allocation-mb
任務配置 - Amazon EMR

9. 報權限錯誤時帶了一串編碼的字符串

有時遇到一些權限上的錯誤，控制臺上或者 cli 會報出如下的錯誤，后面還跟了很長的編碼后的字符串，這個的意思是權限錯誤的具體信息被加密了，想要得到原信息必須用報出這個錯的賬號去執(zhí)行 decode-authorization-message 這個命令去解密。注意：執(zhí)行這個命令也需要單獨的權限，請先確保你有sts服務下的這個權限，再去執(zhí)行解密命令。
Service role test-emr-role has insufficient EC2 permissions. EC2 Message: AmazonEC2Exception: You are not authorized to perform this operation. Encoded authorization failure message
Amazon EC2 中 RunInstances 的編碼授權失敗

10. EMR 擴充 core 節(jié)點的磁盤空間

emr 中 yarn 的日志默認是保存在 hdfs 上的，保存期限是2天，物理位置是在 core 節(jié)點上。100G的節(jié)點實際只有30G左右可以用來存日志，3臺 master 的話就是100G。如果你的日志刷的過快，把hdfs寫滿了，程序就會報錯，這時要么調(diào)節(jié)日志保留期，要么擴core節(jié)點的存儲空間。
擴充存儲空間需要在ec2頁面操作，EMR是沒有直接修改磁盤的設置的，就把core節(jié)點當作一個普通的ec2實例，找到對應的ebs磁盤，然后調(diào)整大小，再到實例里面擴容就好了。
需要注意的是，core有兩個硬盤設備