我们生活在一个奇妙的时代，你可以快速、轻松地连接几个现成的开源工具，根据 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“煮”到身体各个部位烧伤的经历并没有白费。创建单一、廉价且可靠的文件存储的需求越来越大，该文件存储能够抵抗硬件故障，并且可以存储来自不同系统的不同格式的文件，并为来自该数据的报告制作高效且省时的样本。清除。
我还希望更新这个平台的软件不会变成新年的噩梦，需要阅读 20 页的 Java 跟踪信息并使用 Spark History Server 和背光放大镜分析长达一公里的集群详细日志。我想要一个简单而透明的工具，如果由于源数据分区算法选择不当而导致减少数据工作线程内存不足，开发人员的标准 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。最重要的是不要停下来，继续前进，计算，寻找简单明了的解决方案，一切一定会成功！祝大家好运，再见！
来源： habr.com