缘起HR妹子说校招季来了，简历铺天盖地，随便看了几个，不得不说现在的简历实在是太“卷”了。我就突然很想分析下今年的校招投递的简历的整体情况。无意中发现modelscope里提供了简历实体识别的模型。提供了对简历里几种重要实体的识别（https://modelscope.cn/#/models/damo/nlp_raner_named-entity-recognition_chinese-base-resume/summary）可以拿来用下。真实的投递简历当然是不能公开的啦，这里就以热心网友提供为公开的简历数据（https://paperswithcode.com/dataset/resume-ner）测试下流程（就用了那个dev小试了下，毕竟这个模型跑的有点慢，爬——）。-------------------我是正文分割线---------------------分析流程将简历内容调用简历实体识别模型识别实体内容，调用方法参考官方给出的代码范例。将分析结果存储到hive并进行数据分析。对接FineBI进行数据展示。分析结果我选了三个实体类型：专业、学历、职称 （Emm, 其实很想选学校，但是这个模型不区分学校和企业）数据量总共1508条，识别出有专业的有20条，有学历的数据有108条，有职称的数据有695条。（Emm, 为啥有人不写专业呢）ODS(hive)=>DWS(hive)=>APP(mysql)话不多说，上图：学历大部分集中在大专以上，本科居多，可能是数据都是在职员工的简历吧，如果是现在的校招简历，一沓一沓的硕士。职称看起来都是很高级的职位，可能是数据来源是公开简历，我等小透明也不会去公开简历。专业集中在经管类，对着职称一票的经理董事，想问下我等码农专业还有机会吗？最后，说下总体的使用感受吧：识别准确率还是蛮高的，对行业、学历、职称的识别度较高，几乎没有识别错的，就是跑的有点慢 (小pc瑟瑟发抖)单是一个抽取模型，不能将同义词进行归一，如识别出来大学本科、本科、本科学历，对BI还是有点不够用。实体类型有点少，ORG类型有点粗，不能区分学校和企业。这个好像是原始训练数据就是这样？附件模型调用from modelscope.pipelines import pipeline from modelscope.utils.constant import Tasks import json ner_pipeline = pipeline(Tasks.named_entity_recognition, 'damo/nlp_raner_named-entity-recognition_chinese-base-resume') result_file = open("./result.txt", "w", encoding="utf-8") with open("./test.txt", "r", encoding="utf-8") as f: for line in f.readlines(): result = ner_pipeline(line) result_file.write(json.dumps(result) + "\n") result_file.close()ner结果result.txt生成ODS并导入到hiveods_f = open("ods.csv", "w", encoding="utf-8") with open("./result.txt", 'r', encoding="utf-8") as f: for line in f.readlines(): output = eval(line).get("output") print(output) for type_list in output: dict_one = {} dict_one[type_list.get("type")] = type_list.get("span") name = dict_one.get("NAME", '-1') occupation = dict_one.get("PRO", "-1") education = dict_one.get("EDU", '-1') title = dict_one.get("TITLE", '-1') s1 = name+"\t"+occupation+"\t"+education+"\t"+title+"\n" ods_f.write(s1) ods_f.close()ods.csv--建库建表create database jianli default character set utf8mb4 collate UTF8MB4_UNICODE_CI; CREATE TABLE jianli_ods ( name VARCHAR(30), education VARCHAR(30), occupation VARCHAR(30), title VARCHAR(30) ) ; load data local inpath '/root/ods.csv' into table jianli_ods partition(create_day='2022-08-16');生成DWS（hive中操作）-- 建库建表USE jianli; CREATE TABLE jianli_app ( group_type VARCHAR(30), occupation_name VARCHAR(30), occupation_count INT, education_name VARCHAR(30), education_count INT, title_name VARCHAR(30), title_count INT ) row format delimited fields terminated by '\t' stored as textfile; INSERT INTO jianli.jianli_app(group_type, occupation_name, occupation_count, education_name, education_count, title_name,title_count) SELECT '1' as group_type, occupation as occupation_name, count(name) as occupation_count, '-1' as education_name, 0 as education_count, '-1' as title_name, 0 as title_count from jianli.jianli_ods group by occupation; INSERT INTO jianli.jianli_app(group_type, occupation_name, occupation_count, education_name, education_count, title_name,title_count) SELECT '2' as group_type, '-1' as occupation_name, 0 as occupation_count, education as education_name, count(name) as education_count, '-1' as title_name, 0 as title_count from jianli.jianli_ods group by education; INSERT INTO jianli.jianli_app(group_type, occupation_name, occupation_count, education_name, education_count, title_name,title_count) SELECT '3' as group_type, '-1' as occupation_name, 0 as occupation_count, '-1' as education_name, 0 as education_count, title as title_name, count(name) as title_count from jianli.jianli_ods group by title; sqoop export \ --connect jdbc:mysql://xx.xx.xx.xx:3306/jianli \ --username root --password xxxx \ --table jianli_app \ --hcatalog-database jianli \ --hcatalog-table jianli_app \ -m 1mysql对接FineBI

