前言 虽然断断续续，但是做民航领域的ODS等数据方面的设计等，也已经进入第10个年头了。希望借此篇温故而知新，用更全面的思路和技术理念去推动民航数据落地、数据赋能、数据价值化及精细化的发展。 不论是否是民航领域，对于一个企业级的全局数据蓝图，乃至一个行业跨主管上下级之间，其都应该被分为如下6个层次。每个层次起到的作用及职能范围必须清晰。 Metadata、Reference Data、Master Data、Transaction Data等 然而起步之前必须明确“此数据非彼数据”，数据是有特征的，数据被标识和描述有是信息、是价值。所以一定要理解数据特征和功用。从元数据、参考数据、主数据、交易数据，如下给与一个行业领域的经典模型描述。同时之后有汇总数据、分析数据、乃至大数据，但是万变不离其宗，上述4类数据必须严格明确其使用场景和在企业信息数据系统建设中的地位。 ODS ODS即Operational Data Store，但是我更期望沿用国外及经验命名：Operational Data Service。其不仅仅是一个Store的目的，而是企业中特定需要协同的若干业务系统、职能单位、协同领域的数据交互服务，从接入、到存储、到接出、再到被动消费及跟踪，等5大板块。其本质是提供的企业全局协同交易Commitment场景下的Interchange支撑。其中Master Data定义的是交互的Schema；Metadata定义的是数据标准、尤其是精度等；Transcation的发生造成Interchange的发生。但是ODS中的所谓ODSBase存储的不是MDM定义的数据模型，而更多的是为了全局业务协同和数据交换的数据模型。 但是ODSBase中的数据落地，不是面向领域的，而是面向主题的。即DDD的理念基本不会涉及，因为DDD更适合Microservices的架构；相对传统的ODS更适合SOA的架构支撑，故一定要明确，数据落地是面向主题的。 ODS必须有其明确的定位，否则将无法明确其在企业业务系统流转中的范围和功用，将造成大量的数据冗余和浪费，以及数据流转的更模糊化状况。  当定位明确后，成功的ODS将是过渡到传统EDW的最好“媒介”，辅以Message Broker等的业务交易的EMS（Enterprise Messaging System）支撑，将为后续的EDW数据接入和时序数据的聚合等提供优良的数据土壤，同时将ODS中优秀和茁壮的领域数据模型沉淀进入EDW，或更为有价值的IDS中。 然而ODS的建设离不开数据治理和数据管控，但更需要在业务基础上，尤其业务协同上进行服务治理，明确全局业务及数据交互的流转流程，才能建设好优质的数据模型和ODS落地方案。因为其上已经很明确强调，ODS是为了协同而不仅仅是MDM管控的数据交互的Schema。  但是使用ESB在某些场景是能够解决问题，但是其理念在于ESB的中间件与企业级数据架构体系的数据落地的差别。不管ESB还是ODS虽然数据流还是像网络一样纷杂，但是关键是一个数据落地，一个是只为了交换数据或信息、乃至数据流程编排。ODS强调的是数据在特定场景的使用功能，是接入、还是接出或推出、还是被动被消费、或深度血缘或时序跟踪。 ODES ODES即Operational Data Engine & Store，其很明确的是ODS的更精细化及能力的提升。将ODS与Message Broker为核心的Enterprise Data EMS有机的融合在一起。 从Capture Point到Access Point需要的是业务事件的流转，和数据事件的溯源，而非单一的Master Data的数据整体流转。更关键的其是Microservices架构体系得以在行业企业级系统架构中落地的关键，即CQRS的应用。 业务事件或数据事件是由于Transcation造成的，但是为了其将不仅仅是业务事件，将是更多Action所产生，乃至企业的C端用户及IoT终端。但是最终其落地的所谓Logging，即时序性极强的一堆ID集合。其更像Blockchain的理念。  EDS 即Enterprise Data Service。其简单说是不含任何业务逻辑的数据服务。最好其体现为SOAP Web Service，同时封装一定数据完整性，并最终作用于ODSBase之上的数据服务实现。为更上层的数据协同应用的编排提供最好的数据支撑和延展能力。 IDS 即Informational Data Store，其确实是数据的存储，但是是高价值的“信息”存储，而不是为了部门协同和Transaction发生提供实时交易支撑的数据落地。然而其是企业数据仓库，即EDW的在特定领域和协同领域数据分析、洞察及事后智能应用的基础和最好的土壤。在Bigdata等相关技术出现之前，其是最优解决方案和协同价值的评估数据基础。 某些角度，其跟ODS的数据建模是雷同的，也是面向主题的建模，但是跟DDD的面向领域建模是有差别的。DDD更适合Microservices。 更为关键的是数据的维度建设以及时序落地，只有这样才能为后续的分析类的应用产生较强的数据关联和高价值的数据基础。同时在业务层的数据分流，将保障ODS与IDS的数据解耦、冗余、备份、功用等的专一。 数据中台/BDaaS 即Bigdata as a Service，或数据中台/Data Cross-Plane。然而究其本质就是将大数据、云计算、人工智能，即俗称ABC，应用到企业内部数据的升值使用领域。用于代替之前的EDW，或小范围的IDS；并贴合现有的数据化转型，让数据会说话，说好话，说出价值来。如下图所示，其本质上跟ODS等和现有OEM等业务职能系统没有本质和直接的联系。虽然Metadata是大数据建设的关键，但是MDM的Master Data在我看来，在航司这个特定的领域，其也是BDaaS建设的关键和启动很重要的作用。 ODS、ODES、数据中台 所以在很明确行业企业级数据架构蓝图的前提下，一定要将6个不同层次的落地实物分清楚，ODS负责的是协同数据交换、IDS及EDW是传统的企业协同商业智能分析、数据集市等大数据领域的概念，真正是数据中台的领域了。但是Master Data及Metadata贯穿于其中，定义数据治理和管控的基础。 然而好的ODS将是数据中台建设的基础，正如同ODS是EDW的最好过渡一样。但是让企业运营领域更好的做好数据流转及交换，则需要ODES。同时ODES为数据中台BDaaS提供的是更高质量的数据溯源能力。 然而从企业数据价值升值的角度，从ODS到数据中台，其本质是数据赋能的角度，两者存在差异。一个是期望流程顺畅及精准，透明。一个期望的是数据真正能够脱离原理的范围，变为价值。一个是企业信息化的产物，一个是企业数字化转型的产物。 数据架构 不管是哪种企业数据蓝图中的层次，也不管是哪一部分的实现，其数据最终落地到“数据库”，并支撑上层的应用及服务。这都需要从水平和垂直两个维度建设数据系统，为数据的“提纯”、“流转”、“赋能”等提供架构层次的支撑。 数据“流” 抽象所有的数据体系建设，最终关键的是一个流动的数据处理管道，从ETL到CDC，再到大数据的工具和理念，都需要数据有进有出，并且按照一定的理念和规范进行流转。 总结 不管企业的数据架构及治理和管控在哪个层次，其最关键的是在如上的理念基础之上，将行业数据模型及数据规范切合定义好、管控好、落地准、运营精。数据模型、尤其是行业数据模型决定一切，也是最为关键的价值，企业数据资产中的核心价值。 数据模型除了需要资深的行业经验及标准的提取，更关键的是面向应用及服务的场景，以及数据水平和垂直的分层体系、以及血缘和溯源两种需求的实现。