竹磬网-邵珠庆の日记 生命只有一次，你可以用它来做些更多伟大的事情–Make the world a little better and easier


109月/220

向上管理能力决定职业天花板高度

发布在 邵珠庆

在职场中，我们常常听到“能力决定一切”的说法。然而，现实却告诉我们，仅仅依靠专业能力并不足以让你在职场中脱颖而出。
真正决定你职业天花板高度的，往往是另一种能力——向上管理的能力。
向上管理，并不是简单的讨好上级，而是一种通过有效沟通、资源整合和价值传递，与上级建立良性互动关系的能力。

一、什么是向上管理？
1. 向上管理的定义
向上管理，简单来说，就是通过有效的方式管理和影响你的上级，从而获得更多的资源、支持和机会。它并不是一种单向的服从或讨好，而是一种双向的互动和合作。
2. 向上管理的核心

向上管理的核心在于三点：
理解上级的目标和需求：只有了解上级的优先级和痛点，才能更好地为其提供支持。
提供价值：通过解决问题、创造价值，赢得上级的信任和依赖。
建立信任关系：通过有效的沟通和合作，与上级建立长期的信任关系。

二、为什么向上管理决定职业天花板？
1. 资源分配的关键
在职场中，资源的分配往往掌握在上级手中。无论是项目机会、晋升名额，还是培训资源，都需要通过上级的批准。如果你无法有效管理上级，就很难获得这些资源，从而限制了自己的发展空间。
2. 职业发展的助推器
向上管理不仅能够帮助你获得资源，还能为你提供职业发展的助推器。通过与上级建立良好的关系，你可以获得更多的指导、反馈和机会，从而加速自己的成长。
3. 影响力的放大器
在职场中，影响力是决定你能否脱颖而出的关键因素。通过向上管理，你可以将自己的影响力扩展到更高的层级，从而获得更多的认可和支持。

三、案例分析：向上管理的成功与失败
案例一：小王的“默默无闻”
小王是一名技术骨干，专业能力非常出色。然而，他性格内向，不善于与上级沟通。每次完成任务后，他只是简单地汇报结果，从不主动向上级展示自己的贡献。久而久之，上级对他的印象越来越模糊，甚至忘记了他的存在。
在一次晋升机会中，小王本以为凭借自己的专业能力能够顺利晋升，但最终却被另一位同事抢走了机会。这位同事虽然专业能力不如小王，但他善于向上管理，经常与上级沟通，展示自己的价值。
即使你拥有出色的专业能力，如果无法有效管理上级，也很难获得职业发展的机会。

案例二：小李的“主动出击”
小李是一名市场经理，专业能力一般，但他非常善于向上管理。每次完成任务后，他都会主动向上级汇报进展，并提出自己的建议和思考。他还经常与上级沟通，了解其需求和痛点，并主动提供支持。
在一次重要项目中，小李通过向上管理，成功获得了上级的支持和资源，最终顺利完成了任务。项目结束后，他不仅获得了晋升机会，还成为了上级的得力助手。
即使你的专业能力一般，如果能够有效管理上级，依然可以获得职业发展的机会。

案例三：老张的“信任危机”
老张是一名资深经理，专业能力非常出色，但他与上级的关系一直不太融洽。每次与上级沟通时，他总是强调自己的观点，而忽视了上级的需求和感受。久而久之，上级对他的信任逐渐下降，甚至开始怀疑他的能力。
在一次重要决策中，老张提出了一个非常有价值的建议，但由于缺乏信任，上级并未采纳。最终，项目失败，老张也因此失去了晋升机会。
向上管理的另一个关键点：建立信任关系。即使你拥有出色的专业能力，如果无法与上级建立信任关系，也很难获得支持。

四、如何提升向上管理的能力？
1. 理解上级的目标和需求
向上管理的第一步，是理解上级的目标和需求。只有了解上级的优先级和痛点，才能更好地为其提供支持。例如，你可以通过定期沟通、观察上级的行为和决策，来了解其需求和目标。
2. 提供价值
向上管理的核心，是提供价值。你可以通过解决问题、创造价值，赢得上级的信任和依赖。例如，你可以主动承担重要任务，提出有价值的建议，或者帮助上级解决难题。
3. 建立信任关系
向上管理的关键，是建立信任关系。你可以通过有效的沟通和合作，与上级建立长期的信任关系。例如，你可以保持透明和诚实的沟通，及时反馈进展和问题，或者主动承担责任。
4. 展示自己的贡献
向上管理的另一个重要方面，是展示自己的贡献。你可以通过定期汇报、总结和反思，向上级展示自己的价值和贡献。例如，你可以在每次任务结束后，向上级汇报成果和思考，或者主动提出改进建议。

五、向上管理的误区
1. 讨好上级
向上管理并不是讨好上级，而是一种通过提供价值和建立信任关系，与上级建立良性互动关系的能力。如果你只是为了讨好上级而做出不切实际的承诺，反而会适得其反。
2. 忽视专业能力
向上管理并不是忽视专业能力，而是一种通过有效沟通和资源整合，提升自己职业发展的能力。如果你只注重向上管理而忽视专业能力，最终也会失去上级的信任。
3. 单向沟通
向上管理并不是单向的沟通，而是一种双向的互动和合作。如果你只关注自己的需求和目标，而忽视上级的需求和感受，最终也会失去上级的支持。

六、向上管理的未来趋势
1. 数据驱动的向上管理
随着数据技术的发展，向上管理也将变得更加数据驱动。例如，你可以通过数据分析，了解上级的需求和痛点，从而提供更有针对性的支持。
2. 远程办公中的向上管理
随着远程办公的普及，向上管理也将面临新的挑战和机遇。例如，你可以通过在线沟通工具，保持与上级的透明和高效沟通，从而建立信任关系。
3. 多元化的向上管理
随着职场文化的多元化，向上管理也将变得更加灵活和多样化。例如，你可以通过不同的沟通方式和风格，适应不同上级的需求和偏好。

向上管理的能力，决定职业天花板的高度。在职场中，仅仅依靠专业能力并不足以让你脱颖而出。
只有通过有效沟通、资源整合和价值传递，与上级建立良性互动关系，才能突破职业天花板，实现自己的职业目标。

标签: , 没有评论
308月/220

数字化城市管理系统架构图

发布在 邵珠庆

标签: 没有评论
148月/220

DevOps及DevOps工具链

发布在 邵珠庆

DevOps工具链的组成部分

在DevOps领域，工具链是一个核心概念。工具链包括一系列相互关联的技术工具，用于支持从需求分析到测试、部署和运维的全过程。工具链的具体组成部分可能会因组织和项目的不同而有所差异，但常见的组成部分包括以下几个方面。
1、版本控制系统
版本控制系统如Git和Mercurial等，主要用于追踪文件和项目的变更历史。通过版本控制，开发人员可以安全地回滚到以前的版本，也可以方便地查看和比较不同版本之间的差异。
2、持续集成工具
持续集成工具如Jenkins和Travis CI等，用于自动化构建、测试和部署应用程序的过程。这些工具可以帮助开发人员频繁地向主分支提交代码，并自动执行构建、测试和部署步骤，从而降低错误和提高代码质量。
3、自动化测试工具
自动化测试工具如Selenium和JMeter等，用于对应用程序进行功能和性能测试。这些工具可以模拟用户行为，以发现和修复潜在的问题。自动化测试可以显著提高测试效率和覆盖率，并确保应用程序的稳定性和可靠性。
4、容器编排工具
容器编排工具如Kubernetes和Swarm等，用于管理和调度容器化应用程序。这些工具可以自动部署、扩展和管理容器集群，使开发人员可以更轻松地管理和维护应用程序。
5、应用性能管理工具
应用性能管理工具如New Relic和Datadog等，用于监控和分析应用程序的性能。这些工具可以收集和分析实时数据，帮助开发人员快速发现和解决性能问题。
6、日志管理工具
日志管理工具如ELK Stack和Graylog等，用于收集、分析和可视化应用程序的日志。这些工具可以帮助开发人员快速诊断和解决问题，以及优化应用程序的性能和可靠性。
7、配置管理工具
配置管理工具如Ansible和Chef等，用于管理应用程序的配置文件。这些工具可以自动化地管理应用程序的配置，并确保其一致性和安全性。

综上所述，DevOps工具链涉及多个技术工具，这些工具共同帮助开发人员高效地开发、测试、部署和维护应用程序。通过使用这些工具，组织可以实现更高的生产力和更好的软件质量。

 

DevOps工具链与传统工具链的区别
DevOps工具链与传统工具链的区别主要在于工作流程、工作效率、业务价值实现和人员技能要求。
1、在工作流程方面，DevOps工具链强调的是自动化和端到端的流程，从需求分析到代码开发，从测试到部署，再到运维监控，所有的环节都能够通过自动化的工具进行协调和协作，大大提升了软件开发的速度和质量。而传统的工具链更注重于人力的参与和人为的工作流程控制，往往是由单一的开发人员、测试人员或者运维人员完成，整个流程容易出现不协调的情况，导致效率降低，同时也容易导致工作中出现遗漏和错误。
2、在工作效率方面，DevOps工具链通过自动化的方式大大提升了软件开发的效率。比如，代码自动化测试工具可以快速的测试代码的质量和性能，减少了测试人员的工作量和时间；持续集成和持续部署工具可以自动的将代码编译、测试、打包、部署，大大降低了运维人员的工作量和工作难度。而传统的工具链往往需要开发人员手动的进行代码编译、打包、部署等工作，工作量大、效率低，容易出现人为的错误和遗漏。
3、在业务价值实现方面，DevOps工具链通过自动化的方式提高了软件开发的效率和质量，能够更快的实现业务的价值。而传统的工具链往往需要更长的时间和更高的人力成本才能实现业务价值。
4、在人员技能要求方面，DevOps工具链需要开发人员、测试人员和运维人员具备一定的自动化工具使用能力和团队协作能力。而传统的工具链更注重于人力的参与和工作流程的控制，对人员的技能要求相对较低。