4982亿，是2020年天猫双十一成交额最终定格的数字。在这背后，是人类历史上最大规模的人机协同，更是数字世界史无前例的巅峰挑战。阿里云新一代云原生数仓Hologres作为双十一背后重要的技术支撑，消费者的每一次搜索、浏览、收藏、加购，都会变成实时数据流入Hologres进行存储，并与天猫上沉淀的历史离线数据进行交叉比对。2020双十一，Hologres顶住了5.96亿每秒的实时数据洪峰，单表存储高达2.5PB。基于万亿级数据对外提供多维分析和服务，99.99%的查询可以在80ms以内返回结果，真正做到数据的实时及离线一体化，支持在线应用服务。Hologres诞生到参与2020年史上最强双十一的三年多时间里，完成不少从0到1的突破：从一个业务到数百业务实例，覆盖了阿里巴巴集团内90%以上业务场景，包括双十一实时直播间、智能推荐、阿里妈妈数据平台、国际站数据平台、菜鸟数据平台、友盟+全域数据分析、CCO智能客服、新零售数据平台、考拉、饿了么等业务。集群规模从0到近万台，且存储集群和计算集群使用率都比较高，并完成了系统产品化-上云-商业化的三级跳，完美赋能阿里云公共云+专有云+金融云业务。提出HSAP（HybridServing & Analytics Processing）服务分析一体化的系统设计理念，同一份数据同时满足实时离线在线场景的计算需求，极大的简化了数仓架构的复杂度，降低了成本，重新定义数仓趋势。同时，有关Hologres的技术解读Paper入选数据库顶会VLDB《Alibaba Hologres: ACloud-Native Service for Hybrid Serving/Analytical Processing》（http://www.vldb.org/pvldb/vol13/p3272-jiang.pdf）值此之际，我们也将首次对外公开Hologres的核心底层技术，揭秘Hologres为何能支撑阿里巴巴核心场景的落地。 一、传统数仓痛点1）传统数据仓库痛点目前来说，大数据相关的业务场景一般有实时大屏、实时BI报表、用户画像和监控预警等，如下图所示。实时大屏业务，一般是公司领导层做决策的辅助工具，以及对外成果展示，比如双十一实时成交额大屏等场景。实时BI报表，是运营和产品经理最常用到的业务场景，适用于大部分的报表分析场景。用户画像，常用在广告推荐场景中，通过更详细的算法给用户贴上标签，使得营销活动更加有针对性，更加有效的投放给目标人群。预警监控大屏，比如对网站、APP进行流量监控，在达到一定阈值的时候可以进行报警。 对于上面这些大数据业务场景，业界在很早之前就开始通过数据仓库的建设来满足这些场景的需求，比较传统的做法是如下图所示的离线数据仓库，其大致流程就是：首先将各类数据收集起来，然后经过ETL处理，再通过层层建模对数据进行聚合、筛选等处理，最后在需要的时候基于应用层的工具对数据进行展现，或者生成报表。上面这种方式虽然可以对接多种数据源，但是存在一些很明显的痛点：ETL逻辑复杂，存储、时间成本过高；数据处理链路非常长；无法支持实时/近实时的数据，只能处理T+1的数据。2）Lambda架构痛点随着实时计算技术的兴起，出现了Lambda架构。Lambda架构的原理如下图所示，其思路其实是相当于在传统离线数仓的基础上再加上一个处理实时数据的层，然后将离线数仓和实时链路产生的数据在Serving层进行Merge，以此来对离线产生的数据和实时产生的数据进行查询。从2011年至今，Lambda架构被多数互联网公司所采纳，也确实解决了一些问题，但是随着数据量的增大、应用复杂度的提升，其问题也逐渐凸显，主要有：由多种引擎和系统组合而成，开发和维护成本高，学习成本高；数据在不同的View中存储多份，空间浪费，数据一致性的问题难以解决；从使用上来说，Batch，Streaming以及Merge Query等处理过程中均使用不同的language，使用起来并不容易；学习成本非常高，增大了应用成本。上面讲到的问题，在阿里内部其实也都遇到过。如下图所示是阿里巴巴在2011-2016年沉淀下来的一套实时数仓架构，其本质上也是Lambda架构，然而随着业务量及数据的增长，关系复杂度越来越大，成本急剧增加，因此，我们迫切的需要一种更优雅的方案去解决类似的问题。二、HSAP：服务分析一体化基于上述背景，我们提出了HSAP（Hybrid Serving and AnalyticalProcessing）理念，它既能支持很高QPS场景的查询写入，又能将复杂的分析场景在一套体系里面完成。那么，HSAP理念落地的核心是什么？首先，要有一套非常强大的存储，能够同时存储实时数据和离线数据，统一数据存储；同时还要有一种高效的查询服务，在同一个接口下（比如SQL），能够支持高QPS的查询，支持复杂的分析以及联邦查询和分析；系统能够直接对接前端应用，例如报表和在线服务等，不需要再额外的导入导出就能即席分析，统一数据服务，减少数据移动。三、关于Hologres基于HSAP的设计理念，我们要开发并落地出相应的产品，于是便诞生了Hologres。Hologres是基于HSAP服务分析一体化理念的最佳落地实践，兼容PostgreSQL生态、支持MaxCompute数据直接查询，支持实时写入实时查询，实时离线联邦分析，低成本、高时效帮助企业快速构筑流批一体的实时数仓。Hologres这个词是Holographic和Postgres的组合，Postgres比较好理解，代表着Hologres兼容PostgreSQL生态。而Holographic需要展开分享，先看下图：Holographic中文翻译是"全息"，就是大家经常听到的3D全息投影技术的"全息"。而Holographic Principle（全息原理）在物理学中是用来描述一个空间的性质可编码在其边界上。上图是一副假想中黑洞的图片，距离黑洞一定距离处于可以逃逸出黑洞引力的临界点构成了Event Horizon，就是图中发亮光的那一圈。全息原理认为所有落入黑洞的物体信息内容可能会被完全包含在Event Horizon的表面。Hologres要做的事情就是对数据黑洞中的全部信息做存储和各种类型的计算。四、Hologres核心技术揭秘Hologres架构非常简单，是存储计算分离的架构，数据全部存在一个分布式文件系统中，系统架构图如下图所示：服务节点Backend真正去接收数据、存储和查询，并且能够支持数据的计算；执行引擎Frontend接收路由分发的SQL，然后生成逻辑执行计划，再通过优化器生成分布式的物理执行计划，发布到Backend做分布式的执行；接入端由LBS做相应的负载均衡任务。下图中黄色部分均部署在容器中，整个分布式系统可以做到高度容错。兼容PostgreSQL生态，在上层可以直接对接开源或者商业化的开发/BI工具，开箱即可用。存储计算分离Hologres采用存储计算分离架构，用户可以根据业务需求进行弹性扩缩容。分布式存储中，常用的架构有如下三种：Shared Disk/Storage：就是在存储集群上挂载了很多磁盘，每个计算节点都可以直接访问这些共享盘；Shared Nothing：架构就是每个计算节点自己挂载存储，节点之间可以通信，但是各个节点之间的盘不共享，存在资源浪费的情况；Storage Disaggregation：就是相当于把存储集群看做一个大的磁盘，每个计算节点都可以访问，且每个计算节点都有一定的缓存空间，可以对缓存数据进行访问，也无需关心存储集群的管理，这种存储计算分离的架构便于灵活扩容，能够有效节省资源。流批一体的存储Hologres定位是流批一体统一存储。对于典型的Lambda架构，是将实时数据通过实时数据的链路写入到实时数据存储中，离线数据通过离线数据的链路写入到离线存储中，然后将不同的Query放入不同的存储中，再做Merge，由此带来多份存储开销和应用层复杂的Merge操作。而通过Hologres，数据收集之后可以走不同的处理链路，但是处理完成之后的结果都可以直接写入Hologres，这样就解决了数据的一致性问题，也不需要去区分离线表和实时表，降低了复杂度，也大大降低了使用者的学习成本。存储引擎Hologres底层支持行存储和列存储两种文件格式，行存适用于基于PK的点查场景，列存适用于OLAP复杂查询场景。对于两种存储格式Hologres在底层处理也有略微不同，如图所示。数据写入的时候先写log，log存储在分布式文件系统，保证整个服务的数据不会丢失，因为即便服务器挂掉也可以从分布式系统中恢复。Log写完之后再写MemTable，就是内存表，这样系统才认为是数据写入成功。MemTable有一定的大小，写满了之后会将其中的数据逐渐Flush到文件中，文件是存储在分布式系统中的。而对于行存储和列存储的区别就在Flush到文件的这个过程中，这个过程会将行存表Flush成行存储的文件，列存表会Flush成列存文件。在Flush的过程中会产生很多小文件，后台会将这些小文件合并成一个大文件。执行引擎Hologres执行引擎是通用的分布式查询引擎，侧重于优化高并发低延迟的实时查询。通用是指可以表达和高效地执行所有类SQL查询。其它的分布式查询引擎，有的专注优化实时表的常用单表查询，但是对复杂查询表现不佳；有的支持复杂查询，但是实时场景性能要差一截。Hologres的理念是不做妥协，对这些场景都要瞄准极致性能。Hologres执行引擎能够做到对各种查询类型的高性能处理，主要是基于以下特点：端到端的全异步处理框架，可以避免高并发系统的瓶颈，充分利用资源，并且最大可能地避免存储计算分离系统带来的读数据延迟的影响。查询用异步算子组成的执行图DAG表示，可以方便对接查询优化器，利用业界各种查询优化技术。算子内部处理数据时最大可能地使用向量化执行。和存储引擎的深度集成，灵活的执行模型，能够充分利用各种索引，并且最大化地延迟向量物化和延迟计算，避免不必要的读数据和计算。对常见实时数据应用查询模式的自适应增量处理。对一些查询模式的独特优化。优化器Hologres的目标就是用户开箱即可用，即通过SQL就能完成日常所有的业务分析需求，无需再做额外的建模处理等操作。基于新的硬件技术，Hologres设计并实现了自己独特的计算和存储引擎，而优化器扮演的角色就是将用户执行的SQL高效的运行在计算引擎上。Hologres优化器采用基于代价的优化器，能够生成复杂的联邦查询执行计划，尽可能发挥多套计算引擎的能力。同时，在长期与业务打磨的过程当中，也积累沉淀了大量的业务优化手段，让Hologres的计算引擎在不同的业务场景下都能够发挥极致的性能。HOS&HoloFlowHologres最核心的组件名叫blackhole，是一款完全自研的存储计算引擎，采用异步编程方式开发。blackhole的底层提炼出了灵活高效的异步框架：holo-os（简称HOS）。在实现高性能的同时，还实现了load balance，解决了query长尾问题；实现了资源的高利用率、以及多种共享与隔离的机制。于此同时，holo-os还推广到了分布式环境，发展出了holo-flow分布式任务调度框架，这样就能保证在分布式环境下也能享受到单机调度的灵活性。FrontendFrontend是Hologres的接入层，兼容PostgreSQL协议，负责用户请求的接入、处理以及元数据的管理。但由于PostgreSQL是单机系统，处理高并发的用户请求能力有限。而Hologres面对的是复杂的业务场景以及需要支持万甚至亿级别的用户请求，所以在实现上Frontend采用分布式，通过多版本控制+元数据同步等方式实现了多Frontend之间信息实时同步，再配合LBS层的负载均衡实现了完全线性扩展和超高QPS的能力。扩展执行引擎在Frontend的基础上，Hologres也提供多扩展执行引擎。PQE（P Query Engine)：运行SQL以及各种Function的执行器，Hologres兼容Postgres提供扩展能力，支持PG生态的各种扩展组件，如Postgis，UDF（pl/java，pl/sql,pl/python）等，完美满足不同场景不同用户的需求，从而提供更多的计算能力。SQE（S Query Engine）：无缝对接MaxCompute(ODPS)的执行器，实现对MaxCompute的native访问，无需迁移和导入数据，就可以高性能和全兼容的访问各种MaxCompute文件格式，以及Hash/Range clustered table等复杂表，实现对PB级离线数据的交互式分析。生态与数据集成Hologres作为流批一体的实时数仓，支持多种异构数据源的实时、离线写入，包括MySQL、Datahub等，能够达到每秒千万条的实时写入能力，写入即可查和每秒千万次的点查能力。而这些强大的能力都是基于Hologres的JDBC接口。Hologres在接口上完全兼容PostgreSQL（包括语法、语义、协议等），可以直接使用PostgreSQL的JDBC Driver去连接Hologres，并进行数据的读写。目前市面上的数据工具，例如BI工具、ETL工具等等，都支持PostgreSQL JDBC Driver，所以这意味着Hologres天生就有了广泛的工具兼容性和强大的生态，实现从数据处理到数据的可视化分析完整大数据生态闭环。在线服务优化Hologres作为HSAP服务与分析一体化的最佳落地实践，除了具备处理分析型query的能力外，还具备十分强大的在线服务能力，例如，KV点查与向量检索。在KV点查场景中，Holgres通过SQL接口可以轻松稳定地支持百万级的QPS吞吐与极低的延时。在向量检索场景，用户同样可以通过SQL的方式来实现向量数据的导入、向量索引的构建、查询等操作，无需额外转换就能查询，性能经过实际业务的测试也相比其他产品更优。此外，一些非分析型的query通过合理的建表、配合上Hologres强大的索引能力，也同样可以完美适用serving场景。五、数仓架构升级基于Hologres，多个业务场景也完成了架构升级，极大的简化了业务架构的复杂度，如下图所示：总结Hologres作为新一代云原生实时数仓，在今年阿里巴巴双11最核心的数据业务场景，连同实时计算Flink首次落地流批一体，并在稳定性、性能等方面经受住考验，实现商业全链路实时化，毫秒级的海量数据处理能力，为商家和消费者带来了更加智能的消费体验。随着业务的发展和技术的演进，Hologres也将持续优化核心技术竞争力，真正实现服务和分析一体化的美好愿望，为更多用户持续赋能。另，我们将会持续推出以上核心技术的专题解读，敬请关注！作者简介：金晓军（花名仙隐），阿里巴巴资深技术专家，大数据领域从业10年，现从事Hologres设计与研发工作。技术揭秘持续更新中：2020年VLDB的论文《Alibaba Hologres: A cloud-Native Service for Hybrid Serving/Analytical Processing》Hologres揭秘：首次揭秘云原生Hologres存储引擎Hologres揭秘：Hologres高效率分布式查询引擎Hologres揭秘：高性能原生加速MaxCompute核心原理Hologers揭秘：优化COPY，批量导入性能提升5倍+Hologres揭秘：如何支持超高QPS在线服务（点查）场景Hologres揭秘：从双11看实时数仓Hologres高可用设计与实践Hologres揭秘：Hologres如何支持超大规模部署与运维Hologres揭秘：湖仓一体，Hologres加速云数据湖DLF技术原理解析Hologres揭秘：高性能写入与更新原理解析

