银行人的自我分类
我们可以简单的把银行数据人分为两大类：技术数据人和业务数据人。
技术数据人可分为三类
1、所有和数据相关的系统开发岗位和运维岗位
数据相关的系统既包括所有产生数据的业务系统，如核心系统、信贷系统、网银、银行等，也包括各类后端分析系统，报表系统以及存储和加工大量数据的系统，如数据平台、数据仓库、征信平台等。
这类技术数据人在数据人中处于核心地位，他们最了解源系统的表结构，只有他们能写出源系统的数据提取，他们也最为忙碌，尤其是业务系统的相关技术数据人，平时主要负责系统的开发和运维工作，只有在下班后，继续处理数据提取的需求，编写业务系统的数据提取脚本。
2、数据中心的操作岗
这类数据人工作相对单纯，接收脚本、执行脚本、返回数据，他们平时的工作是监控系统的运行情况，在出现异常报警时按照运维手册排查问题，无法解决时上报问题并联系系统开发的同事协助解决。如今，很大一部分精力需要用来处理数据提取的需求。
3、数据分析师
通常是数学或统计学背景，擅长数据分析与建模，在获取到提取的生产数据后进行分析与建模，得到结论，从而指导业务决策。
但随着数据提取需求的爆发式，一个新的岗位应运而生——数据需求岗
大中型银行由于数据提取的需求实在太多，单独设立一个部门或团队来处理数据提取需求，其中就有一部分人专门负责对接业务部门的数据需求。
这个岗位需要充分理解业务需求，把业务需求转化为技术语言，与开发岗沟通，同时还需要验证操作岗取回来的数据是否符合业务需求，以及数据分析师的建模结论是否符合业务预期。
其他还有很多技术数据人，数量不大，甚至没有专门的岗位，但是通常也负责数据相关的重要工作，如数据架构师（通常由系统架构师兼任），数据产品经理，数据、治理及标准管理的相关岗位，数据测试、质量管理相关的岗位，数据采集、外部数据采购相关的岗位，数据安全相关的岗位等等。
为了统一管理，有的银行把相关职能的岗位集中成立了单独的部门，如数据需求、分析、架构、提取等职能的岗位，集中成立数据实验室或大数据中心，专门负责处理各类数据需求；数据管理、治理及标准管理和质量管理相关的岗位，成立数据治理部，推进全行数据治理相关标准的制定、落地和监控；数据采集、测试、安全相关的岗位，成立数据采购部门，扎口全行内外部数据采集的需求。
接着再来聊聊业务数据人
业务数据人通常分散在各业务部门中，目前没有把业务数据人集中形成新部门的做法，因为不同业务条线的需求大相径庭，难以扎口管理。
通常在业务经营分析、监管现场检查、阶段性汇报、新产品可行性分析等环节，甚至是领导提了一句想看某个指标的情况下，需要进行临时性的数据提取需求，或固化为报表需求，由业务数据人编写数据提取或报表需求。
业务数据人通常是业务背景出身，不懂技术，最常用的工具是Excel，因此又被称为“表哥”、“表姐”，在拿到技术部门提取的数据后，通过Excel进行基础的分析，计算一些简单的指标。
业务数据人和技术数据人这个群体，说大不大，说小也不小，他们并非银行原来固有的岗位，而是随着银行对于数据应用和决策的愈发重视而逐步形成的岗位，大部分数据人都有自己的本职工作，在繁忙的业务或开发间隙，兼任数据提取和分析的工作。
可能这么说大家感觉还是比较抽象，到底数据人是在什么情况下需要完成什么样的工作呢？接下来我们就具体看看数据人的主战场在哪里，以及数据人们都从事着怎样的工作。
技术数据人：提不完的数据，写不完的脚本
在大V们的鼓吹下，KOL的洗脑文中，焦虑被源源不断的贩卖给IT民工们，迫使他们通过付费、在线培训、跳槽、转岗来完成个人简历的蜕变，以期达成职业生涯的跃迁。
大家都认为，只要入了数据这行，干上和数据有关的工作，必然是高精尖、高大上的，大数据与人工智能左膀右臂，深度学习、知识图谱信手拈来。
理想很丰满，现实很骨感。
数据分析的工作看似高大上，实则又苦又累，80%的时间花在需求讨论、提取数据、数据清洗、数据整合、缺失值处理以及特征工程部分，只有20%的时间是用来建立模型和评估模型。
外行理解的数据分析，其实类似于Kaggle这种数据建模竞赛的过程，这里的数据集基本都是已经准备好的，需求也很明确，整个数据分析的过程可以简化为从需求讨论直接跳到特征工程。
而实践中，大多数数据达不到数据分析的要求和标准。因为数据都来自于业务系统，而业务系统的建设是按需的，根据市场变化、客户变化等等按需提出并建设，建设的时候很大概率并未考虑后期数据分析的便利性，以及与其他系统的数据标准、规范等是否一致。
在银行，这种现象更为明显，国有大行、股份制和民营银行，科技力量较强，可能会有部分业务系统由行内的开发团队实施，自主实施的业务系统，相对比较容易控制其数据标准。
而其他大多数的银行和金融机构，则缺乏自主建设业务系统的能力，绝大多数业务系统依赖于采购外部供应商的成熟产品。由于每家供应商擅长的领域不同，提供的业务产品自然不尽相同，因此银行内通常的情况是多家供应商的产品系统并存。
在银行没有严格的数据标准和规范的情况下，各家供应商必然是按照各自的标准版本在银行内部署，而各家供应商的数据标准和规范必然是千差万别。
即使银行建立了自己的数据标准和规范，由于通常涉及底层改造，改造难度较大，并且改造后上线也存在一定风险，加上绝大多数银行的业务部门相比科技部门更为强势，对于业务系统的上线时间都有明确要求，多种因素作用下，通常是科技部门妥协，容忍各类标准的供应商产品上线。
这就导致银行内部的数据标准和格式成了一锅大杂烩。
而数据分析，通常是要提取多个业务系统的数据进行处理，加工整合后进行分析的，这就导致数据提取的过程需要面对分散在各处的多源异构数据，再加上数据质量参差不齐，使得数据提取和清洗的过程异常漫长。
后方的需求越来越多，而且越来越急，前方的数据泥潭深不可测，导致的后果，就是技术数据人们满心欢喜的进入数据领域，绝大多数人被分配到的任务80%以上都是数据提取，另外不到20%的任务是沟通数据提取的需求，因为这部分需要的人实在太多了，花的时间实在太长了。
只有极少数的人，从事的是数据分析和建模的工作，并且他们的工作里，大部分的时间也是在处理数据。
最后的建立模型和评估，是皇冠上的珍珠，固然璀璨夺目，但是没有前期工作完成的皇冠底座，珍珠也难以独自闪耀。除了数据科学的自身特点导致数据提取异常缓慢之外，银行的组织架构也是一个不可忽视的因素。
体量越大的银行，分工越细，业务的数据需求提出来以后，有人专门对接需求进行分析，有人专门编写脚本，有人专门负责执行，有人负责处理执行结果反馈给业务部门。
越贴近数据的人，距离业务需求反而越远，最初的需求经过层层转述，信息逐步衰减，误差逐步增大，导致最后的结果通常不能满足业务需要。
再加上银行内部各扫门前雪，宁可无功，但求无过等“文化”的影响，使得数据提取这种跨多个部门、经过多个节点的复杂流程变得更加不可控。
业务数据人：提不完的需求，做不完的报表
看完技术数据人的苦衷，业务数据人们按捺不住了。
“弄得好像都是业务数据人乱提需求一样，业务数据人也很苦的好吗？
在银行，通常业务部门比较强势，因为业务部门是利润中心，而科技部门是成本中心（现在的数据部门通常划归到科技部门），能赚钱的嗓门大，可同时压力也大。
为了完成KPI，经常需要提取各类业务指标；
为了了解客户情况，经常需要查询客户信息和交易历史；
为了解决客户投诉，经常需要提取各类操作日志；
为了设计新产品，经常需要查询各类产品和渠道数据。
技术数据人说，你们需求多我们能理解了，但是为什么经常都要得这么急呢？业务数据人通常会回答：领导要得急呀。
领导为什么总是要得很急？难道都是拍脑袋，今天想要一个数据，明天想要另一个数据，而且都需要马上看到，这样的需求谁满足得了。
其实不是领导拍脑袋，而是市场、客户和监管的变化太快。
市场和客户的变化不难理解，特别是移动互联网时代，互联网巨头们瓜分市场，抢夺客户的速度与原来银行间的竞争相比，不可同日而语。
而银行作为强监管机构，对于监管的要求永远是排在第一优先级的，1104报表、二三类账户、资管新规……
而且监管经常周五临下班出新规，搞得大家要周末加班学习监管最新指示。
外部有了变化，第一冲击的是直接对客的部门，包括网点、客服等，第二冲击是业务部门，最后才会传导到科技部门，因此科技部门不理解业务的急迫是情有可原的。
领导要得急，科技反应慢，为难的就是业务部门的基层员工，在数据领域就是表哥表姐们。
科技数据还没回来，领导又在催，能不能先用以前提的数据做个趋势分析呢？
提取的数据应该和分行填报能匹配，要么先收集一下分行填报的结果？
给分行的填表模板必须做好校验，不然填的数字五花八门。
这个数据经常要提，能不能就固化成报表需求了？
这张报表要跨几个系统拉数据，暂时没办法做报表，能不能写个宏把几个报表的数据整合了？
这几个场景里，有很多业务数据人的痛点，比如历史数据的管理，数出多门的问题，手工填报的准确性，共性需求的提炼，多数据源的打通等等，解决方法可看报表。
但大部分业务数据人还是习惯用Excel来处理数据。虽然Excel很强大，可以应付绝大多数需求，但是在历史数据的管理、手工填报准确性以及多数据源打通等环节依旧力不从心。
上次看到一个段子，说所有数字化转型的需求，最后都会收敛为两个功能：导入Excel和导出Excel。听起来很可笑，但是在很多地方确实是现实。
结语
以上就是技术数据人和业务数据人的生存现状。
看起来大家都有痛点，难道就没办法解决了吗？
银行的大多数问题都是组织架构的问题，具体到数据领域，目前来看，主要有三种数据团队组织架构：
大多数银行仍采用集中式架构，技术数据人专职在数据团队，业务数据人基本还是兼职。
这种模式下，存在技术数据人远离一线需求、沟通成本高、资源分配不均等劣势。
互联网公司普遍采用分散式植入各部门的数据团队架构，但也存在信息孤岛、数据标准不统一、重复“造轮子”等缺点。
因此，目前一些领先银行已经开始采用混合式组织架构，存在独立的数据团队，在各业务部门也有专职的数据人，他们双线考核，同时汇报给业务条线和数据团队。
改变组织架构以后，大家看问题的角度不同，立场不同，目标一致，很多问题就迎刃而解了。
当然，依然还有很多痛点没法通过组织架构的调整解决，这里先抛个砖，后续的文章里会慢慢探讨解决思路，这里分享2篇我觉得不错的实际。
源：GClover