总之，DevOps工具链与传统工具链的区别主要在于工作流程、工作效率、业务价值实现和人员技能要求。

 

DevOps工具链的未来发展
在当前DevOps工具链的全球化发展中，我们可以预见未来的发展趋势。未来，DevOps工具链将面临更多的挑战和机遇，它们将在这个领域创造更多的价值。以下是一些可能的未来发展趋势：
1、云原生和容器化：随着云原生和容器化技术的日益普及，DevOps工具链将变得更加高效和自动化。这将使DevOps团队能够更快地部署、扩展和优化应用程序。未来，我们将看到更多基于容器的解决方案，它们将提供更好的应用程序生命周期管理和更高的开发效率。
2、智能化和自动化：人工智能和机器学习技术的发展将使DevOps工具链变得更加智能化。未来的DevOps工具将能够自动识别和修复代码缺陷，智能地进行任务调度和资源管理。这将极大地提高开发和运维的效率，同时减少人为错误。
3、安全和隐私：随着网络安全威胁的不断升级，DevOps工具链将越来越重视安全和隐私。未来的DevOps工具将具备更强大的安全防护能力，能够实时检测和防范各种安全威胁。同时，DevOps团队将更加重视数据隐私和合规性，确保开发和运维过程中的数据安全。
4、开源和开放标准：随着开源技术的普及，DevOps工具链将更加依赖于开源项目。这将促使开发者和组织积极参与开源项目的贡献，推动DevOps工具链的创新和发展。同时，开放标准将成为未来DevOps工具链的主流，这将有助于实现跨平台和跨厂商的兼容性和互操作性。
5、边缘计算和物联网：随着边缘计算和物联网技术的发展，DevOps工具链将更好地支持这些新兴技术。未来的DevOps工具将能够更好地处理物联网设备的部署和管理，支持边缘计算环境下的应用程序开发和部署。
在未来，DevOps工具链将继续变革和创新，为开发者和组织带来更高的效率和更好的用户体验。随着技术的不断进步，我们可以期待一个更加智能、高效、安全和开放的DevOps工具链。

持续集成（CI）
持续集成是一种开发实践，要求开发人员频繁地将代码变更集成到共享的主分支中。每次集成都会触发自动化构建和测试流程，以确保代码的质量和稳定性。通过这种方式，团队可以尽早发现并修复集成错误，从而减少开发周期中的问题积累。
持续交付（CD）
持续交付是持续集成的延伸，它确保在代码通过所有测试后，能够自动发布到版本库中，随时准备部署到生产环境。持续交付的目标是拥有一个始终处于可部署状态的代码库，但它并不自动进行生产环境的部署，而是需要人工干预来决定何时部署。
持续部署（CD）
持续部署则是持续交付的进一步自动化，它意味着一旦代码通过了所有测试，就会自动部署到生产环境中，无需人工干预。这种实践极大地加快了软件从开发到用户手中的速度，使得新功能和修复能够更快地触达用户。
通过实施CI/CD，开发团队能够实现更快的迭代速度，更高的代码质量，以及更灵活的市场响应能力。这种实践是现代敏捷开发和DevOps文化中不可或缺的一部分。

标签: , , 没有评论
98月/220

Linux系统里面图形接口服务器X server

发布在 邵珠庆

X server是Linux系统里面图形接口服务器的简称。Windows系统的界面是这个系统不可分割的一部分，各种窗口操作界面显示都是由系统核心直接管理的，而Linux的图形界面并不是系统的必要组成部分，它可以在无界面的条件下运行。当需要Linux提供界面的时候，系统就会建立一个或者数个X server，通过X协议跟窗口管理器交互，由独立于系统的应用程序来产生窗口，状态栏，按钮之类的交互界面。

比较常见的Linux界面操作环境有KDE和GNOME，为它们提供系统支持的就是X server，而并非Linux核心。

总结一下linux图形界面层次关系：

linux本身-->X服务器<-[通过X协议交谈]->窗口管理器（综合桌面环境）-->X应用程序。

介绍两种方法在命令行中打开远程端的图形应用程序。

两台主机A和B（B是linux主机）

1. A是linux

1）在A主机上，打开终端，执行：ssh -X user@B（ssh -X user@ip）

2）然后在A终端上执行B主机上的图形化界面程序，该图形界面可在A主机显示。

2. A是Windows

需要安装支持x server协议的终端工具

2.1 使用MobaXterm（已经集成x server协议）

1）在A主机上，打开MobaXterm，执行：ssh -X user@B（ssh -X user@ip）

2）然后在MobaXterm上执行B主机上的图形化界面程序，该图形界面可在A主机显示。

2.2 xshell

需要安装xmanager

实测MobaXterm的图形响应速度比xmanager要快，推荐MobaXterm。
————————————————
版权声明：本文为CSDN博主「hello_courage」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u012247418/article/details/105347383/

标签: , 没有评论
297月/220

JWT详解

发布在 邵珠庆

1.什么是JWT
在介绍JWT之前，我们先来回顾一下利用token进行用户身份验证的流程：

客户端使用用户名和密码请求登录
服务端收到请求，验证用户名和密码
验证成功后，服务端会签发一个token，再把这个token返回给客户端
客户端收到token后可以把它存储起来，比如放到cookie中
客户端每次向服务端请求资源时需要携带服务端签发的token，可以在cookie或者header中携带
服务端收到请求，然后去验证客户端请求里面带着的token，如果验证成功，就向客户端返回请求数据
这种基于token的认证方式相比传统的session认证方式更节约服务器资源，并且对移动端和分布式更加友好。其优点如下：

支持跨域访问：cookie是无法跨域的，而token由于没有用到cookie(前提是将token放到请求头中)，所以跨域后不会存在信息丢失问题
无状态：token机制在服务端不需要存储session信息，因为token自身包含了所有登录用户的信息，所以可以减轻服务端压力
更适用CDN：可以通过内容分发网络请求服务端的所有资料
更适用于移动端：当客户端是非浏览器平台时，cookie是不被支持的，此时采用token认证方式会简单很多
无需考虑CSRF：由于不再依赖cookie，所以采用token认证方式不会发生CSRF，所以也就无需考虑CSRF的防御
而JWT就是上述流程当中token的一种具体实现方式，其全称是JSON Web Token，官网地址：https://jwt.io/

通俗地说，JWT的本质就是一个字符串，它是将用户信息保存到一个Json字符串中，然后进行编码后得到一个JWT token，并且这个JWT token带有签名信息，接收后可以校验是否被篡改，所以可以用于在各方之间安全地将信息作为Json对象传输。JWT的认证流程如下：

首先，前端通过Web表单将自己的用户名和密码发送到后端的接口，这个过程一般是一个POST请求。建议的方式是通过SSL加密的传输(HTTPS)，从而避免敏感信息被嗅探
后端核对用户名和密码成功后，将包含用户信息的数据作为JWT的Payload，将其与JWT Header分别进行Base64编码拼接后签名，形成一个JWT Token，形成的JWT Token就是一个如同lll.zzz.xxx的字符串
后端将JWT Token字符串作为登录成功的结果返回给前端。前端可以将返回的结果保存在浏览器中，退出登录时删除保存的JWT Token即可
前端在每次请求时将JWT Token放入HTTP请求头中的Authorization属性中(解决XSS和XSRF问题)
后端检查前端传过来的JWT Token，验证其有效性，比如检查签名是否正确、是否过期、token的接收方是否是自己等等
验证通过后，后端解析出JWT Token中包含的用户信息，进行其他逻辑操作(一般是根据用户信息得到权限等)，返回结果


2.为什么要用JWT
2.1 传统Session认证的弊端
我们知道HTTP本身是一种无状态的协议，这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，认证通过后HTTP协议不会记录下认证后的状态，那么下一次请求时，用户还要再一次进行认证，因为根据HTTP协议，我们并不知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在用户首次登录成功后，在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为cookie，以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了，这是传统的基于session认证的过程



然而，传统的session认证有如下的问题：

每个用户的登录信息都会保存到服务器的session中，随着用户的增多，服务器开销会明显增大
由于session是存在与服务器的物理内存中，所以在分布式系统中，这种方式将会失效。虽然可以将session统一保存到Redis中，但是这样做无疑增加了系统的复杂性，对于不需要redis的应用也会白白多引入一个缓存中间件
对于非浏览器的客户端、手机移动端等不适用，因为session依赖于cookie，而移动端经常没有cookie
因为session认证本质基于cookie，所以如果cookie被截获，用户很容易收到跨站请求伪造攻击。并且如果浏览器禁用了cookie，这种方式也会失效
前后端分离系统中更加不适用，后端部署复杂，前端发送的请求往往经过多个中间件到达后端，cookie中关于session的信息会转发多次
由于基于Cookie，而cookie无法跨域，所以session的认证也无法跨域，对单点登录不适用
2.2 JWT认证的优势
对比传统的session认证方式，JWT的优势是：