后疫情时代，无论是企业还是大众都意识到了数字化服务的优势。一方面越来越多的消费者接受了线上服务的便捷和精准，另一方面互联网也帮助了企业拓展消费空间和构建消费场景。数字化转型，对于传统行业特别是零食行业来说，已经是影响生存的关键之战。越来越多的零食企业需要通过数字服务，将单纯的线下零售模式转换为线上线下双线经营的模式，为企业拓展新的发展空间。作为一家成长于泉州晋江的高端零食品牌，有零有食成立于2016年，目前员工500余人，拥有1个1.6万m²的生产中心、1个2万m²物流中心，1个营销中心、1个电商子公司、1 个杭州子公司、10个外协冻干厂。是一家集研发、生产、销售为一体的现代型食品公司。公司主打品牌“有零有食”，专注于冻干食品的研发与销售，始终秉承“创新、聚焦、健康”的生产理念，致力于成为冻干食品行业的领导者。基于公司2022年战略解码会三场硬仗之一的“跑通营销打法”的目标,有零有食需要实现搭建一个数字化营销系统,以满足高速增长的线上业务需求,聚焦目标客户,实现精细化营销,提升客户服务能力。为进一步提升企业的数字化营销能力，有零有食与阿里云&瓴羊联手探索营销系统解决方案。在项目合作中，有零有食针对公司的线上线下渠道布局，建立集网红、店铺、客户、地域、业务员、短视频、直播、竞品销售、新媒体运营于一体的数据库; 阿里云&瓴羊提供数字化场景案例及成熟的解决方案，共同搭建数字化营销系统，通过“云钉一体”操作系统、数据可视化分析Quick BI、全渠道企业资源管理Quick Stock等产品和方案落地，实现全域的营销能力和全集团的数据分析能力构建、全渠道的商品履约能力完善。同时，有零有食也希望在数字化体系的基础上把员工培养成具备数字化战略管理、深度分析、产品研发、数字化运营、数字营销等领域的专业化复合型人才。有零有食CEO陈世伟在有零有食与阿里云&瓴羊战略签约会议上表示，数字化营销转型的重要性不仅仅体现在消费者的服务上，阿里云&瓴羊提供的数字化布局还基于有零有食的全产业链模式，为产品研发、品控、物流、员工管理，甚至是助力果农的各个环节赋能。有零有食希望基于阿里云&瓴羊提供的数据技术，能够打通研、产、销的数据，帮助有零有食实现对冻干水果领域的精细追求。在产品研发上，研发前期，有零有食会员对于食品的需求及市场动向调研数据分析是研发的风向标；研发中期，通过仪器感知及市场洞察对食物的口味形成标准化的测算和分析。在品控上，数字化让冻干水果生产的流程清晰可见、品质透明有保证；在物流运输环节，产品都有明确编码，品质在动态监控中让消费者吃起来更放心。数字化的服务不仅能够让冻干水果在消费者面前透明化，让他们吃得更安心，也让企业能够更好地迭代产品，保证质量，充分打开大众关于冻干水果的市场认知。有零有食认为，真正有效的数字化转型并不只是从技术层面出发，通过某一个单独的系统解决某一个问题，而是通过规模化、整体性的数字化部署提供解决方案。数字化转型是未来的必然趋势，从消费者出发，携手阿里云&瓴羊，用云上技术陪伴企业成长，为未来冻干水果零食市场做出更多贡献！

QuickBI是什么？

Quick BI是什么？

