毫无疑问，经验丰富的同事们，他们的头上布满了漏洞，脑子里满是白发，他们正以令人难以置信的速度将数十个“立方体”中的“容器”包以“流行语言”部署在数十台服务器上，并内置了对异步非阻塞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 , /?
- ( C PHP), ? segfaults?
- PHP? : «out of memory»? .
这是一个具体的例子。尽管进行了仔细的多级测试，但客户端的情况非常不规范，输入数据已损坏，但是却出现了令人讨厌的意外错误，发出警报声，并且快速修复过程开始：
此外，kibana允许您组织指定事件的通知，并在短时间内成为公司的工具雇用来自不同部门的数十名员工-从技术支持和开发到质量保证。
监视和衡量公司内任何部门的活动已经变得很方便-代替手动分析服务器上的日志，只需设置日志解析并将其发送到弹性集群就足够了，例如，在kibana仪表板中考虑在3-d上打印的出售的两头小猫的数量。上个月的打印机。
基本商业智能
每个人都知道，公司中的商业智能通常始于极为活跃的使用，是的，是的，Excel。但是，最主要的是它并没有就此结束。云Google Analytics（分析）助您一臂之力-您很快就会习惯美好的事物。
在我们和谐发展的公司中，到处都是出现更密集的工作和更大数据的“先知”。对更深层次和更多层面的报告的需求开始定期出现，并且由于不同部门的努力，不久前组织了一个简单实用的解决方案-ClickHouse和PowerBI的结合。
长期以来，这种灵活的解决方案起到了很大的作用，但是逐渐地，它开始使人们认识到ClickHouse并不是橡胶的，因此不能被嘲笑。
重要的是，在这里必须很好地理解，ClickHouse（例如Druid），Vertica（例如Vertica）和Amazon RedShift（基于postgres）是经过优化的分析引擎，用于相当方便的分析（求和，聚合，列的最小最大值和一些联接） ），因为 与MySQL和我们所知的其他（面向行的）数据库不同，它们被组织为有效地将列存储在关系表中。
实际上，ClickHouse只是一个更大的数据“数据库”，不是很方便的点插入（按预期，一切都可以），但是很好的分析功能和一组有趣的功能强大的数据处理功能。是的，您甚至可以创建一个群集-但您知道用显微镜锤击钉子并不完全正确，因此我们开始寻找其他解决方案。
对python和分析师的需求
在我们公司中，有许多开发人员几乎每天都在用PHP，JavaScript，C＃，C / C ++，Java，Go，Rust，Python，Bash编写代码，历时10至20年。还有许多经验丰富的系统管理员，他们经历了不只一次不符合统计法则的绝对令人难以置信的灾难（例如，raid-10中的大多数磁盘被强雷击毁坏）。在这种情况下，很长一段时间以来，还不清楚“ python分析师”是什么。 Python就像PHP，只是名称稍长，而在解释器的源代码中，改变心灵的物质的痕迹略小。但是，随着越来越多的分析报告创建，经验丰富的开发人员越来越意识到在numpy，pandas，matplotlib，seaborn等工具中进行狭义分工的重要性。
决定性的作用很可能是员工突然晕倒的原因，他们是“逻辑回归”一词与使用yes，yes，pyspark对大数据进行有效报告的证明相结合的结果。
Apache Spark，其功能范式，关系代数和功能使习惯于MySQL的开发人员印象深刻，以至于与经验丰富的分析师加强战斗力的需求日渐明显。
Apache Spark / Hadoop进一步尝试起飞以及出了什么问题
但是，很快就发现，使用Spark显然是系统上不太正确的事情，或者您只需要更好地洗手即可。如果Hadoop / MapReduce / Lucene堆栈是由经验丰富的程序员制作的，这很明显，如果您满怀热情地看一下Java的源代码或Doug Cutting在Lucene中的想法，那么从实用性的角度来看，Spark突然间引起了很大争议，现在还没有开发外来的Scala语言。而且由于不合逻辑且不透明的工作（用于减少操作的分配内存）（许多键一次到达）而导致Spark集群上的计算定期下降-在其周围产生了可扩展空间的光环。此外，大量奇怪的开放端口，临时文件，在最难以理解的地方生长，以及依赖罐子的地狱，这导致系统管理员从小就感受到一种强烈的仇恨（或者也许有必要用肥皂和水洗手）。
结果，我们使用Apache Spark（包括Spark Streaming，Spark SQL）和Hadoop生态系统（以及其他）积极地“幸存”了多个内部分析项目。尽管事实是随着时间的流逝，我们学会了精心烹饪和监控“ it”，但由于数据性质的变化和统一RDD哈希的不平衡，“ it”实际上停止了突然下降，人们渴望在现成的某个地方进行现成，更新和管理的事物。云变得越来越强大。正是在这个时候，我们尝试使用现成的基于Amazon Web Services- EMR的基于云的程序集，随后尝试解决其上的问题。 EMR是由Amazon编写的Apache Spark，带有来自生态系统的其他软件，类似于Cloudera / Hortonworks构建。
橡胶文件存储以进行分析-迫切需要
烧伤身体各个部位的“烹饪” Hadoop / Spark的经验并非徒劳。建立一个单一的，廉价的和可靠的文件存储的需求开始出现，这种文件存储可以抵抗硬件故障，并且可以以不同的格式存储来自不同系统的文件，并且可以从这些数据中高效，及时地选择报告，这种需求越来越明显。
我还希望通过使用Spark History Server和背光放大镜阅读20页的Java跟踪并分析长达一千米的详细集群日志，从而避免该平台的软件更新成为新年的噩梦。我希望有一个简单透明的工具，如果还原数据工作人员为初始数据选择的分区算法选择不当时，开发人员停止执行标准的MapReduce请求，而开发人员停止执行标准的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-mocker容器并消除依赖冲突。
再一次，一个简单的想法。您无需配置Apache Spark，只需为pyspark编写python代码，在桌面上对其进行本地测试，然后在云中的大型群集上运行它，即可指示源数据在何处以及将结果放在何处。有时这是必要且有用的，这就是我们对其进行配置的方式：
因此，如果您需要根据s3中的数据在Spark集群上计算出一些东西-请在python / pyspark中编写代码，对其进行测试并祝您旅途愉快。
那业务流程呢？如果任务失败并消失了怎么办？是的，有人提议以Apache Pig的风格制作漂亮的管道，我们甚至尝试了它们，但现在决定使用我们在PHP和JavaScript中深度定制的业务流程（我知道，虽然存在认知上的失调，但它可以运行多年且没有错误）。
Lake文件格式是性能的关键
了解另外两个关键点非常非常重要。为了尽快执行对Lake中文件的数据请求，并且在添加新信息时性能不会降低，您需要：
- 分别存储文件列（这样您就无需阅读所有行来了解列中的内容）。为此，我们采用了实木复合地板格式并进行了压缩
- 按照精神将爸爸分片的文件非常重要：语言，年，月，日，周。理解这种分片的引擎只会查看正确的父亲，而不会自己处理所有数据。
实际上，通过这种方式，您可以以最有效的方式来安排悬挂在顶部的分析引擎的初始数据，这些数据可以有选择地输入碎片爸爸，并且仅从文件中读取必要的列。无需走到任何地方，它就会“填充”数据（存储将突然破裂）-只需立即以正确的格式将其明智地放入文件系统即可。当然，这里应该很清楚，在DataLake中存储一个巨大的csv文件不是很可取的，它必须首先由群集逐行读取才能提取列。如果还不清楚为什么要再次考虑以上两点。
AWS Athena-在鼻烟盒中“呼出”
然后，在创造湖泊的同时，我们偶然地偶然发现了亚马逊雅典娜。突然发现，通过使用碎片（shards-daddies）以正确的（镶木地板）列格式整齐地折叠巨大的日志文件，您可以非常快速地对它们进行非常有用的选择，并且无需Apache Spark / Glue集群即可构建报表。
s3数据引擎Athena基于传奇的Presto（传奇的Presto），Presto是大规模并行处理（MPP）数据处理方法家族的成员，将数据放置在s3和Hadoop到Cassandra和纯文本文件中。您只需要让Athena执行SQL查询，然后一切“就可以快速且独立地工作”。重要的是要注意，Athena是“智能”的，仅转到必要的分片父亲，并且仅读取请求中所需的列。
向雅典娜开帐单的请求也很有趣。我们支付扫描的数据量。那些。不是针对每分钟群集中的计算机数量，而是针对在100-500台计算机上实际扫描的数据，仅是满足请求所需的数据。
而且，通过仅向经过适当分片的父亲请求必要的列，事实证明，雅典娜服务每月要花费我们数十美元。好吧，与集群分析相比，它很棒，几乎免费！
顺便说一下，这就是我们在s3中存储数据的方式：
结果，在短时间内，公司中完全不同的部门（从信息安全到分析）开始主动向Athena发出请求，并在几秒钟内迅速收到来自“大公司”的有用答案相当长一段时间的数据：几个月，半年等等。
但是我们走得更远，开始通过ODBC驱动程序进入云中：分析师在熟悉的控制台中编写SQL查询，该控制台在100-500台计算机上，在s3中“花费一分钱”毛数据，通常在几秒钟内返回答案。方便。又快我仍然不敢相信。
结果，决定以s3格式存储数据，采用高效的列格式并由父亲进行合理的数据分片...我们免费获得了DataLake和快速廉价的分析引擎。他在公司中非常受欢迎，因为理解SQL并比启动/停止/配置集群快几个数量级。 “如果结果相同，为什么还要支付更多？”
向雅典娜的请求看起来像这样。当然，如果需要，您可以形成足够的复杂且多页的SQL查询，但我们将限于简单的分组。让我们看看客户端几周前在Web服务器的日志中有什么响应代码，并确保没有错误：
结论
走了，不是说这是一条漫长而痛苦的路，不断地充分评估风险以及复杂性和支持成本的水平，我们找到了DataLake和分析解决方案，它的速度和拥有成本永不止步。
事实证明，即使是经验丰富的开发人员，他们也从来没有以架构师的身份工作，也无法用箭头在正方形上绘制正方形，并且从Hadoop生态系统中了解50个术语，因此完全可以满足公司完全不同部门的需求构建高效，快速且廉价的DataLake。
在旅途的开始，我的头脑从打开和关闭软件的最狂野的动物园中分离出来，并了解后代的责任负担。只需从简单的工具开始构建DataLake：nagios / munin-> elastic / kibana-> Hadoop / Spark / s3 ...，收集反馈并深刻理解正在发生的过程的物理过程。一切复杂而泥泞的-交给敌人和竞争对手。
如果您不想上云并喜欢维护，更新和修补开源项目，则可以在低成本的办公机器上（与Hadoop和Presto一起）在本地构建与我们类似的方案。最主要的是不要停下来，继续前进，计数，寻找简单明了的解决方案，一切都一定会成功！祝大家好运，很快再见！