简洁：JWT Token数据量小，传输速度也很快
因为JWT Token是以JSON加密形式保存在客户端的，所以JWT是跨语言的，原则上任何web形式都支持
不需要在服务端保存会话信息，也就是说不依赖于cookie和session，所以没有了传统session认证的弊端，特别适用于分布式微服务
单点登录友好：使用Session进行身份认证的话，由于cookie无法跨域，难以实现单点登录。但是，使用token进行认证的话， token可以被保存在客户端的任意位置的内存中，不一定是cookie，所以不依赖cookie，不会存在这些问题
适合移动端应用：使用Session进行身份认证的话，需要保存一份信息在服务器端，而且这种方式会依赖到Cookie（需要 Cookie 保存 SessionId），所以不适合移动端
因为这些优势，目前无论单体应用还是分布式应用，都更加推荐用JWT token的方式进行用户认证

JWT结构
JWT由3部分组成：标头(Header)、有效载荷(Payload)和签名(Signature)。在传输的时候，会将JWT的3部分分别进行Base64编码后用.进行连接形成最终传输的字符串

JWTString = Base64(Header).Base64(Payload).HMACSHA256(base64UrlEncode(header)   "."   base64UrlEncode(payload), secret)
JWTString=Base64(Header).Base64(Payload).HMACSHA256(base64UrlEncode(header) "." base64UrlEncode(payload),secret)



1.Header
JWT头是一个描述JWT元数据的JSON对象，alg属性表示签名使用的算法，默认为HMAC SHA256（写为HS256）；typ属性表示令牌的类型，JWT令牌统一写为JWT。最后，使用Base64 URL算法将上述JSON对象转换为字符串保存

{
  "alg": "HS256",
  "typ": "JWT"
}
2.Payload
有效载荷部分，是JWT的主体内容部分，也是一个JSON对象，包含需要传递的数据。 JWT指定七个默认字段供选择

iss：发行人
exp：到期时间
sub：主题
aud：用户
nbf：在此之前不可用
iat：发布时间
jti：JWT ID用于标识该JWT
除以上默认字段外，我们还可以自定义私有字段，一般会把包含用户信息的数据放到payload中，如下例：

{
  "sub": "1234567890",
  "name": "Helen",
  "admin": true
}
请注意，默认情况下JWT是未加密的，因为只是采用base64算法，拿到JWT字符串后可以转换回原本的JSON数据，任何人都可以解读其内容，因此不要构建隐私信息字段，比如用户的密码一定不能保存到JWT中，以防止信息泄露。JWT只是适合在网络中传输一些非敏感的信息

3.Signature
签名哈希部分是对上面两部分数据签名，需要使用base64编码后的header和payload数据，通过指定的算法生成哈希，以确保数据不会被篡改。首先，需要指定一个密钥（secret）。该密码仅仅为保存在服务器中，并且不能向用户公开。然后，使用header中指定的签名算法（默认情况下为HMAC SHA256）根据以下公式生成签名

HMACSHA256(base64UrlEncode(header)   "."   base64UrlEncode(payload), secret)
HMACSHA256(base64UrlEncode(header) "." base64UrlEncode(payload),secret)

在计算出签名哈希后，JWT头，有效载荷和签名哈希的三个部分组合成一个字符串，每个部分用.分隔，就构成整个JWT对象



注意JWT每部分的作用，在服务端接收到客户端发送过来的JWT token之后：

header和payload可以直接利用base64解码出原文，从header中获取哈希签名的算法，从payload中获取有效数据
signature由于使用了不可逆的加密算法，无法解码出原文，它的作用是校验token有没有被篡改。服务端获取header中的加密算法之后，利用该算法加上secretKey对header、payload进行加密，比对加密后的数据和客户端发送过来的是否一致。注意secretKey只能保存在服务端，而且对于不同的加密算法其含义有所不同，一般对于MD5类型的摘要加密算法，secretKey实际上代表的是盐值
JWT的种类
其实JWT(JSON Web Token)指的是一种规范，这种规范允许我们使用JWT在两个组织之间传递安全可靠的信息，JWT的具体实现可以分为以下几种：

nonsecure JWT：未经过签名，不安全的JWT
JWS：经过签名的JWT
JWE：payload部分经过加密的JWT
1.nonsecure JWT
未经过签名，不安全的JWT。其header部分没有指定签名算法

{
  "alg": "none",
  "typ": "JWT"
}
并且也没有Signature部分

2.JWS
JWS ，也就是JWT Signature，其结构就是在之前nonsecure JWT的基础上，在头部声明签名算法，并在最后添加上签名。创建签名，是保证jwt不能被他人随意篡改。我们通常使用的JWT一般都是JWS

为了完成签名，除了用到header信息和payload信息外，还需要算法的密钥，也就是secretKey。加密的算法一般有2类：

对称加密：secretKey指加密密钥，可以生成签名与验签
非对称加密：secretKey指私钥，只用来生成签名，不能用来验签(验签用的是公钥)
JWT的密钥或者密钥对，一般统一称为JSON Web Key，也就是JWK

到目前为止，jwt的签名算法有三种：

HMAC【哈希消息验证码(对称)】：HS256/HS384/HS512
RSASSA【RSA签名算法(非对称)】（RS256/RS384/RS512）
ECDSA【椭圆曲线数据签名算法(非对称)】（ES256/ES384/ES512）
标签: , , 没有评论
213月/220

什么是AARRR

发布在 邵珠庆

