数据仓库的ETL组件通常位于仓库本身的阴影下，因此与主数据库或前端组件BI报告相比，对它的关注较少。 同时，从填充数据仓库的机制的角度来看，ETL扮演着关键角色，与其他组件相比，管理员需要给予他们更多的关注。 我的名字叫Alexander，我目前在Rostelecom中管理ETL，在本文中，我将尝试与Rostelecom大型数据仓库中最著名的ETL系统之一的管理员进行一些交流。
如果亲爱的读者通常已经熟悉我们的数据仓库项目和Informatica PowerCenter产品，则可以跳到下一部分。
几年前，单一公司数据仓库的想法已经成熟，并开始在Rostelecom中生效。 已经创建了许多解决单个任务的存储，但是方案的数量在增加，支持成本也在增加，而且很明显，未来是集中的。 从体系结构上讲，这是存储库本身，由多层组成，在Hadoop和GreenPlum，辅助数据库，ETL机制和BI上实现。
同时，由于存在大量地理上分散的异构数据源，因此创建了一种特殊的数据上载机制，其工作由Informatica控制。 结果，数据包最终到达Hadoop前端区域，然后开始通过Hadoop和GreenPlum中的存储层加载数据的过程，并由Informatica中实现的所谓ETL控制机制控制。 因此，Informatica系统是确保存储操作的关键要素之一。
以下内容之一将讨论有关存储的更多详细信息。
当前，Informatica PowerCenter /大数据管理被认为是数据集成工具领域的领先软件。 这是美国Informatica公司的产品，该公司是ETL（提取转换负载），数据质量管理，MDM（主数据管理），ILM（信息生命周期管理）等领域最强大的参与者之一。
我们使用的PowerCenter是集成的Tomcat应用程序服务器，Informatica应用程序本身可在其中运行，以实现其服务：
实际上，
Domain是其他所有内容的基础；在该域内，服务，用户和GRID组件均在工作。
除Informatica Developer客户端（用于与产品进行交互的主要工具）外，
管理员控制台 （基于Web的管理和监视工具）
MRS，模型存储库服务 ，元数据存储库，是物理存储元数据的数据库和正在开发元数据的Informatica Developer客户端之间的一层。 存储库既存储数据的描述，又存储其他信息，包括许多其他Infromatica服务的信息，例如，启动任务或监视数据的时间表以及应用程序参数集，尤其是允许使用同一应用程序进行工作与各种数据源和接收器。
DIS是数据集成服务（Data Integration Service，Data Integration Service） ，是一项服务，在其中进行主要功能流程，在其中运行应用程序，并实际启动工作流（描述映射及其相互作用的顺序）和映射（转换，发生转换本身的块，数据处理）。
实际上，当由DIS启动的负载分布在节点（即属于域的服务器）之间时，
GRID配置实际上是使用多个服务器构建复杂系统的选项。 在此选项的情况下，除了通过额外的GRID抽象层将负载分配给DIS之外，结合多个DIS可以在其上工作而不是在特定单个节点上工作的节点，还可以创建其他备份MRS实例。 当发生主要故障时，可以通过备份节点进行外部调用时，甚至可以实现高可用性。 到目前为止，我们一直拒绝这种建造方案。
Informatica PowerCenter，原理图在工作的第一阶段，数据供应链中经常出现问题，其中一些是由于当时Informatica工作不稳定所致。 我将分享这个传奇故事的一些令人难忘的时刻-Informatica 10的发展。
前Informatica徽标其他Informatica环境也是我们职责范围的一部分，由于负载不同，它们具有各自的特点，但是现在我将确切地回顾一下Informatica是如何发展为数据仓库本身的ETL组件的。
怎么发生的
2016年，当我们开始负责Informatica时，它已经达到10.0版，对于乐观的同事们，他们决定在严肃的解决方案中使用次要版本.0的产品，一切似乎都很明显-您需要使用新版本！ 从硬件资源的角度来看，当时一切都很好。
自2016年春季以来，承包商负责Informatica的工作，据该系统的少数用户称，“该系统每周工作两次”。 在这里有必要说明，存储实际上是在PoC阶段，团队中没有管理员，并且由于各种原因系统经常崩溃，然后承包商工程师再次提出了存储要求。
在秋天，三名管理员出现在团队中，分担了责任，并开始在项目中（包括Informatica）对操作系统进行常规工作。 另外，必须说该产品并不普及，并且拥有一个庞大的社区，您可以在其中找到任何问题的答案并解决任何问题。 因此，俄罗斯合作伙伴Informatica的全面技术支持非常重要，在此帮助下，我们的所有错误和年轻的Informatca 10的错误都得到了纠正。
我们必须为团队和承包商的开发人员做的第一件事是稳定Informatica本身的工作，使基于Web的管理控制台（Informatica Administrator）可操作。
因此，我们经常遇到Informatica开发人员除了查找原因的过程之外，从网络环境的角度来看，崩溃的主要原因是Informatica软件与位于相对远程服务器上的存储库数据库之间的交互。 这导致延迟，并破坏了监视Informatica域状态的机制。 在对数据库进行了一些调整之后，更改了Informatica参数，使其更能容忍数据库延迟，并且由于将Informatica版本更新为10.1并将数据库从先前的服务器转移到更靠近Informatica的服务器，因此该问题失去了相关性，此后便出现了此类崩溃我们没有观察到。
使Informatica Monitor正常运行的尝试之一使用管理控制台，情况也很严重。 由于在有条件的生产环境中可以进行积极的开发，因此同事经常需要分析映射工作，即“随时随地”的工作流程。 在新的Informatica中，数据集成服务没有单独的工具来进行监视，但是管理Web控制台中显示了监视部分（Informatica Administrator Monitor），您可以在其中监视应用程序，工作流和映射，启动，日志的操作。 定期地，控制台变得完全不可用，或者有关DIS中当前进程的信息停止更新，或者在加载页面时发生了错误。
选择Java参数来稳定工作该问题已通过多种方式解决，进行了更改参数的实验，收集了日志，发送了jstack作为支持，同时进行了主动谷歌搜索，并进行了观察。
首先，创建了一个单独的MRS进行监视，因为后来它成为我们环境中资源的主要消耗者之一，因为映射的启动非常密集。 有关Java堆的参数以及其他一些参数已更改。
结果，对Informatica 10.1.1的下一次更新设法稳定了控制台和监视器，开发人员开始更有效地工作，并且常规流程变得更加常规。
开发与管理之间交互的经验可能会很有趣。 在使用复杂系统时，对一切工作原理，可以做什么和不能做什么进行共识的问题始终很重要。 因此，我们可以安全地建议您首先对管理团队进行有关如何管理软件的培训，对开发团队进行有关如何在系统中编写代码和绘制流程的培训，然后再培训第一和第二位处理结果。 当时间不是无尽的资源时，这真的很重要。 即使通过随机枚举选项也可以解决许多问题，但有时某些问题需要先验知识-我们的案例证实了理解此公理的重要性。
例如，当我们试图在MRS中包括版本控制时（事实证明，我们需要一个不同的SVN版本），过了一段时间，我们急切地发现系统重新启动时间增加了几十分钟。 由于延迟启动和禁用版本控制的原因，他们再次表现出色。
在与Informatica相关的显着障碍中，人们可以回想起与不断增长的Java流的史诗般的战斗。 在某个时候，复制的时机已经到来，也就是说，将已建立的过程扩展到大量的源系统。 事实证明，并非所有10.1.1版本的流程都能正常运行，并且一段时间后，DIS无法正常运行。 检测到成千上万的线程，在应用程序部署过程中，线程的数量尤其明显增加。 有时有必要每天重新启动几次以恢复性能。
在这里，您需要感谢您的支持，这些问题已使用EBF（紧急错误修复）进行了相对较快的本地化和修复-之后每个人都感觉该工具确实有效。
它仍然有效！
在目标模式下开始工作时，Informatica如下所示。 Informatica版本10.1.1HF1（HF1是HotFix1，是来自一组EBF的供应商程序集），在三个GRID服务器之一，20个x86_64核心和存储上，安装了额外的EBF，以解决我们的扩展问题和其他一些问题。大量的慢速本地磁盘阵列-这是Hadoop集群的服务器配置。 在同一类型的另一台服务器上，Oracle DBMS与Informatica域和ETL控制机制一起使用。 所有这一切都由团队中使用的标准监视工具（Zabbix + Grafana）进行监视-Informatica本身及其服务以及装入过程中的加载过程。 现在，性能和稳定性（不考虑外部因素）都取决于限制负载的设置。
另外，我们可以说一下GRID。 该环境建立在三个节点上，并可能实现负载平衡。 但是，在测试过程中，发现由于我们应用程序的运行实例之间的交互问题，该配置无法按预期工作，因此暂时决定通过从域中删除三个节点中的两个来放弃此构造方案。 同时，该方案本身保持不变，现在是GRID服务，但退化为一个节点。
目前，仍然存在与定期清洁监控器电路过程中性能下降相关的复杂性-CNN中的同时处理过程和运行中的清洁过程可能会导致ETL控制机制的运行出现故障。 到目前为止，这已通过“拐杖”得到解决-手动清洁监控器电路，同时丢失了所有以前的数据。 对于具有正常专职工作的产品而言，这并不是太关键，但是到目前为止，正在寻求一种常规解决方案。
相同的情况会引起另一个问题-有时会多次启动我们的控制机制。
启动多个应用程序，导致机制崩溃在系统重负载时按计划启动时，有时会出现导致机制崩溃的情况。 到目前为止，该问题已通过手动解决；正在寻求永久解决方案。
通常，可以总结出，在高负载下，提供足够的资源非常重要，这也适用于Informatica本身的硬件资源以及数据库存储库的硬件资源，并确保对其进行最佳设置。 此外，仍然存在关于哪种数据库布局更好的问题-在单独的主机上，还是在Informatica软件可以使用的同一主机上。 一方面，它在一台服务器上会更便宜，而且当组合在一起时，实际上消除了网络交互的可能问题，另一方面，数据库中主机的负载由Informatica的负载补充。
与任何严肃的产品一样，Informatica也有一些奇怪的时刻。
有一次，在分析某种事故时，我注意到MRS日志中奇怪地标记了事件的时间。
MRS日志中的临时二元性“通过设计”事实证明，时间戳记以12小时的格式编写，而没有指定AM / PM，即中午之前或之后。 甚至已就此主题打开了一个应用程序，并且收到了正式答复-如此计划，MRS日志中的标记以这种格式编写。 就是说，有时对于某些错误的发生时间仍然有些好奇。
力求最好
如今，Informatica是一个相当稳定的工具，为管理员和用户提供了便利，在当前功能和潜力方面极为强大。 它在功能上多次超出了我们的需求，并且实际上已经以一种不太典型和典型的方式用于项目中。 困难的部分原因在于机制的工作方式-具体来说是在短时间内启动大量线程，这会密集地更新参数并与存储库数据库一起工作，而服务器硬件资源几乎完全被CPU所利用。
现在，我们已经接近切换到Informatica 10.2.1或10.2.2，其中已经重新设计了一些内部机制，并且支持保证不会在性能和功能上出现许多当前问题。 从硬件的角度来看，由于存储的增长和发展，在不久的将来会有一定的利润空间，因此预计服务器对于我们来说是最佳的。
当然，HA GRID部分中的测试，兼容性测试以及可能的体系结构更改都在前面。 Informatica内的开发将继续进行，因为在短期内我们无法投入任何东西来替代该系统。
那些将继续负责此系统的人当然可以将其带到客户提出的要求的可靠性和性能指标。
本文由Rostelecom数据管理团队编写
实际的Informatica徽标