管理大规模处理财务数据的复杂性

由于这些计算必须在给定的时间框架内完成，因此会产生具有非常弹性的资源需求的批处理过程。（C4）准确性：所提供信息的质量和不确定性。因此，对于财务数据的准确性，用户的QoI及其价值（VoI）直接转化为成本。对于我们的客户来说，VoI是他们订阅的数据的客观数据质量属性和他们自己的主观偏好的函数；这些基于订阅者打算使用其订阅数据的目的。例如，使用终端解决方案的客户通常看重及时性而非完整性，也就是说，如果终端上显示的信息反映了大多数最新事件，他们更喜欢将单个通知完全删除。相反，将相同类型的通知输入其分析系统进行深入分析的客户看重完整性而非及时性，即他们更喜欢延迟的完整事件流，而不是及时但不完整的事件流。总结挑战C1–C4。财务数据的特点对我们的处理系统构成了挑战：我们必须以尽可能少的延迟和中断（C3）高效地丰富和推动大量数据（C2）给我们的客户，因为其价值是基于个人对时间和完整性（C4）的期望。每天大量的数据及其巨大的变化（C1）是一个放大因素，因为我们的系统必须弹性缩放以处理达到平均负载数个数量级的峰值速率。预印本：处理规模为72.3的金融数据的复杂性合规性金融市场的挑战是一个高度监管的领域。随后，我们必须应对基于欧洲和国家立法、特定领域法规和数据处理商业许可协议的广泛限制。

为了进行说明，我们使用了对软件开发生命周期、应用程序环境及其操作有重大影响的示例。（C5）立法：最重要的是，《一般数据保护条例》（GDPR）强调了数据位置、最低使用和个人数据保护的重要性，同时扩大了后者的定义范围。这影响了所有活跃在欧洲的公司的业务流程、数据处理程序和所使用的软件系统。除了此类一般立法外，我们还必须了解仅适用于金融部门的严格国家法律。例如，我们所在国家的瑞士银行（Bankengesetz）或德国银行（KWG）。他们都强调，外包组织仍然对他们外包给我们这样的服务提供商的服务负全部责任。（C6）法规：我们提供的一些服务是与受监管机构进一步要求的组织签订的外包协议。OnEU层面，欧洲银行管理局（EBA）为金融机构和金融产品制定了指导方针。在这种情况下，值得我们注意的是外包安排的重新定义指南[3]。在国家层面上，德国联邦金融监管局（BaFin）、卢森堡部门金融监管委员会（CSSF）或瑞士金融市场监管局（FINMA）制定了额外的要求目录，例如，BaFin的《银行风险管理最低要求》【1】或CSSF关于依赖云计算基础设施的IT外包的指导方针【2】。

所有这些法规都侧重于外包服务及其运营的透明度、问责制和可靠性。这导致了有关报告、变更与事故管理、业务连续性管理（BCM）和IT安全的额外要求：特定事件和合规性报告需要进一步的文档和流程；身份和访问管理（IAM）基于运营和开发之间的最小特权和职责分离（SoD）原则，必须在物理和数字层面加强，并定期报告。（C7）许可证：数据是我们行业的原材料。我们需要与各种数据源以及客户就我们处理的内容维护详细的个人许可协议。这些合同管理服务级别和惩罚，根据这些服务级别和惩罚，我们可以向我们提供具有一定质量的数据，并可以重新分发这些数据，我们的客户也可以使用这些数据。这要求我们实施详细的运行时监控、计量，并向最终用户详细报告数据供应和消耗情况，因为这对于我们数字供应链的成本管理至关重要。8 Frischbier等人总结了挑战C5–C7。从法规遵从性的角度来看，法规（C6）和许可证管理（C7）对透明度和可用性的严格要求与强制执行大量数据使用和机密性的一般立法（C5）产生了紧张关系。

这为我们的软件开发生命周期（SDL）和基础设施与运营组织增加了复杂性，因为我们需要遵守非功能性需求，如数据位置。2.4 IT治理方面的挑战IT治理方面的主要挑战来自我们系统环境的异构性、需要结合基于拉和推的架构模式以及处理非常灵活的工作负载所需的可扩展性。（C8）异质性：大众汽车一直在有机增长（新数字产品和吸引新客户）和无组织增长（并购、并购）。在技术层面上，这种演变增加了IT系统的异构性，随着时间的推移，这些系统将进行大规模管理和运营，尤其是在我们的整个供应链和产品组合都是数字化的情况下。总的来说，并购导致的内在异质性和复杂性的增加更为明显，但同时，有机增长的新数字产品往往会引入新的技术堆栈，而现有产品则依赖于需要维护的传统技术。如果没有积极的治理，多样性的增加会导致技术债务沿着完整的技术堆栈和惯性。例如，在某个时间点，我们的运营团队必须维护14个不同的Linux发行版和版本，因为收购的遗留应用程序依赖于特定的配置，以支持80多个遗留产品系列，并以各种编程语言实现自定义版本。（C9）推拉：我们需要向客户提供数据流，提醒他们某些事件，并从处理后的数据中获得更多的见解。