1 定义
AARRR是一个用于研究用户增长的数据分析模型，是Acquisition、Activation、Retention、Revenue、Refer，这个五个单词的缩写，分别对应用户生命周期中的用户获取、用户激活、用户留存、获得收益、推荐传播这5个重要环节。
2环节介绍
用户获取（Acquisition）
运营一款移动应用的第一步，毫无疑问是获取用户，也就是大家通常所说的推广。如果没有用户，就谈不上运营。
用户激活（Activation）
很多用户可能是通过终端预置、广告等不同的渠道进入应用的，这些用户是被动地进入应用的。如何把他们转化为活跃用户，是运营者面临的第一个问题。
当然，这里面一个重要的因素是推广渠道的质量。差的推广渠道带来的是大量的一次性用户，也就是那种启动一次，但是再也不会使用的用户。严格意义上说，这种不能算是真正的用户。好的推广渠道往往是有针对性地圈定了目标人群，他们带来的用户和应用设计时设定的目标人群有很大吻合度，这样的用户通常比较容易成为活跃用户。另外，挑选推广渠道的时候一定要先分析自己应用的特性（例如是否小众应用）以及目标人群。对别人来说是个好的推广渠道，对你却不一定合适。
另一个重要的因素是产品本身是否能在最初使用的几十秒钟内抓住用户。再有内涵的应用，如果给人的第一印象不好，也会“相亲”失败，成为“娶不到媳妇的老大难”。
用户留存（Retention）
有些应用在解决了活跃度的问题以后，又发现了另一个问题：“用户来得快、走得也快”。有时候我们也说是这款应用没有用户粘性。
我们都知道，通常保留一个老客户的成本要远远低于获取一个新客户的成本。所以狗熊掰玉米（拿一个、丢一个）的情况是应用运营的大忌。但是很多应用确实并不清楚用户是在什么时间流失的，于是一方面他们不断地开拓新用户，另一方面又不断地有大量用户流失。
解决这个问题首先需要通过日留存率、周留存率、月留存率等指标监控应用的用户流失情况，并采取相应的手段在用户流失之前，激励这些用户继续使用应用。
留存率跟应用的类型也有很大关系。通常来说，工具类应用的首月留存率可能普遍比游戏类的首月留存率要高。
获得收益（Revenue）
获取收入其实是应用运营最核心的一块。极少有人开发一款应用只是纯粹出于兴趣，绝大多数开发者最关心的就是收入。即使是免费应用，也应该有其盈利的模式。
收入有很多种来源，主要的有三种：付费应用、应用内付费、以及广告。付费应用在国内的接受程度很低。在国内，广告是大部分开发者的收入来源，而应用内付费在游戏行业应用比较多。
无论是以上哪一种，收入都直接或间接来自用户。所以，前面所提的提高活跃度、提高留存率，对获取收入来说，是必需的基础。用户基数大了，收入才有可能上量。
推荐传播（Referral）
以前的运营模型到第四个层次就结束了，但是社交网络的兴起，使得运营增加了一个方面，就是基于社交网络的病毒式传播，这已经成为获取用户的一个新途径。这个方式的成本很低，而且效果有可能非常好；唯一的前提是产品自身要足够好，有很好的口碑。
从自传播到再次获取新用户，应用运营形成了一个螺旋式上升的轨道。而那些优秀的应用就很好地利用了这个轨道，不断扩大自己的用户群体。
3 使用方法
获取用户（Acquisition）
这个阶段，最初大家最关心的数据是下载量。到今天，一些媒体的报道中也还经常用下载量来衡量一个应用的用户规模和是否成功。不过，下载了应用不等于一定会安装，安装了应用也不等于一定使用了该应用。所以很快激活量成为了这个层次中大家最关心的数据，甚至是有些推广人员唯一关注的数据。通常激活量（即新增用户数量）的定义是新增的启动了该应用的独立设备的个数。从字面上看激活量似乎更应该是第二层Activation的指标，但是因为下载量、安装量这些数据都比较虚，不能真实反映用户是否已经被获取。所以大家都要看激活，这才是真正获取到了新的用户。
另一个非常重要的数据，就是分渠道统计的激活量。因为在渠道推广时，很多应用开发者选择了付费推广。结算的时候，自然要了解在某个渠道有多少真正激活的用户。即使没有付费关系，开发者也需要知道哪个渠道是最有效果的。
但是站在更高的高度看，CAC（用户获取成本 Customer Acquisition Cost）才是最需要去关注的数据。行业里有种粗略的说法，每个Android用户的获取成本大约在4元左右，而iOS用户大约在8元以上。当然，应用市场下载、手机预置、广告等各种不同的渠道的获取成本是完全不同的。这里面有个性价比的问题，有些渠道的获取成本比较高，但是用户质量也比较高。
提高活跃度（Activation）
看到活跃度，大家首先会想到的指标是DAU（日活跃用户）、MAU（月活跃用户）。这两个数据基本上说明了应用当前的用户群规模，在网络游戏行业这是运营人员必看的两个指标。
通常活跃用户是指在指定周期内有启动的用户。但是启动是否真的等于活跃呢？如果在指定周期内只启动了一次，而且时间很短，这样的用户活跃度其实并不高（当然对某些特殊的应用来说可能算高，例如用来记录女性生理周期的应用，一月启动一次就够了）。所以其实还要看另两个指标：每次启动平均使用时长和每个用户每日平均启动次数。当这两个指标都处于上涨趋势时，可以肯定应用的用户活跃度在增加。
针对使用时长和启动次数的渠道统计同样很重要。我们把它们称为渠道的质量数据，如果某个渠道上来的用户，这两个指标很差，那么在这个渠道上投入太多是没有意义的。最典型的就是水货刷机的用户，很多预置的应用都是在刷机完成时被激活的。针对这种被动激活的用户，可以看另一个指标，叫一次性启动用户数量，也就是迄今为止只启动过一次的用户的数量。
除了渠道，另一个和活跃度相关的分析维度是版本。各个版本的使用时长和启动次数也会有差异。对产品经理来说，分析不同版本的活跃度差异有助于不断改进应用。
此外跟活跃度相关的，还有日活跃率、周活跃率、月活跃率这些指标。当然活跃率和应用的类别是很有关系的，比如桌面、省电类的应用的活跃率就比字典类的应用高。
提高留存率（Retention）
下载和安装——使用——卸载或者遗忘，这是用户在每个应用中的生命周期。成功的应用就是那些能尽量延长用户的生命周期，最大化用户在此生命周期内的价值。
对于大部分应用，应该关心的是1-Day Retention 和7-Day Retention。1-Day Retention通常翻译为首日留存率，其实这个“首日”并不是指应用被安装使用的第一天（假设日期为D），而是D 1日，即安装使用的第二天。因为安装使用的第一天没有留存率这个概念（有的话，只能是100%）。到了第二天，前一天安装使用的用户中还有多少百分比的人还在启动使用这款应用，这就是1-Day Retention。因为是第二天，所以有些文章中也叫“次日留存率”。同样的，7-Day Retention是在D 7日启动使用这款应用的占D日首次安装使用这款应用的用户总数的百分比。通常用户新安装使用后的前几天是流失比例最大的时期。
所以这两个指标在留存率分析是最重要的。曾经有游戏行业的行家指出，如果想成为一款成功的游戏，1-Day Retention要达到40%，7-Day Retention要达到 20%。
有些应用不是需要每日启动的，那样的话可以看周留存率、月留存率等指标，会更有意义。留存率也是检验渠道的用户质量的重要指标，如果同一个应用的某个渠道的首日留存率比其它渠道低很多，那么这个渠道的质量是比较差的。
获取收入（Revenue）
关于收入，大家最耳熟能详的指标就是ARPU（平均每用户收入）值。对应的比较少提的还有个指标叫ARPPU（平均每付费用户收入）。
是不是ARPPU高，ARPU就一定会高呢？答案是不一定。因为其中还有个指标是付费用户比例，也就是付费用户在全部用户中所占的比例。如果付费用户比例较低，那么那些收入摊到所有用户身上的平均值就低了。通常来说，如果某个游戏为了提高ARPPU，提高了虚拟道具的价格，那么付费用户比例就会相应地降低。找到一个ARPPU和付费用户比例的平衡点，才能最大化收入。
但是收入并不是最重要的，利润才是。如何最大化利润呢？利润最简化的计算公式是：利润=收入-成本。除CAC（用户获取成本）之外，还有应用本身的开发成本、服务器硬件和带宽成本以及运营成本等等。不过在用户量很大的情况下，CAC会成为最主要的成本，而其它成本不在一个数量级，所以我们在后续讨论中只考虑CAC。
那么收入如何计算？ARPU是一个和时间段相关的指标（通常讲的最多是每月的ARPU值），还不能完全和CAC对应，因为CAC和时间段并没有直接关系。所以我们还要多看一个指标：LTV（生命周期价值）。用户的生命周期是指一个用户从第一次启动应用，到最后一次启动应用之间的周期。LTV就是某个用户在生命周期内为该应用创造的收入总计，可以看成是一个长期累计的ARPU值。每个用户平均的LTV = 每月ARPU * 用户按月计的平均生命周期。
LTV – CAC的差值，就可以视为该应用从每个用户身上获取的利润。所以最大化利润，就变成如何在降低CAC的同时，提高LTV，使得这两者之间的差值最大化。更进一步的，对不同渠道来源用户做断代分析，根据他们不同的CAC和LTV，就可以推导出不同渠道来源的利润率差异。
自传播（Refer）
自传播，或者说病毒式营销，是最近十年才被广泛研究的营销方法。虽然大家都听过一些病毒式营销的经典案例，但是要说怎样量化评估其效果，却很少有人知道K因子(K-factor)这个衡量指标。
其实K因子这个术语并非起源于市场学或软件业，而是来源于传染病学——对，就是研究真正的病毒传播的科学。K因子量化了感染的概率，即一个已经感染了病毒的宿主所能接触到的所有宿主中，会有多少宿主被其传染上病毒。
K因子的计算公式不算复杂，K = (每个用户向他的朋友们发出的邀请的数量) * (接收到邀请的人转化为新用户的转化率)。假设平均每个用户会向20个朋友发出邀请，而平均的转化率为10%的话，K =20*10%=2。这个结果还算是不错的效果——当K>1时，用户群就会象滚雪球一样增大。如果K<1的话，那么用户群到某个规模时就会停止通过自传播增长。
很遗憾的是，即使是社交类的移动应用，K因子大于1的也很少。所以绝大部分移动应用还不能完全依赖于自传播，还必须和其它营销方式结合。但是从产品设计阶段就加入有利于自传播的功能，还是有必要的，毕竟这种免费的推广方式可以部分地减少CAC。以上我们列举了在应用推广运营各个层次（各个阶段）需要关注的一些指标。
总结
在整个AARRR模型中，这些量化指标都具有很重要的地位，而且很多指标的影响力是跨多个层次的。及时准确地获取这些指标的具体数据，对于应用的成功运营是必不可少的。
标签: 没有评论
2110月/210

全国大数据交易所及数据交易平台汇总

发布在 邵珠庆

政府类：
贵阳大数据交易所
gbdex.com/website/
我国乃至全球第一家大数据交易所， 贵阳大数据交易所发展会员数目突破2000家，已接入225家优质数据源，经过脱敏脱密，可交易的数据总量超150PB，可交易数据产品4000余个，涵盖三十多个领域，成为综合类、全品类数据交易平台。
西咸新区大数据交易所
chinabdbank.com/index.h
西咸新区沣西大数据产业发展平台，通过构建有效的市场机制，聚合政府、企业、社会等多类数据资源，整合大数据服务能力，全面运营大秦大数据银行线上服务平台和陕西省社会数据服务大厅线下服务平台。
东湖大数据交易中心
chinadatatrading.com/
武汉东湖大数据交易中心股份有限公司的业务涵盖数据交易与流通、数据分析、数据应用和数据产品开发等，聚焦“大数据+”产业链，提供有价值的产品和解决方案，帮助用户提升核心竞争力。
华东江苏大数据交易平台
bigdatahd.com/
华东江苏大数据交易中心（简称BDEX）是在实施“国家大数据战略”大背景下，经国家批准的华东地区首个领先的跨区域、标准化、权威性省级国有大数据资产交易与流通平台，2015年11月成立于国家级大数据产业基地——江苏盐城大数据产业园，承担助推江苏省国有数据增值开放流通、大数据产业发展之重任。
哈尔滨数据交易中心
hrbdataex.com/
哈尔滨数据交易中心由黑龙江省政府办公厅组织发起并协调省金融办、省发改委、省工信委等部门批准设立。结合政府数据资源、企业数据资源，打造成为立足东三省，辐射全国的大数据交易市场，构建围绕数据的生态系统支撑平台。
上海数据交易中心
chinadep.com/index.html
上海数据交易中心有限公司（简称“上海数据交易中心”），是经上海市人民政府批准，上海市经济和信息化委、上海市商务委联合批复成立的国有控股混合所有制企业，上海数据交易中心承担着促进商业数据流通、跨区域的机构合作和数据互联、政府数据与商业数据融合应用等工作职能。
中国工信数据
miit.gov.cn/n1146312/in