前提条件已开启SQL审计与分析功能。注意事项由于相同地区的PolarDB-X数据库的审计日志均写入日志服务同一个Logstore中，查看当前PolarDB-X实例下的报表数据时，默认为您添加基于__topic__:polardbx_sqlaudit and instance_id:xxxxxxxxx的过滤条件，表示查看当前实例下的所有数据库的日志数据。操作步骤登录云原生分布式数据库控制台。在页面左上角选择目标实例所在地域。在实例列表页，单击PolarDB-X 2.0页签。说明 目前PolarDB-X 2.0实例仅支持华北2（北京）、华东1（杭州）、华北1（青岛）、华东2（上海）、华南1（深圳）、德国（法兰克福）和美国（硅谷）地域。找到目标实例，单击实例ID。在左侧导航栏，单击诊断与优化 > SQL审计与分析。在SQL审计与分析页面，单击日志报表页签，您可以通过单击不同页签查看运营中心、性能中心和安全中心的详情。运营中心：展示了目标PolarDB-X 2.0实例下所有数据库的SQL执行指标、分布、趋势等信息。分类图表类型默认时间范围描述基本指标PV（SQL执行）单值1小时（相对）SQL执行的次数。UV（独立IP用户）单值1小时（相对）独立的用户及IP数量。危险IP数单值1小时（相对）危险IP的数量。说明 更多关于危险IP的详情，请参见安全检测函数。执行错误单值1小时（相对）执行错误的SQL数量。操作表格数单值1小时（相对）SQL操作的表格总数。操作指标累计插入行数单值1小时（相对）插入操作累计插入的数据行数。累计更新行数单值1小时（相对）更新操作累计更新的数据行数。累计删除行数单值1小时（相对）删除操作累计删除的数据行数。累计查询行数单值1小时（相对）查询操作累计返回的数据行数。非表格操作种类单值1小时（相对）非表格操作的SQL种类，例如 show variables like趋势SQL执行趋势柱状图1小时（相对）SQL执行的趋势分布以及对应的错误SQL的分布趋势。操作表格流图1小时（相对）SQL操作表格的分布情况。SQL类型流图1小时（相对）SQL类型的按照时间的分布情况。分布操作用户分布饼图1小时（相对）执行SQL用户的分布情况。SQL执行类型分布饼图1小时（相对）当前时间范围内SQL类型的比例。操作最多的表格Top 50表格1小时（相对）操作最多的表格列表，包括表格的名称以及对应的读、删、改、插的次数。执行分布（世界）地图1小时（相对）执行SQL的客户端IP在世界地图上的分布情况。执行分布（中国）地图1小时（相对）执行SQL的客户端IP在中国地图上的分布情况。性能中心：展示了目标PolarDB-X实例下所有数据库的具体性能指标，例如SQL执行峰值、SQL执行的平均时间、慢SQL（即执行时间超过1s的SQL）的具体分布与来源等。分类图表类型默认时间范围描述基本指标SQL 执行峰值单值1小时（相对）每秒SQL执行条数的峰值。查询带宽峰值单值1小时（相对）每秒查询SQL返回行数的峰值。插入带宽峰值单值1小时（相对）每秒插入SQL插入的行数峰值。更新带宽峰值单值1小时（相对）每秒更新SQL更新的行数峰值。删除带宽峰值单值1小时（相对）每秒删除SQL删除的行数峰值。执行平均时间平均时间单值1小时（相对）SQL平均的执行时间。查询SQL单值1小时（相对）平均每秒查询SQL执行的条数。插入SQL单值1小时（相对）平均每秒插入SQL执行的条数。更新 SQL单值1小时（相对）平均每秒更新SQL执行的条数。删除 SQL单值1小时（相对）平均每秒删除SQL执行的条数。执行分布查询更新带宽趋势折线图1小时（相对）查询SQL、更新SQL操作行数随时间的分布情况。SQL执行时间分布饼图1小时（相对）SQL执行时间的分布情况。慢SQL分布慢SQL表格分布饼图1小时（相对）慢SQL的表格分布情况。慢SQL用户分布饼图1小时（相对）慢SQL的用户分布情况。慢SQL类型分布饼图1小时（相对）慢SQL的类型分布情况慢SQL列表Top 50表格1小时（相对）慢SQL的列表，包括：SQL开始执行的时间点客户端（IP、城市、网络）SQL执行时间PolarDB-X 2.0实例ID数据库表格用户影响行数SQL类型具体SQL语句高代价 SQL模板SQL模板执行时间Top 20表格1小时（相对）按照高代价SQL模板统计该模板 SQL的执行情况，包括：SQL模板ID总体耗时比例执行次数平均执行时间（毫秒）平均影响行数样例SQL事务SQL事务执行影响行数Top 20表格1小时（相对）事务影响行数的Top 20列表，包括：事务ID影响行数事务执行时间Top 20表格1小时（相对）事务执行时间的Top 20列表，包括：事务ID执行时间（毫秒）安全中心：展示了目标PolarDB-X实例下所有数据库的失败SQL和危险SQL（DROP或RUNCATE类型的SQL），以及大批量（影响行数超过100行）删除或修改事件的详情、分布和趋势等。分类图表类型默认时间范围描述安全指标错误数单值1小时（相对）失败SQL的执行次数。大批量删除事件单值1小时（相对）大批量删除事件的 SQL数量。大批量修改事件单值1小时（相对）大批量修改事件的SQL数量。危险SQL执行单值1小时（相对）危险SQL的数量。危险IP数单值1小时（相对）危险IP的数量。说明 更多关于危险IP的详情，请参见安全检测函数。错误分布错误操作类型分布面积图1小时（相对）失败SQL的类型分布。出错客户端外网分布地图1小时（相对）失败SQL的客户端在中国地图上的分布。错误最多的客户端表格1小时（相对）失败SQL的客户端列表，包括：客户端（IP、城市、网络）错误次数主要错误（查询、插入有、更新、删除、其它）出错样例危险SQL情况危险SQL 执行列表表格1小时（相对）危险SQL的列表，包括：SQL开始执行的时间点客户端（IP、城市、网络）SQLPolarDB-X实例ID数据库表格用户大批量事务大批量删除事件Top 50表格1小时（相对）大批量删除SQL的列表，包括：最早执行时间最近执行时间PolarDB-X实例ID数据库表格执行次数平均删除行数平均时长（秒）SQL大批量修改事件Top 50表格1小时（相对）大批量修改 SQL 的列表，包括：最早执行时间最近执行时间PolarDB-X实例ID数据库表格执行次数平均更新行数平均时长（秒）SQL修改数据统计时间日志报表页面的所有图表都是基于不同时间段（默认为过去1小时内的）的数据统计结果，您可以根据业务需求修改目标页签下的所有图表或单一图表的数据统计时间范围。修改目标页签下所有图表的数据统计时间在目标页签右上角，单击请选择，在弹出的页面中修改当前页面所有图表的数据统计时间。修改目标页签下单一图表的数据统计时间将鼠标放置在目标图表右侧的图标后，单击选择时间范围，在弹出的页面中修改当前图表的数据统计时间。

前提条件已注册阿里云账号，并完成实名认证，详情请参见阿里云账号注册流程。 已开通日志服务。首次登录日志服务控制台时，根据页面提示开通日志服务。目标PolarDB-X实例下已创建数据库。 操作步骤登录云原生分布式数据库控制台。在页面左上角选择目标实例所在地域。在实例列表页，单击PolarDB-X 2.0页签。找到目标实例，单击实例ID。在左侧导航栏，单击诊断与优化 > SQL审计与分析。在页面右上角，打开当前数据库SQL审计日志状态开关即可。执行结果SQL审计功能开启后，相同地域下的PolarDB-X数据库的审计日志会写入同一个日志服务的Logstore中。同时，日志服务为您创建以下默认配置。警告 日志服务会不定期更新与升级SQL日志审计功能，专属日志库的索引与默认报表也会自动更新，因此请勿随意删除或修改日志服务为您默认创建的Project、Logstore、索引和仪表盘等设置。默认配置项配置内容Project默认为您创建Project为polardbx-sqlaudit-地域ID-阿里云账户ID，例如polardbx-sqlaudit-cn-hangzhou-123456789。Logstore默认为您创建Logstore为polardbx-sqlaudit-log。地域相同地域下的PolarDB-X数据库的审计日志会写入同一个日志服务的Logstore中。例如，华东1（杭州）地域中所有可用区的PolarDB-X数据库审计日志都会写入日志服务的Logstorepolardbx-sqlaudit-cn-hangzhou-阿里云账户ID 中。Shard默认创建5个分区（Shard），并开启管理Shard功能。索引日志服务自动为您创建索引。警告 您的索引设置会随着功能升级自动更新，请勿手动修改或删除索引。日志存储时间默认保存45天，45天以上的日志自动删除。仪表盘PolarDB-X默认创建如下三个仪表盘：运营中心性能中心安全中心关于仪表盘的更多信息，请参见日志报表。说明 请勿修改默认的仪表盘配置，默认仪表盘会随着功能升级自动更新。您也可以自定义创建新的仪表盘，详情请参见创建仪表盘。

 1 内容介绍随着我国经济持续高速发展,能源、特别是电能的消耗量越来越大；为满足电能需求,今后一个时期,我国电力行业仍需大规模建设。在化石能源逐渐枯竭、环境压力逐年增大的背景下,在现有配电网上引入分布式发电技术将是电力系统未来发展方向之一。分布式电源既能用于电力调峰,也可为边远地区独立供电,还能在节能环保同时给供电企业带来可观的经济效益。但是,分布式电源的引入会对配电网的节点电压、线路电流、功率分配和供电可靠性造成影响,这种影响与分布式电源安装的位置和容量密切相关。因此,研究配电网中分布式电源的选址定容问题是非常重要的工作。为了描述配电网的物理结构、计算配电网的运行状态,本文建立了配电网物理结构的等效模型,并用牛顿-拉夫逊方法计算配电网的潮流。在此基础上,对普通配电网的供电成本进行了计算。本文建立了一种在已有配电网中解决分布式电源选址定容问题的模型,并应用遗传算法对其进行求解。该模型考虑了四项经济指标：发电总成本、分布式电源安装费、停电罚款、碳排放罚款及环境效益损失。以IEEE 33节点配电网系统为算例,对模型适用性和算法的有效性进行验证。2 仿真代码function orgloss(B1,B2,isb,H,pr,Vb,Sbz)n=33;%n=39 ;       n1=32;%n1=38;Zb=(Vb^2/Sbz)*100;for i=1:n1    B1(i,3)=B1(i,3)./Zb;    B1(i,4)=B1(i,4)./Zb;endB1;for i=1:n    B2(i,3)=B2(i,3)/Sbz;    B2(i,4)=B2(i,4)/Sbz;    B2(i,5)=B2(i,5)/Vb;endB2;Y=zeros(n);               %zeros就是生成一个全0的矩阵%创建节点导纳矩阵   电导统一为零for i=1:n1        p=B1(i,1);        q=B1(i,2);        Y(p,q)=Y(p,q)-1/((B1(i,3)+B1(i,4))*B1(i,5));        Y(q,p)=Y(p,q);        Y(p,p)=Y(p,p)+1/(B1(i,3)+B1(i,4))+0.5*B1(i,6);%低压侧不变        Y(q,q)=Y(q,q)+1/((B1(i,3)+B1(i,4))*B1(i,5)^2)+0.5*B1(i,6);%高压侧阻抗乘以变比平方  输入时注意低压侧在前end%disp('节点导纳矩阵：') ;Y;G=real(Y);B=imag(Y);[B1,B2,Times]=powerflow(B1,B2,n,H,pr,isb,Y);disp('初始潮流计算结果如下：');disp('迭代次数：');Timesdisp('节点电压幅值如下（按节点由小到大的顺序）：');B2(:,5)B2%创建Sb，用于存储平衡节点功率Sb=zeros(1);for i=1:n    if i==isb        for j=1:n           Sb=Sb+(B2(i,5)+sqrt(-1)*B2(i,6))*conj(Y(i,j))*conj(B2(j,5)+sqrt(-1)*B2(j,6));         end                                                                endenddisp('初始平衡节点功率：')Sb%求解各条支路的功率Sij=zeros(n);for i=1:n     for j=1:n     Sij(i,j)=Sij(i,j)+(B2(i,5)+sqrt(-1)*B2(i,6))^2*conj(B1(1,4))+(B2(i,5)+sqrt(-1)*B2(i,6))*conj(Y(i,j))*(conj((B2(i,5)+sqrt(-1)*B2(i,6)))-conj((B2(j,5)+sqrt(-1)*B2(j,6))));       endend%disp('线路功率分布：')Sij;%%%求解系统网损Ploss=0;for i=1:n                    for j=1:n            Ploss=Ploss+B2(i,5)*B2(j,5)*(G(i,j)*cos(B2(i,6)-B2(j,6))+B(i,j)*sin(B2(i,6)-B2(j,6)));         endenddisp('初始网损：')Ploss*100000003 运行结果编辑4 参考文献[1]张元凯. 基于遗传算法的分布式电源选址定容问题研究[D]. 东北大学, 2013.[2]徐珂, 聂萌, 王洋,等. 基于改进遗传算法的分布式电源选址定容优化方法及系统:, CN108734349A[P]. 2018.博主简介：擅长智能优化算法、神经网络预测、信号处理、元胞自动机、图像处理、路径规划、无人机等多种领域的Matlab仿真，相关matlab代码问题可私信交流。部分理论引用网络文献，若有侵权联系博主删除。