虽然这需要基于推的体系结构方法[7]，但我们的许多解决方案都需要基于拉的体系结构方法，因为它们依赖于需要根据请求从数据源中提取的静态数据或由客户操作触发的软件解决方案。（C10）可伸缩性、弹性和弹性：我们处理的工作负载在容量、多样性、速度和准确性方面都有很大差异。因此，我们必须在我们的基础设施中提供必要的容量，并使我们的应用程序景观能够根据任何工作负载进行弹性扩展。监管限制也要求我们的系统在多个位置运行以实现灾难恢复能力，这需要分布式状态管理和额外的数据同步。总结挑战C8–C10。除了源于历史上不断增长的系统异构环境（C8）的一般IT治理挑战外，我们处理的数据和必须遵守的监管约束要求我们在架构（C9）中融合基于拉和推的方法，同时操作可大规模扩展的分布式IT系统环境（C10）。预印本：处理规模财务数据的复杂性93大众如何处理规模财务数据大众在技术和组织层面解决规模财务数据处理的复杂性。

在本节中，我们概述了我们应用于生产系统的架构模式、我们在欧洲大陆运营的物理基础设施，以及我们为在遵守法规的同时实现快速开发而采取的主要组织措施。3.1技术：模块化平台和混合基础设施在技术层面上，我们直接应对数据管理方面的挑战C1-C4，合规方面的挑战C5和C6，和C8–C10关于IT治理：我们运营广泛的地理分布基础设施，并将模块化平台方法应用于我们的生产系统，将基于事件的系统（EBS）和面向服务的体系结构（SOA）这两种互补的范例结合到事件驱动的体系结构（EDA）中。技术大局。此方法的三个主要组成部分如图2所示：面向客户的大众云的目标架构（左，上）侧重于通过使用基于Docker Swarmand Kubernetes的开放和商业平台、容器化和微服务来解耦系统和基础设施。在数据源附近，我们的Ticker工厂内部开发的用于饲料加工的分布式基于事件的系统（左，下）与我们的物理基础设施垂直集成（右）：当我们控制完整的技术堆栈时，我们可以定制网络协议，并将软件与硬件对齐，以获得最大的处理性能。暗光纤连接公共云客户数据中心和系统vwd数据中心发布/子网络代理vwd股票报价器工厂FHFHFHFH信息流丰富存储原始数据源LEGENDVWD云许可监控DC1 DC2…DBsMessage总线许可源…位置BackendContainers微服务用户界面vwd云（SOA）vwd股票报价器工厂（distrib.EBS）地理分布式基础设施事件驱动架构P/SBrokersFHPublic CloudFHFeed Handlervwd数据中心图。2.

大画面vwd事件驱动架构（左），容器化面向服务的vwd云（顶部）和垂直集成的分布式报价器工厂（底部）；地理分布式物理基础设施摘录（右）。10 Frischbier等人，《反应式架构》。在体系结构层面上，我们将基于推的DB和基于拉的SOA结合在一起，原因有三：第一，直接解决金融数据流基于推的特性带来的挑战1–C4以及与许可相关的挑战（C7）。第二，通过使用模块化的面向服务的体系结构来解决C8和C9的IT治理挑战，该体系结构可以减少异构性，并允许集成基于拉的遗留应用程序。第三，利用由此产生的EDA的可扩展性和分布式特性来解决C10问题，并根据法规（C6）实施灾难恢复策略，这些法规要求地理分布设置，而不会降低我们的服务质量。SOA：vwd云（C8、C9、C10）。如图2左上角所示，面向客户的生产系统是通过编排集装箱化微服务来实现的。从开发的角度来看，这种方法通过将业务功能封装到仅通过同质接口公开且可通过加密协议访问的服务中，极大地减少了系统环境的异构性。通过REST服务asfacade（例如，Oracle的REST数据服务），将遗留应用程序的功能公开给我们的微服务领域，从而实现集成；可以优化或替换此外观背后的遗留系统，以减少操作异构性，而不会影响依赖的服务[5]。