平台类：
京东万象
wx.jdcloud.com/
以数据开放、数据共享、数据分析为核心的综合性数据开放平台，拥有的数据类型主要包括金融、征信、电商、质检、海关、运营商数据
聚合数据
juhe.cn/
互联网专业数据科技服务商。主要提供两种核心服务：以API数据接口的形式，提供数据服务；以大数据技术，提供数据应用服务。
数据宝
chinadatapay.com/
中国领先的国有数据资产增值运营服务商，提供 公安、运营商、银联、交通、车辆、企业、税务、气象大数据。
百度智能云云市场
cloud.baidu.com/market/
由百度智能云建立的云计算软件或商品的交易与交付平台，下设多个商品品类，包括镜像环境、建站推广、企业应用、人工智能、数据智能、区块链、泛机器人、软件工具、安全服务、上云服务、API服务等，商品数量数千种。
数粮
datasl.com/
大数据领域的流通平台，供数据资源和大数据技术应用产品进行交易，支持API接口、数据包下载、定制等交易模式。
阿凡达数据
avatardata.cn/Docs
API数据接口云服务，专注于数据的采集与分析处理工作，拥有106个数据种类。
HaoService
haoservice.com/
数据互联服务平台。提供30大类以上基础数据API服务、热门源码交易服务。
发源地
finndy.com/
大数据应用平台和大数据解决方案提供商。提供数据交易服务，目前总共拥有20246个数据源。
iDataAPI
idataapi.com/
数据服务提供商，已推出1300多种数据产品和50多种数据分析产品，涵盖30000个网站平台和全球移动APP平台。
天元数据
tdata.cn/
中国领先的云计算、大数据服务商。数据商品涵盖了线上零售、生活服务、企业数据、农业、资源能化等10大类。提供17个API接口、165个数据集、56个数据报告、278个政府开放数据。
中原大数据交易
zybigdatae.cn/
数据资源提供商、数据资产运营商和数据交易服务商，向客户提供大数据全产业链平台与技术服务。提供223个API接口、177个数据集、89个数据报告、2个数据应用。
环境云
envicloud.cn/home?
环境大数据开放平台。拥有3702家注册用户、收录1,041，098，354条环境数据，以积分兑换和免费下载两种方式提供数据服务。
天眼查
tianyancha.com/vipintro
天眼查收录了1.8亿+家社会实体信息（含企业、事业单位、基金会、学校、律所等），90多种维度信息全量实时更新。
企查查
qichacha.com/
提供企业工商信息、法院判决信息、关联企业信息、法律诉讼、失信信息、被执行人信息、知识产权信息、公司新闻、企业年报等企业数据交易服务，覆盖全国1.8亿家企业信息。
杭州钱塘大数据交易中心
qtbigdata.com/index.htm
杭州钱塘大数据交易中心有限公司（简称“钱塘数据”）成立于2015年底，是国内一家工业大数据应用和交易平台。
中关村数海大数据交易平台
shuhaidata.com/
全国第一家数据交易平台，推动数据的流通，发挥数据的商品属性，促成数据交换、整合，将真正带动大数据产业繁荣。
大数据挖掘模型交易平台
mx.tipdm.org/
模型算法交易平台，配套完整建模数据，模型实现过程说明及源代码。
APIX
apix.cn/services/catego
APIX是黑格科技旗下的一款SaaS云服务产品，专注为机构提供实时在线用户数据分析，信用评估，第三方数据接入服务。
抓手数据
zhuashou.net/
运用区块链底层技术，以生产数据产品、建立数据交易生态圈为主要目标，促进数据的开放共享和数据价值的释放
千教堂
d.askci.com/
全球大数据众享平台
中国数据商城
chinadatastore.cn/index
中国领先的大数据交易平台
中国管理大数据
chn-source.com/
管理大数据RBD=平台运营商+数据供应商
数据星河
bdgstore.cn/
是全球首款大数据产业链生态平台，基于国际主流的大数据生态技术研发，结合先进的大数据资产运营理念，汇聚全球近千家大数据公司 。

相关阅读：
最全的中国开放数据（Open Data）及政府数据开放平台汇总
国外最全的开放数据(Open Data)及政府数据开放平台汇总

标签: , , , , , 没有评论
2110月/210

【Open Data】国外开放数据中心及政府数据开放平台汇总

发布在 邵珠庆

纽约政府开放数据平台

https://opendata.cityofnewyork.us/

美国官网数据超市

https://www.data.gov/

提供230,256个数据集、14个数据目录

新加坡政府开放数据平台

https://data.gov.sg/

提供1700个数据集、9个数据目录

休斯顿市开放数据门户网站

http://data.houstontx.gov/

247个数据集、12个数据目录

Academic Torrents

http://academictorrents.com/

共享大量数据集的分布式系统，提供445.96TB的研究数据

Hadoopilluminated.Com

http://hadoopilluminated.com/hadoop_illuminated/Public_Bigdata_Sets.html

提供国外开放数据网站相关信息，目前已集合35个查询途径

United States Census Bureau

https://www.census.gov/

美国人口普查局

Usgovxml.Com

http://usgovxml.com/

USGovXML.com是美国政府提供的公共Web服务和XML数据源的索引。USGovXML.com索引来自 美国政府所有3个分支机构以及董事会，委员会，公司和独立机构的数据来源。

Enigma.Com

https://www.enigma.com/

快速搜索和分析政府、公司和组织发布的数十亿份公共记录。

Datahub.Io

https://datahub.io/

发现和分享高质量数据集，与他人联系和分享知识。

Aws.Amazon.Com/Datasets

https://registry.opendata.aws/

帮助人们发现和共享通过AWS资源提供的数据集。

Databib.Org

http://databib.org/

开放数据网站导航

Quandl.Com

https://www.quandl.com/

金融，经济和替代数据集的主要来源，为投资专业人士提供服务。Quandl的平台被超过40万人使用，其中包括来自世界顶级对冲基金，资产管理公司和投资银行的分析师。

Figshare.Com

https://figshare.com/

研究论文上传网站，已有2600万+浏览量、750万+下载、800，000+上传、200万+文章

GeoLite Legacy Downloadable Databases

https://dev.maxmind.com/geoip/geoip2/geolite2/

IP地理定位数据库

Quora's Big Datasets Answer

https://www.quora.com/Where-can-I-find-large-datasets-open-to-the-public

公共开放数据集汇总

Kaggle Datasets

https://www.kaggle.com/datasets

数据文档，拥有20394个数据集

A Deep Catalog Of Human Genetic Variation

https://www.internationalgenome.org/data

国际基因组样本资源

Google Public Data

https://www.google.com/publicdata/directory

谷歌公开数据搜索网站

World Bank Data

https://data.worldbank.org/

世界银行开放数据搜索网站

NYC Taxi Data

http://chriswhong.github.io/nyctaxi/

纽约出租车数据开放平台

Open Data Philly

https://www.opendataphilly.org/

费城开放数据平台、16个数据目录、354个数据集

Grouplens.Org

https://grouplens.org/datasets/

提供9个数据集，关于书籍、电源、wiki数据集

UC Irvine Machine Learning Repository

http://archive.ics.uci.edu/ml/index.php

加州大学欧文机器学习库，提供481个数据集

Research-Quality Data Sets By Hilary Mason

http://web.archive.org/web/20150320022752/https://bitly.com/bundles/hmason/1

公共数据集汇总

National Climatic Data Center - NOAA

https://www.ncdc.noaa.gov/

美国国家环境信息中心，监测，评估和提供国家气候和历史天气数据和信息

ClimateData.Us

http://www.climatedata.us/

美国宇航局公布的美国气候数据

R/Datasets

https://www.reddit.com/r/datasets/

开放数据集汇总网站

MapLight

https://maplight.org/data/

关于货币的数据集

GHDx

http://ghdx.healthdata.org/

健康指标和评估研究所 - 来自世界各地的健康和人口统计数据集目录，包括IHME结果

St. Louis Federal Reserve Economic Data - FRED

https://fred.stlouisfed.org/

圣路易斯联邦储备银行数据开放网站，该网站提供丰富的经济数据和信息，以促进经济教育和加强经济研究。

New Zealand Institute Of Economic Research – Data1850

https://data1850.nz/

新西兰经济研究所，可在该网站下载自1850年以来的相关经济数据。

Dept. Of Politics @ New York University

http://www.nyu.edu/projects/politicsdatalab/datasupp_datasources.html

纽约大学政治数据中心

Open Data Sources

https://github.com/datasciencemasters/data

Github网站上的开放数据源总结

UNICEF Statistics And Monitoring

https://www.unicef.org/statistics/index_24287.html

联合国儿童基金会官网，开放世界各国家、地区的儿童状况报告