一、中台是一种企业架构1.TOGAF企业架构标准TOGAF是一套企业架构标准。企业架构是指整个公司或企业的软件和其他技术的整体观点和方法。企业架构又细分为业务架构、应用架构、数据架构、技术架构几个方向。其中业务架构的定义是“定义业务战略和组织，关键业务流程及治理和标准”。因为数据中台其实就是组织为了更好的让数据服务业务而构建的一种企业架构，这个架构自然也会包括业务架构和其中的组织架构。定义组织架构要有明确的业务战略，中台就是目前最具有前瞻性的企业IT战略。著名管理大师钱德勒总结过一个黄金定律：战略决定组织，而组织决定成败。2.架构愿景与驱动因素个人以为数据中台架构的愿景是“加速数据驱动业务”。●业务需求驱动在这个大数据爆发的时代，业务部门已经不满足于现有数据对业务的支撑的能力，希望从数据侧获得更多、更大的驱动力。●组织规模驱动当一个组织足够大，部门分化，组织内部的各种系统林立，就会遇到同一数据多源存储使用、数据获取不便、口径难以统一的问题。因为业务系统在设计之初就是为了满足某个业务域的功能需求，缺乏对管理决策支持的设计，所以，缺乏统一的数据平台的组织很难获得全局一致的数据为管理决策做支撑，从组织内部不同部门获取的数据总是缺乏可信、相互冲突。当组织规模足够大，就需要组件一个统一的数据平台来构建组织内部统一的业务数据视图，进而驱动数据为综合业务管理决策服务的能力。●经济效益驱动我们会为每一个小的团队都配置财务、人事这些职能角色么？数据决策和分析是每个业务系统建设到一定阶段都要做的功能，要不要从其他业务系统获取数据，要不要构建自己的数据集市，这些都是重复的职能。部门自己竖烟囱，不仅仅是组织内部数据不统一的问题，还带来了资源的大量浪费。这种情况，会导致各个小团队因为人员没有专业分工，开发人员既要做业务系统功能开发，又要做数据开发，导致团队的专业度和能力受到限制。还会因为各个小团队之间业务割裂，无法达到相应规模应有的规模效应。二、构建统一数据平台1.不同阶段的功能需求计算机系统的出现最基本的诉求是替代或者协助人类进行的重复性的工作，包括计算、记录、控制等。我们从数据库角度来看，这些需求都是操作型的，传统的关系型数据库就是为了解决这类需求而构建的。系统一旦运行起来，就会进入下一个阶段，改进。系统功能的改进需要对业务过程数据进行分析，并通过分析结果进行系统功能改进。另外一方面，系统都是需要人去参与和管理的。大型组织和企业都是由多个不同业务功能的系统组成的复杂系统。如何经营与运转这些系统、管理相关的负责部门、人员，通过经营分析与绩效考核做出管理决策和调整组织的发展，这些复杂的系统，需要对数据进行分析。上面提到的这些阶段分别是：生产系统替代人力、系统改进、经营管理系统构建、管理改进。可以看到越是高阶，对数据分析的需求就越高。2.数据仓库与数据集市关于数据仓库，数据仓库之父比尔·恩门（Bill Inmon）在1991年出版的“Building the Data Warehouse”（《建立数据仓库》）一书中所提出的定义被广泛接受，数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。数据仓库是一个过程而不是一个项目；数据仓库是一个环境，而不是一件产品。数据仓库提供用户用于决策支持的当前和历史数据，这些数据在传统的操作型数据库中很难或不能得到。数据仓库技术是为了有效的把操作形数据集成到统一的环境中以提供决策型数据访问，的各种技术和模块的总称。所做的一切都是为了让用户更快更方便查询所需要的信息，提供决策支持。最开始的分析与决策需求是直接构建在业务系统上的。刚毕业的时候，我在公司做呼叫中心业务的日常管理与分析报表，都是直接在业务系统的数据库上完成的。这里会遇到一些颇具挑战的问题。首当其冲的是性能问题，人对系统返回数据的极限忍耐大概只有3-5秒，但是关系型数据库设计之初并不是决策分析服务的，所以，很多时候只有部分报表能满足这个需求，很多计算数据量大的统计报表响应时间并不好，偶尔还会遇到查询失败的情况。其次是对源系统影响的问题，因为直接在源系统上运行，报表的访问需求是一次访问很多行，如果长时间不能返回运行结果，可能会造成锁阻塞交易业务失败。最后是历史状态难以统计的问题，如果业务系统没有对每次操作保留历史，一旦过了相应的统计时点，历史的状态就难以回溯，报表中常见的环比等需求是难以实现的。所以，业务系统中的分析型需求一旦变多，就不得不做出抉择：要不要把分析型需求放在另外一个数据库实现。最简单的实现方式就是通过数据库同步工具把数据分析在备库实现，常规的数据库厂商都提供实时备库的方案，还有很多中间件产品也可以做到。但是很快结构的问题就会凸现，业务系统的数据模型是为了交易系统的模式（OLTP）设计的，在分析型（OLAP）场景上会 表现出严重的性能瓶颈。要不要为分析型需求单独创建数据模型？这样就出现了数据集市的雏形。当一个组织的IT系统非常多，部门级的数据集市就可能会需要多个业务系统的数据。10年左右我所在的公司是做银行对私CRM的，对私相关的存款、贷款、理财、基金、信用卡等系统都是不同的系统。在没有统一的数据平台（数据仓库）的银行，这些数据都是需要我们去各个系统去拿，有的话就直接从数据平台拿就可以了。如果不去构建数仓的公共模型、直接使用从业务系统的数据，也就是使用数据仓库贴源层数据，会产生很多独立的数据集市。这些独立数据集市会各自获取自己需要的数据加工，如果各个集市拿到的数据有交叉，在最终的计算结果上就会出现大家出的数据项的名字一样，但是数值不同的情况。因为缺乏统一，这个问题很难解决。如果管理方能接受稍微有些差异的统计数据，这个问题倒是也过得去。但是如果有统一的数据仓库平台，这个问题就会迎刃而解。多个集市的公共数据统一计算、协调一致，构建一个公共数据层。这样组织（企业）的数据在数据仓库环境就可以拥有一份唯一可信的版本，所有的数据都集中到了数据仓库环境，并基于共同的数据做分析。在数据仓库环境，可以支撑组织（企业）做面向企业经营管理的各种场景的数据分析、决策支持。3.构建数据管理组织如果只是在业务系统的数据库上直接做数据分析，很多时候我们只是要业务系统的研发人员兼职（未进行专业职业分工，开发质量与效率难以保证）把自己设计的表结构的数据分析统计做了。所以，在这种情况下并没有所谓的数据管理组织。但是如果从业务系统中剥离出来，构建了数据集市或者数据仓库，数据管理组织就会从业务系统的IT组织中剥离出来。站在组织（企业）管理的统一视角，我们并不建议构建独立数据集市的IT架构，还是推荐构建基于数据仓库的IT架构和相应的管理组织。从统一的视角出发，我们会把数据仓库（包括数据集成、数据公共层、数据集市），基于数据仓库的数据分析应用统一放到一个大的决策支持部门（团队）。这个团队要解决的问题就是数据分析，这个领域传统的叫法有“商业智能分析（Business Intelligence，简称：BI）”、“决策支持”。在这个组织中会分化为两类大的工作分工，平台和应用。平台就是着眼于数据集成、公共层构建、数据管理、数据服务，用来支撑应用集市的各种能力。应用就是原来从业务系统中剥离出来的系统分析与改进、业务管理的分析与改进，这些数据分析的能力。整个团队的目标都是服务业务部门的数据分析，从层次上来说一前一后，从角色上来说一主一“辅”，共同完成业务的数据分析需求。所以，从职能上可以把数据平台的组织分为三大块：平台管理团队、基础平台团队、数据应用团队。平台管理团队负责整体平台的架构管理职能、数据治理职能，管理数据平台与数据应用团队进行日常数据研发与维护工作。平台管理团队的下辖的需求管理组负责整个平台的业务需求的统一管控，确保数据平台组织和数据应用组织对业务需求的理解是一致的、工作的分解是认可的。平台管理团队下辖的架构管理组负责制定和维护整个平台的集成架构、分层架构、服务架构。平台管理团队下辖的数据治理组负责制定面向质量、安全的管理要求和标准规范，监督整个数据平台组织的治理能力的落地执行。平台管理团队下辖的运行维护组织负责对整个组织内部使用的各项资源管理，软件与数据库日常运维。基础平台团队是支撑数据应用团队的共性数据需求。数据应用组一般按照业务部门构建，会根据部门需求构建部门级的数据集市或者应用级的数据集市。基础平台团队所做的数据模型的建设工作，是面向数据应用中的公共的部分，例如原始数据的集成，明细粒度数据模型的设计，汇总粒度的数据模型设计。大体的划分原则是基础的集成和明细粒度数据，只要有一个应用使用，这个基础能力就要补充在基础平台组织的明细层模型。而汇总粒度的数据模型设计则需要2个以上的应用的共性需求，才会构建到基础平台汇总层模型。数据应用团队的人员管理权限在数据平台，但是服务的对象是实际的业务部门。业务部门就是数据应用组的甲方，而数据应用组则是业务需求的承建乙方。组织架构如下：4.构建数据管理流程数据管理流程是指数据平台组织内部从需求到研发交付中各个组织、人员之间的协作流程。●研发管理流程上图是一个数据平台数据研发管理流程，从业务需求到数据开发都有哪些团队的什么角色的人员参与，不同的团队角色负责哪些模块。1.业务部门提出需求。业务部门有专门与数据平台对接的角色，这个角色是业务部门中的IT人员，他们负责接收业务侧的业务需求转化为IT侧的需求。2.平台管理团队的需求管理组会接受业务需求，并组织基础平台团队与数据应用团队来对业务需求进行评审和分解。这个过程会确定哪些需求可以在基础平台部门实现，要实现这些需求基础平台团队和数据应用团队都应该做哪些工作。这里的主要拆分原则就是公共、共享需求在基础平台团队实现和个性在数据应用团队实现。因为有的时候会做一些提前的设计，所以，这个公共的尺度主要由基础平台团队把握，由架构组和治理组定期参与评审。3.进入设计与研发阶段，两个团队会通力配合，分别研发自己负责的部分，联合开发、测试、发布，并按照研发计划确保正常上线。4.因为基础平台的公共层累积到一定程度，就可以覆盖大部分的基础数据需求。所以，基础平台团队在需求评审过程结束后可能并没有实际要开发的工作，只需要做好当前公共层数据数据使用的业务支持、答疑解惑。●架构管理流程架构管理主要管理两个方面，第一技术架构，第二业务流程架构。其中技术架构包括数据集成架构、研发分层架构。数据集成架构确定了业务系统与数据平台之间的数据集成工具与方案，离线集成采用什么方案、实时集成采用什么方案，在什么系统和场景下使用什么方案。集成架构在两种情况下会有更新，第一新的系统集成需求，第二原有的集成方案不满足业务需求。在需求评审阶段，如果遇到上面两个问题，可以邀请架构组进入到需求阶段评估，把架构问题验证通过并形成方案后，再进入开发阶段。数据分层架构主要的目的是把数据研发工作分为贴源层、公共层、应用层这几个大的层次，原则上应用层只能从公共层获取数据、公共层的贴源层数据可以覆盖应用层的数据范围，公共层的汇总层可以覆盖多个应用层的共性加工需求。分层架构在平台创建初期制定，后期也不需要调整。架构管理组主要的作用是在开发阶段、运维阶段调研发现有违反分层架构原则的问题，并提出相应的整改要求。架构组的管理流程主要是发现问题，并发起整改的需求流程。●数据治理流程数据质量主要分为集成质量、数据加工质量、线上服务质量三部分。管理流程主要是确保质量工作做到位、及时发现质量问题，并跟进问题的解决。质量工作检查点流程要在研发工作中嵌入，开发脚本后是否有做单元测试，测试的报表是否有主管的review确认。应用上线前有没有做应用的功能测试、数据验证测试，是否有主管的review确认。重要的业务，是否做了线上质量问题监测的任务。这些检查点，要能在日常工作中体现，并可以给质量团队按期审核。数据质量问题发现。通过源端数据质量监测、线上数据质量问题监测，及时发现问题。并通过治理流程，把问题派发到相应的责任组织进行改进。数据安全主要解决日常工作使用数据的安全流程。主要分为数据研发过程中的安全检查点及数据权限申请与审批流程。数据安全检查点要在研发工作中嵌入。依据最小可用原则，在研发阶段申请到的安全级别高的数据权限，在进入上线后固定时间区间会被自动释放。每一类数据表和数据项，原始的数据安全分级在加工后要进行重新评定。数据权限申请与审批流程，确定了组织内哪些组织是数据的生产方和拥有者，拥有者最终审批决定数据内容的访问权限。审批流程要能体现出相关的业务需求和功能需求确实需要相应的数据进行开发、业务分析等场景，并能体现实际操作人员和其主管的审批责任。还有是否设定专业的评审角色对相应流程进行管理，数据分类分级的审批结果是否在组织内部定期回顾等。●运维管理流程运维管理是研发管理的延伸，数据研发的意义不是研发过程而是数据本身，数据平台提供了数据的服务，保障服务的质量也是数据质量的一个方面。运维管理流程从平台基础技术组件、平台批量任务运行、平台提供的数据服务能力几个方面对平台进行运维保障。平台运维管理流程主要的目的是在发现问题后，保障整个组织能快速的对对问题做出决策，找到第一责任人和问题兜底处理团队，确保问题快速修复。并能在事后，对问题发生的原因进行分析改进与问题追责。资源管理流程从整个平台资源规划与利用的角度，对新创建的数据应用、原有数据应用对数据平台的资源使用进行合理的扩容、缩容。在平台管理团队发现对资源使用不利的问题后（例如存储资源、计算性能），引入架构团队与研发团队，共同对问题进行解决。也可以由应用侧发起流程，引入运维与架构团队，协助问题处理。三、加速数据服务业务1.数据中台还是后台“数据中台还是数据后台“，这是一个涉及到本质的话题。从组织整体架构来看，IT部门就是一个后台支持部门，业务部门才是前台部门。从IT架构来看，业务和生产系统才是一线人员的核心支撑，数据分析更多的是从事后分析和事中研判的角度出现，仍然是一个偏后台的角色。从管理和经营的角度来看，这部分工作主要依托数据分析的结果进行辅助决策，所以对数据分析的依赖更高。即便是某个生产过程中的最细小的环节，在进行数据分析后都可能获得巨大的业务改进价值。但是困难的是如何能从数据中发掘出能改进业务、辅助决策的数据价值。在传统的数据仓库环境，数据部门一直被当作一个后台部门。常规的业务模式就是被动响应的模式，对业务部门的响应与业务需求之间的关系是迟滞的。之前参与过的一个项目，一线人员提的需求，排计划都排到了1年以后。后台部门能获取到的资源都是局促的，数据服务业务的能力也是局促的。所以，回过头来看数据中台，我们是否转变思维，核心还是要把数据部门放到更重要的位置，加大对数据部门的投资。让数据部门对业务的支撑能力和规模更大，相比之前更加前置。让数据部门从一个纯成本部门的位置变成真正的价值部门的位置。值得关注的是，在近些年大数据风起云涌带来的巨大的技术变革中，阿里提出的中台战略依托这种变革看到了数据服务业务的更大的潜力，并兴起了数据中台建设的大潮。2.加速数据服务业务数据中台最核心的诉求，还是希望加速利用数据服务业务。因为“数据服务业务”这个口号可能几十年前就有了，所以相比之前数据中台要做的就是让这个过程的速度更快，“加速数据服务业务”。如何加速呢？大数据技术给我们带来了更多技术的可能，让数据服务业务的能力和范围更加扩展。但是并不能解决速度问题，如果组织规模和能力不变，反而可能因为事情变多、技术变复杂，变得更慢。所以，构建中台化的组织是非常重要的。从技术上补充大数据与算法分析的人员能力，从组织上对数据团队进行分化扩充，让数据对业务支撑从以前的力不从心变成绰绰有余才可以做到真正的加速。对数据中台的投资近些年变的越来越大，越来越多的组织尝试对自己的数据团队做出变革，引入相关的技术与项目。但是我们是否从本质上对组织结构和模式做出改变呢？我们是否创建出了更加敏捷的数据业务化、业务数据化的通路，来适应这个大变革的时代？对数据部门来说，我们要怎么做调整工作方法和思维，才能加速数据服务业务？数据中台的核心思想其实已经告诉我们，就是“服务化”。只有我们把数据变成各种触手可得的服务，才能真正做到加速。服务化（数据即服务、信息即服务、分析即服务）需要我们把业务人员需要的不同层次的数据、信息、分析都变成服务，用服务化的思想，服务化的流程去支撑业务。从之前的被动响应变成主动推送，从业务人员自己去发现问题提出改进需求，变成与一起为业务人员发掘需求，变成业务人员的左右手。为此，我们需要面向更好的服务业务去建设服务化的能力与应用，构建面向服务的组织。只有这样才能真正实现数据中台的业务目标。3.构建服务化的组织服务化的组织的创建要以服务为目标构建，要创造一个数据部门的“客户服务团队”，这个团队能快速响应业务部门对数据部门的服务需求，并在组织内部分解需求，对需求做出快速的响应。所以，在组织架构的设计上，我把数据管理组重新定义为数据服务组，并在这个组织下新增数据服务运营（资产运营）组。服务化的起点一定是组织的管理层以服务化为目标去构建组织，所以要在管理组织内分化出数据服务管理职能。数据服务团队除了之前对数据平台和数据应用组织有协调和指导的作用，组内需求管理、架构管理、数据治理、运行维护等职能外，新增数据服务运营子团队（服务运营&资产运营）。这个团队与数据平台和数据应用一样，也是一个直接负责对接业务、解决业务问题的组织。这个组织通过梳理整个平台的数据资产，提供平台层面的数据资产服务门户，对整个平台的服务能力和服务质量进行监督管理。并通过资产门户直接面对一线业务人员和数据研发人员提供数据平台的数据和应用的咨询服务、即时分析服务，收集平台侧零散的业务和技术需求，并从服务的角度评价平台的产品、团队的服务能力。4.构建数据服务流程服务化的组织需要整合和重构原有的业务流程，通过服务化去减少或者缩短业务与数据之间的距离。下图是一个依托数据门户的服务流程举例：在数据中台的服务构建中，数据门户是非常重要的一环。门户会让数据团队与业务人员之间的技术和距离的鸿沟消失，构建出一个交互和共建的数据协作平台，通过对平台所有数据资产的梳理与服务以及问答等服务化的方法让原有的数据研发流程变短。所以，我们的数据服务流程都要以资产门户为基础去构建。上图是一个面向服务的数据研发组织阵型，每个数据团队都有不同的分工。但是我们在传统的数据需求组织直接面对业务部门的基础上增加了数据服务组织。我们以下面几个场景为例，来看服务化流程。1.数据服务场景。通过数据资源目录找到相应的数据，申请权限；2.数据报表需求；a需求：定义报表，指标定义,标签定义b开发：数据元定义，模型设计,数据模型映射，算法定义；c运维：质量问题反馈3.数据问答；a找不到数据；数据服务组，指定到数据资源目录对应的表；b对特定数据使用问题；数据服务组解答，如果是质量问题，转到质量管理；开发把质量问题转变为需求，需求组审核，进行开发；4.数据安全；a 治理组，定义新增数据源的数据安全；b 数据组，数据变化后，修改数据安全的定义级别；c 治理组，审核通过后，定义最终确定后才会在数据资源目录开放；四、道路艰险而漫长从管理学角度，组织（Organization）即由若干个人或群体所组成的、有共同目标和一定边界的社会实体。它包含三层意思：(1)组织必须是以人为中心，把人、财、物合理配合为一体，并保持相对稳定而形成的一个社会实体。(2)组织必须具有为本组织全体成员所认可并为之奋斗的共同目标。(3)组织必须保持一个明确的边界，以区别于其他组织和外部环境。上述三条，是组织存在的必要条件。数据中台的组构建是数据中台成功的关键因素，并不是我们购买了某一款中台产品或者做了一个相关咨询就能达成中台的目标。我以一般的数据仓库项目为例，在做数据仓库项目的时候，我们长用3-5-7这三个数字来衡量一个组织数据仓库平台的成熟度。即便是客户购买了行业领先的行业解决方案和产品，也需要3年才能达到基础，5-7年才能相对成熟。而数据中台架构中又包含数据仓库的构建，涉及的组织面更大、涉及的工作范围更大，即便我们仍然使用数据仓库的标准来衡量，我们现在的数据中台项目大多还都处在打基础这个范围内（阿里大约在2018年左右提出了数据中台架构）。在数据中台构建的道路上，我们仍然会遇到很多很多的未知和困难，只有不断的排除这些困难才能达到最终的目标，中台化的组织构建就是实现这个目标的利器。因为每个组织对中台的需求和目标都可能有差异，组织内部也各有不同，以上的内容思考更多是从一个行业参与者的个人角度，给相关的组织提供一些思考和参考的内容，思考有所欠缺的部分还请指正。