通过这种平台方法，我们可以透明地结合基于拉和推的系统，无缝地重用和重组产品的现有功能，以利用协同效应，并通过整合和标准化系统来降低基础架构级别的复杂性。EBS：大众股票报价器工厂（C1–C4、C6、C10）。如红色分解图（图2，中间）所示，信息从我们的股票报价器工厂（底部）流向我们的大众汽车云上托管的数据驱动解决方案（顶部）；每个逻辑组件都使用多层体系结构实现，并分布在各个位置（底部，左侧）。我们的centralprocessing系统的ticker工厂中的提要处理程序（FH）实例订阅了500多个数据源，以接收、检查、清除和规范传入的提要。每个FH都经过定制，以匹配其提要的特定协议、语法和语义，并随其工作负载水平扩展。如果标准属性在原始通知中不可用，那么频繁的丰富和规范化就是添加标准属性，例如总容量、开放/关闭或日高/日低。规范化数据与客户或贡献者提供的其他参考数据一起输入到我们的事件存储（EStore）层。事件存储实现结合了内存和关系数据库。在浓缩组件中检测到复杂事件，并通过将实时数据与数据库中的历史和上下文数据进行融合，得出KPI。分布式PubSub代理网络（C1、C3、C4、C6、C10）。我们通过分布的基于内容的发布/订阅代理网络（图2中的blueoverlay网络）推送规范化数据，该网络部署在各个位置和公司间订单，即一些代理在客户的位置上运行。

通过这种分散的网络，我们可以解决灾难恢复问题，同时还可以通过应用程序级多播和基于对我们在数据世界中处理的3000万个符号中的任何一个的细粒度订阅进行过滤，将流量降至最低。WePreprint：大规模处理财务数据的复杂性11通过限制或延迟只有权获得不太精细或不太及时数据的订阅者的通知流，部分降低了QoI。许可（C7）。我们的中央许可系统负责管理客户从某些feed接收数据的权限、计量消耗量并随后向数据源和权限报告。混合式多站点基础架构。我们的系统运行在一个混合基础设施上，大部分地区由我们拥有和运营千兆连接[4]。地理分布式物理基础设施（C6、C10）。出于监管和性能方面的原因，我们在不同的位置运行地理分布的物理基础设施，如图2右侧所示：专用数据中心、配置站点、托管环境和公共云平台。整体设置旨在实现灾难恢复能力，即一个不可用的站点可以由另一个站点进行补偿。虽然我们的主要生产基地位于欧洲大陆，但根据当地法规，我们也在香港或伦敦等当地交易所现场配备了自己的硬件，以实现连接。千兆连接（C1、C3、C4、C10）。我们使用冗余的专用暗光纤千兆线路连接我们的位置。这也将我们与大多数贡献者和客户联系在一起，因为这是交换金融数据流的主要模式，因为它们的容量和延迟要求很高；同样，将我们的位置连接到全球公共云提供商。这样，我们可以在网络中透明地使用这些资源。

目前，一个专用的公共云连接具有10 Gbit带宽，但可以对连接进行集群。资源池（C1、C3、C4、C6、C8、C10）。在我们的站点中，我们操作每个站点数百个物理和虚拟服务器的级联层。虽然我们在很大程度上依赖虚拟化来优化资源利用率、安全性、弹性和可扩展性，但我们根据要处理的工作负载运行不同的资源池：用于处理数据馈送和Legacy单片应用程序的专用物理服务器，用于向客户提供托管终端的虚拟桌面环境，集装箱系统专用云平台（vwdCloud）和公共云环境，利用资源弹性进行批处理和突发。在内部，我们使用千兆线路和软件定义网络（SDN）：10 Gbit用于交通密集型平台，1 Gbit用于利用率较低的环境。关于存储，我们混合使用了集中式和分散式超聚合存储解决方案（如CEPH）。从产品和法规遵从性的角度来看，长期存储对我们来说是一个至关重要的话题，因为出于监管原因，我们必须将某些数据保存长达十年。因此，我们结合了连续同步的站点和非站点存储池。3.2组织：平衡敏捷性与监管责任。组织结构和措施为技术设计决策和工具设定了框架，以充分发挥其潜力，反之亦然。因此，我们将双速方法应用于生产系统，以解决C6、C8和C10问题，方法是平衡可靠改进遗留系统（慢轨）的需要与fast12 Frischbier等人的创新，以使用敏捷方法开发新产品，如SCRUM（快轨）。