如何跨组织共享数据

我敢肯定你看到了,“看情况而定”。

这取决于一切。对于与B部门共享客户数据,A部门共享客户数据的解决方案可能完全不同。

多年来我最喜欢的概念是“最终一致性”的概念。这个词来自于亚马逊谈论的分布式系统。

前提是,虽然现在分布式企业中的数据状态可能不完全一致,但“最终”是一致的。

例如,当在系统A上更新客户记录时,系统B的客户数据现在已过时,不匹配。但是,“最终”,A的记录将通过一些过程发送给B。因此,最终,这两个实例将匹配。

当你使用一个单一的系统时,你没有“EC”,而是有即时的更新,一个单一的“真相来源”,通常还有一个处理种族状况和冲突的锁定机制。

您的操作越能处理“EC”数据,就越容易分离这些系统。一个简单的例子是销售人员使用的数据仓库。他们使用DW运行每日报告,但直到清晨才运行报告,并且总是查看“昨天”(或更早)的数据。因此,DW不需要实时地与日常操作系统保持完全一致。对于一个流程来说,在业务结束时运行并在一个大型的、单一的更新操作中集中处理事务和活动是完全可以接受的。

您可以看到这个需求如何解决许多问题。对事务数据没有争用,不用担心某些报表数据会在统计数据累积过程中发生变化,因为报表对实时数据库进行了两次单独的查询。不需要为了高细节的聊天来吸收网络和CPU处理等。

现在,这是一个极端、简化和非常粗糙的EC示例。

但是考虑一下像谷歌这样的大系统。作为搜索的消费者,我们不知道谷歌在搜索页面上搜索结果的更新时间和时间。什么?1s?10秒?10小时?很容易想象如果你访问Google的西海岸服务器,你会得到与他们的东海岸服务器不同的搜索结果。这两个实例决不是完全一致的。但在很大程度上,它们基本上是一致的。对于他们的用例,他们的消费者不会真正受到延迟和延迟的影响。

考虑电子邮件。A想要发送消息给B,但是在这个过程中,消息是通过系统C、D和E路由的。每个系统都接受消息,对它承担全部责任,然后将它交给另一个系统。发件人看到电子邮件继续发送。接受者不会真的错过它,因为他们不一定知道它的到来。因此,有一个很大的时间窗口可以让消息在系统中移动,而无需任何人关心它有多快。

另一方面,A可能在和B打电话,“我刚发了,你收到了吗?现在?现在?现在明白了吗?”

因此,存在某种潜在的、隐含的性能和响应级别。最后,“最终”,A的发件箱匹配B的收件箱。

这些延迟、对过时数据的接受,无论是一天的数据还是1-5年的数据,都是控制系统最终耦合的因素。这个要求越宽松,耦合就越松散,在设计方面,您拥有的灵活性就越强。

这对于CPU中的核心来说是正确的。在同一个系统上运行的现代多核多线程应用程序,可以对“相同”数据有不同的视图,只有微秒的时间过期。如果您的代码能够正确地处理可能彼此不一致的数据,那么“快乐的一天”就顺其自然了。如果不需要,您需要特别注意以确保数据完全一致,使用诸如易失性内存限定或锁定构造等技术,所有这些都会以其方式降低性能。

所以,这是基本考虑。所有其他的决定都从这里开始。回答这个问题可以告诉您如何跨计算机分区应用程序、共享哪些资源以及如何共享它们。可以使用哪些协议和技术来移动数据,以及执行传输所需的处理成本。复制、负载平衡、数据共享等都基于这个概念。

根据第一条评论进行编辑。

没错。例如,在这里的游戏中,如果B不能更改客户数据,那么更改客户数据有什么坏处?你能冒险让它在短时间内过时吗?也许您的客户数据输入速度足够慢,您可以立即将其从A复制到B。假设将更改放在一个队列上,由于容量较低,很容易获取(<1s),但即使如此,它仍将与原始更改“脱离事务”,因此有一个小窗口,其中a将具有b不具有的数据。

