云中的企业数据操作系统：必要，但还不够

云过去的意思是“租用别人的服务器”，但它越来越代表一套架构和设计模式，定义了我们如何设计和交付21世纪的企业计算解决方案。对于数据和分析平台解决方案，这意味着重新考虑服务、API和数据产品方面的解决方案。

云中有什么变化？一切！计算、存储和网络服务被配置为代码并按需提供。可以根据需要启动、停止和扩展服务。默认情况下，操作是自动化的。PAYG定价模型限制了风险，实现了快速试验，降低了进入壁垒，缩短了价值实现的时间。也许最重要的是，通过调用和连接服务，来创建封装有重要业务的可复用流程，一个具有良好定义的接口（“APIs”）的可组合服务的丰富生态系统就可以实现“组合式”的系统开发。在一个巨大的经济不确定性的时代，价值实现的时间和灵活性显得越来越重要；云架构与“数据运营”方法相结合，实现了数据和分析产品的敏捷、增量开发，没有这些，任何数字转型项目都注定在最好的情况下毫无意义，在最坏的情况下将彻底失败。

从概念上讲，可以说，很多都不是新的。从20世纪80年代开始的面向服务的架构运动，在此之前的面向对象编程的革命，甚至可以追溯到50年代和60年代的结构化编程运动，他们都有许多相同的目标。但是正如一位英国首相曾经说过的“重要的是什么有效”，云设计模式已经被证明不仅适用于很多用例，而且可以快速经济地扩展。这就是为什么它们很重要。

持久而灵活的云对象存储为组织提供了“任何数据、任何格式”的灵活性。而且它在经济上做到了这一点，使组织能够无限期地保留“冷”数据——或者至少，只要业务需要，监管机构允许。但是，可靠和持久的对象存储还将实现PB级的根本架构简化，例如，大大简化高可用性、备份和恢复解决方案以及操作，并支持“企业数据操作系统”的部署。

当然，存储数据本身就增加了成本，而不是价值——操作系统只是一个成功计算平台的组件——因此云分析架构包含可插入的处理引擎，可以直接读写到企业数据操作系统，以便处理数据并创造价值。在许多情况下，这些处理引擎维护集成和建模数据的本地副本，其格式优化了可伸缩性和性能，而不是为了持久性和经济性。但是，由于可插拔的处理引擎也可以直接读写到对象存储层，因此它们可以从对象存储层加载数据，归档到对象存储层，并在运行时动态地查询和组合数据，例如，支持探索和发现工作负载。随着越来越多的数据流入到这些数据主干网中，意味着任何可以插入到数据操作系统的应用程序或平台都可以连接到整个企业的数据，而且几乎是实时的。这为企业提供了一个机会，使几十年的老旧的数据采集流程现代化，分析从主要面向批处理转为以事件驱动，这是一个关键点，因为越来越多的业务和业务流程已经数字化，并且转移到了线上。

到目前为止，还不错。但是有一个“但是”

如果您有大规模企业数据管理的背景，看看大型云服务提供商（CSPs）吹捧的参考架构和设计模式，问问自己“这幅图有什么问题？”有很多服务，APIs很充裕——但数据产品通常被描述为只不过是一个兼容S3的bucket。这导致一批架构师和设计师做出糟糕的决策，技术债务迅速积累，最终业务放缓，而不是加速。数据被孤立地、硬连接到每个分析业务流程，必然导致更多的烟囱和仓库，此时云模式可能会变得不那么“良性循环”，而更加进入“恶性循环”。

只有当数据和分析被组织用来降低成本，提高客户满意度，推动新的增长，提高绩效时，它们才具有真正的价值。在一个经济充满巨大不确定性的时代，重要的是实现价值的时间和灵活性。我所知道的加快速度的最好方法是消除不必要的工作，并尽可能地自动化其余的工作。重复使用数据产品是“消除不必要工作”的终极游戏，它是如此成功，使组织能够将预测性分析从实验和测试状态快速变为生产和规模化部署。

就其本身而言，企业数据操作系统是必要的，而不是足够的：必须将原始数据细化并处理成数据产品，然后才能广泛利用这些数据来推动业务成果的改善；为了实现端到端业务流程的优化，仍然需要集成和连接的数据。敏捷性和价值实现时间要求我们构建和设计可复用的数据产品，而复用要求我们批判性地考虑需要哪些数据产品来支持业务所需的分析用例，如何使用它们以及需要的特性。

许多基于Hadoop的数据湖都失败了，因为组织不重视数据管理。随着数据和分析迁移到云端，继续采用自由放任方式进行数据管理的组织很可能会再次因基于云对象存储的数据湖而失败。

所有这些都意味着，正确的云数据架构首先要了解支持分析过程所需的数据产品、它们所执行的角色以及这些角色所需的功能性和非功能性特征。这意味着要了解哪些数据将被如此频繁地组合和重复使用，我们应该承担集中和集成这些数据的成本——哪些数据只需要连接，就可以实现无缝的ETL处理和“无论何时何地”的查询自由，无论数据在生态系统中的何处，更多的用户都能够更快地访问更多的数据。

我们将这种架构模式称为“连接的云数据仓库”，下次还会有更多内容。