一家公司要想成为数据驱动型企业，除了选对工具，勇于探索数据相关实践，还得有一个懂数据管理的老板。

　　过去，很多企业的做法是，CEO无须了解数据库具体是什么，数据仓库能解决哪些问题，他们对于NoSQL、对于数据存储也知之甚少，不清楚企业为什么要建Spark集群，更不知道如何使用数据湖来处理结构化和非结构化数据，因为他们不需要了解底层技术。

　　说白了，CEO一直关注的是数据分析和机器学习带来的商业价值，而不是如何部署底座技术。但这里有一个悖论是，CEO不了解底层技术，又怎么能知道一个新技术需要投入多少人力、物力和时间，创造多大的商业价值？

　　用业务语言理解数据网格

　　所以，不管是数据网格、数据架构，还是分布式云，这些新的数据管理技术不仅是技术人员的专属，还要把这些技术“翻译出来”，让哪怕是不懂技术的业务人员也明白，甚至能成功驾驭，这便是数据驱动型企业应该努力的方向。

　　换言之，以数据管理为导向，不仅是CEO的事，任何人都应该以通俗易懂的语言理解关键技术和实践方案。比如：可以从一个从简单概念开始理解，不管是数据湖、数据仓库、数据网格、数据架构，都和公司整体的数据战略有关。

　　当理解了相关数据概念后，自然会有更进一步的求知欲。例如，简单了解了数据网格概念后，我们还希望以更独特的视角，来正确审视技术问题。

　　我们都知道，数据网格是一种分散的数据管理方法，公司内的多个团队负责自己的数据，推动全员协作和业务灵活性。更直白的理解是，数据网格旨在解决具体问题，是一种解决方案的类型，并有着独特的重要性。

　　从技术的角度看，很多人都会从数据仓库、数据湖和网格之间的技术差异角度，来理解数据网格。这样导致概念理解越来越复杂，但如果我们聚焦在业务上，会更容易理解这一概念。

　　比如：数据质量往往会影响业务分析和决策的准确性，而通过实施数据网格范式，可以提高数据的质量和准确性，从而增加企业之间的信任，然后更广泛地利用数据做出正确决策。

　　从这个角度看，领域所有权是核心原则之一，它保证了生成数据的团队对数据的质量和准确性负责。这种数据作为产品的原则确保了与其他组共享的数据是准确的、可重用的、自我记录的，并且符合高标准。

　　数据网格和数据架构并不是“非此即彼的关系”

　　既然数据网格如此重要，为什么很多首席数据官重点关注的是数据架构？数据网格和数据架构是怎样一种关系？

　　从字面意义理解，数据架构是一个术语，是用来描述将不同的系统编织在一起的架构，就像纺织一样，在组织的数据之上创建一个一致的层。数据架构足够优秀，可以提供更强的洞察力和数据分析能力，并支持来自不同来源的数据的互联性。

　　从数据网格和数据架构二者关系来看，数据网格可以帮助业务团队使用数据进行分析并提高数据质量，而数据架构可以帮助首席数据官和数据治理团队管理对连接数据源的访问，无论这些数据源存储在哪里，不管是数据仓库、数据湖、文件系统，还是SaaS应用程序，都有一致性体验。

　　看上去，数据网格和数据架构各自为政、各负其责，但其实二者是一个统一体。业务团队要数据科技视角理解数据，并且学会正确使用数据，而企业的首席数据官则专注于主动数据治理，旨在减少数据普惠化过程中的摩擦和风险。

　　分布式云带来更强大的灵活性和实用性

　　那么，既然数据网格和数据架构已经能解决很多问题了，为什么又出来一个分布式云？

　　事实上，不管是数据网格、数据架构还是分布式云，最根本的目的是存储数据，以满足应用需求、性能和安全等目标。并且，在大多数企业中，并不存在用于存储、管理和利用数据的通用架构。

　　分布式云的优势是，不是指定存储信息背后的‘方式’，而是代表人们通过正确的技术组合得到的‘什么’。分布式云使组织能够选择适合他们的方法，而不是只规定和推动一种做事方式。因为，用例在变化，需求在变化，技术在变化，这就是为什么很多人都说数据云更关注灵活性和实用性的最根本原因。

　　分布式云可以部署在公共云、本地私有云、混合云和多云的任何组合上。任何分布式云的‘大脑’都是云分析平台，它可以处理和连接来自每个来源和架构的数据。最终目标是，为了从数据中获得最大价值。更重要的是，通过在整个组织中扩展分析引擎和功能的能力，使数据科学家以外的团队能够访问、查询数据，并将数据转化为见解和洞察力。

　　总结而言，存储、管理、集成、治理和使用数据，听起来数据管理非常简单。但是，要想成为一家数据驱动型企业，我们必须通过正确的方法、工具和实践路径来解决纷繁复杂的数据问题。