EDW国际数据管理最新趋势（二）｜信息供应链与数据产品
最近Data Fabric、Data Mesh、DataOps等话题非常火。其实，信息供应链谈的也是同样的东西，那就是如何将数据治理与数据集成整合在一起的解决方案。下图虽然简单但涵盖了非常大的信息量。将4A架构进行了拆解，应用架构与技术架构主要是支撑业务，业务架构与数据架构驱动企业进行数字化变革，在这个过程中靠数据架构打通数据与业务。下面讲述如何设计一个数据产品。类似敏捷开发的Use Case设计，数据产品的设计也可以用一张画布来展示，包括数据产品的输入、输出接口设计，元数据设计，使用场景设计等。接下来是一个具体的数据产品的画布例子。《设备错误修复》这样一个数据产品，输入是IoT数据，通过过滤与加工，捕获异常数据，并进行修复。回到信息供应链，从经典的Bill Inmon数仓体系，从贴源层到数仓到数据集市也在逐步升级，越来越多数仓模型采用更为灵活的Data Vault模型。数据集市变化更大，除了传统的维度模型支撑BI报表和数据可视化，也输出面向数据挖掘平台的数据资产目录，面向AI的知识图谱，面向SOA的流式数据输出等。 最后我们看一下信息供应链全景图第一：数据产品的设计，包括数据产品业务需求（Use Case）设计和数据模型设计（业务逻辑模型）第二：从数据生产到数据消息，中间分为三层：贴源层、中间层Data Vault、信息访问层（多种形态） 总结一下，信息供应链的核心是数据产品，数据产品的核心是设计（业务需求与数据模型）。
查看详情
EDW国际数据管理最新趋势（一）：数据战略与数据治理
今天有幸给大家分享一下，我在前不久参加刚刚召开的EDW2023的一些内容。考虑到分享内容是原汁原味的，所以很多PPT就用的原始英文版。我会给予相应的讲解。EDW大会全称Enterprise Data World，是DAMA International（国际数据管理协会）的年度峰会，由Dataversity主办，是最全面的关于数据和信息管理的全球会议，至今已举办26届。EDW期待什么：为期5天的会2天的深入教程和研讨会50多个案例研究200小时的教育行业专家和从业者专业认证（CDMP）培训和测试1,000多名与会者介绍高级主题最佳实践尖端技术展厅和新产品展示EDW的参与者：由下图可以看出，也是以大型企业为主。各行业都有参与，金融、能源、制造、零售、政府等，与国内情况类似。 这是一些EDW的演讲者，我们熟悉的行业大咖Robert Seiner，《数据质量十步法》的作者Danette Mcgilvray, John O’Brien, Donna Burbank, Peter Aiken。EDW2023在洛杉矶的Anaheim举办，著名的Disney Land就在旁边。我是唯一一位从中国来参加EDW2023的，也是唯一一位华人演讲者。所以今天给大家讲讲EDW2023的见闻及数据治理的国际趋势。（EDW2023开幕式）下图是我在EDW2023的演讲现场，演讲内容是关于数据模型管控与DataOps，现场座无虚席，大家听的很专注，时不时有人提问题讨论，演讲之后有很多人也过来找我单独讨论，对我的演讲很认可，我很有信心的讲我们的数据模型管控解决方案在国际上是很先进的。下面，我会精简四个EDW2023的演讲主题。第一个是《数据战略与数据治理》，由大咖Donna Burbank演讲， Donna是我的老同事、老朋友，曾任Erwin产品营销VP，我们之前经常一块出差。在本次DAMA中国数据管理峰会上，DAMA国际副主席Marilu Lopez也分享了数据战略的主题演讲。数据战略这个话题比较泛，Donna的演讲很诙谐，我觉得值得拿出来分享一下。定位业务场景是数据战略的首要任务。业务场景无非是在降本、增效、合规、安全这几个大的方向里面找，根据企业的实际情况。其次，如何将数据治理通俗化，你可以先拿家里人做练习，听听非专业人士如何理解数据，试试如何说服他，把数据治理的价值灌输给他。因此，数据战略的推进执行更多需要的是业务视角和通俗化，而不是专业大佬。像下面这张图，数据架构师在大声疾呼“你的数据模型不是三范式将会世界末日”这显然不适合数据战略的宣导。业务高管都是结果导向，跟他们的沟通要简单直接，像“将客户数据与产品使用数据关联，可以提高销售额”，直接讲数据对业务的帮助。可见，西方数据治理发展了40年，仍然需要不断地将数据治理通俗化、业务导向的宣贯。经典的2分钟电梯营销。当你跟CEO在电梯偶遇，你如何介绍你的项目给CEO? 讲“跨数据源的元数据采集，确保一致性”？显然CEO不知道你在说什么。 “获取线上营销活动的客户画像”，CEO听了兴奋点就来了，数据治理继续加大投入！所以，我们做数据治理的人还要学会将其通俗化，跟专业外的人士交流，尽量通俗化，讲业务场景。先将更多的人拉入自己阵营，而不是高高在上的专业老学究，与别人无法对话。团结了利益相关方，我们就可以逐步开展体系性数据治理。 “胡萝卜加大棒”、“阴阳”，一方面管控，一方面共同决策（拉着干活）。除了战略，相关制度、组织架构、衡量标准、平台工具都是需要搭建的。 下面的文化和沟通是重要基础，需要不断地培训和宣贯。这是细化的关键步骤，大家可以参照一下自己企业的数据战略进行补充。
查看详情
数据资产与自助BI的一体化实践
01数据资产中的数据治理随着数据资源被提高到数据资产的高度，数据治理成为确保有效管理和利用数据资产的一组流程和技术，而数据资产目录是包含企业数据资产的全息描述信息的存储库，并充当有效管理数据资产的（逻辑上的）单一事实来源。组织中的分析师和数据科学家有效地使用数据资产目录来回答业务问题，数据治理专员通过数据资产目录实施数据治理策略，并促进数据的正确使用。通过资产目录发布的数据资产，通过以下数据治理能力达成资产认证：数据质量保障 ：数据资产是在有效数据质量监控下的有效数据，通过业务规则承袭，业务用数需求等建设数据治理度量规则，确保用户在使用数据时，或者数据管道搬运数据时，系统把数据质量问题及时提醒数据分析师，以便评估数据质量对数据分析的可用性。权威源头认证：数据资产目录帮助我们识别哪些数据集是数据的权威源头，并通过认证的方式发布资产，并跟踪数据所有权和认证随时间的变化。数据分类分级：数据安全治理要求根据数据敏感度、PII 以及其他关键元数据对数据进行数据安全的分类分级。数据安全等级是数据资产如何共享和流通的依据，是数据资产必备的属性。数据血脉关系：在使用数据集之前，分析师必须首先了解基础数据的来源。数据血缘关系图是对数据来源的可视化展示，为数据集成建立了完整的数据加工流向说明，可以帮助用户确定数据是否具有正确信息，以帮助回答特定业务问题。指标与标准：如果一个组织对关键企业指标和业务属性没有一套一致的定义，那么随着时间的推移，不同的分析师总是会使用一组不同的规则来衡量同一个指标。这种不一致给企业带来了一组相互矛盾的分析结果，并导致对数据缺乏信任。其它重要信息：使用情况统计信息是从基础 BI 工具中收集的，并在数据治理工具中呈现给用户。这些统计信息标识了业务用户对每个数据集的使用程度，并由业务用户来确定哪些数据集在用户群中获得了使用，哪些数据集则尚未发掘业务应用。02数据资产与企业级BI数据资产目录提供的丰富业务元数据，对于数据分析师和数据科学家来说是非常宝贵的，因为他们可以了解更多的数据上下文信息，并决定在分析中使用哪些现有资产。不过，只靠这个工具还不能完全满足组织的完整治理需求，因为它们无法支持企业中所有数据使用者的需求。典型的业务用户不会将数据目录工具用作其日常工作的一部分，市场上的BI和分析工具通常没有与数据资产进行有效集成，用户不会从其中包含的大量信息中受益。因此，许多组织都难以从维护这些工具中的治理数据所需的大量持续投资中实现业务价值。另一方面，随着数据管理的发展，企业级BI成为企业数据管理要求，越来越多的企业要求数据分析在数据安全可靠，可管可控的背景下开展：数据安全和合规性： 受管理的BI解决方案包括强大的数据安全措施，以确保敏感数据的保护。这有助于确保企业数据不会被未经授权的人访问。此外，它还有助于确保企业符合法规和合规性要求，如数据安全法，个保法等。数据整合和质量控制： 受管理的企业级BI解决方案通常包括数据整合和质量控制功能，以确保数据的一致性和准确性。这有助于减少数据错误和冗余，提高数据可信度。用户权限和访问控制： 受管理的企业级BI解决方案允许企业管理员配置用户权限和访问控制，以确保只有授权人员能够访问特定数据和报表。这有助于保护数据的安全性。综上所述，数据资产的治理和BI可视化分析是相辅相成的关系，将两者结合起来，可以让BI的自服务能力更强，惠及更多业务用户。同时也让数据治理有的放矢，数据资产落地可用，发挥数据治理的显性价值。下面我分享一下Datablau的探索。03数据分析治理一体化方案（即D&A治理方案）数据与分析（D&A）治理方案是一种组织内部的框架和策略，用于确保数据和分析活动在组织内部有效管理、保护和利用。一个健全的D&A治理方案有助于确保数据的质量、合规性、安全性和可用性，以支持决策制定和业务运营。整个方案涉在产品和工具上，主要达到这几个点：3.1 数据视图统一数据资产的统一编目，可以按照业务的架构关系或者分析主题，将数据进行分类，非常便于用户找到有用的数据。BI工具中通常从数据库中采集到的元数据，是没有业务视角的技术元数据，业务用户需要在技术人员的帮助下，将数据进行分类并进行补全，这在一个企业级发生时，对企业整体分析造成很大的阻碍，不利于数据驱动的数据分析。在我们的产品中，通过BI的接口，我们将元数据的业务语义等信息写入BI数据集中，并将数据目录和数据权限信息同步到用户视角之下，这对于最终用户是非常好的体验，也是数据治理组织应该赋能的方式。 (以FineBI和YonghongBI为例)3.2 数据权限统一数据安全与合规是企业级数据管理的关键要求。在数据资产的定义中，完善了数据的所有者，技术管理者，参与者等干系人信息。同时也定义了数据的安全类别和等级。最后我们需要定义数据和组织间的数据访问策略和授权体系，这使得数据具备了标准化的流通和共享，同时在安全体系的审计和监控之下。传统BI应用都采用了主题集市，这是一个分布式的以部门为单位的数据使用模式。这种模式之下，数据的授权和复制是很难追踪的。现在企业的数据授权，大多是基于权限电子流的授权体系，这在数据比较少的情况下，还可以运转，但是一旦多到授权部门无法执行的地步，我们可能会被迫放松甚至放开数据权限的管理。这在过去很多企业都发生过。根据这些痛点，Datablau发布了基于企业岗权体系统一数据访问的方案。 （基于岗权体系的数据授权与访问）在这个方案中，个人对数据的访问，完全由所在岗位决定。数据的权限粒度到行级和列级，按照对岗位的授权，进行RBAC粒度的权限绑定。最后数据的访问完全由数据网关进行控制。这个方案的优点是管理简单，融入到岗位体系中。最终用户无感知，权限约束由数据网关完成。 （数据网关技术架构）3.3 建立可用数据资产开发流程数据资产的可用性（Availebility）是保持数据资产活力的重要指标。业界过去进行了大量的数据资产盘点的工作，对数据的业务实体进行了整合定义（参见华为L3-L4实体定义），这对于推动业务对数据的理解和管理，数据的业务化连接等方面起很大的作用。然而这对于本文的数据资产与企业BI的一体化运营，还是远远不够的。此项工作的问题主要是盘点的数据资产是一个初级产品，距离可交付的数据产品，还需要大量的工作。在我们的实践中，将数据资产的逻辑层盘点和数据交付进行了拉通，确保发布到BI的数据资产是可应用的数据，并对此进行的专项管理。通过对数据资产的分类，我们将数据资产分为物理态，逻辑态，以及可交付。通过将数据资产和BI数据交付融入到一个体系中，更好的服务了用户。也是我们践行主动数据治理的理念，发挥数据治理的价值。04总结BI工具是我们业务部门最重要的数据分析工具，通过这个集成方案，达到数据资产的赋能，更有利于提高业务部门数据分析能力。同时这也是数据治理非常好的机会，融治于用的主动治理方法，让数据治理价值显性化，提高了组织的业务可连接性。Datablau的产品矩阵和解决方案，为以上方案提供支撑，经过数个案例验证，取得不错效果，希望对您有借鉴意义。
查看详情
2023DAMA演讲回顾｜数据资产入湖管理新实践
下文为Datablau数语科技创始人&CEO王琤先生在2023DAMA中国管理峰会发表的《数据治理新实践与发展趋势》主题分享实录第二部分：数据资产入湖管理这个话题，我们从数据模型管控的经典流程讲起。 这个图在《华为数据管理之道》或Datablau的模型管控解决方案都可以看到。但我们发现很多企业还是不知道怎么做，其中主要问题是模型设计怎么做。 TP侧-业务系统设计阶段，业务系统需求方与开发方会共同做模型设计，这个是传统系统开发的基本功，非常成熟。如果可以打通模型管理与DevOps(CI/CD)会将TP侧管控的更落地。所以，TP侧的模型管控主要是推动业务系统开发要做设计，形成这个习惯，就自然落下来。AP侧是主要有挑战的。首先模型设计谁干？如何建统一数据底座（标准数据模型层），进而数据资产入湖？模型与数据资产目录如何联动？面向业务的数据资产目录？有的企业是照搬数仓的模型设计到数据湖，问题是模型对应的数据资产目录是按数据域，对业务很不友好，对业务不可用。所以AP侧的数据模型是需要拉通业务一起建设的，数据模型与数据资产目录只设计一次，而不是各建各的。所以，今天我来重点聊聊，拉通业务部门建设AP侧业务域模型，同时进行数据资产入湖管理的成功实践案例。下图是这个案例的背景， 业务系统数据需要按业务域设计标准模型层，之后按入湖规范进行评审后入湖。统一数据底座支撑各种数字化转型的应用。下图是数据资产入湖的流程图，这个案例精彩之处在于流程是由业务发起的。业务根据数据需求先梳理业务流程、业务对象、业务属性。之后将这些业务对象、业务属性交给对口IT做数据探源。之后交给数据管理，按需发布数据标准，落标、核标率，数据质量检核及评分。过程中会输出三个产出物： 1、入湖所需数据标准信息清单；2、入湖所需元数据信息清单；3、入湖所需数据质量评分信息清单。三部分汇总为评审数据入湖信息清单。最后交给主题域数据owner进行审批。具体流程如下：这种业务发起的方式大大提高了数据资产盘点的效率，整个流程捋顺了，既不是数据治理部自己闷头苦干最后被定义为自说自话，也不是数据治理部苦苦求着业务部门协助补充业务相关信息。下图是通过一张大表拉通四个利益相关方的实例。最终这些都将作为数据架构或数据资产目录落地到数据资产管理平台。数据模型与数据资产目录的转换可以通过如下方式。将主题域分组、主题域、业务对象、逻辑实体、属性，映射到L1-L5的数据资产目录。设计只需要做一次，数据模型与数据资产目录可以自动同步。总结一下，这个案例给出如何拉通业务部门构建AP侧数据中台的数据架构、数据模型的实践。通过业务部门梳理业务流程业务对象、业务对口IT进行数据探源、数据治理发布数据标准、提交入湖信息清单，最后由数据owner审批入湖。这对于苦苦陷在拉通业务，甚至自己埋头苦干最后还不被业务认可的数据管理部门，是非常有参考价值的。
查看详情
如何通过数据治理来提升业务价值——业务场景治理
数据治理，一方面是为了对数据的规范管理和控制，还有一方面是让数据能够为业务提供服务和创造价值。近些年来，随着数据治理技术发生着日新月异的变化，行业对数据治理的需求和指导也被逐步推进和实践，从宏观上看，数据治理的组织架构、规章制度、标准规范日趋完善，实现了数据规范化管理，但在支撑业务减本增效、支持业务创新等方面尚存距离。具体体现在以下几点：与业务过程脱节无法针对业务过程中的数据需求与痛点进行问题解决，导致治理的数据无法真正满足业务需要或带来价值。低治理效率没有在业务流程中嵌入数据质量管理等机制，无法发现并解决早期的数据问题，需要在业务运行过程中不断纠错和补救，效率低下业务过程指标缺失没有与业务场景密切结合的数据治理，无法为业务过程提供准确和及时的业务指标，无法实现数据驱动的业务管理数据安全隐患只专注企业横向的数据分类分级，而忽略考虑了纵向业务流程中的数据安全与授权要求，可能导致重要业务数据的泄露、篡改和滥用，或者过高的数据分级影响了业务流程的流畅性业务创新受限不结合业务场景去炫新技术、鼓吹大模型，没有高质量和标准化的数据支持，难以实现真正的业务创新与赋能，大数据、人工智能只是工具与手段而已。至此，数据治理进入了一个新的发展阶段，为了避免数据治理成为数据管理部门、IT部门的一厢情愿，而忽视业务部门的需求和参与，形成数据治理的怪圈，企事业机构的数据管理部门开始从宏观的数据治理框架和策略，转向具体的业务流程和场景的数据治理，以此为业务提供有效的数据支持和决策依据，增强业务的参与度和满意度。结合业务场景的数据治理业务参与到数据治理过程中，业务流程是一道绕不开的主题。业务流程是企业为实现特定目的而执行的一系列活动或任务。业务流程是企业运营的基础，也是数据产生和消费的场景。数字化、可视化业务流程，可以通过数据来更好提高业务问题识别度、专注业务问题实际解决，从而增强企业的竞争优势和客户满意度。企业的业务流程可以看作是数据的源头，数据都是在各种业务场景和业务流程中产生和使用的。如果脱离了业务流程，进行的数据治理就可能变成空中楼阁，无法产生真正的业务价值。因此，将数据治理融入到业务流程中，进行业务场景化的数据治理，就变得极为重要。下面以一个大家比较熟悉的保险行业业务来描述如何以业务场景进行数据治理作为例子。我们都买过保险产品，日常也体验过诸如车险、商业医疗险等这些日常险种服务，来年如果不续保、想更换保险公司的最大原因通常也都是对理赔服务不满意而导致，因此保险公司如何提高客户满意度、降低客户流失率，就可将保险理赔选作为数据治理的一个业务场景，定位业务问题与流程、联动各利益相关者制定数据方案。我想通过下面这张图来说明数据治理如何结合理赔业务场景来提升业务价值的。第一步：明确业务目标在选定业务场景的数据治理同时，首先须明确该场景的治理目标。通过客户满意度调查和客户流失数据分析，发现理赔业务中存在客户查询理赔进度困难、理赔流程自动化程度低等问题。因此，确定项目的业务目标是：改善理赔效率，提升客户满意度。第二步：分析业务问题，确定关键数据要素根据业务目标，识别出两个关键业务问题，分析这两个业务问题的根因，确定保单记录、理赔记录、代理商和客服中心的记录作为关键数据要素。这些数据要素关系到理赔进度跟踪和自动化流程执行。第三步：对数据要素按业务和技术维度梳理1）业务维度- 设置理赔时长、客户满意度、自动化程度为关键绩效指标（KPI）- 确定量化考核指标，如理赔时长减少5%，满意度达到4.5分等- 制定数据治理规则，如理赔政策一致性规则、数据质量规则2）技术维度- 明确关键数据要素的来源系统，如保单系统、理赔系统- 数据集或表单，如保单标头、理赔内容等- 信息项与属性，如理赔类型、理赔金额等第四步：建立规则与属性的关联将业务规则与技术属性关联，例如将理赔政策一致性规则与理赔类型属性关联。第五步：构建血缘关系通过关联保单系统和理赔系统中的数据要素，构建起端到端的血缘关系，包括业务血缘、数据血缘，应用血缘实现业务监控与行动。通过对理赔业务场景的数据治理，明确了业务目标，找到影响目标的关键问题，针对问题建立了数据KPI和数据核查规则，通过数据血缘、业务血缘的联动来跟踪和监控数据，提醒、督促利益相关者及时处理问题，最终实现了提升理赔效率和客户满意度的目标。这充分体现了业务场景数据治理的重要性。与脱离业务的数据治理相比，业务场景治理结合具体业务流程和问题，可以更好发挥数据治理的价值，解决实际业务痛点，而不是停留在一味的落标率、数据仓库质量达标率、血缘覆盖度等纯治理过程中。如何实现业务场景数据治理北京数语科技有限公司致力于做技术最先锋的数据治理厂商，如何将先进的数据治理技术与客户业务流程相结合，通过智能化和自动化创建数据治理业务场景，帮助企业快速落实业务流程的数据和规则，技术驱动的数据治理与业务流程结合，从而实现企业的数字化转型和价值增长。数据治理和业务流程之间存在着紧密的联系和相互影响。一方面，数据治理为业务流程提供了可靠、准确和及时的数据支持，帮助企业做出更好的决策和行动。另一方面，业务流程为数据治理提供了清晰的目标、需求和反馈，帮助企业优化数据的生命周期和价值。根据上述保险理赔的例子，通过将数据集、属性、数据标准、关键指标以及法规政策等元素融入业务流程，将人和行为活动关联起来，理解数据在其中的上下文，实现数据治理的业务场景化。如何通过技术进行业务场景治理落地呢？我将以下面三个步骤综合描述。第一步：创建数据治理业务场景数据治理业务场景是指将数据治理与业务流程相结合，形成一个完整的数据治理视角，包括业务流程、业务节点、业务数据、业务指标、业务规则、业务利益相关者等元素。创建数据治理业务场景的步骤如下：1）围绕业务场景构建数据治理基础平台：维护好数据标准、做好指标定义，逆向应用系统数据模型，对数据进行分类分级、开发数据质量检核与清洗规则、采集全面的元数据生成血缘。这些是数据治理的基础工作，为数据治理业务场景提供数据的规范性、完整性、准确性、可信性和可用性。2）创建关键业务流程：根据业务场景与业务方进行协作梳理核心业务流程，在画布中定义出关键业务节点形成业务流程。这些是业务场景治理的核心工作，为数据治理业务场景提供业务的流程性、连贯性、逻辑性和可视化。3）关联业务节点中的全方位元素：围绕业务流程智能、自动关联业务场景中的利益相关者、数据集等元素，自动形成人、事、物、活动于一体的数据治理业务场景。为数据治理业务场景提供业务的全面性、关联性、动态性和智能化。 第二步：配置数据治理目标与规则数据治理目标是指根据业务目标分解出业务问题，将问题落地成KPI与指标、规则，通过数据治理业务场景中的人和制度落实考核，设计考核标准、时限。配置数据治理目标与规则的步骤如下：1）明确业务目标：业务目标是数据治理的出发点和归宿，需要明确业务的期望和方向，如改善理赔效率、提升客户满意度。2）分解业务问题：业务问题是数据治理的驱动力和挑战，需要分解业务目标，找出影响业务目标的关键因素和障碍，如查询理赔进度困难、理赔流程自动化程度低。3）落地KPI与指标、规则：KPI与指标、规则是数据治理的衡量和执行，需要将业务问题具体化，定义出可量化和可执行的KPI与指标、规则。如理赔登记资料完整率、现场调查时长、审批时长、付款时长。4）设计考核标准、时限：考核标准、时限是数据治理的激励和约束，需要根据KPI与指标、规则，设计出合理和可达的考核标准、时限，如数据质量达标率、数据治理完成率、数据治理周期、数据治理奖惩等。三、驱动业务流程提升与改进业务流程提升与改进是指根据数据治理目标与规则，实时监控业务场景中设定KPI变化、分析业务指标趋势发展，对触碰设定的阀值预警，根据规则进行预案决策。驱动业务流程提升与改进的步骤如下： 1）实时监控KPI变化：KPI变化是数据治理的反馈和结果，需要实时监控业务场景中设定的KPI，如业务指标、数据质量、数据安全等，及时发现数据治理的效果和问题。2）分析业务指标趋势发展：业务指标趋势发展是数据治理的分析和预测，需要分析业务场景中的业务指标，如审批时长、赔付时长、客户满意度的现状和趋势。3）对触碰阀值预警：阀值预警是数据治理的告警和响应，需要对业务场景中触碰设定的阀值，如数据质量低于标准、数据安全出现风险、数据一致性出现差异、数据分析出现异常、数据应用出现问题等，及时发出预警和通知。4）根据规则进行预案决策：预案决策是数据治理的决策和改进，需要根据业务场景中的规则，如数据质量修复、数据安全处理、数据一致性协调、数据分析优化、数据应用改进、紧急业务行动等，采取相应的措施和方案，提升和改进业务流程。业务场景数据治理提升业务价值通过上述保险业案例，我们可以理解业务场景数据治理的核心思想是将数据治理的目标、原则、流程、标准、指标、工具和组织等要素与业务场景相结合，形成一套完整的数据治理体系，从而实现数据治理的有效性和高效性。业务场景数据治理是一种以业务目标为导向，以业务流程为切入点，以数据为支撑的数据治理方法，它能够更好地满足业务的多样化和动态化的需求，实现数据和业务的协同和共赢。业务场景数据治理的优势在于，它能够更贴近业务的实际需求和场景，更灵活地应对业务的变化和发展，更有效地解决数据治理的难点和痛点，更有利于提升数据治理的成熟度和水平，从而为业务流程提供更有价值的数据支持，帮助企业实现业务的创新和优化，提升业务的效率和效益，增强业务的竞争力和可持续性。总之，业务场景数据治理是一种符合数据治理的本质和目标的数据治理方法，它能够实现数据治理和业务流程的有机结合，为企业提供更高质量、更安全合规、更具价值的数据，从而为企业的发展和转型提供强大的数据动力和保障。
查看详情
再谈数据标准落标，论数据模型设计工具
工欲善其事必先利其器。工具是用来提高生产效率，其次才是管理属性。一个工具顺不顺手极大影响生产效率和管理效果。工具用不起来，管理制度也落不下去。管理自说自话，下面各干各的，最终两张皮。Datablau参与某全球知名企业数据治理的早期就是这种情况，数据标准挂墙上，由于工具没人用，数据模型设计还是想怎么设计就怎么设计，所谓模型管控形同虚设。中国传统文化缺少工匠精神，对工匠的尊重度和话语权比较低。企业不愿意为效率工具买单，因为是给底下干活的人用的，体现不出来管理亮点，除非知识产权的法律风险。企业寄希望于通过管理平台将企业的资产有效管理和利用起来。国内管理平台不标准化也是很大的问题，这是另一个话题，这里不展开讨论。最终发展出来的形态就是企业雇用大量人力资源外包，带着外包团队搞 “创新”，最后甲乙双方都陷在泥潭里形成负向循环。整体营商环境导致厂商只能追逐短期利益，难以长期专注投入在工具上，所以打造出来的精品工具寥寥无几。WPS算是非常经典的优秀工具，很多人每天在上面工作超过10个小时。撰写一份汇报、表格，在WPS上花的时间如果换成网页端的OA管理系统可能就要数倍时间，不用有效的工具根本完成不了工作。实际情况就是在WPS上撰写，然后粘贴到OA系统中。可以看出效率工具和管理平台的定位和价值泾渭分明。同样，数据领域中，跟数据模型设计相似，数据开发平台也是工具+管理的场景，由于工具不够好使，常常开发熟手喜欢在其他第三方工具中撰写SQL，如Dbeaver, UltraEdit，而不是在ETL系统中设计job或管理平台中写SQL。设计一个ETL job比写十个存储过程还慢。实际情况就是第三方工具中写SQL调试，运行通过后拷贝到Excel，最后由Excel导入管理平台。这样的管控只能在批量Excel导入时才能开始，已经太晚了，审批时再让开发人员补信息，都是应付了事。所以工具的关键是效率！帮匠人提高效率才能真正用起来。管理制度才能落下去！管理工作常常需要以润物细无声的方式来落地，近几年大行其道的敏捷开发就是将管理做轻做到每日的站立会议里，及时调整需求，及时发现blocker。传统瀑布式以阶段性交付物作为管控，过去十几年的血泪史证实瀑布式对于现代应用开发越来越难成功，常常评审时已经开发完了或者需求已经变更的物是人非了。好的实践，例如：源代码的编码规范在每次工具中编译时都会提示，如果等到几百万行代码都开发完了，提交代码评审改也改不动，于事无补，只是走形式。曾经看到有个企业做数据模型管控仅是在项目上线时在管理平台上提交一个Excel，要求设计的模型与数据标准在Excel里说明映射关系。实际执行时，项目还是粗放式开发，到上线前补这个Excel。看上去都落标了，实际质量可想而知。这种模式显然在执行层面还是两层皮。上线时应付了事。数据标准还是落不下去。归根结底是工具不好用，降低效率，导致开发人员私底下仍然各行其是，怎么快怎么方便怎么来。管理制度自然落不下去。回归到主题，什么是高效的数据模型设计工具？图形化设计能力ER图设计是图形化设计，而不是弹出个表单逐项去填。我几乎没见过有人真用表单去建模的，实在是太慢太难用了，顶多就是做些小修改时会用到。1. 图形化拖拽式模型设计2. ER图自动布局（Diagramming Layout）数据模型的主流表达法有：Peter Chen,1976年由华人Peter Chen发明的最古典的表示法 IE(Information Engineeing)，最广泛被使用的Barker， Oracle相关工具采用此表示法IDEF1X，美国联邦政府广泛使用的表示法· Datablau DDM采用Information Engineering，源自Crow's Foot表⽰法（也有叫做James Martin表⽰法的），中⽂翻译中对使⽤了Crow's Foot表⽰法的模型.也有笼统的称做鸭掌模型的（关联关系的关联基数中采⽤到了⼀个鸭掌形的三叉线来表⽰）。下图是IE表示法的关系：· 自动布局一个数据模型中通常有成百上千张表和关联关系，叠放在一起，如果手动摆放每个实体和关系是能把人搞崩溃的工作量，自动布局是模型设计工具必备的功能。下图是个典型的反例，所有实体矩形都需要手动调整大小才能展示完整的字段，每个实体的位置需要手动调整才能显示完整，每个关系线也需要手动调整。这个工具就是表单形式编辑加图形静态展示，本质上不是模型设计工具。追求工具顺手好用、提高效率的开发人员，显然是不会去用的，还不如直接在Excel输入，再统一转换。作为设计工具不能设计，只能当成表格去录入，就失去了设计工具的意义，管理目标更达不到。图形设计能力对于模型设计工具是最关键的！Datablau DDM支持多种自动布局模式，帮助设计人员节省数百个小时，真正使模型设计工具用起来，企业数据模型管控模式落地。3. 撤消、恢复（UNDO/REDO）撤消、恢复是作为工具必须具备的能力。表、字段、属性、关系的设计需要反复修改斟酌， UNDO/REDO是高频使用的功能，提高效率。很多设计操作是复合操作，例如建立外键（FK）关系除了画关系线也会创建外键字段（key migration），背后有一系列的操作，UNDO需要将复合操作的每一步都逆向操作，每步之间有逻辑依赖关系，这是非常复杂的。4. 绘图样式（Theme）ER图是每个企业的数据地图，被不同角色的人反复查看。良好的绘图样式可以帮助相关人员快速理解业务。样式区分不同的业务域，区分主键、外键，区分实体、视图等。总之，数据模型管控和数据标准落标需要有好用的模型设计工具帮助使用者提高效率，进而以润物细无声的方式来将管理制度落地。数据模型设计工具是通过图形化操作来设计，效率是表单方式设计的数十倍。以我们近百家企业客户的实际经验，帮您的数据架构师、数据模型师、开发工程师配备一款高效数据模型设计工具，他们也愿意配合数据管理的宏大目标，推进数据生产规范化！
查看详情符合业务目标的数据战略建设
我们都知道，战略是通往目的的手段，是企业取得最佳商业成果的方法。处于当今的数字化社会，企业需要满足实现数字化转型及数字社会的需求，提升企业数据资产价值，推动行业甚至社会面的数据流通及数据价值变现。因此企业更需要重视企业的战略部署。数据战略是企业战略下的一部分，在早期数据的重视度不足的情况下，企业战略建设更重视业务战略的建设，在当前数字社会形势下，国家明确将数据要素定义为生产力的重要组成的情形下，企业意识到数据的重要性，也认识到数据治理的重要性以及良好的数据治理将是企业数字化转型的重要保障。因为作为数据治理体系的先行建设内容——数据战略建设也得到企业家们的重视。数据战略的建设目标是为了更好地支撑企业业务战略的实现，所以数据战略建设必须符合企业的业务目标。关于企业战略、业务战略及数据战略▶ 定义• 企业战略就是企业以未来为基准点，为寻求维持持久的竞争优势而做出的有关全局的筹划与谋略。• 业务战略是指把企业拥有的一切资产通过剥离、出售、转让、兼并、收购等方式进行有效地运营，以实现最大的资本增值。--MBA智库• 数据战略是组织开展数据工作的愿景、目的、目标和原则。它包含数据战略规划、数据战略实施和数据战略评估--来自《数据管理能力成熟度评估模型（GB/T 36073—2018）》上图中企业战略架构说明了企业中各层次战略的主要建设内容及对应的企业组织架构位置。上图中另一个经典的战略调整模型节选自《dama-dmbok2.0》，在这个模型我们可以清晰地理解到业务战略与IT战略依赖关系。在《dama-dmbok2.0》另一张典型的信息模型（阿姆斯特丹信息模型）中，更详细地描述了从业务到IT的信息关系，我们可以从数据管理的角度上，将数据管理部分的内容与这个模型进行对应。数据战略的重要性好的数据战略不仅包括企业发展和运营的业务目标，还包括对实现这一目标所需的组织与人员、制度与流程、技术与工具的支撑和保障！（如下图）· 在数字化时代，数据是企业重要的生产要素，企业战略的最终实现离不开对数据的有效利用。所谓数据战略就是指战略性地使用数据，以推动企业战略的实现。因此，数据战略目标应与企业战略目标一致，通过有效的数据治理让数据得到更加合理、有效、充分的使用，驱动业务目标的实现。脱离了使用，数据治理就没有了意义；脱离了业务目标，数据资产就没有了价值。· 在当前的数字化转型大环境中，企业的数据战略是与企业业务和数字化战略相关联并衍生的。· 企业的数据战略将回答了以下的问题：企业将如何使用数据来产生价值——通常是通过数据驱动的洞察和业务流程，以及数据支持的业务模型(数据货币化)，企业如何管理数据以产生价值，即收集、存储、处理和分发数据(数据基础)数据战略定义了反映组织当前数据成熟度状态的能力和发展需求。因此数据战略是“必须拥有的”，数据战略比以往任何时候都更重要。数据战略框架我们可以参考国外成熟的数据战略框架来进行数据战略的建设：在这个框架中，通过数据战略将业务目标与技术解决方案联系起来，并分等级层次解决了不同等级下统一数据和业务。第1级：数据战略--“自上而下”与业务优先级保持一致：数据战略最重要的起点是对齐经营战略使用数据策略。第2级：数据治理--管理围绕数据的人员、流程、策略和文化：数据治理提供用于管理有关数据的人员、流程、策略和文化的框架。组织在这个级别的成熟度（或缺乏成熟度）可以决定您战略性地使用数据的选项，以及将其付诸实践的时间表。第3级：数据管理实践--利用和管理数据以获得战略优势：这个级别包括各种数据管理实践，这些实践有助于利用数据获得战略优势，例如数据质量、主数据管理、数据仓库等。第4级：协调和集成不同的数据源：数据集成将会有许多不同的问题需要解决：所有这些数据源在哪里？我们需要的关于客户的所有这些来源的数据是多少？我们怎么知道它在哪里，它应该在哪里？我们如何整合所有不同的格式？我们如何理解它并通过元数据获取信息？客户的名字、姓氏、地址的含义和上下文是什么？第5级：“自下而上”的数据源管理和清单：在当今数据经济社会，使数据管理变得复杂的原因是，您有许多不同的数据源：关系数据库、大数据、非结构化数据、XML、文档、语音和媒体，那么如何理解它们呢？这些不同的来源如何应用于为业务战略提供信息。数据战略建设中需要理解并符合业务目标▶ 寻找实现商业价值的“杠杆”数据战略需要识别如何在实现商业价值及业务需求上的“快速获胜”。我们可以通过回答以下问题来获取可快速，易获得最高业务价值的数据领域：1.是否支持高知名度、高关注度的业务产品或者新的业务营销活动？2.是否可以集中宝贵的资源、时间及精力来进行您的数据活动，而且不是低价值的数据活动？3.您的数据战略及数据活动策划是否围绕业务价值的关键领域，并可以通过建立模型或架构设计来帮助战略实施。▶ 应用结构化数据治理框架成功的数据战略在很大程度上依赖于数据架构和数据治理，结构化的数据治理框架有助于协调业务和IT以获得长期成功。我们在设计结构化的数据治理框架时，需要从组织、流程、管理制度、工具和企业文化等方面来思考如何支持企业数据治理的愿景及数据战略的实现。通过数据治理框架协调业务和IT的数据活动，并将在短至1年，长至5年内获得成功（由于当今的多元化商业环境，数据战略一般周期为3年）。▶ 与各种各样的利益相关者交流在我们开始制定数据战略时，我们不仅仅需要理解并分析各种资料及需求文档（企业战略、业务战略、企业架构、数字化转型架构），我们还需要识别在组织中数据活动的利益相关者，并与他们充分沟通！▶ 制定及分析商业案例（业务案例）通过制定及分析商业案例（业务案例），特别是当前聚焦的案例，考虑数据战略如何支撑并服务于企业的商务活动，提升业务价值。▶ 映射组织能力从数据战略框架上我们可以发现，数据战略的实施与企业中组织架构及组织变革是有密切关系的。组织能力、组织结构和角色是任何数据战略的关键，数据战略的组织能力分解需保持与业务流程的一致性，数据治理组织架构需保障业务利益相关方的充分参与。▶ CDO团队的职能范围和优先任务应与业务战略保持一致根据IBM商业价值研究院发布的文章中提到，作为企业数据治理的领头人角色CDO（首席数据官）及他的团队在企业中的职能范围及团队的优先任务是如何使企业数据管理与业务战略保持一致：▶ 寻找“速赢”最佳能体现数据战略是否符合业务目标的展示方式，就是我们需要数据战略能快速并阶段性地展示可实现或已成功的数据驱动的业务价值。所以进行数据战略建设时，我们需要寻找“速赢” 的项目。· “速赢” 项目是一个在能显示早期价值的同时朝着长期目标努力的项目。· 展示数据战略工作的早期价值，随着时间的推移继续提供迭代价值。· “速赢”并不是一种草率的“快速解决方案”-将影响到未来使用。· “速赢”的第一步是精心策划，将为未来的努力奠定坚实的基础。▶ 战略规划与指标分解工具数据战略并不是愿景，也不是仅仅是一句话的内容，我们需要实现将数据战略进行战略规划、战略能力分解、战略指标分析等内容。数据战略本质也是战略，所以我们可以参考战略分解框架或工具来进行我们的数据战略的建设：上面来自BCG的GFCPL框架。从这个框架上我们可以：体系化地梳理及思考流程，帮助执行团队将战略转化可执行的、清晰的实施路线地图。▶ 数据战略实施路线图数据战略建设最终需要一张实施路线图来描述我们是如何实现数据战略的。除了我们在制作实施路线图上确定关键数据活动与关键业务计划保持一致外，还需要注意在人员配置和培训上保持一致。我们还需要知道，数据战略实施路线图不是一张活动内容清单，我们必须定义好“阶段主题”、“快速胜利”、业务价值、阶段目标、关键利益相关者的阶段认同等。▶ 数据战略模板数据战略模板定义了数据战略的关键内容。为了帮助企业制定数据战略，可以采用如数据战略模板这种可视设计工具，数据战略模板将定义核心元素并指导要解决的问题。企业可以参照数据战略模板，并在与业务专家、数据经理、数据科学家和其他利益相关者讨论和定义数据战略的关键内容的研讨会上使用。数据战略模板定义了数据战略的关键内容。1.战略层定义了行动需求、愿景、任务和范围以及业务价值2.业务层包括数据“用例”和能力3.实现层包括行为准则和路径支持数据战略的最佳数据实践以下有总结出来10个最佳数据实践，这些数据实践可以帮助推动企业数据战略的成功。这些实践来源于人员组织、流程和技术的实践角度，他们分别是：▶ 让数据成为全公司的战略资产创建数据优先的文化：• 指定执行领导来倡导数据战略和相关计划。• 获得不同管理层的支持，从最高管理层到团队领导。数据战略需要得到所有利益相关者的支持和优先次序。• 定义整个公司的通用定义、原则和指标，必要时组织内部培训。• 通过单一事实来源实施跨职能、横向数据流程。• 通过让非技术团队访问数据来实现数据民主化。▶ 鼓励数据驱动的思维方式数据驱动就是本能地转向数据寻找答案，并根据数据的内容做出决定。数据需要成为回答问题的首选。客户流失需要多长时间？是什么导致了这一收购高峰？为什么我们的客户转向免费增值替代方案？▶ 跟踪关键绩效指标和指标将您的战略目标与关键绩效指标（或 KPI）相匹配。▶ 不要去追逐最新的技术趋势数据策略与简单的技术堆栈一样有效。成功的关键在于流程和数据质量，而不是技术。▶ 找到合适的人来推动数据战略您的数据战略主管不必是技术人员。您只需要知道如何在团队之间导航、做出数据驱动型决策并了解数据如何与业务目标相关联的人。销售、营销和技术交叉的产品经理可能是您理想的人选。▶ 建立无懈可击的数据安全流程数据安全关系到每个人。这不仅仅是IT、法律或您的外部数据保护官要处理的事情。▶ 找到合适的数据分析工具和技术每个人都应该能够检查与他们相关的数据集并从中得出结论。最好的分析技术是那些在提供战略见解的同时仍尊重您的数据治理和隐私政策的技术。▶ 建立单一事实来源您需要每个人都可以信任的单一事实来源 （SSOT），而不是跨团队使用孤立的数据。▶ 通过数据自动化提高生产力数据自动化是使用自动化工具（而不是手动执行）提取、转换和存储数据的过程。▶ 使用Web数据丰富现有数据无论是大型企业还是初创公司，内部数据都不足以推动出站销售和营销。数据需要使用来自互联网的信息来完成，特别是对于潜在客户生成。数据战略与数据架构数据战略包括了数据架构，从两者之间的作用关系来看是这样的。而数据架构从企业架构这一角度来看是依赖于业务架构，并需要保持与应用架构的一致性要求。所以符合业务目标的数据战略建设可以通过数据架构来实现与业务战略的一致性。从体系思考中我们需要将数据架构跟数据战略对齐，通过工具实现数据战略与数据架构的对齐。从上图我们可以更清晰地了解到数据架构和数据战略之间的关系，及是如何支持企业战略落地及企业动作的。数据战略评估关于数据战略，除了制定、能力分解、规划、实施路线图等建设工作外，我们还需要通过制定数据战略的成功评估指标来评估数据战略的成果并为数据战略的修正提供帮助。关于数据战略评估的核心组件同样我们也可以参考下面内容：作为数据战略的评分卡，我们需要分别针对识别、配置、存储、处理和治理这五个核心评估组件进行能力及指标拆解，与其他评估框架一样，通过各组件的指标评分汇总，最终形成数据战略的总评分结果。我们的目标是通过评估来促进及改良我们的数据战略，我们需将评分卡与实际目标（包括数据目标及业务目标）在工作记录表格进行关联。反思▶ 组织数据战略建设需要打造组织自身团队建设，而不是只依赖外部输入也许您会觉得制定符合业务目标的数据战略很不容易，而且有不少企业总会是想这些内容只要找到合适的乙方咨询团队来帮企业制定就可以了。关于这一点虽然大部分企业领导及数据管理部门领导口头都是说这样是不对，但是由于种种原因，他们还是会认为乙方咨询团队可以搞定一切，而且也不需要太多费用及时间。他们更可能认为付钱就可以解决一切了（虽然大部分最终都总是会认为付的钱不值或者少付），这也许就是典型的口不对心的表现吧，个人认为这也许就是国内的数据管理现状之一吧。所以，个人在这里还是会老话反复提一下：“临渊羡鱼 不如退而结网”，“授人以鱼不如授之以渔”。个人认为企业如果希望通过外部助力来进行企业的数据战略建设，必须认识到下面的几点：· 外部咨询永远都是项目制交付，最好的结果也只能是阶段性有效。· 企业业务的敏捷需求，需要的是最了解企业内部实际情况的人依赖业务发展而进行数据战略及数据治理规划调整。· 在当前数据量激增，需求复杂性增加、企业商业模式快速调整的现状，要求支撑业务战略的数据战略也需要敏捷迭代，在企业内部不同部门的数据策略也需要跟随部门业务迭代而变更。▶ 数据战略的成功是需要充分利用IT工具及技术自动化能力在当今数据量激增的时代，只依赖或者大部分工作依赖人工来进行数据管理及数据处理是不现实的，我们需要充分使用合适的IT技术工具及其自动化能力来协助我们的数据管理工作，通过IT技术及平台固化数据治理流程，约束并规范人们的数据操作保障数据正确、安全、高质量地使用，最终成功实现组织的数据战略目标。当然，我们不需要一定采用最先进的技术，只需要根据我们的现状采用最合适的技术，不需要盲目地追求及崇拜技术的先进性。另外就目前来看也许“数据资产管理”平台可能是实现当前组织数据战略的最佳工具。因为它可以打通从业务到数据，从数据的资产价值及路线来管理并使用数据，能有效促进了组织各用户角色的数据应用，也有利于体现组织数据战略落地的价值（包括数据价值及业务价值）。
查看详情
数据模型设计必读方法论！很实用
数据架构的重要构件之一是数据模型，当然从数据架构的视角来说的数据模型是指企业级数据模型。本篇文章更多是讨论如何设计和管理数据模型，此处的数据模型是泛指在组织中通过数据建模的过程，来发现、分析和确定数据需求范围，并用于表示和传达这些数据需求的成果。不仅仅是指企业级数据模型，也包括系统级或应用级的数据模型。01概述首先，我们明确什么是数据模型及数据建模：数据建模是发现、分析和确定数据需求范围，然后以称为数据模型的精确形式表示和传达这些数据需求的过程。数据建模是数据管理的重要组成部分。数据模型描述了组织的数据资产并促使组织理解其数据资产。数据模型根据组织的了解或组织的期望来描述组织的数据。数据模型包含一组带有文本标签的符号，这些符号试图可视化地表示传递给数据建模者的数据需求。数据建模的常用方案（模式）会有：关系、维度、面向对象、基于事实、基于时间和NoSQL建模。数据模型的组件有实体、关系、事实、键和属性等。关于数据模型和设计的语义图如下所示：数据建模的业务驱动因素可以通过数据模型对于实现有效管理数据的重要性来说明，数据模型可以：提供有关数据的通用词汇表捕获并记录有关组织数据和系统的明确知识在项目期间充当主要的沟通工具提供自定义、集成甚至替换应用程序的起点那么建模的目标会有什么呢，从下图我们可以了解到：02基本概念建模的数据类型可以通过四种主要的数据类型来进行建模：类别信息：用于对事物进行分类和分配类型的数据。例如，按市场类别或业务部门分类的客户；按颜色，型号，尺寸等分类的产品；订单按打开还是关闭状态分类。资源信息：所需资源的基本概要执行诸如产品，客户，供应商，设施，组织和客户等操作流程。在IT专业人员中，资源实体有时称为参考数据。业务事件信息：在进行业务流程时创建的数据。示例包括客户订单，供应商发票，现金提取和业务会议。在IT专业人员中，事件实体有时被称为事务业务数据。详细交易信息：详细交易信息通常是通过销售系统（商店或在线）产生的。它也可以通过社交媒体系统，其他Internet交互（点击流等）以及机器中的传感器产生的，这些传感器可以是船只和车辆的一部分，工业组件或个人设备（GPS，RFID，Wi-Fi等）。与业务事件信息的使用方式类似，此类详细信息可以被汇总，用于导出其他数据并进行趋势分析。这类数据（大容量和/或快速变化的数据）通常称为大数据。这些类型指的是“静态数据”。例如，还可以在包括协议的系统方案以及消息传递和基于事件的系统的方案中对动态的数据进行建模。数据模型组件：实体、关系、属性、域。这些概念估计大部分人特别是对于数据模型有所了解的人都较熟悉。我们在这里只是将其中一些容易被忽略或者有些特点的概念说明一下。实体的别名（用下面的表格来说明实体还可被称为其它名称：实体类型、 实体实例）实际上实体的别名也可能跟建模模式相关，在关系建模中，经常就称为实体，而在维度建模中，会称为维度表和事实表，在面向对象建模中，会称为类和对象，在基于时间建模通过使用集线器、卫星表和链接表，在NoSQL建模中会使用文档或节点。另外实体的别名也会数据模型的详细级别（层次）相关，如在概念数据模型中称为概念实体，在逻辑数据模型中称为逻辑实体，在物理数据模型中称为物理表。关于关系，我们在这里用几张图形中说明一下关系的分类，关系在数据模型中会分为一元关系、二元关系和三元关系。关于键，在数据模型中也是很重要的，如我们常提到的主键、外键、代理键等。数据模型中的键可以根据键的构造（简单、复合、替代）和功能（候选、主键、备用）来分类。在构造型的键中我们会分为单键、复合键、代理键（也是单键的一种）；在功能类型的键中我们将分为候选键、主键和备用键，主键和备用键也是候选键。一般情况下，主键是代理键时，实体中同时也会有备用键，这时候的备用键实际上就是业务键。数据建模模式前面我们提到了常用的建模模式会有六种：关系，维度，面向对象，基于事实，基于时间和NoSQL建模。下面我们来了解一下这六种建模模式之间的区别会有哪些（示例、表示法、建模层级）下面是一些表示法的示意图：03数据建模活动在DAMA中，数据建模活动主要是数据建模计划、构建数据模型、查看数据模型、维护数据模型组成。在数据建模计划中，可交付成果包括：图表（模型图）、定义、当前问题和未解决问题、数据血缘。图表是解决了建模的详细程度（概念、逻辑或物理）和建模模式的表述；定义保障了数据模型的精度要求；数据血缘将协助数据建模人员对数据需求有非常深刻的了解并确定源属性；关于当前问题和未解决问题的文档，将会联合建模小组外相关人员来负责解决问题。构建数据模型主要是考虑正向工程和逆向工程的建模。说明建模是一个经常反复的过程。查看数据模型就是将对数据模型进行质量控制。维护数据模型，让数据模型与其他元数据相似，需要根据需求的变化而对数据模型进行更新。而且也需要保障数据模型不同级别间的一致性（如逻辑模型与物理模型的一致性）。数据建模工具我们需要知道就是哪些工具属于数据建模所需的：数据建模工具（特指构建数据模型的工具，当然也有可能包括其它建模相关辅助功能）、血缘工具、数据分析工具、元数据存储库、数据模型模式、行业数据模型。数据模型治理数据模型与设计质量管理数据模型和数据库设计应在企业的短期需求和长期需求之间保持合理的平衡。可以通过下面几个方面来保障数据模型和设计质量：1、制定数据建模和设计标准标准数据建模和数据库设计可交付成果的列表和描述适用于所有数据模型对象的标准名称，可接受的缩写和不常见单词的缩写规则的列表所有数据模型对象的标准命名格式的列表，包括属性和列类词创建和维护这些可交付成果的标准方法的列表和说明数据建模和数据库设计角色和职责的列表和描述数据建模和数据库设计中捕获的所有元数据属性的列表和描述，包括业务元数据和技术元数据。例如，准则可以设置数据模型捕获每个属性的血统的期望。元数据质量期望和要求有关如何使用数据建模工具的准则准备和领导设计评审的准则数据模型版本化指南阐述不鼓励的做法 2、审查数据模型和数据设计质量项目团队应该对概念数据模型，逻辑数据模型和物理数据库设计进行需求审查和设计审查。审查会议的议程应包括审查初始模型（如有），对模型所做的更改以及任何其他已考虑和拒绝的选项，以及新模型与现有模型或架构标准的符合程度的项目。在未经批准的审查中，建模者必须重新设计以解决问题。如果存在建模者无法自行解决的问题，则最终的发言权应由模型反映的系统所有者给出。3、管理数据模型的版本控制和集成数据模型和其他设计规范需要仔细的变更控制，就像需求规范和其他SDLC交付品一样。数据建模指标可以用来提供数据模型验证示例的一种方法是Data ModelScorecard®，它提供11种数据模型质量指标：构成记分卡的十个类别中的每个类别，以及所有十个类别的总体分数（Hoberman ，2015）。关于数据模型和设计的内容本文将基本内容表达出来，如果想更好地进行数据建模并提升个人建模水平，最终达到数据建模师的水平，还是需要去学习相关理论并进行大量的练习及实践。(注释：本文图文均为转载)
查看详情
基础数据标准落标白皮书
数据标准概述1.定义数据是由特定的环境产生的，这些环境因素包括生产者、时间、系统等， 这就造成了同一个语义的数据，会有多种不同的定义方法，这给后期进行数据汇集和整合带来障碍，因此，数据处理的前奏就是数据标准化，数据标准作为一个统一的数据共识，在企业的标准化中起到重要作用。数据标准一般包括下面几个，为了统一本文阅读共识，列出如下：· 基础数据标准：标准是针对数据原始定义，一般面向原系统数据或ODS层数据。包括业务语义，管理标准，技术规范，质量要求等。· 指标体系：标准针对衍生型数据，一般面向集市层的报表等计算型数据。· 标准代码：具体指数据标准中的枚举值和语义，可以作为基础数据标准的一部分，数据标准维度也是大部分来源于此。· 标准编码：特指主数据治理中的实体对象数据的唯一编码和规则，比如设备唯一编码。· 业务术语词典：指企业数据定义过程中，从业务名词到物理表和字段的标准化翻译的词根和词素。· 其他规范：包括数据库设计规范，元数据规范，模型规范等，具体可以在其他治理活动下定义，也是广义数据数据标准的一部分。一般情况下，本文所述的数据标准落标主要指：（a）基础标准落标 （c）标准代码落标 （e）命名标准落标指标体系的落标因为在数据后期，是比较容易实现的，因此不在重点讨论中。标准编码则特定于主数据治理过程中实现，不在此赘述。2.落标概述数据标准的落标意义在于，企业由此开始进行数据驱动文化，开始从源头进行数据的标准化生产，加速数据的融合与统一的效率，节省大量数据应用和处理的成本。数据标准的落标程度可以分为基本拉通型落标和全局管控型落标。基本拉通型落标是指设计的数据元素符合数据标准的基本语义和业务规则，物理定义符合技术规范，具体数据语义可以进行无规范的衍生。落标范围重点是核心业务系统的核心标准和交叉标准，还有数据仓库系统的。这种类型适合中小银行的上手阶段，以及没有重大系统升级机会的系统，其核心目的是减少数据融合成本，加速数据消费的效力，适合进行数据化驱动转型的企业。全局管控型落标是指设计的数据元素符合数据标准的基本语义和业务规则，物理定义符合技术规范，具体的物理数据语义需要进行有规范的衍生，数据质量需要落地为数据库约束或者质量验核规则。落标范围是核心业务系统和重点业务系统，以及数据仓库等衍生系统。这种适合IT能力强，数据基础好的企业。其核心目标是掌控企业全局数据，做到数据快速迭代，适合致力于打造数据快速创新型企业。3.落标过程中的衍生数据在落标过程中是可以进行一定程度的数据语义衍生的，比如电话号码 衍生为供应商电话。如果衍生的字段有确实的细化语义，或者其他业务要求，就需要也有一些数据标准需要定义为子类标准或者同义标准。子类标准当一类数据标准有进行细化的必要，并带来特定的语义和业务规则，就需要在原有标准上进行衍生。比如“电话“衍生为”手机“和“座机“，这是因为这两类衍生标准带来不同的业务属性，不同的数据格式，以及不同质量检查规则。也有一些可以不进行标准级别的衍生，比如“姓名“，具体语义的设计可能是“客户姓名”和“供应商姓名“，这两个衍生可以不作为子类标准制定，这是因为业务语义是因为数据所在的语义环境变化，本质并没有不同。同义词同一类语义标准，在不同的业务口径中或者不同的人群中，会有不同的名词，比如保单号和保单代码是同一语义的名词。这时候需要将两者定义为同义词，并在每一个定义时，标注清楚使用语境。4.落标难点我国银行业的数据治理已经开展十几年，在有数据监管驱动和自身数据价值挖掘的驱动下，大部分行已经进行了数据标准框架定义和梳理，发布了各个板块的数据标准指导文件，有的甚至落实了数据标准流程和人员角色。然而数据标准的落标在大部分普通银行仍然是个不是很理想。现在数据标准梳理和发布是比较容易的事情，各咨询厂商手里也积攒了大量各个行积累的数据标准，可以比较全面的提交给各个银行。可是落标不理想的原因我认为有这么几个问题。1.存量数据大，积重难返根据破窗常理，没人在乎再多一块破窗户。数据业务系统绝大部分已经建设完成，木已成舟，不标准也没法修改了。2.开发设计规范不重视开发团队的责任和考核点主要是系统上线，支撑业务，在开发团队的很多人看来，数据标准化的设计是一个可选项，影响上线时间才是大事。3.标准落标不方便，影响效率我看过很多家咨询公司的数据标准，技术规范普遍缺失。这证明标准开始就没有认真考虑落标问题，这就造成落标很不方便，先在Excel里查找，再手工拷贝，再类型翻译，确实影响效率。4.监管与激励缺失，落与不落都一样现在的数据结构和字典中，落标与不落标是没有量化跟踪的，这直接造成激励与认责无法落地执行。5.人力与关注点缺失，没人管普通银行并不像四大行那样人财雄厚，数据治理工作普遍是3-4个人兼职完成，日常被大部分其他工作排满，不可能把这项工作量化起来，也无从着手。国内外银行落标简介为了认真的研究这个命题，我们决定调查几个国内落标的典型案例，看看我们能从中学习点什么。调查从总体看思路，细节不符之处在所难免，望读者不吝指出共同完善。1.建设银行落标方法建设银行从2014年新一代项目时，开始大力度的进行彻底的和全方位的数据标准落地工程。建行师从IBM的四层模型法，通过九大银行业概念设计了企业级逻辑模型。依托于此企业级逻辑模型，打造了企业级数据字典。通过设立数据标准处和架构处，进行了流程和规范管制，进行强力度的模型和数据的落标管理。具体请看下面一个示意图：从示意图看出，建行采用了源头控制的方法，基于建行的得天独厚的逻辑模型优势，打造了一个企业级的数据字典，由于业务系统从C模型继承开发，所以存量问题基本得到解决。从模型开发设计阶段开始，模型团队就要根据现有标准进行落标的设计，沟通方式可以是电话或邮件，通过长期工作，效率基本不影响开发进度。缺失的标准通过标准组来进行更改和维护。测试阶段，需要提交数据字典映射到企业级数据字典，每一个新数据项的增加都可以说明这是或者不是标准，都会记录在案。核检阶段，现在主要是送数过程中进行检查，不通过将不能向后台送数。近期要进行上线核检，提高落标的早期检查力度。2.国外银行业落标作为Erwin的开发者，在外企的数据管理领域工作多年，对国外数据管理有较多认识，接触过很多国外银行业客户，如SunTrust，苏格兰皇家银行，citibank等。此前有幸参加了国外的EDW大会。我发现了国外确实数据发展阶段与我国有很大不同。国外普遍比较重视数据建模工作，业务系统成熟多年，数据的修改全部由模型工具控制。会有专业的建模师和架构师来贯彻落标工作。同时，模型工具也已经标准化和全局推广了，在EDW大会上很少听到由讨论落标的话题，在他们的意识里，落标已经固化在建模过程中完成，甚至元数据管理也较少话题，因为也已经成为广泛共识。相反，他们非常多的谈的是Business Glossary， 国内却很少提及。总结一下，国外的系统建设期，因为在建模理论和系统化设计思维方面的优势，再加上企业管理制度的方面比较成熟，银行业的数据建模工具的使用率非常高，使得数据的早期落标得到较彻底的执行。同时，早期的数据标准问题也基本到现在有了成熟的解决路径。模型驱动的标准落标方案1.落标关键点剖析根据笔者的经验与实践，数据标准的落标需要重点考虑三大问题：问题1：什么数据需要制定哪些标准问题2：什么系统落什么标准 问题3：什么人与什么时间执行如果这三个问题没有想清楚，基本数据标准的梳理会停留在Excel层面，标准的政策会停留在墙上，无法走入每个设计者的头脑和每个系统的每个字段。我们先来说第一个问题，什么数据需要制定标准，首先我们回到数据标准所要解决问题的初衷，数据标准主要解决数据在共享，融合，汇集应用中的不一致问题。好的，那么我们看哪些数据会出现在这个这三个环节中，以及哪些容易出现问题。对于与一个企事业组织来说，按照价值链，一般关注三大要素：客户，产品，大运营。IBM和TD将银行业划分为九大概念数据，也是围绕客户与产品的大运营活动细分。那么有如下几类数据会在数据应用过程中，会更多出现融合和汇总的机会，需要格外注意。第二个问题和第三个问题是实际工作中非常困扰的，落标的大多数困难与此有关，因此我将其放在一起来说明。一般我将系统与数据分列如下列表：通过这个表格的内容，我们发现数据标准从源头落地，会减少数据的处理成本，提高数据应用的效益，缺点是对于存量系统和外购系统存在较大改动风险和成本。如果从数据的仓库层进行落标，比较容易着手处理，落标后的下游数据系统则自动统一数据标准，然而数仓层的报表应用与业务系统的报表存在口径不一致性在所难免，仍然需要源数据层进行必要调整。无论从哪一层入手，模型的优良设计环节都是必要条件，否则整个落标过程会没有抓手，流程也不顺畅。2、落标整体方案无论是原系统数据还是数仓数据，都是不同的开发团队负责，遵循软件开发标准的流程包括设计，开发，测试，上线，维护等环节，因此我们需要在这个过程中，将数据标准这个优良的炮弹，送到最前线，同时，管理团队需要参与这个过程的关键节点中，这需要企业在数据管理上提高管理和执行水平。鉴于普通银行当前的数据基础水平，数据的落标同样受到人力和财力的制约。所以一个自动化水平非常高的落标方案是非常切合我国普通银行的发展阶段的。因此，本落标方案的关键思想是在开发阶段由模型设计人员进行落标，标准管理和架构管理人员进行评审和核准，同时，自动检测能力来提高执行水平和激励环节的落地。2.1标准的定位这里主要是在系统的需求设计和准备过程中，我们对数据标准需要准备好一些前提条件：· 标准的技术规范已经准备好 数据标准已经具有详细的技术规范，包括物理数据类型，可以直接应用的物理层上，并已经准备好逻辑数据类型到不同数据库的类型映射。这里数据类型在DDM中是逻辑数据类型，具备自动类型转换能力。· 标准的主题已经准备好 标准的主题其实是标准的应用范围和检索目录，对于具备条件的银行应该设计出逻辑模型，对数据标准进行业务组织。这样在落标过程中，这是重要的选择依据。· 标准已经权威发布 标准已经经过讨论，进行了公开发布，具有流程上的正式性和权威性。2.2模型设计中的落标 数据模型是一个更好的数据字典，其向上承接业务语义，向下实现物理数据，它不但包含了数据字典，更重要的是包含了业务的主题，业务主对象，数据关系，以及数据标准的映射。所以模型及其工具的运用不但是企业数据管理是否成熟的重要标志，也是数据标准落标的重要依托。不进行模型设计和管理，落标操作则事倍功半，因为失去了管理的最佳时机。通过创新一个模型工具，在开发阶段，自动管理数据字典和模型，实现下面三个落标操作。建立标准和数据的映射 标准落地的属性继承一般情况下，数据字段落地标准时要引用标准中上述内容，另还包含数据的标准代码，其中强制性一致的是标准中的技术规范。物理字段的落地衍生对于一个标准落地的物理字段，如果语义本质是相同的，并且业务规则没有变化，不过满足系统环境，而加上特定限定环境。比如“电话”在供应商的表里叫“供应商电话”，这是一种落地衍生情况，并不需要创建一个新的标准。如前一节所示有一些则需要新的标准或新的子类标准。建立代码的标准引用对字段中的数据类型的引用进行标准化，坚决杜绝Comment里手工写枚举代码的情况。标准化命名 2.3模型的评审 在模型的开发基本完成后，在系统的测试阶段，我们加入模型的评审环节，这个作为系统上线的前奏，避免上线前的修改造成时间紧张等情况。模型评审前需要创建模型基线，评审包含以下几个内容：标准的落标引用 模型工具应该自动提供报告，重点检查是否有重要的标准没有引用和落地，通过自动化的工具，智能发现落标的潜在问题。自定义标准与词典的评审和转化DDM模型工具具备自定义数据标准和词典等能力，通过与开发团队评审，提高自定义标准的转化率，完善标准库。元数据的充足率模型工具应该自动提供报告，列出中文名称没有填写的字段。其他模型质量比如检查模型主题覆盖率等。2.4上线的核准 一般情况下，系统的上线过程需要一个更加标准的流程，提交设计，文档，测试报告，升级步骤等内容，有专业的团队和流程工具来审核。在这个过程中，我们并不主张此环节进行落标的核准，因为此环节已经太晚，我推荐在评审环节完成落标工作，在此环节中，只需要提交落标和模型报告作为过审文档。模型核准环节包含以下几个工作要做：模型生产库基线与封板根据评审时建立的模型分支，建立模型的生产库基线，并进行封板操作。模型基线报告提供模型标准数据字典，标准落标报告，模型质量报告。2.5自动监测变化 对于已经发布的模型，随着进入维护期，某些升级的情况下，可能会有徒手修改库表结构的情况发生，为了保证模型与生产库的一致，在自动检测阶段，主要负责定期发现不一致的情况，并发出预警邮件，过程如下。3、新增和变更流程在实际落标过程中，需要新增或修改标准的情况是必然出现的。因此在设计阶段或者模型评审阶段，进行变更流程。4、角色与人力安排根据银行当前的组织结构，需要有建立“标准和架构组”，至少2人编制，可以是虚拟组织结构和兼职角色。数据架构师（1人）：由企业资深（10+年数据开发经验）数据设计人员或管理人员担任，熟悉行业数据模型和企业主流业务逻辑模型，比较熟悉各系统模型情况。主要负责模型管控，落标评审，模型质量等工作。标准管理员（1人）：由高级（5+年数据管理经验）数据标准设计和管理人员担任，比较熟悉标准和企业业务逻辑模型。主要负责标准维护，标准评审，模型质量提高等工作。5、存量数据如何落标存量系统的落标是很多企业进行标准化第一障碍，前面也进行了痛点分析，那么如何解决落标问题呢？我建议遵循下面方法。存量系统先管理好数据模型和字典，这作为未来统一数据标准的基础。摸清模型存量系统不符标准的情况，尤其是那些标准代码，编码规则，存储格式等严重影响数据指标和拉通汇集的情况。根据非标问题的影响程度，制定未来的落标计划，选择合适的升级版本时机，进行逐项的落标。未落标前，可以先落标ODS层或API层，这样可以纠正后期应用的标准化问题。6、标准代码的多标准处理企业里存在多套标准是非常有可能的，比如一个客户类型的代码，原系统一套标准，数仓一套标准，报送EAST模型可能又是一套标准，那么怎么管理这多套标准呢？建议对标准进行有效范围的定义，以明确每套标准的用途，比如原系统的标准作为地方标准，数仓的作为中央标准，EAST模型的标准作为对外标准。建立标准之间的映射管理，做好数据拉通的依据解决。这样设计标准的维护和变更就可以重点选择哪里进行新增，以及如何进行统一等。
查看详情