Undata

http://data.un.org/Default.aspx

联合国国际统计数据库，包含6,000多万个数据点，涵盖广泛的统计主题，包括农业，犯罪，通信，发展援助，教育，能源，环境，金融，性别，健康，劳动力市场，制造业，国民核算，人口与移民，科学技术，旅游，运输和贸易。

NASA SocioEconomic Data And Applications Center - SEDAC

https://sedac.ciesin.columbia.edu/

社会经济数据和应用中心，是美国国家航空航天局地球观测系统数据和信息系统（EOSDIS）中的分布式主动档案中心（DAAC）之一。

The GDELT Project

https://www.gdeltproject.org/#intro

GDELT博客是世界上最大的人类社会开放研究平台的最新新闻，公告，信息和应用程序的官方一站式存储库。

Sweden, Statistics

https://www.scb.se/en/

瑞典统计局，提供瑞典国家统计数据，包含26个数据集。

Github Free Data Source List

https://www.datasciencecentral.com/profiles/blogs/great-github-list-of-public-data-sets

Github公共数据集

StackExchange Data Explorer

https://data.stackexchange.com/

一个开源工具，用于对来自StackExchange网络的公共数据进行任意查询。

San Fransisco Government Open Data

https://datasf.org/opendata/

旧金山政府开发数据网站

IBM Blog Abour Open Data

https://www.datasciencecentral.com/profiles/blogs/the-free-big-data-sources-everyone-should-know

数据科学中心

Liver Tumor Segmentation Challenge Dataset

https://competitions.codalab.org/competitions/17094

Public Git Archive

https://github.com/src-d/datasets/tree/master/PublicGitArchive

Git Hub开放数据平台汇总

GHTorrent

http://ghtorrent.org/

Microsoft Research Open Data

https://msropendata.com/

来自Microsoft Research的免费数据集，以推进自然语言处理，计算机视觉和特定领域科学等领域的最新研究。

Open Government Data Platform India

https://data.gov.in/

印度开放政府数据（OGD）平台-data.gov.in-是一个用于支持印度政府开放数据倡议的平台。

Google Dataset Search (Beta)

https://toolbox.google.com/datasetsearch

谷歌数据集搜索门户

Data.Gov

http://data.gov/

它是美国政府免费提供有关气候和犯罪等各种惊人信息的门户。

Data.Gov.Uk

http://data.gov.uk/

有来自英国所有中央部门以及许多其他公共部门和地方当局的数据集。它充当有关一切信息的门户，包括商业与经济，犯罪与正义，国防，教育，环境，政府，卫生，社会和交通运输。

美国人口普查局（US Census Bureau）

https://www.census.gov/

该网站是有关政府掌握的有关美国公民生活的统计数据，包括人口，经济，教育，地理等。

中央情报局世界概况

https://www.cia.gov/library/publications/the-world-factbook/

世界上每个国家的事实；重点研究267个国家/地区的历史，政府，人口，经济，能源，地理，通讯，运输，军事和跨国问题。

欧盟开放数据门户

http://open-data.europa.eu/en/data/

数据的增长包括欧盟内部的经济发展以及欧盟机构内部的透明度，包括地理，地缘政治和金融数据，统计数据，选举结果，法律法规以及犯罪，健康，环境，交通运输和科学研究的数据。

加拿大开放数据

http://www.data.gc.ca/

包含许多政府和地理空间数据集的试点项目。它可以帮助您探索加拿大政府如何通过开放数据，开放信息和开放对话来提高透明度，加强问责制，提高公民参与度并推动创新和经济机会。

Datacatalogs.Org

https://opengovernmentdata.org/

它提供来自美国，欧盟，加拿大，CKAN等的开放政府数据。

美国国家教育统计中心

https://nces.ed.gov/

国家教育统计中心（NCES）是收集和分析与美国和其他国家/地区的教育相关数据的主要联邦实体。

英国数据服务

https://www.ukdataservice.ac.uk/

英国数据服务集合包括英国政府资助的主要调查，跨国调查，纵向研究，英国人口普查数据，国际总量，商业数据和定性数据。

标签: , , , , , 没有评论
2110月/210

大数据数据开放平台

发布在 邵珠庆

2015年国务院印发的《促进大数据发展行动纲要》，要求“2018年底前建成国家政府数据统一开放平台，率先在信用、交通、医疗、卫生、就业、社保、地理、文化、教育、科技、资源、农业、环境、安监、金融、质量、统计、气象、海洋、企业登记监管等重要领域实现公共数据资源合理适度向社会开放”，截止2019年，已经有50多个地市开放了平台，开放了约15个领域数据，包括教育科技、民生服务、道路交通、健康卫生、资源环境、文化休闲、机构团体、公共安全、经济发展、农业农村、社会保障、劳动就业、企业服务、城市建设、地图服务。 同时，研究显示，中国开放政府数据实践存在六个方面的主 要问题：数据量少、价值低、可机读比例低，开放的多为静态数据，数据授权协议条款含糊，缺乏便捷的数据获取 渠道，缺乏高质量的数据应用，缺乏便捷、及时、有效、公开的互动交流。最后基于研究的评估结果，为中国开放政府数据的发展提出了政策建议。

参考论文：

关键词：

电子政务；开放政府；政府数据；政府数据开放；大数据数据开放平台。

四川省

成都市公共数据开放平台

http://www.cddata.gov.cn/

已开放：602个数据集，60个部门，27301171条数据，39个API，12个应用

数据开放--四川省人民政府网站

http://www.scdata.net.cn/odweb/index.htm

达州市政府数据开放平台

http://data.dazhou.gov.cn/

雅安市人民政府数据开放栏目

http://www.yaan.gov.cn/shuju.html

北京市

北京市政务数据资源网

http://www.bjdata.gov.cn/jkfb/index.htm

56家单位、1147类数据集、7653万余条数据记录

上海市

上海市政府数据服务网

http://www.data.sh.gov.cn/home!toHomePage.action

https://data.sh.gov.cn/

开放数据项总量32312条 开放数据资源1958个 开放数据部门45个

天津市

天津市信息资源统一开放平台

https://data.tj.gov.cn/

21 个主题、39 个部门、384 个数据集、116 个数据接口

福建省

福建省公共信息资源统一开放平台

https://data.fujian.gov.cn/odweb/

697346300条数据； 698个数据资源； 37个部门；1318个API；3个应用

厦门市大数据开放平台

http://data.xm.gov.cn/

8896790条数据 、789个资源、327个API、39个部门

广东省

开放广东

http://gddata.gd.gov.cn/

2369个政府数据集，58个数据应用，超过1.39亿条政府数据

广东省金融数据开放平台

http://210.76.74.192/

佛山市政府数据开放平台

http://www.foshan-data.cn/

提供部门(个)：49主题分类(个)：25数据集(个)：1071数据总量(个)：45078449

深圳市政府数据开放平台

http://opendata.sz.gov.cn/

数据目录1,260个 数据总量121,338,216条 数据接口1,002个 调用次数1,945,673次

广州市政府数据统一开放平台

http://data.gz.gov.cn/

68个部门，1307个数据集，100248678数据量，81693下载量

数据东莞

http://dataopen.dg.gov.cn/dataopen/

36797385条数据、69个部门、714类资源、12757个数据包、2100037次浏览、173422次下

惠州市政府数据开放平台

http://data.huizhou.gov.cn/

3141349条数据、348个数据集、5个部门

珠海市民生数据开放平台

http://data.zhuhai.gov.cn/

#/ 已开放：195条数据；188个数据资源；74个部门

广东省政府数据统一开放平台-潮州市

http://gddata.gd.gov.cn/index.php/data/ls/Type/0/v/344.html

广东省政府数据统一开放平台-河源市

http://gddata.gd.gov.cn/index.php/data/ls/Type/0/v/339.html

江门市数据开放平台

http://data.jiangmen.gov.cn/

提供：26个部门、12个主题分类.299个开放数据集、65.21万条数据、1994次下载量

中山市政府数据统一开放平台

http://zsdata.zs.gov.cn/web/index

数据集总数215，机构部门56，数据条数1736366，下载总数43801

肇庆市人民政府数据开放平台

http://www.zhaoqing.gov.cn/sjkf/

贵州省

贵阳市政府数据开放平台

http://www.gyopendata.gov.cn/

已开放 6180610条数据, 2841个数据集 , 310个API, 52个市级部门 , 13个区县

遵义市政府数据开放平台

http://www.zyopendata.gov.cn/

171开放数据集；219个开放文件；30个部门

铜仁市政府数据开放平台

http://gztrdata.gov.cn/

累计提供310个数据资源，其中数据类型资源69个

海南省

海南省政府数据统一开放平台

http://data.hainan.gov.cn/

14个已开放数据集； 969个已开放API；34个已开放部门

河南省

河南省公共数据开放平台

http://data.hnzwfw.gov.cn/odweb/

32个部分，20个领域，3497200数据量，709数据集，1418API，8个应用

江西省

江西省政府数据开放网站

http://data.jiangxi.gov.cn/

9个部门 , 153192条数据； 72个数据目录； 1个接口

宁夏回族自治区

宁夏回族自治区数据开放平台

http://ningxiadata.gov.cn/odweb/index.htm