进程管理进程就是运行中的程序，一个运行着的程序，可能有多个进程。 比如 LinuxSir.Org 所用的 WWW服务器是 apache 服务器，当管理员启动服务后，可能会有好多人来访问，也就是说许多用户来同时请求 httpd 服务，apache 服务器将会创建有多个 httpd 进程来对其进行服务。进程分类进程一般分为交互进程、批处理进程和守护进程三类。值得一提的是守护进程总是活跃的，一般是后台运行，守护进程一般是由系统在开机时通过脚本自动激活启动或超级管理用户 root 来启动。比如在 Fedora 或 Redhat 中，我们可以定义 httpd 服务器的启动脚本的运行级别，此文件位于/etc/init.d 目录下，文件名是 httpd，/etc/init.d/httpd 就是 httpd 服务器的守护程序，当把它的运行级别设置为 3 和 5 时，当系统启动时，它会跟着启动。[root@localhost ~]# chkconfig --level 35 httpd on由于守护进程是一直运行着的，所以它所处的状态是等待请求处理任务。比如，我们是不是访问LinuxSir.Org ，LinuxSir.Org 的 httpd 服务器都在运行，等待着用户来访问，也就是等待着任务处理。进程的属性进程 ID（PID)：是唯一的数值，用来区分进程；父进程和父进程的 ID（PPID)；启动进程的用户 ID（UID）和所归属的组（GID）；进程状态：状态分为运行 R、休眠 S、僵尸 Z；进程执行的优先级；进程所连接的终端名；进程资源占用：比如占用资源大小（内存、CPU 占用量）；父进程和子进程他们的关系是管理和被管理的关系，当父进程终止时，子进程也随之而终止。但子进程终止，父进程并不一定终止。比如 httpd 服务器运行时，我们可以杀掉其子进程，父进程并不会因为子进程的终止而终止。在进程管理中，当我们发现占用资源过多，或无法控制的进程时，应该杀死它，以保护系统的稳定安全运行进程管理命令psps 为我们提供了进程的一次性的查看，它所提供的查看结果并不动态连续的；如果想对进程时间监控，应该用 top 工具。ps 的参数说明：ps 提供了很多的选项参数，常用的有以下几个； l 长格式输出； u 按用户名和启动时间的顺序来显示进程； j 用任务格式来显示进程； f 用树形格式来显示进程； a 显示所有用户的所有进程（包括其它用户）； x 显示无控制终端的进程； r 显示运行中的进程； ww 避免详细参数被截断； 我们常用的选项是组合是 aux 或 lax，还有参数 f 的应用； ps aux 或 lax 输出的解释；USER 表示启动进程用户。PID 表示进程标志号。%CPU 表示运行该进程占用 CPU 的时间与该进程总的运行时间的比例。%MEM 表示该进程占用内存和总内存的比例。VSZ 表示占用的虚拟内存大小，以 KB 为单位。RSS 为进程占用的物理内存值，以 KB 为单位。TTY 表示该进程建立时所对应的终端，"?"表示该进程不占用终端。STAT 表示进程的运行状态，包括以下几种代码：D，不可中断的睡眠；R，就绪（在可运行队列中）；S，睡眠；T，被跟踪或停止；Z，终止（僵死）的进程，Z 不存在，但暂时无法消除；W，没有足够的内存分页可分配；<高优先序的进程；N，低优先序的进程；L，有内存分页分配并锁在内存体内（实时系统或 I/O）。START 为进程开始时间。TIME 为执行的时间。COMMAND 是对应的命令名。 ps 应用举例：实例一：ps aux 最常用[root@localhost ~]# ps -aux |more可以用 | 管道和 more 连接起来分页查看；[root@localhost ~]# ps aux > ps001.txt[root@localhost ~]# more ps001.txt 这里是把所有进程显示出来，并输出到 ps001.txt 文件，然后再通过 more 来分页查看；实例二：和 grep 结合，提取指定程序的进程；[root@localhost ~]# ps aux |grep httpdroot 4187 0.0 1.3 24236 10272 ? Ss 11:55 0:00 /usr/sbin/httpdapache 4189 0.0 0.6 24368 4940 ? S 11:55 0:00 /usr/sbin/httpd实例三：父进和子进程的关系友好判断的例子：这里用到了 f 参数；父与子关系一目了然；[root@192-168-189-131 ~]# ps auxfroot      3609  0.0  0.0   2364    80 ?        Ss   Jun18   0:00      |   \_ runsv grafanaroot      3610  0.0  0.0   2508   288 ?        S    Jun18   0:00      |       \_ svlogd -tt /var/log/gitlab/grafana992       3611  0.0  0.7 1524792 29412 ?       Ssl  Jun18  24:49      |       \_ /opt/gitlab/embedded/bin/grafana-server -config /root      3876  0.0  0.0   5720   272 ?        S    Jun18   0:00      \_ /bin/bash /opt/gitlab/bin/gitlab-ctl tailroot      3877  0.0  0.0  96932  1924 ?        S    Jun18   0:01          \_ /opt/gitlab/embedded/bin/ruby /opt/gitlab/embedded/biroot      3879  0.0  0.0   2600   192 ?        S    Jun18   0:00              \_ sh -c find -L /var/log/gitlab -type f -not -path  root      3882  0.0  0.0   4552    76 ?        S    Jun18   0:00                  \_ xargs tail --follow=name --retryroot      3883  0.0  0.0   4288   196 ?        S    Jun18   4:23                      \_ tail --follow=name --retry /var/log/gitla例四：找出消耗内存最多的前 10 名进程# ps -auxf | sort -nr -k 4 | head -10 例五：找出使用 CPU 最多的前 10 名进程# ps -auxf | sort -nr -k 3 | head -10pstree功能：pstree 命令列出当前的进程，以及它们的树状结构。格式：pstree [选项] [pid|user]主要选项如下：-a：显示执行程序的命令与完整参数。 -c：取消同名程序，合并显示。 -h：对输出结果进行处理，高亮显示正在执行的程序。 -l：长格式显示。 -n：以 PID 大小排序。 -p：显示 PID。 -u：显示 UID 信息。 -G：使用 VT100 终端编码显示。 -U：使用 UTF-8（Unicode）编码显示。 说明：使用 ps 命令得到的数据精确，但数据庞大，这一点对掌握系统整体概况来说是不容易的。pstree 正好可以弥补这个缺憾。它能将当前的执行程序以树状结构显示。pstree 支持指定特定程序（PID） 或使用者（USER）作为显示的起始。应用实例如下:进程启动的时候可能会产生自己的一个子进程。运行 pstree 命令就可以很容易地看到这些信息。以超级用户权限运行 应用实例如下。进程启动的时候可能会产生自己的一个子进程。运行 pstree 命令就可以很容易地看到这些信息。以超级用户权限运行 pstree：如果出现一下问题：-bash: pstree: command not found需要安装一下：[root@192-168-189-131 ~]# yum -y install psmisctoptop 命令用来显示系统当前的进程状况。格式：top [选项]主要选项如下d：指定更新的间隔，以秒计算。 q：没有任何延迟的更新。如果使用者有超级用户，则 top 命令将会以最高的优先序执行。 c：显示进程完整的路径与名称。 S：累积模式，会将已完成或消失的子进程的 CPU 时间累积起来。 s：安全模式。 i：不显示任何闲置（Idle）或无用（Zombie）的进程。 n：显示更新的次数，完成后将会退出 top。 说明：top 命令和 ps 命令的基本作用是相同的，都显示系统当前的进程状况。但是 top 是一个动态显 示过程，即可以通过用户按键来不断刷新当前状态。这里结合下图来说明它给出的信息。第一行表示的项目依次为当前时间、系统启动时间、当前系统登录用户数目、平均负载。第二行显示的是 Tasks: 114 total 进程总数、2 running 正在运行的进程数、110 sleeping 睡眠的进程数、0 stopped 停止的进程数、2 zombie 僵尸进程数第三行显示的是目前 CPU 的使用情况，Cpu(s): 0.3% us 用户空间占用 CPU 百分比、1.0% sy 内核空间占用 CPU 百分比、0.0% ni 用户进程空间内改变过优先级的进程占用 CPU 百分比、98.7% id 空 闲 CPU 百分比、0.0% wa 等待输入输出的 CPU 时间百分比、0.0% hi、0.0% si第四行显示物理内存的使用情况，Mem: 191272k total 物理内存总量、173656k used 使用的物理内存总量、17616k free 空闲内存总量、22052k buffers 用作内核缓存的内存量第五行显示交换分区使用情况，Swap: 192772k total 交换区总量、0k used 使用的交换区总量、192772k free 空闲交换区总量、123988k cached 缓冲的交换区总量、内存中的内容被换出到交换区，而后又被换入到内存，但使用过的交换区尚未被覆盖，该数值即为这些内容已存在于内存中的交换区的大小。相应的内存再次被换出时可不必再对交换区写入。第六行显示的项目最多，下面列出了详细解释。PID（Process ID）：进程标志号，是非零正整数。USER：进程所有者的用户名。PR：进程的优先级别。NI：进程的优先级别数值。VIRT：进程占用的虚拟内存值。RES：进程占用的物理内存值。SHR：进程使用的共享内存值。STAT：进程的状态，其中 S 表示休眠，R 表示正在运行，Z 表示僵死状态，N 表示该进程优先值是负数。%CPU：该进程占用的 CPU 使用率。%MEM：该进程占用的物理内存和总内存的百分比。TIME：该进程启动后占用的总的 CPU 时间。COMMAND：进程启动的启动命令名称，如果这一行显示不下，进程会有一个完整的命令行。top 命令使用过程中，还可以使用一些交互的命令来完成其他参数的功能。这些命令是通过快捷键启动的。<空格>：立刻刷新。A 分类显示系统不同资源的使用大户。有助于快速识别系统中资源消耗多的任务。f 添加删除所要显示栏位. o 调整所要显示栏位的顺序. r 调整一个正在运行的进程 Nice 值. k 结束一个正在运行的进程. z 彩色/黑白显示开关P：根据 CPU 使用大小进行排序。T：根据时间、累计时间排序。q：退出 top 命令。m：切换显示内存信息。t：切换显示进程和 CPU 状态信息。c：切换显示命令名称和完整命令行。M：根据使用内存大小进行排序。W：将当前设置写入～/.toprc 文件中。这是写 top 配置文件的推荐方法。可以看到，top 命令是一个功能十分强大的监控系统的工具，对于系统管理员而言尤其重要。但是，它的缺点是会消耗很多系统资源