我們生活在一個奇妙的時代，你可以快速、輕鬆地連接幾個現成的開源工具，根據 stackoverflow 的建議在“意識關閉”的情況下設置它們，而無需深入研究“多個字母”，然後啟動將其投入商業營運。 當你需要更新/擴展或有人不小心重啟了幾台機器時 - 你意識到某種強迫性的噩夢已經開始，一切都變得非常複雜得面目全非，沒有回頭路，未來是模糊的和更安全的，不用編程，而是飼養蜜蜂和製作乳酪。
那些更有經驗的同事們，腦子裡佈滿了錯誤，因此已經灰白了，考慮以令人難以置信的速度在數十台服務器上以“流行語言”內置支持的“立方體”中部署“容器”包，這並非沒有道理。異步非阻塞I/O，謙虛一笑。 他們默默地繼續重新閱讀“man ps”，鑽研“nginx”原始程式碼直到眼睛流血，並寫，寫，寫單元測試。 同事們知道，當「這一切」有一天在除夕之夜被押注時，最有趣的事情就會到來。 只有深入了解 UNIX 的本質、記憶的 TCP/IP 狀態表和基本的排序搜尋演算法，才會對他們有所幫助。 當鐘聲響起時，讓系統恢復生機。
哦，是的，我有點心煩意亂，但我希望我能傳達出期待的狀態。
今天我想分享我們為DataLake部署方便且便宜的堆疊的經驗，該堆疊解決了公司中完全不同結構部門的大部分分析任務。
不久前，我們意識到，公司越來越需要產品和技術分析的成果（更不用說機器學習形式的錦上添花），並了解趨勢和風險——我們需要收集和分析越來越多的指標。
Bitrix24 中的基本技術分析
幾年前，在推出 Bitrix24 服務的同時，我們積極投入時間和資源來創建一個簡單可靠的分析平台，有助於快速發現基礎設施中的問題並規劃下一步。 當然，建議使用盡可能簡單易懂的現成工具。 因此，選擇 nagios 進行監控，選擇 munin 進行分析和視覺化。 現在，我們在 nagios 中有數千個檢查，在 munin 中有數百個圖表，我們的同事每天都成功地使用它們。 指標清晰，圖表清晰，系統已經可靠運行了好幾年，並且定期添加新的測試和圖表：當我們將新服務投入運行時，我們會添加多個測試和圖表。 祝你好運。
掌握脈搏 - 高級技術分析
「盡快」接收有關問題的資訊的願望促使我們使用簡單易懂的工具 - pinba 和 xhprof 進行積極的實驗。
Pinba 透過 UDP 資料包向我們發送有關 PHP 部分網頁運行速度的統計數據，我們可以在 MySQL 存儲中在線查看（Pinba 自帶 MySQL 引擎，用於快速事件分析）問題的簡短列表並做出響應他們。 xhprof 自動允許我們從客戶端收集最慢 PHP 頁面的執行圖表，並分析可能導致這種情況的原因 - 冷靜地倒茶或喝更烈性的東西。
前段時間，該工具包補充了另一個基於反向索引演算法的相當簡單易懂的引擎，完美實現在傳奇的 Lucene 庫 - Elastic/Kibana 中。 根據日誌中的事件將文件多執行緒記錄到逆 Lucene 索引中，並使用分面劃分快速搜尋它們，這個簡單想法非常有用。
儘管 Kibana 中的可視化具有相當技術性的外觀，具有“桶”“向上流動”等低級概念以及尚未完全遺忘的關係代數的重新發明語言，但該工具開始幫助我們很好地完成以下任務：
- 在過去一小時內，Bitrix24 用戶端在 p1 入口網站上出現了多少個 PHP 錯誤？哪些錯誤？ 理解、原諒並迅速改正。
- 過去 24 小時內，德國入口網站上進行了多少次視訊通話，通話品質如何，頻道/網路是否有任何問題？
- 從最新服務更新中的原始程式碼編譯並推廣到客戶端的系統功能（我們的 PHP C 擴充功能）的工作效果如何？ 是否存在段錯誤？
- 客戶資料是否適合 PHP 記憶體？ 是否有任何關於超出分配給進程的記憶體的錯誤：「記憶體不足」？ 找到並消除。
這是一個具體的例子。 儘管進行了徹底和多層次的測試，客戶在非常不標準的情況下並且輸入資料被損壞，收到了一個惱人且意想不到的錯誤，警報響起，快速修復它的過程開始了：
此外，kibana 允許您組織特定事件的通知，並且在很短的時間內，公司中的該工具開始被來自不同部門的數十名員工使用 - 從技術支援和開發到 QA。
公司內任何部門的活動都變得方便追蹤和衡量——無需在伺服器上手動分析日誌，只需設定一次解析日誌並將其發送到彈性集群即可享受，例如在 kibana 中思考儀表板顯示上一個農曆月份3D 列印機列印的已售出雙頭小貓的數量。
基本業務分析
每個人都知道，公司的業務分析通常始於極度積極地使用 Excel。 但最主要的是事情並沒有就此結束。 基於雲端的 Google Analytics 也火上澆油——您很快就會開始習慣這些好東西。
在我們和諧發展的公司裡，到處都出現了利用更大數據進行更密集工作的「先知」。 對更深入和多方面的報告的需求開始定期出現，透過不同部門的人的努力，前段時間組織了一個簡單實用的解決方案 - ClickHouse 和 PowerBI 的結合。
在很長一段時間裡，這個靈活的解決方案很有幫助，但漸漸地人們開始意識到 ClickHouse 不是橡膠，不能被這樣嘲笑。
在這裡，重要的是要充分理解ClickHouse，就像Druid、Vertica、Amazon RedShift（基於postgres）一樣，都是針對相當方便的分析（求和、聚合、按列的最小-最大以及一些可能的連接）進行優化的分析引擎。 ）， 因為與我們所知的 MySQL 和其他（面向行）資料庫不同，它是為了有效儲存關係表的資料列而組織的。
從本質上講，ClickHouse只是一個更容量的“資料庫”，沒有非常方便的逐點插入（這就是它的意圖，一切都好），但令人愉快的分析和一組有趣的強大的數據處理功能。 是的，您甚至可以創建一個集群 - 但您知道用顯微鏡敲釘子並不完全正確，我們開始尋找其他解決方案。
對Python和分析師的需求
我們公司有許多開發人員，幾乎每天都在 10-20 年裡編寫 PHP、JavaScript、C#、C/C++、Java、Go、Rust、Python、Bash 程式碼。 還有許多經驗豐富的系統管理員經歷過不只一場絕對令人難以置信的災難，這些災難不符合統計規律（例如，當 raid-10 中的大多數磁碟被強烈雷擊摧毀時）。 在這樣的情況下，很長一段時間人們並不清楚什麼是「Python分析師」。 Python 與 PHP 類似，只是名稱更長一些，解釋器原始碼中的改變思想的物質的痕跡更少一些。 然而，隨著越來越多的分析報告的創建，經驗豐富的開發人員開始越來越多地理解 numpy、pandas、matplotlib、seaborn 等工具的狹隘專業化的重要性。
最有可能的決定性作用是員工突然暈倒，因為「邏輯回歸」這個詞與使用pyspark對大數據進行有效報告的演示相結合。
Apache Spark 的功能範式與關係代數完美契合，其功能給習慣使用 MySQL 的開發人員留下了深刻的印象，因此加強經驗豐富的分析師團隊的必要性變得顯而易見。
Apache Spark/Hadoop 的進一步嘗試取得成功，但進展並不順利
然而，很快我們就發現 Spark 在系統上有些問題，或者只是需要更好地洗手。 如果說Hadoop/MapReduce/Lucene 堆疊是由相當有經驗的程式設計師編寫的（如果你仔細觀察Java 的原始程式碼或Doug Cutting 在Lucene 中的想法，這一點是顯而易見的），那麼Spark 突然是用外來語言Scala 編寫的，它是從實用性角度來看非常有爭議，目前尚未開發。 由於reduce操作的記憶體分配不合邏輯且不太透明（許多鍵同時到達），Spark叢集上的計算量經常下降，這在它周圍創造了一個有增長空間的光環。 此外，大量奇怪的開放端口、生長在最難以理解的地方的臨時文件以及地獄般的jar 依賴關係讓情況變得更加嚴重——這讓系統管理員產生了一種從小就眾所周知的感覺：強烈的仇恨（或可能是強烈的仇恨）。他們需要用肥皂洗手）。
因此，我們「倖存」了幾個積極使用 Apache Spark（包括 Spark Streaming、Spark SQL）和 Hadoop 生態系統（等等）的內部分析專案。 儘管隨著時間的推移，我們學會瞭如何很好地準備和監控“它”，並且由於數據性質的變化和統一RDD 哈希的不平衡，“它”實際上停止了突然崩潰，但想要獲取已經準備好的東西的願望在雲端的某個地方進行更新和管理變得越來越強大。 正是在這個時候，我們嘗試使用Amazon Web Services現成的雲端元件— 隨後，嘗試使用它解決問題。 EMR 是由 Amazon 準備的 Apache Spark，以及來自生態系統的其他軟體，就像 Cloudera/Hortonworks 所建構的那樣。
用於分析的橡膠文件存儲是迫切需要的
把Hadoop/Spark「煮」到身體各部位燒傷的經驗並沒有白費。 創建單一、廉價且可靠的文件存儲的需求越來越大，該文件存儲能夠抵抗硬體故障，並且可以存儲來自不同系統的不同格式的文件，並為來自該數據的報告製作高效且省時的樣本。清除。
我還希望更新這個平台的軟體不會變成使用 Spark History Server 和背光放大鏡讀取 20 頁 Java 追蹤並分析長達一公里的叢集詳細日誌的新年噩夢。 我想要一個簡單而透明的工具，如果由於來源資料分區演算法選擇不當而導致減少資料工作線程記憶體不足，開發人員的標準 MapReduce 請求停止執行，則不需要定期深入了解該工具。
Amazon S3 是 DataLake 的候選人嗎？
Hadoop/MapReduce 的經驗告訴我們，我們需要一個可擴展、可靠的檔案系統和其上的可擴展工作線程，「靠近」數據，以免透過網路驅動數據。 工作人員應該能夠讀取不同格式的數據，但最好不要讀取不必要的信息，並能夠以方便工作人員的格式提前儲存數據。
再次，基本思想。 沒有必要將大數據「倒入」單一集群分析引擎中，這遲早會窒息，您將不得不對其進行醜陋的分片。 我想以可理解的格式儲存文件，只是文件，並使用不同但可理解的工具對它們執行有效的分析查詢。 並且將會有越來越多的不同格式的文件。 最好不要對引擎進行分片，而是對來源資料進行分片。 我們需要一個可擴展且通用的 DataLake，我們決定...
如果您將文件儲存在熟悉且眾所周知的可擴展雲端儲存 Amazon S3 中，而無需從 Hadoop 準備自己的文件，會怎麼樣？
很明顯，個人資料是“低”的，但是如果我們把它拿出來並“有效地驅動它”，那麼其他資料呢？
Amazon Web Services 的大數據分析生態系統 - 簡而言之
根據我們使用 AWS 的經驗來看，Apache Hadoop/MapReduce 已經在各種用途下活躍使用了很長一段時間，例如在 DataPipeline 服務中（我羨慕我的同事，他們學會瞭如何正確準備它）。 在這裡，我們設定來自 DynamoDB 表的不同服務的備份：
多年來，它們一直在嵌入式 Hadoop/MapReduce 叢集上正常運作。 「設定好後就忘記它」：
您還可以透過在雲端中為分析師設定 Jupiter 筆記型電腦並使用 AWS SageMaker 服務來訓練和部署 AI 模型來投入戰鬥，從而有效地參與資料撒旦主義。 這對我們來說是這樣的：
是的，您可以為自己或雲端中的分析師挑選一台筆記型電腦，並將其連接到 Hadoop/Spark 集群，進行計算，然後確定一切：
對於單一分析項目來說確實很方便，對於某些項目，我們已經成功使用 EMR 服務進行大規模計算和分析。 DataLake 的系統解決方案怎麼樣，它會運作嗎？ 此時我們在希望與絕望的邊緣繼續尋找。
AWS Glue - 整齊打包的 Apache Spark
事實證明，AWS 有自己的「Hive/Pig/Spark」堆疊版本。 Hive的作用，即DataLake 中的檔案及其類型的目錄由「資料目錄」服務執行，該服務並沒有隱藏其與 Apache Hive 格式的兼容性。 您需要向此服務新增有關文件所在位置及其格式的資訊。 資料不僅可以在s3中，還可以在資料庫中，但這不是本文的主題。 以下是我們的 DataLake 資料目錄的組織方式：
文件已註冊，太好了。 如果文件已更新，我們會手動或按計劃啟動爬蟲，這將從湖中更新有關它們的資訊並保存它們。 然後可以處理來自湖泊的數據並將結果上傳到某個地方。 在最簡單的情況下，我們也上傳到 s3。 資料處理可以在任何地方完成，但建議您透過 AWS Glue API 使用進階功能在 Apache Spark 叢集上配置處理。 事實上，您可以使用pyspark 庫來取得舊的、熟悉的python 程式碼，並在具有一定容量的叢集的N 個節點上配置其執行並進行監控，而無需深入Hadoop 的內部，拖曳docker-moker 容器並消除依賴衝突。
再一次，一個簡單的想法。 無需配置 Apache Spark，只需為 pyspark 編寫 python 程式碼，在桌面上本地測試，然後在雲端的大型叢集上運行，指定來源資料在哪裡以及將結果放在哪裡。 有時這是必要且有用的，我們的設定方式如下：
因此，如果您需要使用 s3 中的資料在 Spark 叢集上進行計算，我們可以在 python/pyspark 中編寫程式碼，對其進行測試，祝雲端好運。
編排方面又如何呢？ 如果任務掉落消失了怎麼辦？ 是的，建議以 Apache Pig 風格製作一個漂亮的管道，我們甚至嘗試過它們，但現在我們決定在 PHP 和 JavaScript 中使用我們深度定制的編排（我知道，存在認知失調，但它有效，對於年並且沒有錯誤）。
Lake中儲存的文件格式是效能的關鍵
了解另外兩個關鍵點非常非常重要。 為了盡快執行對湖中文件資料的查詢，並且在添加新資訊時效能不降低，您需要：
- 單獨儲存文件的列（這樣您就不必閱讀所有行來了解列中的內容）。 為此，我們採用了壓縮的 parquet 格式
- 將文件分成語言、年、月、日、週等資料夾非常重要。 了解這種類型分片的引擎將僅查看必要的資料夾，而不會連續篩選所有資料。
本質上，透過這種方式，您可以為掛在頂部的分析引擎以最有效的形式佈置來源數據，即使在分片資料夾中，也可以選擇性地輸入和僅讀取檔案中的必要列。 您不需要在任何地方「填滿」資料（儲存空間只會爆裂） - 只需立即明智地將其以正確的格式放入檔案系統中即可。 當然，這裡應該要清楚的是，在 DataLake 中儲存一個巨大的 csv 檔案是不太可取的，因為叢集必須先逐行讀取該檔案才能提取列。 如果還不清楚為什麼會發生這一切，請再思考一下以上兩點。
AWS Athena - 玩偶盒
然後，在創建湖泊時，我們意外地遇到了亞馬遜雅典娜。 突然發現，透過將龐大的日誌檔案以正確的（鑲木地板）列格式仔細排列到資料夾分片中，您可以非常快速地從中做出資訊豐富的選擇，並無需Apache Spark/Glue 叢集即可建構報告。
s3 中數據驅動的 Athena 引擎基於傳奇 - MPP（大規模平行處理）資料處理方法系列的代表，將資料就地取用，從 s3 和 Hadoop 到 Cassandra 和普通文字檔案。 您只需要求 Athena 執行 SQL 查詢，然後一切都會「快速、自動地運行」。 值得注意的是，Athena 是「智慧」的，它只存取必要的分片資料夾並只讀取請求中所需的列。
向 Athena 請求的定價也很有趣。 我們支付 。 那些。 不是針對每分鐘集群中的機器數量，而是...針對100-500台機器上實際掃描的數據，僅是完成請求所必需的數據。
透過僅從正確分片的資料夾中請求必要的列，事實證明 Athena 服務每月要花費我們數十美元。 好吧，與集群分析相比，太棒了，幾乎免費！
順便說一句，這是我們在 s3 中對資料進行分片的方式：
結果，在很短的時間內，公司中從資訊安全到分析等完全不同的部門開始主動向 Athena 提出請求，並在幾秒鐘內迅速從相當長的一段時間內（數月、半年等 P.
但我們走得更遠，開始到雲端尋找答案 ：分析師在熟悉的控制台中編寫 SQL 查詢，該控制台在 100-500 台機器上「花幾分錢」將資料發送到 s3，並通常在幾秒鐘內返回答案。 舒服的。 而且速度很快。 我還是不敢相信。
因此，我們決定將資料以高效的列式格式儲存在 s3 中，並將資料合理地分片到資料夾中…我們免費獲得了 DataLake 和一個快速且便宜的分析引擎。 他在公司裡變得很受歡迎，因為… 理解 SQL 並且工作速度比透過啟動/停止/設定叢集快幾個數量級。 “如果結果是一樣的，為什麼要付出更多？”
對雅典娜的請求看起來像這樣。 當然，如果需要，您可以形成足夠的 ，但我們將僅限於簡單分組。 讓我們看看客戶端幾週前在 Web 伺服器日誌中收到的回應代碼，並確保沒有錯誤：
發現
我們經歷了一條漫長但痛苦的道路，不斷充分評估風險、複雜性水準和支援成本，我們找到了一個資料湖和分析的解決方案，它的速度和擁有成本都讓我們滿意。
事實證明，建立一個有效、快速且廉價的DataLake 來滿足公司完全不同部門的需求，甚至是經驗豐富的開發人員的能力範圍之內，即使他們從未擔任過架構師，也不知道如何在正方形上畫出正方形。箭頭並了解 Hadoop 生態系統的 50 個術語。
在旅程的開始，我的頭腦因開放和封閉軟體的許多野生動物園以及對後代責任負擔的理解而分裂。 只需開始使用簡單的工具建立您的 DataLake：nagios/munin -> elastic/kibana -> Hadoop/Spark/s3...，收集回饋並深入了解正在發生的過程的物理原理。 一切複雜而陰暗的東西──都交給敵人和競爭對手。
如果你不想上雲，喜歡支援、更新和修補開源項目，你可以在本地建立一個與我們類似的方案，在廉價的辦公室機器上使用 Hadoop 和 Presto。 最重要的是不要停下來，繼續前進，計算，尋找簡單明了的解決方案，一切一定會成功！ 祝大家好運，再見！
來源： www.habr.com