22个已开放部门；128个数据集类；343175条政府数据；13个应用；12个API；545544条访问量；456个下载量

石嘴山政府数据开放平台

http://szssjkf.nxszs.gov.cn/

已开放97个数据集，107个数据资源，32个部门

银川市城市数据开放平台

http://data.yinchuan.gov.cn/

提供：32个部门数据；228个开放数据目录数量、7832个数据总条数、45个API数量

山东省

山东公共数据开放网

http://data.sd.gov.cn/

59部门，34216目录，7.35亿数据，70284API，41应用

济南市公共数据开放网

http://www.jndata.gov.cn/

71个部门 2106个数据集 4300个接口 6506个文件

青岛公共数据开放网

http://data.qingdao.gov.cn/

2818个数据集、7260个API、25个领域、12个文件集

陕西省

陕西省公共数据开放平台

http://www.sndata.gov.cn/

57个部门1300多个可开放目录，省级部门已开放121个目录1654万条数据

哈尔滨市政府数据开放平台"

http://data.harbin.gov.cn/ 54个部门; 1059个数据集; 5167696条数据; 5782个数据文件; 2284个API; 7个APP

浙江省

浙江政务服务网“数据开放”专题网站

http://data.zjzwfw.gov.cn/

68个省级单位提供的350项数据类目，包含100项可下载 的数据资源，137个数据接口和8个移动APP

宁波市政府数据服务网

http://www.datanb.gov.cn/nbdatafore/web/indexpage.action

20类主题、432个资源、3065883数据

安徽省

合肥市政府数据开放平台

http://61.133.142.137

"已开放79个部门，3个数据种类，211233条数据

蚌埠市信息资源开放平台

http://data.bengbu.gov.cn/

数据总量140条，112次下载次数、29次调用次数、2837次浏览总数

黄山市人民政府数据开放栏目

http://www.huangshan.gov.cn/DataDevelopment/showTopicContentList/8/page_1.html

湖北省

武汉市政务公开数据服务网

http://www.wuhandata.gov.cn/whData/

"开放数据部门101家，开放数据集2192类，开放数据总量118417条，4个API,54个应用

湖南省

长沙市政府门户网站数据开放平台

http://www.changsha.gov.cn/data/

40个部门，236个接口，6个app

江苏省

苏州市政府数据开放平台

http://www.suzhou.gov.cn/dataOpenWeb/data

常州市政府数据开放平台

http://opendata.changzhou.gov.cn/

390705条数据； 198个数据资源； 24个部门

黑龙江省

哈尔滨市政府数据开放平台

http://data.harbin.gov.cn/

54个部门; 1059个数据集; 5167696条数据; 5782个数据文件; 2284个API; 7个APP

嫩江市政务公开统计数据

http://www.nenjiang.gov.cn/zwgk/tjsj/

新疆维吾尔自治区

新疆维吾尔自治区政务数据开放网

http://data.xinjiang.gov.cn/index.html

内蒙古自治区数据开放

http://gzw.nmg.gov.cn/zwgk/zdlyxxgk/sjkf/

台湾省

台湾

http://data.gov.tw/

38745个资料集，18个分类，649个部门

国家相关部门统计信息网站汇总

中国人民银行

http://www.pbc.gov.cn/diaochatongjisi/116219/index.html

主要包括社会融资规模、金融统计数据、货币统计、金融机构信贷收支统计、金融市场统计、企业商品价格指数等等，数据权威且容易查找，实用性强。

中国银行业监督管理委员会

Http://Www.Cbrc.Gov.Cn/Chinese/Home/DocViewPage/110009.Html

主要包括银行业的数据统计，包括资产负债规模、主要监管数据等。

中国证券监督管理委员会

http://www.csrc.gov.cn/pub/newsite/sjtj/

主要包括证券市场、期货市场相关数据，每天更新快报，并有周报、月报等定期更新。

中国银保险监督管理委员会

http://www.cbirc.gov.cn/cn/index.html

对银行业和保险业机构的公司治理、风险管理、内部控制、资本充足状况、偿付能力、经营行为和信息披露

中国国家统计局

http://www.stats.gov.cn/tjsj/

主要包括国家经济宏观数据，社会发展、民生相关重要数据及信息，非常全面，且定期发布统计出版刊物，实用性强。

国家数据

http://data.stats.gov.cn/

数据源来自国家统计局，但排版更清晰简洁，包括国计民生各个方面的月度数据、季度数据、年度数据、各地区数据、部门数据以及国际数据。

数据-中国政府网

http://www.gov.cn/shuju/

主要包括CPI、GDP、PPI、工业生产增长指数、固定资产投资、社会消费品零售总额、粮食产量等的指数统计，只列出了主要数据，数据来源于国家统计局，点击会跳转至统计局的国家数据网站。查找起来比较简洁清晰，适合需要快速获取这些基础数据的人群。 

中国经济数据库

https://www.ceicdata.com/zh-hans/products/china-economic-database

中国互联网信息中心

http://www.cnnic.cn/

主要包括互联网发展相关基础数据，相对第三方机构的互联网数据而言，数据更宏观且权威。

香港  https://data.gov.hk/sc/

澳门 https://www.dsec.gov.mo/home_zhmo.aspx

标签: , , 没有评论
31月/210

深入理解 http 反向代理（nginx）

发布在 邵珠庆

反向代理(reverse proxy)

明白了直接访问, 明白了所谓的正向代理, 下面就可以来说说反向代理是怎么回事了.

反向代理与正向代理的一个很大区别就是, 它不需要客户端(浏览器)去做什么配置, 并没有什么配置代理服务器的操作.

如果说正向代理是主动配置, 主动走代理, 那么反向代理则是"被代理", 从这点上看, 反向代理有时又称为"透明代理", 也即是浏览器都不知道自己被代理了, 浏览器以为发给它响应的就是最终的网页服务器, 其实不过是个"代理".

还是举购物的例子来比喻. 有时你在网上购物会看到有商家声称自己就是厂家, 东西都很便宜, 属于厂家直销, 于是你下单了. 过段时间, 你又发现有另一家店声称自己才是真正的厂家直销, 然后你仔细看了两家店铺的信息, 才发现前一个商家是假的, 它不是真的厂家.

但为啥这个假的厂家直销它还是这么便宜呢? 以至于价格跟真的厂家直销的没啥区别. 原因可能则是店家直接就是坐落在厂家旁边, 然后他可能与厂家有那么点关系, 认识里面一些人之类的, 这让他能以很便宜的价格从厂家拿到货, 又因为离得近, 几乎没有任何物流成本, 从某种层面看, 它声称厂家直销也不算怎么骗人. 当然严格来说, 它属于伪厂家直销, 他依然还是个代理商

它声称是李逵, 其实它是李鬼.

用一个图对比一下这两种情形:

深入理解 http 反向代理（nginx）

那么这样的一种模式就有点 反向代理 的味道了, 你以为自己买到了直销, 其实你还是"被代理"了, 还是经过了中间商.

只是这个中间商对你来说不是那么明显, 甚至说对你是透明的, 把你蒙在了鼓里.
虽然都是"代理", 这跟线下店面购买还是很不同的, 在线下你去商店买时, 你很清楚自己经过了代理的中间商, 也即是商店本身, 但在远程线上这种声称自己是厂家直销的情形, 有时你还真不好判断自己是不是被代理了.

那么 http 的反向代理其实也是这样一个道理. 比如你访问我的网站 xiaogd.net, 然后你看下主页的请求里的服务器信息, 它告诉你响应这个主页请求的是一台 Nginx server, 如下图所示:

问题是 Nginx 是最终生成这个网页的 server 吗? 其实不是的! 如果你了解 Nginx, 就会知道它通常只是一个静态资源服务器, 而我的网站主页是一个动态生成的内容, 其实你要是认真看过我网站底部的一个声明, 如下图所示:

深入理解 http 反向代理（nginx）

就会明白这个主页其实是 php 的一个叫 wordpress 的建站应用去生成的. 在我的云主机的内部, Nginx 其实是将主页的请求转发给一个所谓的 php-fpm 网关

这个 php-fpm 网关基本可以看作是个 php 的 web 服务器, 不过严格来说它用的协议不是 http, 而是一种内部简化的 fastcgi 协议.
如果你要较真的话, 这可以算是 反向代理 模式, 但整体不全是 http 反向代理, 但对外而言则确实是.

从它那里取得最终响应的内容, 并再次转发给浏览器, 整个情形见如下的示意图:

深入理解 http 反向代理（nginx）

这是内部配置的一个情况:

location ~ .php$ {
    root           /ftp/wwwroot;
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  $document_root/$fastcgi_script_name;
    include        fastcgi_params;
}

请求被转发到内部一个在 9000 端口上监听的 php 应用服务器.

从外部浏览器的角度看, 请求直接发给了 Nginx server, 响应也从 Nginx server 里回来了, 中间没有任何的(正向)代理. 至于说你内部请求又被怎么转发了, 显然浏览器是无从知道也不需要去知道的.

站在整个体系设计者的角度去看, 当然但很多请求 Nginx 其实是没有能力去响应的, 它只不过在内部把它代理给了另一个内部的 php 应用服务器, 内部的 php 应用服务器才是最终的响应生成者.

