1. 無線網卡高級配置裡面的，這個是什麼意思，每一個的意思是
1、802.11b preamble:是802.11b幀的前導域，用於設備之間的數據同步。
2、Adhoc 11n：Adhoc是一種不依賴與基礎設備而組網的一種技術，節點與節點之間互相承擔路由轉發和廣播等功能。
3、Dynamic MIMO power save：動態電源調節技術。
4、network address:就是網卡的MAC地址，默認為空，可以修改為其他的MAC地址。
5、receive buffers:網卡最大可用的接收緩存。
6、scan valid interval:掃描間隔，保持默認即可。
7、transmit buffers:網卡最大可用的發送緩存。
2. Ipa 安裝失敗問題排查
啟動應用時，出現提示「未受信任的企業級開發者」
請回到 iOS 系統桌面，然後依次打開 設置 - 通用 - 描述文件與設備管理，然後，點擊對應描述文件進入後，再點擊按鈕 信任即可。具體解決辦法請見： 運行企業版應用
應用安裝快結束後，圖標變為暗色圖標，或彈出」無法安裝XXX「的提示
如果您是該應用的開發者，請檢查應用的簽名是否正確，這個問題出現的原因一般是由於應用的簽名不正確導致的。一般來說，對於 Adhoc 簽名方式重點檢查當前設備 UDID 是否已經注冊；對於 In-house 簽名(即企業簽名) 方式來說，需要重點檢查證書是否被撤銷。如果您不是這個應用的開發者，請聯系開發者解決。
在網頁中點擊「安裝」按鈕後，沒有彈出「是否安裝」的提示，或者提示安裝失敗
這個問題出現的原因，一般是由於用戶已經從蘋果官方 App Store 上安裝了相同的應用。解決辦法是：先在您的設備中刪除之前已經安裝的應用，然後再從蒲公英安裝即可。
安裝應用時，出現提示「無法連接到 www.pgyer.com 」
這個問題一般是由於用戶的網路，或者手機緩存錯誤造成的，可以嘗試如下兩個方法來解決：
重啟手機，然後嘗試重新安裝。
換一個網路環境，例如換一個 Wi-Fi 熱點，或由 Wi-Fi 換成 3G/4G 等，然後重新安裝。
其他一些可能導致應用無法安裝的原因：
原因一：開發者在打包App時，導出 iOS App 的安裝包文件（.ipa文件）時，選擇了 App-Store 方式。
在導出 iOS 的 .ipa 文件時，有些開發者選擇了 App-Store 方式，這種方式導出的 .ipa 文件，只適合於上傳到蘋果 App Store，並不能通過蒲公英來安裝。如果是這種方式導出的 .ipa文件，傳到蒲公英上時，蒲公英會顯示「App-Store版」，這種版本是不能通過蒲公英安裝的。
原因二：在導出 iOS App 的安裝包文件（.ipa文件）時，選擇了 Ad-hoc 方式，但是沒有添加設備 UDID。
在導出 iOS 的安裝包文件時，如果選擇了 Ad-hoc 方式（一般用於蘋果個人開發者賬戶），那麼，如果要某台設備可以安裝，則必須要將這台設備的 UDID 添加到導出安裝包時所用的證書文件中（. mobileprovision文件），才可以在這台設備上安裝。
使用 Ad-hoc 方式導出的安裝包文件上傳到蒲公英後，蒲公英會顯示為「內測版」，同時會在應用管理中，顯示出該安裝包的證書中包含的 UDID 列表。開發者可以根據顯示出的 UDID 列表，來排查某台設備的 UDID 有沒有被添加到安裝包的證書中。
原因三：在導出 iOS App 的安裝包文件（.ipa文件）時，選擇了 In-house 方式，但是證書已過期或被撤銷。
在導出 iOS 的安裝包文件時，如果選擇了 In-house 方式（一般用於蘋果企業開發者賬戶），此時，如果出現無法安裝的情況，開發者可以檢查一下自己的企業開發者證書是否已過期或是否被撤銷。因為蘋果對於企業開發者證書管理較為嚴格，所以開發者如果使用不當，可能會導致企業證書被蘋果官方撤銷，被撤銷後的企業證書導出的安裝包，也是無法正確安裝的。
原因四：開發者在生成App安裝包時，沒有在 Xcode 中設置正確的 Architecture。
iOS 應用的 Architecture（架構），決定了這款 iOS 應用可以在哪些設備機型上安裝。例如，如果某個應用在 Xcode 中只添加了 arm64 這一種 Architecture，那麼最終打包後的安裝包文件上傳到蒲公英後，對於 iPad mini、iPhone5 等以下設備，都是無法安裝的（因為這些設備都不是 arm64 架構）。換句話說，如果需要在某個設備上可以安裝，App 就必須支持那個設備的 Architecture。
所以，正確的解決方法是，在生成 App 安裝包時，盡可能讓 App 支持更多的 Architecture。
具體操作方法是：在 Xcode - Build Settings - Architecture 中，增加 armv7、armv7s、arm64，以便所有設備都可以安裝。然後，將 "Build active architecture only" 設置為 NO。對於各個 iOS 設備支持的 Architecture 類型。 請點擊這里查看 。
原因五：App 支持的 iOS 系統版本，和當前設備系統版本不符。
App 支持的 iOS 系統版本過低或者過高，都可能導致 App 無法安裝成功。例如，如果某個 App 設置了只支持 iOS 11.0 以上的系統時，那麼，如果在低於這個版本的系統上安裝時，是無法安裝成功的。
因此，解決的方法也很簡單，我們應該盡量讓 App 盡可能支持更寬泛的系統版本。
具體操作方式是：在 Xcode - General - Deployment Info - Deployment Target 中，給 App 設置一個盡量低的版本，例如 iOS 6.0。
原因六：設備上已經安裝了這個App，且已經安裝的 App 和要安裝的 App 是用不同證書打包的。
這種情況下，也會造成 App 安裝失敗。解決的方式很簡單，用戶只需將設備上原來已經安裝的 App 刪除，再重新安裝新的 App 即可。
原因七：Info.plist 文件中的LSRequiresIPhoneOS 沒有設置，或者設置了 NO。
對於 iOS 的 App 來說，如果Info.plist 文件中的LSRequiresIPhoneOS 沒有設置，或者設置了 NO，那麼由 Xcode 導出的安裝包（.ipa 包），就不會包含 Payload 文件夾，而是被一個叫做 Applications 的文件夾代替。這樣的安裝包在安裝時，會被 iOS 判定為無效的安裝包，所以無法被正確安裝。
解決方式也很簡單，只需要將Info.plist 文件中的LSRequiresIPhoneOS 設置為 YES，然後重新打包即可。具體操作為：在 Xcode 中打開 Info.plist 文件，然後檢查 LSRequiresIPhoneOS 是否已設置，如果沒有設置，就添加一個，然後將 LSRequiresIPhoneOS 的類型設置為 Boolean，值設置為 YES。
設置好以後，可以看到 Info.plist 文件中顯示 Application requires iPhone environment 的值為 YES。
另外，還可以使用蒲公英的 Mac OS 客戶端 來打包上傳 App，蒲公英的 Mac OS 客戶端在打包安裝包時，自動處理了這個問題。
原因八：網路出現中斷或異常。
遇到這種情況，用戶可檢查自己手機的所連接的網路是否穩定、速度是否正常等。能否打開其他網站，或者更換一個 Wi-Fi，或者由 Wi-Fi 換成 3G/4G 等，然後重新安裝。
用這樣的方式嘗試後，一般都可以解決問題。
嘗試過以上方案，還是無法解決？
如果根據以上的方式進行排查後，依然無法解決問題，那麼可以使用蒲公英的 Mac OS 客戶端來查看安裝日誌。
蒲公英的 Mac OS 客戶端中，提供了實時查看 App 安裝日誌的功能，開發者可以方便的根據 App 的安裝日誌，來准確的判斷具體安裝失敗的原因，具體方法請見： 查看iOS的安裝日誌
來源於 鏈接：https://www.jianshu.com/p/73e77ff62f48
參考文檔： https://www.jianshu.com/p/128ceffcb399
3. 技術干貨：SQL on Hadoop在快手大數據平台的實踐與優化
快手大數據架構工程師鍾靚近日在 A2M 人工智慧與機器學習創新峰會分享了題為《SQL on Hadoop 在快手大數據平台的實踐與優化》的演講，主要從 SQL on Hadoop 介紹、快手 SQL on Hadoop 平台概述、SQL on Hadoop 在快手的使用經驗和改進分析、快手 SQL on Hadoop 的未來計劃四方面介紹了 SQL on Hadoop 架構。
SQL on Hadoop，顧名思義它是基於 Hadoop 生態的一個 SQL 引擎架構，我們其實常常聽到 Hive、SparkSQL、Presto、Impala 架構。接下來，我會簡單的描述一下常用的架構情況。
HIVE，一個數據倉庫系統。它將數據結構映射到存儲的數據中，通過 SQL 對大規模的分布式存儲數據進行讀、寫、管理。
根據定義的數據模式，以及輸出 Storage，它會對輸入的 SQL 經過編譯、優化，生成對應引擎的任務，然後調度執行生成的任務。
HIVE 當前支持的引擎類型有：MR、SPARK、TEZ。
基於 HIVE 本身的架構，還有一些額外的服務提供方式，比如 HiveServer2 與 MetaStoreServer 都是 Thrift 架構。
此外，HiveServer2 提供遠程客戶端提交 SQL 任務的功能，MetaStoreServer 則提供遠程客戶端操作元數據的功能。
Spark，一個快速、易用，以 DAG 作為執行模式的大規模數據處理的統一分析引擎，主要模塊分為 SQL 引擎、流式處理 、機器學習、圖處理。
SPARKSQL 基於 SPARK 的計算引擎，做到了統一數據訪問，集成 Hive，支持標准 JDBC 連接。SPARKSQL 常用於數據交互分析的場景。
SPARKSQL 的主要執行邏輯，首先是將 SQL 解析為語法樹，然後語義分析生成邏輯執行計劃，接著與元數據交互，進行邏輯執行計劃的優化，最後，將邏輯執行翻譯為物理執行計劃，即 RDD lineage，並執行任務。
PRESTO，一個互動式分析查詢的開源分布式 SQL 查詢引擎。
因為基於內存計算，PRESTO 的計算性能大於有大量 IO 操作的 MR 和 SPARK 引擎。它有易於彈性擴展，支持可插拔連接的特點。
業內的使用案例很多，包括 FaceBook、AirBnb、美團等都有大規模的使用。
我們看到這么多的 SQL on Hadoop 架構，它側面地說明了這種架構比較實用且成熟。利用 SQL on Hadoop 架構，我們可以實現支持海量數據處理的需求。
查詢平台每日 SQL 總量在 70 萬左右，DQL 的總量在 18 萬左右。AdHoc 集群主要用於交互分析及機器查詢，DQL 平均耗時為 300s；AdHoc 在內部有 Loacl 任務及加速引擎應用，所以查詢要求耗時較低。
ETL 集群主要用於 ETL 處理以及報表的生成。DQL 平均耗時為 1000s，DQL P50 耗時為 100s，DQL P90 耗時為 4000s，除上述兩大集群外，其它小的集群主要用於提供給單獨的業務來使用。
服務層是對上層進行應用的。在上層有四個模塊，這其中包括同步服務、ETL 平台、AdHoc 平台以及用戶程序。在調度上層，同樣也有四方面的數據，例如服務端日誌，對它進行處理後，它會直接接入到 HDFS 里，我們後續會再對它進行清洗處理；服務打點的數據以及資料庫信息，則會通過同步服務入到對應的數據源里，且我們會將元數據信息存在後端元數據系統中。
網頁爬取的數據會存入 hbase，後續也會進行清洗與處理。
HUE、NoteBook 主要提供的是互動式查詢的系統。報表系統、BI 系統主要是 ETL 處理以及常見的報表生成，額外的元數據系統是對外進行服務的。快手現在的引擎支持 MR、Presto 及 Spark。
管理系統主要用於管理我們當前的集群。HiveServer2 集群路由系統，主要用於引擎的選擇。監控系統以及運維系統，主要是對於 HiveServer2 引擎進行運維。
我們在使用 HiveServer2 過程中，遇到過很多問題。接下來，我會詳細的為大家闡述快手是如何進行優化及實踐的。
當前有多個 HiveServer2 集群，分別是 AdHoc 與 ETL 兩大集群，以及其他小集群。不同集群有對應的連接 ZK，客戶端可通過 ZK 連接 HiveServer2 集群。
為了保證核心任務的穩定性，將 ETL 集群進行了分級，分為核心集群和一般集群。在客戶端連接 HS2 的時候，我們會對任務優先順序判定，高優先順序的任務會被路由到核心集群，低優先順序的任務會被路由到一般集群。
BeaconServer 服務為後端 Hook Server 服務，配合 HS2 中的 Hook，在 HS2 服務之外實現了所需的功能。當前支持的模塊包括路由、審計、SQL 重寫、任務控制、錯誤分析、優化建議等。
•無狀態，BeaconServer 服務支持水平擴展。基於請求量的大小，可彈性調整服務的規模。
•配置動態載入，BeaconServer 服務支持動態配置載入。各個模塊支持開關，服務可動態載入配置實現上下線。比如路由模塊，可根據後端加速引擎集群資源情況，進行路由比率調整甚至熔斷。
•無縫升級，BeaconServer 服務的後端模塊可單獨進行下線升級操作，不會影響 Hook 端 HS2 服務。
•Hive 支持 SPARK 與 TEZ 引擎，但不適用於生產環境。
•SQL on Hadoop 的 SQL 引擎各有優缺點，用戶學習和使用的門檻較高。
•不同 SQL 引擎之間的語法和功能支持上存在差異，需要大量的測試和兼容工作，完全兼容的成本較高。
•不同 SQL 引擎各自提供服務會給數倉的血緣管理、許可權控制、運維管理、資源利用都帶來不便。
•在 Hive 中，自定義實現引擎。
•自動路由功能，不需要設置引擎，自動選擇適合的加速引擎。
•根絕規則匹配 SQL，只將兼容的 SQL 推給加速引擎。
•復用 HiveServer2 集群架構。
基於 HiveServer2，有兩種實現方式。JDBC 方式是通過 JDBC 介面，將 SQL 發送至後端加速引擎啟動的集群上。PROXY 方式是將 SQL 下推給本地的加速引擎啟動的 Client。
JDBC 方式啟動的後端集群，均是基於 YARN，可以實現資源的分時復用。比如 AdHoc 集群的資源在夜間會自動回收，作為報表系統的資源進行復用。
路由方案基於 HS2 的 Hook 架構，在 HS2 端實現對應 Hook，用於引擎切換；後端 BeaconServer 服務中實現路由 服務，用於 SQL 的路由規則的匹配處理。不同集群可配置不同的路由規則。
為了保證後算路由服務的穩定性，團隊還設計了 Rewrite Hook，用於重寫 AdHoc 集群中的 SQL，自動添加 LIMIT 上限，防止大數據量的 SCAN。
•易於集成，當前主流的 SQL 引擎都可以方便的實現 JDBC 與 PROXY 方式。再通過配置，能簡單的集成新的查詢引擎，比如 impala、drill 等。
•自動選擇引擎，減少了用戶的引擎使用成本，同時也讓遷移變得更簡單。並且在加速引擎過載 的情況下，可以動態調整比例，防止因過載 對加速性能的影響。
•自動降級，保證了運行的可靠性。SQL 路由支持 failback 模塊，可以根據配置選擇是否再路由引擎執行失敗後，回滾到 MR 運行。
•模塊復用，對於新增的引擎，都可以復用 HiveServer2 定製的血緣採集、許可權認證、並發鎖控制等方案，大大降低了使用成本。
•資源復用，對於 adhoc 查詢佔用資源可以分時動態調整，有效保證集群資源的利用率。
當查詢完成後，本地會輪詢結果文件，一直獲取到 LIMIT 大小，然後返回。這種情況下，當有大量的小文件存在，而大文件在後端的時候，會導致 Bad Case，不停與 HDFS 交互，獲取文件信息以及文件數據，大大拉長運行時間。
在 Fetch 之前，對結果文件的大小進行預排序，可以有數百倍的性能提升。
示例：當前有 200 個文件。199 個小文件一條記錄 a，1 個大文件混合記錄 a 與 test 共 200 條，大文件名 index 在小文件之後。
Hive 中有一個 SimpleFetchOptimizer 優化器，會直接生成 FetchTask，減小資源申請時間與調度時間。但這個優化會出現瓶頸。如果數據量小，但是文件數多，需要返回的條數多，存在能大量篩掉結果數據的 Filter 條件。這時候串列讀取輸入文件，導致查詢延遲大，反而沒起到加速效果。
在 SimpleFetchOptimizer 優化器中，新增文件數的判斷條件，最後將任務提交到集群環境，通過提高並發來實現加速。
示例：讀取當前 500 個文件的分區。優化後的文件數閾值為 100。
一個表有大量的子分區，它的 DESC 過程會與元數據交互，獲取所有的分區。但最後返回的結果，只有跟表相關的信息。
與元數據交互的時候，延遲了整個 DESC 的查詢，當元數據壓力大的時候甚至無法返回結果。
針對於 TABLE 的 DESC 過程，直接去掉了跟元數據交互獲取分區的過程，加速時間跟子分區數量成正比。
示例：desc 十萬分區的大表。
•復用 split 計算的數據，跳過 rece 估算重復統計輸入過程。輸入數據量大的任務，調度速率提升 50%。
•parquetSerde init 加速，跳過同一表的重復列剪枝優化，防止 map task op init 時間超時。
•新增 LazyOutputFormat，有 record 輸出再創建文件，避免空文件的產生，導致下游讀取大量空文件消耗時間。
•statsTask 支持多線程聚合統計信息，防止中間文件過多導致聚合過慢，增大運行時間。
•AdHoc 需要打開並行編譯，防止 SQL 串列編譯導致整體延遲時間增大的問題。
HS2 啟動時會對物化視圖功能進行初始化，輪詢整個元資料庫，導致 HS2 的啟動時間非常長，從下線狀態到重新上線間隔過大，可用性很差。
將物化視圖功能修改為延遲懶載入，單獨線程載入，不影響 HS2 的服務啟動。物化視圖支持載入中獲取已緩存信息，保證功能的可用性。
HS2 啟動時間從 5min+提升至<5s。
HS2 本身上下線成本較高，需要保證服務上的任務全部執行完成才能進行操作。配置的修改可作為較高頻率的操作，且需要做到熱載入。
在 HS2 的 ThriftServer 層我們增加了介面，與運維系統打通後，配置下推更新的時候自動調用，可實現配置的熱載入生效。
HiveServer2 的 scratchdir 主要用於運行過程中的臨時文件存儲。當 HS2 中的會話創建時，便會創建 scratchdir。在 HDFS 壓力大的時候，大量的會話會阻塞在創建 scratchdir 過程，導致連接數堆積至上限，最終 HS2 服務無法再連入新連接，影響服務可用性。
對此，我們先分離了一般查詢與 create temporay table 查詢的 scratch 目錄，並支持 create temporay table 查詢的 scratch 的懶創建。當 create temporay table 大量創建臨時文件，便會影響 HDFS NameNode 延遲時間的時候，一般查詢的 scratchdir HDFS NameNode 可以正常響應。
此外，HS2 還支持配置多 scratch，不同的 scratch 能設置載入比率，從而實現 HDFS 的均衡負載。
Hive 調度其中存在兩個問題。
一、子 Task 非執行狀態為完成情況的時候，若有多輪父 Task 包含子 Task，導致子 Task 被重復加入調度隊列。這種 Case，需要將非執行狀態修改成初始化狀態。
二、當判斷子 Task 是否可執行的過程中，會因為狀態檢測異常，無法正常加入需要調度的子 Task，從而致使查詢丟失 Stage。而這種 Case，我們的做法是在執行完成後，加入一輪 Stage 的執行結果狀態檢查，一旦發現有下游 Stage 沒有完成，直接拋出錯誤，實現查詢結果狀態的完備性檢查。
•HS2 實現了介面終止查詢 SQL。利用這個功能，可以及時終止異常 SQL。
•metastore JDOQuery 查詢優化，關鍵字異常跳過，防止元數據長時間卡頓或者部分異常查詢影響元數據。
•增加開關控制，強制覆蓋外表目錄，解決 insert overwrite 外表，文件 rename 報錯的問題。
•hive parquet 下推增加關閉配置，避免 parquet 異常地下推 OR 條件，導致結果不正確。
•executeForArray 函數 join 超大字元串導致 OOM，增加限制優化。
•增加根據 table 的 schema 讀取分區數據的功能，避免未級聯修改分區 schema 導致讀取數據異常。
•部分用戶並沒有開發經驗，無法處理處理引擎返回的報錯。
•有些錯誤的報錯信息不明確，用戶無法正確了解錯誤原因。
•失敗的任務排查成本高，需要對 Hadoop 整套系統非常熟悉。
•用戶的錯誤 SQL、以及需要優化的 SQL，大量具有共通性。人力維護成本高，但系統分析成本低。
SQL 專家系統基於 HS2 的 Hook 架構，在 BeaconServer 後端實現了三個主要的模塊，分別是 SQL 規則控制模塊、SQL 錯誤分析模塊，與 SQL 優化建議模塊。SQL 專家系統的知識庫，包含關鍵字、原因說明、處理方案等幾項主要信息，存於後端資料庫中，並一直積累。
通過 SQL 專家系統，後端可以進行查詢 SQL 的異常控制，避免異常 SQL 的資源浪費或者影響集群穩定。用戶在遇到問題時，能直接獲取問題的處理方案，減少了使用成本。
示例：空分區查詢控制。
SQL 專家系統能解決一部分 HS2 的任務執行的錯誤診斷需求，但是比如作業 健康 度、任務執行異常等問題原因的判斷，需要專門的系統來解決，為此我們設計了作業診斷系統。
作業診斷系統在 YARN 的層面，針對不同的執行引擎，對搜集的 Counter 和配置進行分析。在執行層面，提出相關的優化建議。
作業診斷系統的數據也能通過 API 提供給 SQL 專家系統，補充用於分析的問題原因。
作業診斷系統提供了查詢頁面來查詢運行的任務。以下是命中 map 輸入過多規則的任務查詢過程：