现在大脑真的开始旋转了。在1秒的“滞后”中发生了什么,这是最糟糕的情况。你能绕着它转吗?如果你能设计一个1s左右的滞后,你可以设计一个5s、1m左右的滞后,甚至更长的滞后。您在B上实际使用了多少客户数据?也许B是一个系统,旨在促进订单从库存中挑选。很难想象有什么比简单的客户ID和名字更重要的了。只是在组装订单时,用来大致识别订单的对象。

拣货系统不一定需要打印出所有客户信息,直到拣货过程结束,然后订单可能已经转移到另一个系统,该系统可能是最新的,尤其是运输信息,因此最终拣货系统不需要几乎不需要任何客户数据。实际上,您可以在拣货单中嵌入客户信息并将其非规范化,这样就不需要或期望稍后进行同步。只要客户ID是正确的(无论如何都不会更改)和名称(很少更改,不值得讨论),这是您需要的唯一真实参考,并且在创建时,您的所有提货单都是完全准确的。

诀窍在于心态,打破系统,专注于完成任务所必需的基本数据。不需要的数据不需要复制或同步。人们对非规范化和数据缩减之类的事情感到恼火,尤其是当他们来自关系数据建模世界时。有充分的理由,应该谨慎考虑。但是,一旦进行了分发,就隐式地取消了规范化。见鬼,你现在正在大规模复制。所以,你也可以更聪明一些。

所有这些都可以通过可靠的过程和对工作流的透彻理解来减轻。识别风险,制定应对风险的政策和程序。

但最困难的部分是在一开始就打破与中央数据库的联系,并告诉人们,当你拥有一个单一的、中央的、完美的信息存储时,他们不能像他们所期望的那样“全部拥有”。

这绝对不是一个全面的答复。抱歉,我的长篇文章,我希望它能增加我在这里的想法。

我对你提到的某些方面有一些看法。

duplicate data

根据我的经验,这通常是部门化或专业化的副作用。该部门率先收集其他专业团体认为有用的某些数据。由于这些数据与其他数据采集混合在一起,因此它们没有对这些数据的唯一访问权,为了利用这些数据,它们也开始收集/存储数据,从本质上使其重复。这个问题永远不会消失,就像在重构代码和消除重复方面有一个连续的工作一样,需要不断地为集中访问、存储和修改带来重复的数据。

well-defined interfaces

大多数接口都是以良好的意图定义的,并将其他约束牢记在心。然而,我们只是有一个习惯,从先前定义的接口所施加的约束中成长出来。也是一个连续重构的例子。

tight coupling vs loose coupling

如果有的话,大多数软件都会受到这个问题的困扰。考虑到我们所面临的时间限制,紧密耦合通常是权宜之计解决方案的结果。松耦合导致了一定程度的复杂性,当我们想要完成事情时,我们不喜欢这种复杂性。Web服务的咒语已经流传了很多年了,我还没有看到一个很好的解决方案的例子,它完全缓解了这一点。

architectural simplification

对我来说,这是解决你在问题中提到的所有问题的关键。我想到了SIP和H.323 VoIP的故事。SIP非常简单,易于构建,而H.323就像一个典型的电信标准,试图设想世界上关于VoIP的每个问题,并为其提供解决方案。最终结果,sip增长得更快。遵从H.323的解决方案是一件痛苦的事情。事实上,H.323合规性是一个巨大的行业。

On a few architectural fads that I have grown up to.

多年来,我开始喜欢REST架构,因为它很简单。它提供了对数据的简单、独特的访问,并易于围绕它构建应用程序。我看到企业解决方案比任何其他问题(如性能等)都更容易遭受重复、隔离和数据访问的痛苦。对我来说,其他问题是解决这些问题的灵丹妙药。

为了解决这些问题,我喜欢中央“数据中心”的概念。数据中心代表特定实体的“单一真实来源”,但只存储ID,不存储名称等信息。实际上,它只存储ID映射-例如,这些映射将客户ID映射到系统A中,将客户编号映射到系统B中,并将客户编号映射到系统C中。接口系统之间使用集线器知道如何将一个系统中的信息与另一个系统关联起来。

这就像一个中心翻译;不必编写特定的代码来从A->B、A->C和B->C映射,随着您添加更多系统,其出勤率呈指数增长,您只需转换到/从中心:A->中心、B->中心、C->中心、D->中心等。