前言：笔者从事于传统软件行业十五年以上，曾就职于国内大、中、小型软件公司及传统企业的IT部门，也曾去过外企（日企等），自己觉得对.net各方面的开发、架构及运用，以及各类通用的软件及行业软件诸如OA、财务、CRM、人事及ERP、WMS、MES，GIS、BIM、教育、电商、网站、APP等都有了相当程度的了解，已经有了个人特色的编程思想。在一次偶然的机会，我去了某微软外服公司，参与了微软某大数据平台的开发工作，顿时感觉眼界大开、以前积累的知识经验等完全派不上用场，仿佛进入了一片从所未知的知识海洋。微软在大数据、云计算、人工智能、边缘计算、数字孪生方面等远远走在了中国的前面，已经完全有了自己可演进的生态体系。在此我把在微软外服的一些工作经历和内容在不涉密的情况下分享出来，希望对大家有所帮助。我主要讲和国内企业以及普通外企不一样的地方，初来乍到，说的不对的地方希望各位多多指导。（注意：文章比较长，可以先收藏再查看）
我入职的是微软某业务部门的大数据外服团队，入职的经历如下：
填写大量的表格，数量仅次于二手房过户交易和办理过银行按揭贷款；
体检：公司替你预约好了体检名额，自己预约体检时间即可；
背调：背景调查由国外知名的背调公司进行，需要上网注册账户，填写表格、上传证件等，这家公司应该也是微软在全球的背调合作伙伴；
公司入职培训：有些是线下的、有些线上的，培训结束都需要在线进行测试，通过的标准各不相同；
微软入职培训：有Supplier Code of Conduct Training, Microsoft Security 101，Privacy 101等，如果申请别的权限组，还要进行Privacy 201、Security Foundations、Windows Data Handling等的在线培训。总结这些培训，感到微软在客户的合同和服务、以及新产品的研发上市信息等比较关注，要求所有人严格保密；
值得一提的是，微软的在线培训网站做的非常漂亮，我算是在界面和美工方面很挑剔的了，也禁不住对他们的网站感到赞叹！这里我截两张图
虽然是内部网站，他们也是在页面框架设计、照片方面精益求精、花了不少心思的。
入职两周左右，终于收到了微软开通的账号，账号的格式是v-xxxx@microsoft.com，这是微软专门为Vendor开通的账号，据说以前还有@msn.com结尾的，现在申请不到了。有了这个账号，我们可以给电脑加域（中国区基本是fareast域，访问到的多数是fareast、Redmond和NorthAmerica域的资源）、登录VPN，不受限制地访问网络、自动激活电脑上的Windows、Office、Visual Studio等软件，还可以申请微软的资源权限组和安全权限组。部门的一些老鸟有六、七十个组，我申请了二十来个，有了权限，你可以访问微软全球的数据库、代码库和内部网站。微软公司通过VPN、AD域、Portal以及和Windows、Office套件等的全面集成，把整个公司遍布全球的海量内部资源整合起来，实现跨地域、跨时区、跨部门、跨种族的工作协作；比如我们的大数据业务部门，就能经常收到Cosmos组的求助邮件；有的时候我们在处理报表的时候还能直接和微软PowerBI开发小组进行会议沟通，而对方的工程师很可能是来自印度或越南的程序员小哥。他们在帮你解决问题的时候，不会管你是公司直属部门还是Vendor，不管你是黑人、白人还是黄色人种、来自哪个派系，一视同仁地提供技术服务（这也正是比尔盖茨推荐的《世界是平的——21世纪简史》一书中描绘的景象）；当国内的公司各部门之间还在抢夺资源和功劳、相互拆台、各自为政搞山头主义的时候，不能为微软的开放和平等感到羞愧吗？
微软的工作区域称之为Offsite Facility，门口有保安，进出都需要刷卡，进去后就等于进入了微软内部的工作区域，不允许携带除手机外的任何电子产品；里面各个区域都相对独立，进入机房和会议室还要刷不同级别的卡；内部网络独立，连重装系统都得用微软自己的装机软件，保证装出来的系统干净、无毒，受到微软的管控。然后电脑上只允许装微软授权的软件（大概三四十个左右），安装未经授权的软件可是要受到处罚的。理论上微软可以监控到你在电脑上的一举一动，前些日子有人安装了Adobe的软件，微软立马就给所有的Vendor发警告邮件，要求卸载。正因为操作系统时时刻刻受到微软监控，所以我们国家一些重要的政府机关都有封闭的内部网络，从外部需要通过堡垒机访问；国家还在芯片、操作系统研发上投入巨资（也被PPT和打磨的芯片骗走不少钱），就是出于安全上的考虑；都用老美的芯片和系统，对FBI、CIA等就没有秘密可言了。
每个工位配备两台显示器（也有的工位使用三台，看见一位女孩在那边熟练地操纵）、一副耳麦（因为经常要和国外sync up），电脑都是最新11代i7芯片。工作环境从操作系统到应用软件是全英文的，使用在线的Office文档编辑（前身可能是OWA）、通讯使用Team软件（类似于腾讯QQ+腾讯会议，可以录屏（微软官方很大部分培训视频都是用Team录的）。
刚开始在这里工作，就算你是编程高手、技术很牛，也有三大障碍需要克服，一是技术，微软私家的大数据技术在全球领先、早已深入到各方面的业务运作中，国内最多就是教你怎么装个Hadoop，国内的云服务提供商主要业务也就是卖VPS；二是业务，工作中有上千条数据处理的流程分布在EB级的服务器集群中，不在这里工作几年，根本理不清这里面的数据流向、思路和算法；三是英语，国外发来的邮件是全英文的，specific（需求规格书）也是全英文的，回复邮件也要用英文，需要一定的英文基础，建议培训班出来同学不要来这里工作，英文这关过不了。
和我们对接的部门在美国西雅图微软总部，有十几个人，部门的主管和高级程序员都是华人，由此可见华人在微软公司内部担任了相当重要的岗位，也是微软的中坚力量。虽然都是华人，但邮件沟通也是使用英文（其实英语的文法是很美的，一点不亚于中国的唐诗宋词）。通过Outlook的部门层级示意，大家可以清晰地看到自己在微软公司内部处于怎么样的一个层级位置：
（不管是谁，都可以看见自己离微软的CEO位置其实没差几步：）
微软班车称之为MS Connector，在全市有近40条线路（节假日也有），站点遍布全市各个角落，数量可以装备一个小型城市的公交线路；班车有手机APP（据说鹅厂也有APP），APP里可以查每一条线路、每个站点、每一辆车的实时位置。上车需刷卡，刷卡机也是联网的，理论上只要刷卡上车，不管几点到公司，就算是考勤成功了。
微软内部使用的大数据平有一系列产品组成，主要供内部使用，我目前接触到的有：
数据存储、转换、计算：Cosmos、Object Store等；
数据调度：Sangam、Xflow、Azure Data Factory（ADF）等；
数据展现、可视化：Power BI、Jarvis及一些不便于透露名称的内部平台。（这里就不做介绍了）
微软也是很早就进行大数据平台研发并投入产品使用的公司之一，只不过他们的Cosmos、Object Store以及周边的平台等一直只在内部使用。不像Hadoop等很早就开源并为人熟知。据说微软会把Cosmos一部分功能开放出来，不知道目前情况怎样（Azure上的Cosmos DB和Cosmos不一样）；微软在Azure上提供了称之为HD Insight群集的功能，包括Hadoop、Spark、Storm等多种开源大数据技术，可以使用多种语言的SDK、以及在Visual Studio上使用Hive、Pig等进行开发。
Cosmos应该是微软最早的大数据平台，一直用到现在。既然是大数据，那么它有多大呢？我这里截了张图，是某个集群某天的数据量。
可以看到，这个虚拟卷上的总数据量达到了4.3EB。我们知道，1EB=1024PB、1PB=1024TB、1TB=1024GB，我计算了一下，如果用1TB的台式机硬盘装这些数据，约需要450万块，这些硬盘首尾相连可以从南京排到上海，再从上海排回南京。这还可能只是微软某一个数据中心的数据量。各个业务部门使用的数据量也十分惊人，都在几百PB级别，有的上了EB。进入目录，目录和单个文件的大小也是惊人的：
这些文件里存放着各种结构化、非结构化的数据信息。在一定的时间内对这些文件处理，并且提炼出相应的有用的信息，这就是大数据处理和分析平台的作用。
Cosmos上支持存放的文件格式有txt、Csv、Tsv、SS等，其中SS（Strut Stream）为列式存储，在很大程度上能提升查询聚合的效率、大幅度提升数据压缩率，在存放数据的时候可以选择相应的格式进行存储。
Cosmos运行平台是Windows Server，他的底层很可能是基于Hadoop、由java开发，微软扩展了它的功能，能够运行.net和python等，本身就可以执行spark任务，从一些出错信息及通过ADF可以看到。
在Cosmos上处理数据、编程开发的语言叫Scope，在我看来，Scope是种DSL（Domain Specific Language，详见Martin Fowler 的《领域特定语言》一书）；我觉得它是一种由模板语言、T-SQL、LINQ、Lambda和C#（或者Python）组成的混合体。Scope脚本上传到Cosmos后，由内置的C++解释器转译成C#，再由编译器编译成IL，执行。
大家可以看到，转译后的代码里那些标记、占位符、Linq等都转换成了可处理的Row类的Process类，方便Cosmos调度执行，Scope语言更像是SqlServer2005起用使用的CLR存储过程。
从上面看出来我感觉Scope的编译器优化功能并不强，只有些基本的优化功能，它把原始流程分解成一步步调度并行执行（不过这样也方便CPU和GPU进行简单的并行处理），这样一旦开发人员能力水平不高，会使得编写的job占用大量的CPU和IO，经常超时等。所以Cosmos上的job会产生各种状况，相同的数据和代码执行时间会相差很多，我们团队曾经把国外程序员编写的需要执行五六个小时的job优化到一半时间内执行完毕。我想如果微软如果让SqlServer开发团队参与Cosmos开发，可能会在性能优化方面要好很多。
在Cosmos上执行的任务及调度器，微软的开发团队都提供了相应的Visual Studio插件来管理，可以很方便的在VS中编写脚本、发布任务、实时查看作业的完成情况，每一步的资源消耗等，还提出了代码优化建议、资源分配的优化建议等，一些信息也可以在Windows Azure上查看：
大家可以看到，单表的数据量有400多亿条，几TB的数据量；拆解出来的处理步骤步能够在分钟级别进行筛选、置换、聚合等操作。我们还曾经收到过使用Scope的求助信息，提到了一个文件有6百多TB，五万亿多条数据，并行处理的时候需要数万个核心并行处理，结果两次拆解出来的行数不同。像这样万亿级别的表，足够保存全世界所有人每天的网页点击记录，从而带来巨大的商机。
在平台上执行脚本需要消耗token令牌，一个token关联1到2个CPU核心、3到6GB的内存。平台的总token数量有限，分配给每个团队的也有限。执行完cosmos脚本后平台会给出优化意见，进行代码调优也是一份有技术含量的工作，比较常见的问题是数据倾斜导致任务执行时间变长甚至执行失败等。
Cosmos的技术还是很牛的，既要负责大量数据的多重副本存放，还要每时每刻执行相当数量查询和计算，进行复杂的权限管理、映射等，并且得保证数据的服务质量。微软在很早以前就实现了单Cosmos集群超过9000+台服务器。（在去IOE的过程中，国内阿里王坚两个团队为了实现单集群达到5000台服务器搞了好长时间，险些没有完成，后来还大吹特吹了一番，那还只是跑mysql数据库）
Cosmos平台提供了数据存放，执行Scope脚本的功能，主要用来进行数据的ETL，和一些算法的实现（空间换时间等），那么面对每天产生的大量的增量数据，需要有一定作业调度功能，才能够按每小时、每日、每周乃至每月定时执行一些分析任务。
对大数据平台上的数据进行调度处理的平台，我们用过了Sangam、Xflow和Azure Data Factory。
Sangam应该是针对Cosmos较早的作业调度平台，在14年前后使用的团队比较多，目前处于弃用的阶段。
Xflow平台功能和Sangam的差不多，多了一些可选功能和其他作业的调度功能，在通常情况下也能正常使用，不过最近也有传言也进入了废弃期，以下是xflow的任务执行时序图。
我感觉ADF是微软大数据调度处理集大成的产品，目前已经发展到了第二代，开放给外部使用，它基于Azure云提供服务，整合了自家和市面上各种关系型、非关系型数据平台，只有你想不到的，没有它做不到的，支持的部分数据源如下图。如果数据源在内网，可以使用免费的Azure代理和云端进行数据交换。ADF能够调用Azure Function、WebApplication、HD Insight等种种复杂的功能，执行python、java包，执行机器学习，有着完整的流程处理界面，并且编程环境和自家的Azure DevOps无缝整合，使用git或者tfs进行源码管理，内部整合了全套CI/CD的功能，支持敏捷、CMMI等开发模式。从内部到外部、横向纵向都整合了起来。微软自从研发SSIS（Sql Server Integration Service，见《Professional Microsoft SQL Server 2012 Integration Services》）的年代开始，就在为统一各种数据平台、进行的数据的传输、过滤、转换、计算而努力，而据我看来Azure Data Factory应该是秉承这方面的思想而开发的，到目前为止，市面上应该还没有的类似的能与之竞争的产品，最多也只可能在某一点上对其进行模仿。
ADF底层我猜想还是用微软自家的WF（Windows Workflow）中的顺序工作流、状态机工作流进行作业管理和调度。
除了Cosmos数据库外，我们还使用了Object Store。Object Store是微软适应当下的大数据分析发展趋势，基于新一代AI+ R生态而开发的Key-Value哈希型数据库，提供了非常恐怖的访问性能和基于GPU加速，能够进行图遍历、机器学习、神经网络计算等。根据官方的文档，key的大小限制在2k，value限制在16兆以内，而单表的大小是没有限制的，很多表超过了20PB；如此大的数量，使用不同的存储介质（Memory,SSD,HDD）都能够提供毫秒级的数据访问时间。针对每个表，有着称之为CoProcessor（协程）来处理和业务所需要的数据，还有一些常驻的机器学习代码，下面放一张整体的架构图：
在Cosmos上，我们进行海量数据的存储、计算、转换，最终的一部分处理结果放到Object Store上（不全是），它能够利用协程对海量数据进行查询及展现。顾名思义，在Object Store上存放的数据都是对象，必须是满足某种格式的结构化数据，它提供了语义化的存储机制。对运行在每个表上常驻内存的Copoc（协程）来说，不管多大的数据对它来说都是透明的，都只是类的一些实例，读写只是把数据加载到相应的内存地址，因此减去了非常多的和存储引擎、模式匹配、共享内存打交道的中间过程，并且在哈希索引的加持下，无论对多大的数据（TP、PB）级都能达到毫秒级的访问速度，可以满足一些搜索引擎、大数据实时分析调度系统的需要。
Object Store的设计思想部分借鉴了RocksDB，本身也提供了RocksDB的接口调用方式。
令人惊奇的是，Object Store团队开放了全部源码的下载，他们在主页里公布了代码库位置、编译要求等，这就意味着只要能访问Object Store资源的微软账号就都能够下载源码；全部代码大概有六百多G，在普通电脑上编译需要10到14个小时，还额外需要一部分空间用于存放临时文件和nuget包。
前面提到过，微软的大数据平台并不是一个完全坚固和稳定的系统（微软很多产品都是Bug多多，我同事说微软的某个Sharepoint版本的js脚本像是实习生写的；Cosmos演进和运维了十年，也只能内部用用，没法作为一个成熟产品开放给外部使用），基于集群服务器数量大小、数据量大小和同时进行的作业数量、网络延迟等，数据的调度和分析结果充满了各种不确定性。在我们平台运行着一千多个作业，每天都要收到数十封作业失败、延迟的邮件；有的作业连续两天执行失败，第三天又好了，有的作业执行失败，经查看是内部某台服务器上某个文件缺失的原因；有些由其他团队维护的依赖文件今天没有按时生成，导致我们的作业一直没有按时执行；连续失败若干次的作业会被隔离，今天不再继续执行。
面对数据源的不稳定和处理系统的相对脆弱，为了交给客户一个稳定、满意的产品，我们国内的程序员在这方面进行了艰苦卓绝的努力，凝聚着团队的智慧和汗水。举某一方面例子，大家知道对于每天生成的数据，需要查看结果最好的方法是每天定时执行某个数据处理的脚本，但是，如果到了这个时间点，原始数据还没有生成怎么办？今天就不再执行了吗？缺了一天的数据隔天需要补吗？如果数据又在后面某个时间点出现了，该不该、该如何通知程序以及后续的任务顺序执行？每个作业的优先级、并行度该如何设置比较合适？某些任务不容易在服务器上提交成功，应该有怎样的补救措施？这些都需要我们进行编码解决。在ADF流程中，处处充满了防御式的编程，我们合理调用微软Azure上的各种Function、Web hook等，实现了诸如依赖文件检测、失败任务优化提交等功能，保证了数据正常处理和使用，也一直得到国外同行和主管的高度评价，微软的一些其他团队也纷纷把作业交给我们来管理和维护。
|
 |
