| 标题 | 浅谈智慧电科院数据中台建设及关键技术 |
| 范文 | 尹春林 杨政 摘要：本文主要是通过智慧电科院中台建设的概念入手，指出电科院中台建设的目标是建成“模型规范统一、数据完整全面、分析灵活智能”的数据中台，对于数据中台的建设采用创新型的建设思路，基于知识图谱、模型管理、深度学习算法给出中台应用架构设计，包括：应用架构、功能架构、技术架构和数据架构。同时对构建数据中台所需关键技术进行阐述。以满足中台建设不同架构的技术需求，从而对电科院的数字化转型中台建设，提供一定的研究对策，达到更好的电科院管理。 关键词：供电企业;电科院;数据中台 中图分类号：TP311? ? ? 文献标识码：A 文章编号：1009-3044（2021）16-0213-02 开放科学（资源服务）标识码（OSID）： 面对电科院数据发展的现状与存在的不足，需要将没有采集的信息采集起来，没有共享的数据即时共享出来，形成跨专业数据共享共用的生态，把过去没有用好的数据价值挖掘出来，快速体现数据价值。在专注数据标准化等基础工作的同时，数据建设要改变以往梳理好了再用的方法和习惯，提升至以用促建、以建助用、用建一体，以数据价值挖掘、发展数字经济为导向。 1 数据中台建设 1.1 数据中台的内涵 数据中台的定位是为许多专业和单位提供数据共享和分析应用服务。在信息分析和管理领域的支持下，它催生了共同的知识服务能力，并通过知识服务满足横向的跨专业和纵向的跨不同层次的知识共享、价值挖掘、分析和应用以及整合的需求。 构建企业级的标准数据，数据统一存储，形成大数据资产层，通过统一的数据服务接口为客企业内外部客户提供高效、共享的数据服务。数据中台的主要特点归纳为三点：首先是创造流量;其次是跨界分析;第三是整合资源。 1.2 数据中台的建设目标 电科院的目标是：建成“模型规范统一、数据完整全面、分析灵活智能”的数据中台，实现多维度数据的统一存储、管理与服务。 1.3 数据中台设计的总体思路 企业中台主要包括业务中台、数据中台和技术中台以及企业中台稳定、安全、规范运行的保障体系。 其中，对于数据中台的建设采用创新型的建设思路，基于知识图谱、模型管理、深度学习算法，在保持原有系统数据体系不变的情况下，采用自动发现数据资源关系、动态感知数据变化及影响范围、自主分析技术;利用数据云图全局展现企业数据资产图谱实现多维数据目录搜索与定位。 2 数据中台应用架构设计 构建数据中台，需要充分应用“云大物移智链”等现代信息技术和先进通信技术，实现电力系统各个环节万物互联、人机交互，大力提升数据自动采集、自动获取、灵活应用能力，实现“数据一个源、电网一张图、业务一条线”，“一网通办、全程透明” 。坚持统一数据管理，系统建设必须严格遵循电网企业统一的信息数据模型和数据采集、定义、编码、应用等标准，建成统一标准、统一模型的数据中台，确保数据共享。 2.1 应用架构 数据中台主要包括基础管理域、处理域、分析域三部分。 基础管理域的核心是编码标准化、组织机构标准化，通过定义统一编码字典和组织机构，为业务数据的融合与标准化提供基础支撑。目的是建立标准编码，解决当前业务数据编码不一致、编码粒度不一致的问题，为业务数据标准化提供基础支持;建立标准组织机构，解决当前业务数据组织机构体系不一致的问题，为业务数据标准化提供基础支持; 处理域是公司未来业务系统的各类业务数据存储、处理的中心，解决了当前业务系统业务数据冗余分散杂乱的问题，为公司未来各业务应用提供唯一的、标准的业务数据。 分析域总体设计：包含标准物理模型和指标体系设计，标准物理模型依据YNCIM模型进行设计。分析域完成业务数据融合、贯通、标准化转换、汇总、构建知识图谱、提取非结构化数据中蕴含的业务实体等功能，为数据挖掘和数据分析进行数据准备。 2.2 功能架构 基础管理域为其他两个域提供业务概念、标准编码、标准组织机构; 处理域维护标准业务数据，提供给未来业务系统共享使用; 分析域完成数据分析所需的所有数据准备工作。 2.3技术架构 基础管理域管理业务域、业务模型、标准编码、标准组织机构，这些信息具有唯一性，处理域和分析域共享; 处理域为未来业务系统提供标准业务数据共享服务，处理域的数据可以发布到分析域供数据分析使用; 分析域提供大数据存储和大数据计算，完成数据汇总、非结构化数据信息获取、图构建、数据提炼工作。 3 构建数据中台的关键技术 3.1 构建数据中台所需关键技术 如表1所示，数据中台的关键技术可以概括为五个类别，即：信息采集、信息存储与管理、信息共享与交流、信息的展示。 3.2 数据采集传输 这个一般对应于公司的日志平台，任务是将数据采集后缓存在某个地方，供后续的计算流程进行消费使用。 目前市面针对日志采集的有 Flume，Logstash，Filebeat，Fluentd ，rsyslog 几种常见的框架，我们挑应用较广泛的前两者介绍下： 从两者的设计思想来看，Flume 最初并不是为了采集日志而设计，而是定位在把数据传入 HDFS 中，这和 Logstash 有根本的区别。所以它理所应当侧重于数据的传输和安全，且需要更多的二次开发和配置工作。而 Logstash 明显侧重先对日志数据进行预处理，为后续的解析做铺垫。它搭配 ELK 技术栈使用起来比较简单，更像是为你准备好的便當，开盒即食。 1）日志采集如何工作 Flume 由三个部分组成：Source，Channel 和 Sink，对应于采集，缓存和保存三个环节。其中，Source 组件用来采集各种类型的数据源，如 directory、http、kafka 等。Channel 组件用来缓存数据，有 memory channel，JDBC channel和 kafka channel 三种。最后再通过 Sink 组件进行保存，分别支持 HDFS，HBase，Hive 和 Kafka 四种存储方式。 2）数据传输 Kafka Kafka 最初是由领英开发，并随后于 2011 年初开源， 并于 2012 年 10 月 23 日由Apache Incubato 孵化出站。该项目的目标是为流程性知识提供一个统一的、高吞吐量、低延迟的平台。持久层基本上是一个 "遵循分布式交易工作架构的大规模发布/订阅消息队列"，这使得它作为企业级基础设施对过程流知识具有价值。 3.3 数据存储 数据库存储方面，有单机/分布式、关系型/非关系型、列式存储/行式存储三个维度的划分，各种维度交叉下都有对应产品来解决某个场景下的需求。 在数据量较小的情况下，一般采取单机数据库，如应用非常广泛，技术成熟的 MySQL。数据量大到一定程度后，就必须采取分布式系统了。目前业界最知名的就是 Apache 基金会名下的 Hadoop 系统，它基本可以作为大数据时代存储计算的经典模型。 3.4 数据计算&查询 1）批计算和流计算 大数据处理场景可分为批处理和流处理两个，分别对应离线分析和实时分析。常见框架分类有： 仅批处理框架：Hadoop MapReduce 仅流处理框架：Storm，Samza 混合框架：Spark，Flink 篇幅所限，除了上文已经提到的 Hadoop 生态外，我们再简单科普下 Spark： 2）Spark 和 Flink Apache Spark 是一种包含流处理能力的下一代批处理框架。 批处理模式下，Spark 与 MapReduce 不同，它将数据处理工作全部在内存中进行，计算性能大幅改善。流处理模式下，Spark 主要通过 Spark Streaming 实现了一种叫做微批（Micro-batch）的概念。这种技术将信息流视为一系列可怕的小 "批次"，可由批处理引擎的本地语言学处理。这在应用中是正确的，但与真正的流处理框架相比，在性能方面仍有差距。 而 Flink 作为更新一代的处理框架，拥有更快的计算能力，更低的延迟，已经慢慢崭露头角。不过一个框架的应用，特别是开源框架，需要足够长的时间进行运行，测试和优化。大数据技术在开源社区的推动下，迭代日新月异。在不久的将来，相信 Flink 会像 Spark 取代 Storm 一样，逐渐成为大数据处理技术的主流。 3）数据查询 经过处理后的数据，还需要有高效的查询引擎才能被用户接触和使用。目前 OLAP 的查询技术框架大致可分为三类： 基于 HBase 做预聚合：如 Opentsdb， Kylin 等，均需指定预聚合的指标，在数据接入的时候进行聚合运算，适合相对固定，维度较多的业务报表类需求。 基于 Parquet 做列式存储：如 Presto， Drill，Impala 等，基本是完全基于内存的并行计算，Parquet 系能降低存储空间，提高IO效率，以离线处理为主，很难提高数据写的实时性，超大表的 Join 支持可能不够好。 基于 Lucene 做外部索引：如 ElasticSearch，Solr 等，能够满足的的查询场景远多于传统的数据库存储。 我们以常见的 Presto，Druid，Kylin 三个模型来讲讲各自的特点： Presto：由 Facebook 开源，是一个分布式数据查询框架，原生集成了 Hive、 Hbase 和关系型数据库。它背后所使用的执行模式与Hive有根本的不同，并没有使用 MapReduce。因其所有的处理都在内存中完成（与上文的 Spark 类似），大部分场景下要比 Hive 快一个数量级。 Druid：由 MetaMarket 开源，是一个分布式、面向列式存储的准实时分析数据存储系统，延迟性最细颗粒度可到 5 分钟。它能够在高并发环境下，保证海量数据查询分析性能，同时又提供海量实时数据的查询、分析与可视化功能。 Kylin：Cube 预计算技术是其核心，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速。劣势在于每次增减维度必须对 Cube 进行历史数据重算追溯，非常消耗时间。 3.5 数据可视化及分析 在数据可视化这块，一般会采取三个途径来进行数据展示。最基础的利用开源的图表库，如国外的 HighCharts、D3，百 度的 ECharts，还有阿里 Antv 的 G2、G6、F2 等。往上一层是各个知名公司开源的可视化框架，如 Airbnb 的 Superset，Redash，Metabase 等等。这些框架一般能够满足从数据源接入，自助制作报表和报表整理展示的功能，接入起来更加方便。再往上一层就是商用的可视化软件，如国外的 Tableau，Qlik ，国内的 FineReport，永洪 BI 等等。这种软件需要付费，但都具备更丰富的可视化功能并提供一些技术支持，对于那些没有精力折腾可视化的公司会是个不错的选择。 可视化框架： 这里主要介绍下业内比较出名的 Superset 和 Metabase。 前者的方案更加完善，支持集合不同数据源形成对应的指标，再通过丰富的图表类型进行可视化。在时间序列分析上比较出色，支持移动平均及周期偏移等分析方法。同时与 Druid 深度集成，可以快速解析大规模数据集。劣势则是不支持分组管理报表，一旦报表多了使用起来很麻烦。且不提供图表下钻及联动功能，权限管理也不够友好。 Metabase 则比较注重非技术人员（如产品经理和运营人员）的使用体验，让他们能自由地探索数据，回答自己的问题，界面相对来讲更加美观。在权限管理上做得较为完善，甚至无需账号也可以对外共享图表和数据内容。Dashboard 支持分类，便于管理报表。劣势在时间序列分析上不支持不同日期对比，还需要自定义SQL 实现。每次查询仅能针对一个数据库查询，操作比较繁琐。 4 结语 數据中台改变了业务系统自我收集和自我使用的既定秩序，有效整合了支持现有业务系统的相关信息资源，建立了综合管理和集中存储的知识平台，保证了存储的安全性和调用的多样性，扩大了海量信息的创新应用，有效建立了信息 "说话 "的思想，依靠信息科学地分析各部门日常业务工作中的问题，客观地提出针对性的解决方案。做到数据中台一定要与业务价值对齐，关键技术与架构建设对齐，有效支撑未来的大数据智库建设。 参考文献： [1] 蔡菁菁.浅谈利用数据中台实现通信企业数字化转型[J].中国新通信，2020，22（12）：1. [2] 李广乾.什么是数据中台？[J].中国信息界，2019（6）：72-75. [3] 李巍巍.数据中台技术在业务系统中的应用研究[J].现代信息科技，2019，3（21）：108-110. [4] 杜栋，杨莉媛，谢炯. 企业中台战略研究——以国家电网公司为例[C]. 中国电机工程学会电力信息化专业委员会.生态互联 数字电力——2019电力行业信息化年会论文集.中国电机工程学会电力信息化专业委员会：人民邮电出版社电信科学编辑部，2019：286-289. [5] 于浩淼，赵月芳，陈盟，等.企业中台建设思路与实践方案[J].电信技术，2019（8）：78-80. 【通联编辑：李雅琪】 |
| 随便看 |
|
科学优质学术资源、百科知识分享平台，免费提供知识科普、生活经验分享、中外学术论文、各类范文、学术文献、教学资料、学术期刊、会议、报纸、杂志、工具书等各类资源检索、在线阅读和软件app下载服务。