在整个体系里面, Nginx 的角色就是一个"反向代理"服务器, 浏览器被代理了, 但它无从知道自己是否被代理了, 这一切对它而言是透明的, 反正它自己是没有主动走(正向)代理的.

当然了, 你现在知道了我内部的配置, 如果直接访问 xiaogd.net:9000, 那就是真正的"直接访问"了, 那就绕过了 Nginx.

不过需要说明的一点是, 直接访问是访问不通的, 因为 9000 端口并没有对外放开. 但是在内部是可以访问到的, 比如这样尝试用 wget 去访问:
wget localhost:9000

这样就是真正的"直接访问"了, 没有任何的代理, 既没有正向代理, 也没有反向代理.
需要说明的一点是, 用 wget 这样去获取响应还是会报错, 因为 wget 使用的是 http 协议, php 的 cgi 网关实际使用的是 fastcgi 协议, 是一个比 http 更为简化的协议, 作为内部通讯更加高效, 不过 wget 不支持这个协议, 但 Nginx 能理解这个协议, 整个过程是这样的:
browser -- [http] --> Nginx -- [fastcgi] --> php-fpm
严格来说, 不完全是 http 代理, 内部的反向代理实际用的是 fastcgi 网关协议, 不过这个原理还是一样的, 如果内部用一个比如 tomcat 来响应, 那么全程就都可以是 http 协议.
browser -- [http] --> Nginx -- [http] --> tomcat
而如果在内部发请求 80, 比如 wget localhost 那就还是被反向代理, 请求先到在 80 端口监听的 Nginx, Nginx 再转给 php-fpm.
另: 关于端口及缺省端口相关知识, 可以参考这篇深入理解端口.

为什么要使用反向代理?

那么到了这一步我们又面临一个新的问题, 那就是为啥要整这个反向代理呢? 类似于碰到正向代理时的诘问那样, 直接访问不香吗? 为啥还要走这个反向代理? 关于正向代理前面已经解释了一些原因, 而反向代理的出现, 正像这个世界上没有无缘无故的爱与恨一样, 自然也有它存在的原因.

一个很直接的原因就是利用反向代理可以作为内部 负载均衡(load balance) 的手段.

举个例子来说, 假如我现在开发了一个 java web 的应用作为我的网站后台, 我直接部署它到 tomcat 服务器上, 让 tomcat 监听 80 端口, 直接对外服务. 一开始访问量也不大, 所以这样也是没有问题的, 如下图所示:

深入理解 http 反向代理（nginx）

注: 因为 http 协议的缺省端口就是 80, 所以用户输入地址时可以省略这个端口号, 也即只需这样: xiaogd.net, 而不是繁琐的像这样: xiaogd.net:80, 关于缺省端口的话题, 还是可以参考前面所提的 深入理解端口.

但过一段时间之后, 访问量可能上来了, 一个 tomcat 进程处理不过来, 那怎么办呢? 于是我打算再起一个新的 tomcat 进程, 但这样就面临一个问题, 只有一个 80 端口, 它已经被第一个 tomcat 进程占用, 如果还要再起另外一个, 则只能选用其它的端口, 比如 8080.

当使用另外一个端口时, 确实可以启动两个 tomcat 的进程, 但用户想访问到第二个 tomcat 进程的服务, 却要这样去访问: xiaogd.net:8080. 显然, 这样的方案是有问题的, 用户根本不知道 8080 端口上服务的存在, 就算你有办法告诉用户, 用户也可能不太理解, 用户同时也很怕麻烦的, 为啥要我输入一个冒号加 8080 呢?

此外, 就算有些用户愿意如你所说转向访问 8080 端口, 你还是不能很好的控制把访问量平均地分配在两个 tomcat 上, 毕竟这是用户随机决定的, 也许很多用户又突然涌过来了 8080 端口的应用上, 造成了这边的拥挤.

又或者只有很少的用户愿意听从你的劝告转到新的 8080 端口上, 访问还是集中在旧的 80 端口上的, 这样旧的应用上响应还是很缓慢, 而新的应用却因为没几个用户访问而显得空闲, 没有得到充分的使用.

那么, 在这种情况下, 反向代理的好处就体现出来了, 具体的操作是这样的, 让 Nginx 作为一个前置的反向代理, 监听在 80 端口上; 而第一个 tomcat 则躲到幕后, 同时它也不再监听 80 端口(需要让给 Nginx), 而改为监听一个其它没有被使用的端口, 比如 8081, 然后让 Nginx 转发请求给它处理.

当然了, 如果只有一个 tomcat, 配置大概是这样的:

location / {
    proxy_pass   http://127.0.0.1:8080;
}

请求处理的流程是这样的:

请求: browser -- [http] --> Nginx -- [http] --> tomcat
响应: browser

自然, 这种情形下反向代理似乎不太必要, 还加多了一个环节, 响应速度反而慢了.

但如果有两个 tomcat, 情况就不一样了, 此时就可以在 Nginx 这个反向代理的层面, 启用负载均衡的策略, 大概的配置如下:

http {
    upstream myapp1 {
        server 127.0.0.1:8080;
        server 127.0.0.1:8081;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

此时, 如果同时涌入了很多请求, Nginx 会把一半的请求交给 8080 端口上的 tomcat, 另一半的请求交给 8081 端口上的 tomcat, 如下图所示:

深入理解 http 反向代理（nginx）

对外来看, 所有请求还是 Nginx 来处理, 用户不需要去做选择, 也不需要知道什么 8080, 8081 端口上应用的存在, 他们还是继续访问原来的网址 xiaogd.net 即可, 无需做任何改变.

如果你在云上有好几台主机, 甚至还可以将其组成一个内网, 然后将 tomcat 部署在不同的主机上. 比如有三台主机的话, 一台运行 Nginx 监听 80 端口, 其余两台运行 tomcat, 分别监听 8080 和 8081 端口, 同时接受并处理 Nginx 反向代理过来的请求, 如下图所示:

如果两台 tomcat 主机的配置不同, 比如一台的性能更强劲些, 还可以调整负载的比例(即权重, weight), 让性能更强的一台承担更多的请求:

http {
    upstream myapp1 {
        server 192.168.0.20:8080 weight=3;
        server 192.168.0.21:8080 weight=2;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

如上配置 3:2 的权重比, 让其中一台承担 60% 的请求, 而另一台性能较差的则承担 40%, 也即每 5 个请求, 3 个会被转到 ip 为 20 的主机上, 2 个会转到 ip 为 21 的主机上.

自然, 有人可能还会有疑问, 所有请求都还是要经过 Nginx, 它能处理得过来吗? 答案是可以的, 因为它的功能仅仅是转发, 这就有点像美团外卖, 虽然它每天接受成千上万的人的点餐, 但它自己不需要去买菜, 洗菜, 切菜, 炒菜等, 它仅仅需要把订单交给饭店餐馆, 然后把它们做好的饭菜配送出去, 也即那些耗时的做饭过程都交给了饭店餐馆处理.

在这种反向代理的模式中, 同样的, 生成网页这个重任交到了隐藏在背后的 tomcat, 生成一个复杂的动态网页可能需要经过一些复杂的计算, 要查询数据库, 要拼凑各个页面组件, 可能会比较耗时, 但这些请求被两个 tomcat 应用并发地处理了, 因此响应的速度还是得到了保证, 而这些就是反向代理能给我们带来的好处.

总结

至此, 关于直接访问, (正向)代理以及反向代理就介绍完了, 最后总结下三种情形及与购物例子的比喻.

在直接访问的情形中, 浏览器直接访问了最终生成响应的服务器, 类似我们以厂家直销的方式从厂商购物, 如下图所示:

深入理解 http 反向代理（nginx）

在(正向)代理的情形中, 浏览器主动访问代理服务器, 通过它间接获取最终响应, 类似我们从商店购物, 而商店的物品又是从厂家购来的, 如下图所示:

深入理解 http 反向代理（nginx）

在反向代理的情形中, 从浏览器的角度看还是类似于直接访问, 但它的请求在服务端被透明的代理了. 类似于我们在网上从一个声称是厂家直销的"伪厂家"那里购物, 这个伪厂家实际还是把我们的订单转给了真正的厂家, 并从中拿了货给我们, 只是我们无从知道这一切幕后的交易, 如下图所示:

深入理解 http 反向代理（nginx）

在一个复杂的网络中, 浏览器的请求还可能先被正向代理了, 然后又被反向代理了, 如下图所示::

深入理解 http 反向代理（nginx）

关于 http 正向代理和反向代理就讲到这里.

标签: , , , 没有评论
   下一页

支持博主

了解慈善捐款计划

关于邵珠庆博客

文章标签

API GA Git Google Analytics HTML5 jquery JS Linux MySQL nginx PHP SaaS web 互联网 代码 使用 分析 创业 原理 命令 好东西 如何 工具 常用 开发 总结 技巧 技术 插件 数据 文件 方法 时间 架构 框架 汇总 百度 管理 系统 网站 网站分析 设计 详解 问题 阿里云

记事邵珠庆博客

1、Web前端网址导航
2、邵珠庆极客筛站
3、识别移动设备访问代码


最近文章

最近评论

博客日历

2025年7月
一 二 三 四 五 六 日
« 9月    
 123456
78910111213
14151617181920
21222324252627
28293031  

目录分类

文章归档

博客功能