一些出错信息，文件没找到（可见最底层代码是java）、自己把任务取消了、执行下去没有得到响应等。有的时候会在一段时间内job全部提交不上去，直到提交微软的事故工单（ICM）才得以解决，过段时间又提交不上了；有的时候别的团队修改了一个Scope Module的DLL引用，导致大量引用该Module的脚本在编译期间内编译失败，而Scope开发团队似乎早就意识到了这点，在文档中提出了解决方法。 |
|
在通常情况下我们提交到Cosmos的C#代码的目标框架是.Net Framework4.7.2，我想如果把目标框架改成.net5或者.net6，性能上是否有所提高，本来我想Cosmos执行的job应该是IO密集型而不是CPU密集型，不管使用什么样的静态语言编写，最终效果差别不会太大，但事实并非如此。在微软的一些讨论组和邮件里有的团队使用.net Core或者.net5，在Cosmos和Object Store上执行结果的性能直线下降，原先只需要10毫秒的执行步骤改成.net core之后，执行时间竟然翻了一番，达到20毫秒；其他一些.net代码执行时间也大幅度延长，至此Cosmos团队还没有正式予以回复。虽然通过开源和制定一年一个大版本的roadmap，使得.net得以跨平台和统一架构，但是人多手杂，在一些对于性能要求比较高的场合，开源社区贡献的代码是否经过了严密的测试和验证呢？仅仅靠一两个人的PR？
由我国华为、电信、航天科工、三一集团、海尔、阿里研究院等组成工业物联网产业联盟（AII）近期发布的《工业互联网体系架构（版本2.0）》中，从能力、应用、商业、产业四个层面对我国工业互联网产业进行了业务界定。其中用到的关键技术如5G、边缘计算、区块链、工业人工智能、数字孪生等，微软Azure早就都提供了相应的、开箱即用的低代码、零代码解决方案。具体如下：
设备层和数据汇集、感知层：
微软Azure提供了诸如IOT HUB、IOT Center这样的产品，方面用户采集数据，进行设备通讯和管控；通常情况下，对一个中型企业做数据采集，其采集点往往有数十万个，自己编写程序去对接，耗时耗力，程序的稳定性、可靠性还不容易掌控，这些交由云端的IOT HUB处理，按照节点数量和时长付费，省去很多精力、也不用自己去做运维，实际上是很节约成本的。
边缘计算：
微软提供了IOT Edge的托管服务，在 IoT Edge 设备上本地部署的智能，将特定工作负荷迁移到网络边缘，并在GitHub上提供了免费的SDK开发包；甚至可以提供了搭载Intel或者nVidia的芯片的智能硬件设备（可能国内购买和租借不到）在现场进行分析和计算。
区块链：
微软早在2015年就在Azure里提供了区块链服务，不过近期关闭，用户可以从应用市场中使用由ConsenSys公司提供的Quorum服务或者使用VM镜像，使用体验等同于微软其他Azure产品。
人工智能：
这方面Azure提供的产品更加多了，有视觉识别、人脸识别、表单识别、语义分析、机器学习、认知服务、语音服务等，而且都是低代码和零代码实现，很容易和需求进行对接，有兴趣的朋友可以自己去微软Azure上面去看。
数字孪生：
配合Azure和微软的Helolens2等产品，结合Unity3d、虚幻引擎等，可以非常方便的搭建出数字孪生平台。微软帮助中心有一些教材，比如使用风力发电站进行数字孪生模拟的教程，非常简单，并且还有视频指导。（使用 Azure 数字孪生和 Unity 生成混合现实数字孪生体 ； 使用 Azure 数字孪生和 Unity 将 IoT 数据连接到 HoloLens 2）
5G技术：
我觉得国内对他的宣传是有些过头了，华为号称自己是5G技术的龙头老大，结果自己新出的旗舰手机上都用不了5G芯片，这不是很大的讽刺吗？
微软的产品给人以简单易用的印象，通过封装和抽象来隐藏内部的复杂性，表面上给用户一个简单易用的产品；当国内的小微企业、初创公司还在进行新的技术探索、理论上的研究和论证以及重复造轮子的时候，微软早就提供了低成本、简单易用的全家桶产品了。
当然，我们国家这方面的建设不太可能去使用微软现成的技术（使用的话也会采用由世纪互联运营的Azure，符合国内政策法规），否则政府的补贴、投入会落入何处？我们国家对新技术的运用和推广采取自上而下的行政手段，结合每年的财政预算，使得社会财富进行再次分配，这也是具有中国特色的游戏规则；当然缺点也很明显，宏观大于微观，没有执行层面上的战术和细节，也没有进行市场化的论证，这样的效率也是显而易见的；中国制造业大而不强，在沿海一些较为发达的城市，很多企业的管理人员连Excel都没有用起来，还在一家客户每年用一本本账册手工记账。中国企业的信息化、数字化、智能化发展路线何时能够实现呢？
公司规定按照国家的规定上下班。到了上班的点，放眼望去，上百人的工位才稀稀拉拉来了几个人，一刻钟后，大家才陆陆续续过来，也不知道几点钟前人会到齐，碰到周末节假日大家连续请假也很常见，公司HR对管理、劳动纪律等也不是非常重视；进公司前，已经明确告知公司不提倡加班，实在有事需要工作加班的，必须提前申请和逐级批复，手续还特别麻烦；一次我下班稍微晚走了几分钟，碰到保安已经在问里面剩几个准备赶人回家了。
就是这样的公司，我上网查了下今年上半年居然还盈利了好几个亿。在国内的很多公司，老板不相信任何一个人，不相信你有能力把事情做好、也不相信你会好好工作，他把每个人当作光拿钱不干活的罪犯看待。进公司的时候先一遍遍给你洗脑和画饼：马云、十八罗汉、阿里巴巴、纳斯达克敲钟、全员持股等；上班后每天工作前又唱又跳喊口号，讲奋斗和励志故事，打鸡血；然后就是996、7117，好一点的大小周；员工每个人每天都工作到很晚，假装在认真工作，其实啥活都没干、都在骗公司晚饭、夜宵和打车费用。这样的公司，到最后不是拿不出产品，就是被内耗拖垮，不到半年、一年就关门大吉。
我们和这样的公司相比，简直是是一个天一个地。其中的差别就在于企业工作内容附加值的巨大差异。我们的团队，支撑起了微软某一方面全球业务的大数据分析工作，为微软公司带来了很高的利润。国内的企业，老板们还在绞尽脑汁地想怎么拓展业务、打击同行对手，怎么圈钱、套路别人、开个皮包公司倒买倒卖骗钱骗补贴；相比这样的公司我们实在是太高大上了。我们的企业该有的福利一样不少，还有着优秀的人才、杰出的团队、做着先进的、一流的工作，这还不是每个码农所向往的好公司吗？
我希望国内有更多的像这样高附加值的软件企业诞生，靠着良好的业务和工作氛围，通过我们每一个新生代IT农民工的自觉、自律和每个人的自我价值实现，进而带动整个软件行业生态向着良性的、健康的、可持续化的的方面去发展，最终实现整个中华民族的繁荣和复兴！
微软外服工作札记系列
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。