1. 大型网站系统的特点
高并发、大流量
高可用
海量数据
用户分布广泛，网络情况复杂
安全环境恶劣
需求快速变更，迭代频繁
渐进式发展
2. 大型网站架构演化历程
2.1. 初始阶段架构
问题：网站运营初期，访问用户少，一台服务器绰绰有余。
特征：应用程序、数据库、文件等所有的资源都在一台服务器上。
描述：通常服务器操作系统使用 linux，应用程序使用 PHP 开发，然后部署在 Apache 上，数据库使用 Mysql，通俗称为 LAMP。汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了。
大型互联网架构概述，看完文章又涨知识了
2.2. 应用服务和数据服务分离
问题：越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足，一台服务器已不足以支撑。
特征：应用服务器、数据库服务器、文件服务器分别独立部署。
描述：三台服务器对性能要求各不相同：应用服务器要处理大量业务逻辑，因此需要更快更强大的 CPU；数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存；文件服务器需要存储大量文件，因此需要更大容量的硬盘。
大型互联网架构概述，看完文章又涨知识了
2.3. 使用缓存改善性能
问题：随着用户逐渐增多，数据库压力太大导致访问延迟。
特征：由于网站访问和财富分配一样遵循二八定律：80% 的业务访问集中在 20% 的数据上。将数据库中访问较集中的少部分数据缓存在内存中，可以减少数据库的访问次数，降低数据库的访问压力。
描述：缓存分为两种：应用服务器上的本地缓存和分布式缓存服务器上的远程缓存，本地缓存访问速度更快，但缓存数据量有限，同时存在与应用程序争用内存的情况。分布式缓存可以采用集群方式，理论上可以做到不受内存容量限制的缓存服务。
大型互联网架构概述，看完文章又涨知识了
2.4. 使用应用服务器集群
问题：使用缓存后，数据库访问压力得到有效缓解。但是单一应用服务器能够处理的请求连接有限，在访问高峰期，成为瓶颈。
特征：多台服务器通过负载均衡同时向外部提供服务，解决单一服务器处理能力和存储空间不足的问题。
描述：使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，提升系统的并发处理能力，使得服务器的负载压力不再成为整个系统的瓶颈。
大型互联网架构概述，看完文章又涨知识了
2.5. 数据库读写分离
问题：网站使用缓存后，使绝大部分数据读操作访问都可以不通过数据库就能完成，但是仍有一部分读操作和全部的写操作需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。
特征：目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到一台服务器上。网站利用数据库的主从热备功能，实现数据库读写分离，从而改善数据库负载压力。
描述：应用服务器在写操作的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库。这样当应用服务器在读操作的时候，访问从数据库获得数据。为了便于应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，使数据库读写分离的对应用透明。
大型互联网架构概述，看完文章又涨知识了
2.6. 反向代理和 CDN 加速
问题：中国网络环境复杂，不同地区的用户访问网站时，速度差别也极大。
特征：采用 CDN 和反向代理加快系统的静态资源访问速度。
描述：CDN 和反向代理的基本原理都是缓存，区别在于 CDN 部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器时反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。
大型互联网架构概述，看完文章又涨知识了
2.7. 分布式文件系统和分布式数据库
问题：随着大型网站业务持续增长，数据库经过读写分离，从一台服务器拆分为两台服务器，依然不能满足需求。
特征：数据库采用分布式数据库，文件系统采用分布式文件系统。
描述：分布式数据库是数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用。不到不得已时，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。
大型互联网架构概述，看完文章又涨知识了
2.8. 使用 NoSQL 和搜索引擎
问题：随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂。
特征：系统引入 NoSQL 数据库及搜索引擎。
描述：NoSQL 数据库及搜索引擎对可伸缩的分布式特性具有更好的支持。应用服务器通过统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。
大型互联网架构概述，看完文章又涨知识了
2.9. 业务拆分
问题：大型网站的业务场景日益复杂，分为多个产品线。
特征：采用分而治之的手段将整个网站业务分成不同的产品线。系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。
描述：应用之间可以通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。
纵向拆分：将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的 Web 应用系统。纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离即可。
横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。
大型互联网架构概述，看完文章又涨知识了
2.10. 分布式服务
问题：随着业务越拆越小，存储系统越来越庞大，应用系统整体复杂程度呈指数级上升，部署维护越来越困难。由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。
特征：公共业务提取出来，独立部署。由这些可复用的业务连接数据库，通过分布式服务提供共用业务服务。
大型互联网架构概述，看完文章又涨知识了
3. 大型网站架构模式
3.1. 分层
大型网站架构中常采用分层结构，将软件系统分为应用层、服务层、数据层：
应用层 - 负责具体业务和视图展示。如网站首页及搜索输入和结果展示。
服务层 - 为应用层提供服务支持。如用户管理服务、购物车服务等。
应用层 - 提供数据存储访问服务。如数据库、缓存、文件、搜索引擎等。
分层架构的约束：禁止跨层次的调用（应用层直接调用数据层）及逆向调用（数据层调用服务层，或者服务层调用应用层）。
分层结构内部还可以继续分层，如应用可以再细分为视图层和业务逻辑层；服务层也可以细分为数据接口层和逻辑处理层。
3.2. 分割
将不同的功能和服务分割开来，包装成高内聚低耦合的模块单元。这有助于软件的开发和维护，便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。
3.3. 分布式
大于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。
分布式意味可以用更多的机器工作，那么 CPU、内存、存储资源也就更丰富，能够处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。
分布式也引入了一些问题：
服务调用必须通过网络，网络延迟会影响性能
服务器越多，宕机概率也越大，是可用性降低
数据一致性非常困难，分布式事务也难以保证
网站依赖错综复杂，开发管理维护困难
常用的分布式方案：
分布式应用和服务
分布式静态资源
分布式数据和存储
分布式计算
3.4. 集群
集群即多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。
集群需要具备伸缩性和故障转移机制：伸缩性是指可以根据用户访问量向集群添加或减少机器；故障转移是指，当某台机器出现故障时，负载均衡设备或失效转移机制将请求转发到集群中的其他机器上，从而不影响用户使用。
3.5. 缓存
缓存就是将数据存放在距离最近的位置以加快处理速度。缓存是改善软件性能的第一手段。
网站应用中，缓存除了可以加快数据访问速度以外，还可以减轻后端应用和数据存储的负载压力。
常见缓存手段：
CDN
反向代理
本地缓存
分布式缓存
使用缓存有两个前提：
数据访问热点不均匀，频繁访问的数据应该放在缓存中
数据在某个时间段有效，不过很快过期，否则缓存数据会因已经失效而产生脏读
3.6. 异步
软件发展的一个重要目标和驱动力是降低软件耦合性。事物之间直接关系越少，彼此影响就越小，也就更容易独立发展。
大型网站架构中，系统解耦的手段除了分层、分割、分布式等，还有一个重要手段——异步。
业务间的消息传递不是同步调用，而是将一个业务操作拆分成多阶段，每个阶段间通过共享数据的方式异步执行进行协作。
在单一服务器内部可通过多线程共享内存队列的方式实现异步，处在业务操作前面的线程将操作输出到队列，后面的线程从队列中读取数据进行处理；
在分布式系统中，多个服务器集群通过分布式消息队列实现异步。
异步架构是典型的生产者消费模式，二者不存在直接调用。异步消息队列还有如下特性：
提高系统可用性
加快响应速度
消除并发访问高峰
3.7. 冗余
大型网站，出现服务器宕机是必然事件。要保证部分服务器宕机的情况下网站依然可以继续服务，不丢失数据，就需要一定程度的服务器冗余运行，数据冗余备份。这样当某台服务器宕机是，可以将其上的服务和数据访问转移到其他机器上。
访问和负载很小的服务也必须部署 至少两台服务器构成一个集群，目的就是通过冗余实现服务高可用。数据除了定期备份，存档保存，实现 冷备份 外；为了保证在线业务高可用，还需要对数据库进行主从分离，实时同步实现 热备份。
为了抵御地震、海啸等不可抗因素导致的网站完全瘫痪，某些大型网站会对整个数据中心进行备份，全球范围内部署 灾备数据中心。网站程序和数据实时同步到多个灾备数据中心。
3.8. 自动化
大型网站架构的自动化架构设计主要集中在发布运维方面：
发布过程自动化
自动化代码管理
自动化测试
自动化安全监测
自动化部署
运维自动化
自动化监控
自动化报警
自动化失效转移
自动化失效恢复
自动化降级
自动化分配资源
3.9. 安全
密码 和 手机校验码 进行身份认证
登录、交易等重要操作需要对网络通信进行 加密，存储的敏感数据如用户信息等也进行加密处理
防止机器人程序攻击网站，使用 验证码 进行识别
对常见用于 攻击 网站的 XSS 攻击、SQL 注入、进行编码转换等相应处理
对垃圾信息、敏感信息进行 过滤
对交易转账等重要操作根据交易模式和交易信息进行 风险控制
4. 大型网站核心架构要素
架构 的一种通俗说法是：最高层次的规划，难以改变的决定。
除了系统功能需求外，架构还需要关注以下架构要素：
4.1. 性能
性能问题无处不在，所以网站性能优化手段也十分繁多：
前端
浏览器缓存
静态资源压缩
合理布局页面
减少 cookie 传输
CDN
应用服务器
本地缓存
分布式缓存
异步消息队列
集群
代码层面：使用多线程、改善内存管理
数据库
索引
数据库缓存
SQL 优化
4.2. 可用性
可用性指部分服务器出现故障时，还能否对用户提供服务
冗余自动化：通过预发布验证、自动化测试、自动化发布、灰度发布等手段，减少将故障引入线上环境的可能
通过负载均衡设备建立集群共同对外提供服务
数据存储在多台服务器，互相备份
4.3. 伸缩性
衡量伸缩的标准就是是否可以用多台服务器构建集群，是否容易向集群中增删服务器节点。增删服务器节点后是否可以提供和之前无差别的服务。集群中可容纳的总服务器数是否有限制。
应用服务器集群 - 只要服务器上保存数据，则所有服务器都是对等的，通过负载均衡设备向集群中不断加入服务器即可
缓存服务器集群 - 加入新的服务器可能会导致缓存路由失效，进而导致集群中的大部分缓存数据都无法访问。虽然缓存数据可以通过数据库重新加载，但是如果应用严重依赖缓存，可能会导致网站崩溃。需要改进缓存路由算法保证缓存数据的可访问性。
关系型数据库集群 - 关系型数据库虽然支持数据复制，主从热备等机制，但是很难做到大规模集群的可伸缩性，因此关系型数据库的集群伸缩性方案必须在数据库之外实现，通过路由分区等手段将部署有多个数据库的服务器组成一个集群。
NOSql 数据库集群 - 由于先天就是为了应对海量数据而产生，因此对伸缩性的支持通常都非常好。
4.4. 扩展性
衡量扩展性的标准就是增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或很少改动，既有功能就可以上线新产品。主要手段有：事件驱动架构和分布式服务。
4.5. 安全性
安全性保护网站不受恶意攻击，保护网站重要数据不被窃取。