精华内容
参与话题
问答
  • 技术栈

    千次阅读 2019-10-22 19:47:35
    整个后台技术栈我的理解包括 4 个层面的内容: 语言:用了哪些开发语言,如:C++/Java/Go/PHP/Python/Ruby 等等; 组件:用了哪些组件,如:MQ 组件,数据库组件等等; 流程:怎样的流程和规范,如:...

    整个后台技术栈我的理解包括 4 个层面的内容:

    • 语言:用了哪些开发语言,如:C++/Java/Go/PHP/Python/Ruby 等等;

    • 组件:用了哪些组件,如:MQ 组件,数据库组件等等;

    • 流程:怎样的流程和规范,如:开发流程,项目流程,发布流程,监控告警流程,代码规范等等;

    • 系统:系统化建设,上面的流程需要有系统来保证,如:规范发布流程的发布系统,代码管理系统等等;

    各系统组件选型

    1、项目管理/Bug管理/问题管理

    项目管理软件是整个业务的需求,问题,流程等等的集中地,大家的跨部门沟通协同大多依赖于项目管理工具。有一些 SaaS 的项目管理服务可以使用,但是很多时间不满足需求,此时我们可以选择一些开源的项目,这些项目本身有一定的定制能力,有丰富的插件可以使用,一般的创业公司需求基本上都能得到满足,常用的项目如下:

    • Redmine:用 Ruby 开发的,有较多的插件可以使用,能自定义字段,集成了项目管理,Bug 问题跟踪,WIKI 等功能,不过好多插件 N 年没有更新了;

    • Phabricator:用 PHP 开发的,Facebook 之前的内部工具,开发这工具的哥们离职后自己搞了一个公司专门做这个软件,集成了代码托管, Code Review,任务管理,文档管理,问题跟踪等功能,强烈推荐较敏捷的团队使用;

    • Jira:用 Java 开发的,有用户故事,task 拆分,燃尽图等等,可以做项目管理,也可以应用于跨部门沟通场景,较强大;

    • 悟空 CRM :这个不是项目管理,这个是客户管理,之所以在这里提出来,是因为在 To B 的创业公司里面,往往是以客户为核心来做事情的,可以将项目管理和问题跟进的在悟空 CRM 上面来做,他的开源版本已经基本实现了 CR< 的核心 功能,还带有一个任务管理功能,用于问题跟进,不过用这个的话,还是需要另一个项目管理的软件协助,顺便说一嘴,这个系统的代码写得很难维护,只能适用于客户规模小(1万以内)时。

    2、DNS

    DNS 是一个很通用的服务,创业公司基本上选择一个合适的云厂商就行了,国内主要是两家:

    • 阿里万网:阿里 2014 年收购了万网,整合了其域名服务,最终形成了现在的阿里万网,其中就包含 DNS 这块的服务;

    • 腾讯 DNSPod:腾讯 2012 年以 4000 万收购 DNSPod 100% 股份,主要提供域名解析和一些防护功能;

    • 如果你的业务是在国内,主要就是这两家,选 一个就好,像今日头条这样的企业用的也是 DNSPod 的服务,除非一些特殊的原因才需要自建,比如一些 CDN 厂商,或者对区域有特殊限制的。要实惠一点用阿里最便宜的基础版就好了,要成功率高一些,还是用 DNSPod 的贵的那种。

    在国外还是选择亚马逊吧,阿里的 DNS 服务只有在日本和美国有节点,东南亚最近才开始部点, DNSPod 也只有美国和日本,像一些出海的企业,其选择的云服务基本都是亚马逊。

    如果是线上产品,DNS 强烈建议用付费版,阿里的那几十块钱的付费版基本可以满足需求。如果还需要一些按省份或按区域调试的逻辑,则需要加钱,一年也就几百块,省钱省力。

    如果是国外,优先选择亚马逊,如果需要国内外互通并且有自己的 APP 的话,建议还是自己实现一些容灾逻辑或者智能调度,因为没有一个现成的 DNS 服务能同时较好的满足国内外场景,或者用多个域名,不同的域名走不同的 DNS 。

    3、LB(负载均衡)

    LB(负载均衡)是一个通用服务,一般云厂商的 LB 服务基本都会如下功能:

    • 支持四层协议请求(包括 TCP、UDP 协议);

    • 支持七层协议请求(包括 HTTP、HTTPS 协议);

    • 集中化的证书管理系统支持 HTTPS 协议;

    • 健康检查;

    如果你线上的服务机器都是用的云服务,并且是在同一个云服务商的话,可以直接使用云服务商提供的 LB 服务,如阿里云的 SLB,腾讯云的 CLB,亚马逊的 ELB 等等。如果是自建机房基本都是 LVS + Nginx。

    4、CDN

    CDN 现在已经是一个很红很红的市场,基本上只能挣一些辛苦钱,都是贴着成本在卖。国内以网宿为龙头,他们家占据整个国内市场份额的 40% 以上,后面就是腾讯,阿里。网宿有很大一部分是因为直播的兴起而崛起。

    国外,Amazon 和 Akamai 合起来占比大概在 50%,曾经的国际市场老大 Akamai 拥有全球超一半的份额,在 Amazon CDN入局后,份额跌去了将近 20%,众多中小企业都转向后者,Akamai 也是无能为力。

    国内出海的 CDN 厂商,更多的是为国内的出海企业服务,三家大一点的 CDN 服务商里面也就网宿的节点多一些,但是也多不了多少。阿里和腾讯还处于前期阶段,仅少部分国家有节点。

    就创业公司来说,CDN 用腾讯云或阿里云即可,其相关系统较完善,能轻松接入,网宿在系统支持层面相对较弱一些,而且还贵一些。并且,当流量上来后,CDN 不能只用一家,需要用多家,不同的 CDN 在全国的节点覆盖不一样,而且针对不同的客户云厂商内部有些区分客户集群,并不是全节点覆盖(但有些云厂商说自己是全网节点),除了节点覆盖的问题,多 CDN 也在一定程度上起到容灾的作用。

    5、RPC 框架

    维基百科对 RPC 的定义是:远程过程调用(Remote Procedure Call,RPC)是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序,而程序员无需额外地为这个交互作用编程。

    通俗来讲,一个完整的 RPC 调用过程,就是 Server 端实现了一个函数,客户端使用 RPC 框架提供的接口,调用这个函数的实现,并获取返回值的过程。

    业界 RPC 框架大致分为两大流派,一种侧重跨语言调用,另一种是偏重服务治理。

    跨语言调用型的 RPC 框架有 Thrift、gRPC、Hessian、Hprose 等。这类 RPC 框架侧重于服务的跨语言调用,能够支持大部分的语言进行语言无关的调用,非常适合多语言调用场景。但这类框架没有服务发现相关机制,实际使用时需要代理层进行请求转发和负载均衡策略控制。

    其中,gRPC 是 Google 开发的高性能、通用的开源 RPC 框架,其由 Google 主要面向移动应用开发并基于 HTTP/2 协议标准而设计,基于 ProtoBuf(Protocol Buffers)序列化协议开发,且支持众多开发语言。本身它不是分布式的,所以要实现框架的功能需要进一步的开发。

    Hprose(High Performance Remote Object Service Engine)是一个 MIT 开源许可的新型轻量级跨语言跨平台的面向对象的高性能远程动态通讯中间件。

    服务治理型的 RPC 框架的特点是功能丰富,提供高性能的远程调用、服务发现及服务治理能力,适用于大型服务的服务解耦及服务治理,对于特定语言(Java)的项目可以实现透明化接入。缺点是语言耦合度较高,跨语言支持难度较大。国内常见的冶理型 RPC 框架如下:

    • Dubbo:Dubbo 是阿里巴巴公司开源的一个 Java 高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 Spring 框架无缝集成。当年在淘宝内部,Dubbo 由于跟淘宝另一个类似的框架 HSF 有竞争关系,导致 Dubbo 团队解散,最近又活过来了,有专职同学投入。

    • DubboX:DubboX 是由当当在基于 Dubbo 框架扩展的一个 RPC 框架,支持 REST 风格的远程调用、Kryo/FST 序列化,增加了一些新的feature。Motan:Motan 是新浪微博开源的一个 Java 框架。它诞生的比较晚,起于 2013 年,2016 年 5 月开源。Motan 在微博平台中已经广泛应用,每天为数百个服务完成近千亿次的调用。

    • rpcx:rpcx 是一个类似阿里巴巴 Dubbo 和微博 Motan 的分布式的 RPC 服务框架,基于 Golang net/rpc 实现。但是 rpcx 基本只有一个人在维护,没有完善的社区,使用前要慎重,之前做 Golang 的 RPC 选型时也有考虑这个,最终还是放弃了,选择了 gRPC,如果想自己自研一个 RPC 框架,可以参考学习一下。

    6、名字发现/服务发现

    名字发现和服务发现分为两种模式,一个是客户端发现模式,一种是服务端发现模式。

    框架中常用的服务发现是客户端发现模式。

    所谓服务端发现模式是指客户端通过一个负载均衡器向服务发送请求,负载均衡器查询服务注册表并把请求路由到一台可用的服务实例上。现在常用的负载均衡器都是此类模式,常用于微服务中。

    所有的名字发现和服务发现都要依赖于一个可用性非常高的服务注册表,业界常用的服务注册表有如下三个:

    • etcd,一个高可用、分布式、一致性、key-value 方式的存储,被用在分享配置和服务发现中。两个著名的项目使用了它:Kubernetes 和 Cloud Foundry。

    • Consul,一个发现和配置服务的工具,为客户端注册和发现服务提供了API,Consul还可以通过执行健康检查决定服务的可用性。

    • Apache ZooKeeper,是一个广泛使用、高性能的针对分布式应用的协调服务。Apache ZooKeeper 本来是 Hadoop 的子工程,现在已经是顶级工程了。

    除此之外也可以自己实现服务实现,或者用 Redis 也行,只是需要自己实现高可用性。

    7、关系数据库

    关系数据库分为两种,一种是传统关系数据,如 Oracle,MySQL,Maria,DB2,PostgreSQL 等等,另一种是 NewSQL,即至少要满足以下五点的新型关系数据库:

    1. 完整地支持 SQL,支持 JOIN / GROUP BY /子查询等复杂 SQL 查询。

    2. 支持传统数据标配的 ACID 事务,支持强隔离级别。

    3. 具有弹性伸缩的能力,扩容缩容对于业务层完全透明。

    4. 真正的高可用,异地多活、故障恢复的过程不需要人为的接入,系统能够自动地容灾和进行强一致的数据恢复。

    5. 具备一定的大数据分析能力。

    传统关系数据库用得最多的是 MySQL,成熟,稳定,一些基本的需求都能满足,在一定数据量级之前基本单机传统数据库都可以搞定,而且现在较多的开源系统都是基于 MySQL,开箱即用,再加上主从同步和前端缓存,百万 pv 的应用都可以搞定了。不过 CentOS 7 已经放弃了 MySQL,而改使用 MariaDB。MariaDB 数据库管理系统是 MySQ L的一个分支,主要由开源社区在维护,采用 GPL 授权许可。开发这个分支的原因之一是:甲骨文公司收购了 MySQL 后,有将 MySQL 闭源的潜在风险,因此社区采用分支的方式来避开这个风险。

    在 Google 发布了 F1: A Distributed SQL Database That Scales 和 Spanner: Google’s Globally-Distributed Databasa 之后,业界开始流行起 NewSQL。于是有了 CockroachDB,于是有了奇叔公司的 TiDB。国内已经有比较多的公司使用 TiDB,之前在创业公司时在大数据分析时已经开始应用 TiDB,当时应用的主要原因是 MySQL 要使用分库分表,逻辑开发比较复杂,扩展性不够。

    8、NoSQL

    NoSQL 顾名思义就是 Not-Only SQL,也有人说是 No – SQL,个人偏向于 Not-Only SQL,它并不是用来替代关系库,而是作为关系型数据库的补充而存在。

    常见 NoSQL 有4个类型:

    • 键值,适用于内容缓存,适合混合工作负载并发高扩展要求大的数据集,其优点是简单,查询速度快,缺点是缺少结构化数据,常见的有 Redis,Memcache,BerkeleyDB 和 Voldemort 等等;

    • 列式,以列簇式存储,将同一列数据存在一起,常见于分布式的文件系统,其中以 Hbase,Cassandra 为代表。Cassandra 多用于写多读少的场景,国内用得比较多的有 360,大概 1500 台机器的集群,国外大规模使用的公司比较多,如 eBay,Instagram,Apple 和沃尔玛等等;

    • 文档,数据存储方案非常适用承载大量不相关且结构差别很大的复杂信息。性能介于 kv 和关系数据库之间,它的灵感来于 lotus notes,常见的有 MongoDB,CouchDB 等等;

    • 图形,图形数据库擅长处理任何涉及关系的状况。社交网络,推荐系统等。专注于构建关系图谱,需要对整个图做计算才能得出结果,不容易做分布式的集群方案,常见的有 Neo4J,InfoGrid 等。

    除了以上4种类型,还有一些特种的数据库,如对象数据库,XML 数据库,这些都有针对性对某些存储类型做了优化的数据库。

    在实际应用场景中,何时使用关系数据库,何时使用 NoSQL,使用哪种类型的数据库,这是我们在做架构选型时一个非常重要的考量,甚至会影响整个架构的方案。

    9、消息中间件

    消息中间件在后台系统中是必不可少的一个组件,一般我们会在以下场景中使用消息中间件:

    • 异步处理:异步处理是使用消息中间件的一个主要原因,在工作中最常见的异步场景有用户注册成功后需要发送注册成功邮件、缓存过期时先返回老的数据,然后异步更新缓存、异步写日志等等;通过异步处理,可以减少主流程的等待响应时间,让非主流程或者非重要业务通过消息中间件做集中的异步处理。

    • 系统解耦:比如在电商系统中,当用户成功支付完成订单后,需要将支付结果给通知ERP系统、发票系统、WMS、推荐系统、搜索系统、风控系统等进行业务处理;这些业务处理不需要实时处理、不需要强一致,只需要最终一致性即可,因此可以通过消息中间件进行系统解耦。通过这种系统解耦还可以应对未来不明确的系统需求。

    • 削峰填谷:当系统遇到大流量时,监控图上会看到一个一个的山峰样的流量图,通过使用消息中间件将大流量的请求放入队列,通过消费者程序将队列中的处理请求慢慢消化,达到消峰填谷的效果。最典型的场景是秒杀系统,在电商的秒杀系统中下单服务往往会是系统的瓶颈,因为下单需要对库存等做数据库操作,需要保证强一致性,此时使用消息中间件进行下单排队和流控,让下单服务慢慢把队列中的单处理完,保护下单服务,以达到削峰填谷的作用。

    业界消息中间件是一个非常通用的东西,大家在做选型时有使用开源的,也有自己造轮子的,甚至有直接用 MySQL 或 Redis 做队列的,关键看是否满足你的需求,如果是使用开源的项目,以下的表格在选型时可以参考:

    以上图的纬度为:名字、成熟度、所属社区/公司、文档、授权方式、开发语言、支持的协议、客户端支持的语言、性能、持久化、事务、集群、负载均衡、管理界面、部署方式、评价。

    10、代码管理

    代码是互联网创业公司的命脉之一,代码管理很重要,常见的考量点包括两块:

    • 安全和权限管理,将代码放到内网并且对于关系公司命脉的核心代码做严格的代码控制和机器的物理隔离;

    • 代码管理工具,Git 作为代码管理的不二之选,你值得拥有。GitLab 是当今最火的开源 Git 托管服务端,没有之一,虽然有企业版,但是其社区版基本能满足我们大部分需求,结合 Gerrit 做 Code review,基本就完美了。当然 GitLab 也有代码对比,但没 Gerrit 直观。Gerrit 比 GitLab 提供了更好的代码检查界面与主线管理体验,更适合在对代码质量有高要求的文化下使用。

    11、持续集成

    持续集成简,称 CI(continuous integration),是一种软件开发实践,即团队开发成员经常集成他们的工作,每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。持续集成为研发流程提供了代码分支管理/比对、编译、检查、发布物输出等基础工作,为测试的覆盖率版本编译、生成等提供统一支持。

    业界免费的持续集成工具中系统我们有如下一些选择:

    • Jenkins:Java 写的有强大的插件机制,MIT 协议开源 (免费,定制化程度高,它可以在多台机器上进行分布式地构建和负载测试)。Jenkins 可以算是无所不能,基本没有 Jenkins 做不了的,无论从小型团队到大型团队 Jenkins 都可以搞定。不过如果要大规模使用,还是需要有人力来学习和维护。

    • TeamCity:TeamCity 与 Jenkins 相比使用更加友好,也是一个高度可定制化的平台。但是用的人多了,TeamCity就要收费了。

    • Strider:Strider 是一个开源的持续集成和部署平台,使用 Node.js 实现,存储使用的是 MongoDB,BSD 许可证,概念上类似 Travis 和Jenkins。

    • GitLab CI:从GitLab 8.0开始,GitLab CI 就已经集成在 GitLab,我们只要在项目中添加一个 .gitlab-ci.yml 文件,然后添加一个 Runner,即可进行持续集成。并且 GitLab 与 Docker 有着非常好的相互协作的能力。免费版与付费版本不同可以参见这里:https://about.gitlab.com/products/feature-comparison/。

    • Travis:Travis 和 GitHub 强关联;闭源代码使用 SaaS 还需考虑安全问题;不可定制;开源项目免费,其它收费。

    • Go:Go 是 ThoughtWorks 公司最新的 Cruise Control 的化身。除了 ThoughtWorks 提供的商业支持,Go 是免费的。它适用于 Windows,Mac 和各种 Linux 发行版。

    12、日志系统

    日志系统一般包括打日志,采集,中转,收集,存储,分析,呈现,搜索还有分发等。一些特殊的如染色,全链条跟踪或者监控都可能需要依赖于日志系统实现。日志系统的建设不仅仅是工具的建设,还有规范和组件的建设,最好一些基本的日志在框架和组件层面加就行了,比如全链接跟踪之类的。

    对于常规日志系统ELK能满足大部分的需求,ELK 包括如下组件:

    • ElasticSearch 是个开源分布式搜索引擎,它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本机制,RESTful 风格接口,多数据源,自动搜索负载等。

    • Logstash 是一个完全开源的工具,它可以对你的日志进行收集、分析,并将其存储供以后使用。

    • Kibana 是一个开源和免费的工具,它可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面,可以帮助汇总、分析和搜索重要数据日志。

    • Filebeat 已经完全替代了 Logstash-Forwarder 成为新一代的日志采集器,同时鉴于它轻量、安全等特点,越来越多人开始使用它。

    因为免费的 ELK 没有任何安全机制,所以这里使用了 Nginx 作反向代理,避免用户直接访问 Kibana 服务器。加上配置 Nginx 实现简单的用户认证,一定程度上提高安全性。另外,Nginx 本身具有负载均衡的作用,能够提高系统访问性能。ELK 架构如图4所示:

    对于有实时计算的需求,可以使用 Flume + Kafka + Storm + MySQL 方案,一 般架构如图 5 所示:

    其中:

    • Flume 是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的日志收集系统,支持在日志系统中定制各类数据发送方,用于收集数据;同时,Flume 提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力。

    • Kafka 是由 Apache 软件基金会开发的一个开源流处理平台,由 Scala 和 Java 编写。其本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”,它以可水平扩展和高吞吐率而被广泛使用。

    Kafka 追求的是高吞吐量、高负载,Flume 追求的是数据的多样性,二者结合起来简直完美。

    13、监控系统

    监控系统只包含与后台相关的,这里主要是两块,一个是操作系统层的监控,比如机器负载,IO,网络流量,CPU,内存等操作系统指标的监控。另一个是服务质量和业务质量的监控,比如服务的可用性,成功率,失败率,容量,QPS 等等。常见业务的监控系统先有操作系统层面的监控(这部分较成熟),然后扩展出其它监控,如 Zabbix,小米的 Open-Falcon,也有一出来就是两者都支持的,如 Prometheus。如果对业务监控要求比较高一些,在创业选型中建议可以优先考虑 Prometheus。这里有一个有趣的分布,如图6所示。

    亚洲区域使用 Zabbix 较多,而美洲和欧洲,以及澳大利亚使用 Prometheus 居多,换句话说,英文国家地区(发达国家?)使用 Prometheus 较多。

    Prometheus 是由 SoundCloud 开发的开源监控报警系统和时序列数据库(TSDB)。Prometheus 使用 Go 语言开发,是 Google BorgMon 监控系统的开源版本。相对于其它监控系统使用的 push 数据的方式,Prometheus 使用的是 pull 的方式,其架构如图 7 所示:

    如上图所示,Prometheus 包含的主要组件如下:

    • Prometheus Server 主要负责数据采集和存储,提供 PromQL 查询语言的支持。Server 通过配置文件、文本文件、ZooKeeper、Consul、DNS SRV Lookup 等方式指定抓取目标。根据这些目标会,Server 定时去抓取 metrics 数据,每个抓取目标需要暴露一个 http 服务的接口给它定时抓取。

    • 客户端 SDK:官方提供的客户端类库有 Go、Java、Scala、Python、Ruby,其他还有很多第三方开发的类库,支持 Nodejs、PHP、Erlang 等。

    • Push Gateway 支持临时性 Job 主动推送指标的中间网关。

    • Exporter Exporter 是 Prometheus 的一类数据采集组件的总称。它负责从目标处搜集数据,并将其转化为 Prometheus 支持的格式。与传统的数据采集组件不同的是,它并不向中央服务器发送数据,而是等待中央服务器主动前来抓取。Prometheus 提供多种类型的 Exporter 用于采集各种不同服务的运行状态。目前支持的有数据库、硬件、消息中间件、存储系统、HTTP 服务器、JMX 等。

    • Alertmanager:是一个单独的服务,可以支持 Prometheus 的查询语句,提供十分灵活的报警方式。

    • Prometheus HTTP API 的查询方式,自定义所需要的输出。

    • Grafana 是一套开源的分析监视平台,支持 Graphite,InfluxDB,OpenTSDB,Prometheus,Elasticsearch,CloudWatch 等数据源,其 UI 非常漂亮且高度定制化。

    创业公司选择 Prometheus + Grafana 的方案,再加上统一的服务框架(如 gRPC),可以满足大部分中小团队的监控需求。

    14、配置系统

    随着程序功能的日益复杂,程序的配置日益增多:各种功能的开关、降级开关,灰度开关,参数的配置、服务器的地址、数据库配置等等,除此之外,对后台程序配置的要求也越来越高:配置修改后实时生效,灰度发布,分环境、分用户,分集群管理配置,完善的权限、审核机制等等,在这样的大环境下,传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求,业界有如下两种方案:

    • 基于 zk 和 etcd,支持界面和 api ,用数据库来保存版本历史,预案,走审核流程,最后下发到 zk 或 etcd 这种有推送能力的存储里(服务注册本身也是用 zk 或 etcd,选型就一块了)。客户端都直接和 zk 或 etcd 打交道。至于灰度发布,各家不同,有一种实现是同时发布一个需要灰度的 IP 列表,客户端监听到配置节点变化时,对比一下自己是否属于该列表。PHP 这种无状态的语言和其他 zk/etcd 不支持的语言,只好自己在客户端的机器上起一个 Agent 来监听变化,再写到配置文件或共享内存,如 360 的 Qconf。

    • 基于运维自动化的配置文件的推送,审核流程,配置数据管理和方案一类似,下发时生成配置文件,基于运维自动化工具如 Puppet,Ansible 推送到每个客户端,而应用则定时重新读取这个外部的配置文件,灰度发布在下发配置时指定IP列表。

    创业公司前期不需要这种复杂,直接上 zk,弄一个界面管理 zk 的内容,记录一下所有人的操作日志,程序直连 zk,或者或者用 Qconf 等基于 zk 优化后的方案。

    15、发布系统/部署系统

    从软件生产的层面看,代码到最终服务的典型流程如图 8 所示:

    从上图中可以看出,从开发人员写下代码到服务最终用户是一个漫长过程,整体可以分成三个阶段:

    • 从代码(Code)到成品库(Artifact)这个阶段主要对开发人员的代码做持续构建并把构建产生的制品集中管理,是为部署系统准备输入内容的阶段。

    • 从制品到可运行服务 这个阶段主要完成制品部署到指定环境,是部署系统的最基本工作内容。

    • 从开发环境到最终生产环境 这个阶段主要完成一次变更在不同环境的迁移,是部署系统上线最终服务的核心能力。

    发布系统集成了制品管理,发布流程,权限控制,线上环境版本变更,灰度发布,线上服务回滚等几方面的内容,是开发人员工作结晶最终呈现的重要通道。开源的项目中没有完全满足的项目,如果只是 Web 类项目,Walle、Piplin 都是可用的,但是功能不太满足,创业初期可以集成 Jenkins + Gitlab + Walle(可以考虑两天时间完善一下),以上方案基本包括制品管理,发布流程,权限控制,线上环境版本变更,灰度发布(需要自己实现),线上服务回滚等功能。

    16、跳板机

    跳板机面对的是需求是要有一种能满足角色管理与授权审批、信息资源访问控制、操作记录和审计、系统变更和维护控制要求,并生成一些统计报表配合管理规范来不断提升IT内控的合规性,能对运维人员操作行为的进行控制和审计,对误操作、违规操作导致的操作事故,快速定位原因和责任人。其功能模块一般包括:帐户管理、认证管理、授权管理、审计管理等等。

    开源项目中,Jumpserver 能够实现跳板机常见需求,如授权、用户管理、服务器基本信息记录等,同时又可批量执行脚本等功能;其中录像回放、命令搜索、实时监控等特点,又能帮助运维人员回溯操作历史,方便查找操作痕迹,便于管理其他人员对服务器的操作控制。

    17、机器管理

    机器管理的工具选择的考量可以包含以下三个方面:

    1. 是否简单,是否需要每台机器部署 Agent(客户端)

    2. 语言的选择(Puppet/Chef vs Ansible/SaltStack )开源技术,不看官网不足以熟练,不懂源码不足以精通;Puppet、Chef 基于 Ruby 开发,Ansible、SaltStack 基于 Python 开发的

    3. 速度的选择(Ansible vs SaltStack)Ansible 基于 SSH 协议传输数据,SaltStack 使用消息队列 zeroMQ 传输数据;大规模并发的能力对于几十台-200 台规模的兄弟来讲,Ansible的性能也可接受,如果一次操作上千台,用 salt 好一些。

    一般创业公司选择 Ansible 能解决大部问题,其简单,不需要安装额外的客户端,可以从命令行来运行,不需要使用配置文件。至于比较复杂的任务,Ansible 配置通过名为 Playbook 的配置文件中的 YAML 语法来加以处理。Playbook 还可以使用模板来扩展其功能。

    创业公司的选择

    1、选择合适的语言

    • 选择团队熟悉的/能掌控的,创业公司人少事多,无太多冗余让研发团队熟悉新的语言,能快速上手,能快速出活,出了问题能快速解决的问题的语言才是好的选择。

    • 选择更现代一些的,这里的现代是指语言本身已经完成一些之前需要特殊处理的特性,比如内存管理,线程等等。

    • 选择开源轮子多的或者社区活跃度高的,这个原则是为了保证在开发过程中减少投入,有稳定可靠的轮子可以使用,遇到问题可以在网上快速搜索到答案。

    • 选择好招人的 一门合适的语言会让创业团队减少招聘的成本,快速招到合适的人。

    • 选择能让人有兴趣的 与上面一点相关,让人感兴趣,在后面留人时有用。

    2、选择合适的组件和云服务商

    • 选择靠谱的云服务商;

    • 选择云服务商的组件;

    • 选择成熟的开源组件,而不是最新出的组件;

    • 选择采用在一线互联网公司落地并且开源的,且在社区内形成良好口碑的产品;

    • 开源社区活跃度;

    选择靠谱的云服务商,其实这是一个伪命题,因为哪个服务商都不靠谱,他们所承诺的那些可用性问题基本上都会在你的身上发生,这里我们还是需要自己做一些工作,比如多服务商备份,如用 CDN,你一定不要只选一家,至少选两家,一个是灾备,保持后台切换的能力,另一个是多点覆盖,不同的服务商在 CDN 节点上的资源是不一样的。

    选择了云服务商以后,就会有很多的产品你可以选择了,比较存储,队列这些都会有现成的产品,这个时候就纠结了,是用呢?还是自己在云主机上搭呢?在这里我的建议是前期先用云服务商的,大了后再自己搞,这样会少掉很多运维的事情,但是这里要多了解一下云服务商的组件特性以及一些坑,比如他们内网会经常断开,他们升级也会闪断,所以在业务侧要做好容错和规避。

    关于开源组件,尽可能选择成熟的,成熟的组件经历了时间的考验,基本不会出大的问题,并且有成套的配套工具,出了问题在网上也可以很快的找到答案,你所遇到的坑基本上都有人踩过了。

    3、制定流程和规范

    • 制定开发的规范,代码及代码分支管理规范,关键性代码仅少数人有权限;

    • 制定发布流程规范,从发布系统落地;

    • 制定运维规范;

    • 制定数据库操作规范,收拢数据库操作权限;

    • 制定告警处理流程,做到告警有人看有人处理;

    • 制定汇报机制,晨会/周报;

    4、自研和选型合适的辅助系统

    所有的流程和规范都需要用系统来固化,否则就是空中楼阁,如何选择这些系统呢?参照上个章节咱们那些开源的,对比一下选择的语言,组件之类的,选择一个最合适的即可。

    比如项目管理的,看下自己是什么类型的公司,开发的节奏是怎样的,瀑布,敏捷的 按项目划分,还是按客户划分等等,平时是按项目组织还是按任务组织等等。

    比如日志系统,之前是打的文本,那么上一个 ELK,规范化一些日志组件,基本上很长一段时间内不用考虑日志系统的问题,最多拆分一下或者扩容一下。等到组织大了,自己搞一个日志系统。

    比如代码管理,项目管理系统这些都放内网,安全,在互联网公司来说,属于命脉了,命脉的东西还是放在别人拿不到或很难拿到的地方会比较靠谱一些。

    5、选择过程中需要思考的问题

    技术栈的选择有点像做出了某种承诺,在一定的时间内这种承诺没法改变,于是我们需要在选择的时候有一些思考。

    看前面内容,有一个词出现了三次,合适,选择是合适的,不是最好,也不是最新,是最合适,适合是针对当下,这种选择是最合适的吗?比如用 Go 这条线的东西,技术比较新,业界组件储备够吗?组织内的人员储备够吗?学习成本多少?写出来的东西能满足业务性能要求吗?能满足时间要求吗?

    向未来看一眼,在一年到三年内,我们需要做出改变吗?技术栈要做根本性的改变吗?如果组织发展很快,在 200 人,500 人时,现有的技术栈是否需要大动?

    创业过程中需要考虑成本,这里的成本不仅仅是花费多少钱,付出多少工资,有时更重要的是时间成本,很多业务在创业时大家拼的就是时间,就是一个时间窗,过了就没你什么事儿了。

    基于云的创业公司后台技术架构

    结合上面内容的考量,在对一个个系统和组件的做选型之后,以云服务为基础,一个创业公司的后台技术架构如图10所示:

    转自:https://mp.weixin.qq.com/s/rpc5Xqi_uCYZBjfebuIPvA

    ps:纯属学习记录

    展开全文
  • IT项目管理技术栈.xmindIT项目管理技术栈.xmindIT项目管理技术栈.xmindIT项目管理技术栈.xmindIT项目管理技术栈.xmindIT项目管理技术栈.xmindIT项目管理技术栈.xmindIT项目管理技术栈.xmindIT项目管理技术栈.xmindIT...
  • 2019前端技术栈梳理

    2019-09-23 15:43:03
    2019前端技术栈参考图 图中关于前端技术栈主要分为三个阶段: 1. 前端基本功HTML、CSS、JavaScript 2. 前端模块化、工具化 3. 前端的深入学习 比熊很赞同曹刘阳老师在2016年前端技术观察里提到的学好前端自己领域的...

    首先Mark住值得参考的资料

    1. 一个关于前端、后端和运维roadmap的网站
    2. 2016年前端技术观察

    2019前端技术栈参考图
    前端
    图中关于前端技术栈主要分为三个阶段:

    1. 前端基本功HTML、CSS、JavaScript
    2. 前端模块化、工具化
    3. 前端的深入学习

    比熊很赞同曹刘阳老师在2016年前端技术观察里提到的学好前端自己领域的知识,专一门,再去扩展其它领域知识。近几年前端技术更新速度惊人,导致初学者在学习过程中形似而神离,搞不清本质;所以小目标是在2019年结束前做一遍梳理,之后的文章会尽可能涉及到技术栈里的每部分内容。

    文章内容准确性和正确性上可能会出现偏差,望前辈指正。今后在不断深入的过程中也会对历史文章进行补充和修正。

    手工雪花酥,一个前端姑娘值得骄傲的副业

    展开全文
  • 内容涵盖目前火热的分布式微服务架构的全部技术栈,是高阶班微服务课程的升级版本。本教程由大牛老师操刀,对老版的五大技术做了升级加强和替换更新,对原有技术进行了更加深入的讲解,此外,引入了后起新秀Spring...
  • 【摘要】传统的以SQL为中心的技术栈无法有效地应对大数据场景带来的多元异构数据管理、大规模关系网络管理和复杂网络分析等挑战,本文针对新型大数据技术栈展开研究。通过分析图数据模型的优势,结合图技术的发展和...

    【摘要】传统的以SQL为中心的技术栈无法有效地应对大数据场景带来的多元异构数据管理、大规模关系网络管理和复杂网络分析等挑战,本文针对新型大数据技术栈展开研究。通过分析图数据模型的优势,结合图技术的发展和应用现状,提出以图为中心的新型大数据技术栈,该技术栈在生物数据网络、科技知识图谱等实际应用中得到较好的验证。尽管该技术栈的大面积推广还存在支撑工具不足、应用生态不够成熟等困难。但我们相信,以图为中心的新型大数据技术栈会在更多的大数据应用场景中发挥更大的价值。

    1 以SQL为中心的技术栈

      1969年,Codd提出关系模型(Relational Model),旨在以元组(Tuple)和关系(Relation)来表达和组织数据。遵循关系模型的数据库即关系数据库,或称为关系数据库管理系统(RDBMS)。1974年,IBM开始第一个关系数据库System R的研发;1979年,Oracle公司推出第一个商业数据库Oracle。随后,关系数据库得到迅猛发展,并逐渐成为主导的数据库类型,包括DB2、SAP Sybase、Informix等。

      RDBMS广泛应用于联机事务处理(OnLine Transaction Processing,OLTP)和联机分析处理(OnLine Analytical Processing,OLAP)的场景,OLAP系统一般以数据仓库(Data Warehouse,DW)作为基础,即从数据仓库中抽取详细数据的一个子集并经过必要的聚集存储到OLAP存储器中供前端分析工具读取。作为商业智能的关键部分,数据仓库主要用以数据的统计分析,可进一步区分为关系OLAP(Relational OLAP,ROLAP)、多维OLAP(Multidimensional OLAP,MOLAP)和混合型OLAP(Hybrid OLAP,HOLAP)三种类型。其中,ROLAP直接采用RDBMS存储;MOLAP则将OLAP分析所用到的多维数据存储为多维数组的形式,形成“数据立方体”的结构,底层仍以RDBMS为主,综合列式存储、内存数据管理等系统搭建而成。

      结构化查询语言(SQL)的提出和推广,促进了RDBMS以及数据仓库技术的广泛应用。几乎所有的RDBMS都提供了SQL语言的支持,另外,数据仓库经常借助ETL(Extract, Transform,Load)工具,如DataPipeline、Kettle、Talend、Informatica、DataX、Oracle oldenGate等,来实现多源数据的集成和转换,这个过程往往会借助于SQL语言完成。

      SQL语言在云计算和大数据时代仍占有重要地位,这方面的应用具体表现为三种形态:SQL on Hadoop、SQL over NoSQL以及Analytical SQL。

    01 SQL on Hadoop

      基于Hadoop/Spark构建的SQL引擎,如:Hadoop生态中的重要的Hive数据仓库系统,对内屏蔽了HDFS、HBase等存储的差异性,对外仅暴露了HiveQL语言作为查询语言;Spark中相应的模块为Spark SQL,它基于DataFrame和DataSet两个编程抽象,提供了分布式SQL查询引擎;第三方的SQL引擎如Impala,提供了SQL语义,能查询存储在Hadoop的HDFS和HBase中的PB级大数据。

    02 SQL over NoSQL

      针对NoSQL数据库对外暴露SQL查询接口,如:Apache Phoenix针对HBase封装了SQL化的操作接口;solr-sql实现了针对文档搜索引擎Solr的SQL接口;著名的SQL引擎Apache alcite则将SQL引入到流式数据的实时查询和分析;2006年,有学者提出CQL(Continuous Query Language)的概念,华为于2015年推出开源其流处理平台SQL引擎StreamCQL。作为华为FusionInsight大数据平台的重要组件,StreamCQL提供了在分布式流处理平台上的类SQL查询能力。

    03 Analytical SQL

      SQL语言不仅用于数据库的查询分析和ETL,还被扩展到更多数据分析的场合。多维分析的例子如Apache Kylin,基于HBase存储,通过采用预计算和分层立方体的方法实现了多维数据的统计和快速查询,其中统计的语言采用SQL,如图1所示。2018年,谷歌在BigQuery服务上推出BigQueryML,作为BigQuery功能的一部分,BigQueryML可以让数据科学家和分析师在大型的结构化或半结构化的数据集上构建和部署机器学习模型。另外一个例子是SQLFlow,SQLFlow的目标是将SQL引擎和AI引擎连接起来,仅需使用几行SQL代码即能描述整个应用或者产品背后的数据流和AI构造。其中所涉及的SQL引擎包括MySQL、Oracle、Hive、SparkSQL、Flink等,AI引擎包括TensorFlow、PyTorch等深度学习系统,也包括XGBoost、LibLinear、LibSVM等传统机器学习系统。

    图1 Apache Kylin提供SQL的多维统计接口

      可以看出,在过去50年的数据管理与分析技术的发展历史中,SQL及关系模型扮演着极其重要的角色。图2从模型、语言、关键技术、工具、场景、应用等层次展示出以SQL为中心的技术栈,信息系统一旦采用以SQL为中心的技术栈,就意味着具有更大的技术开放性、稳定性和可扩展性。

    图2 以SQL为中心的技术栈

    2 新型大数据技术栈的需求

      大数据技术和应用的迅猛发展,给占据主导地位的SQL技术栈带来了新的挑战,这些挑战主要包括:多元异构数据的融合管理、大规模关系网络的管理与复杂的网络分析需求。

    01 多元异构数据的融合管理需求

      大数据具备显著的4V特征,即:体量大(Volume)、多元性(Variety)、速度快(Velocity)、价值大(Value)。从多元性来看,除了结构化数据之外,大数据更多地体现为海量的文本、图像、音频、视频等类型的非结构化数据。有研究指出,在所有的数据中,非结构化数据占据到高达85%的比重。传统的RDBMS不能高效地管理多元异构数据,这些冲突主要体现在以下方面。

      1、RDBMS“先建模(Schema First)”的模式带来建模的不灵活性。

      2、传统架构很难支持水平扩展。

      3、SQL引擎所秉承的ACID(Atomicity, Consistency, Isolation, Durability)原则,成为实现轻型数据管理的沉重包袱。

      基于此,NoSQL的概念被提出。NoSQL数据库自发明之日起,就具备利于大数据存储的特性:无模式(schema-less)、可水平扩展的架构、更为宽松的BASE(Basically Available,Soft-state,Eventual Consistency)原则。通常认为NoSQL数据库包括4种类型,即KV数据库、列式数据库、文档数据库和图数据库。

      SQL/NoSQL/NewSQL技术虽然实现了对多元数据的管理,但数据的孤岛化问题仍然存在,各类数据管理系统之间还是存在明显的边界。基于此,业界推出了诸如Multi-model Database、Polystore等混合式数据管理系统架构,以及Lambda、Kappa等混搭式大数据架构,然而,这种混搭式的技术架构又大大增加了开发和运维的成本及难度。如图3所示,作为Polystore的一个典型实现系统,BigDAWG将数据划分为关系型数据区、数组区以及文本区,底层分别基于PostgreSQL、SciDB、Accumulo作为存储,这种架构要求开发人员掌握不同系统之间的Cast语法,并要求运维人员熟练掌握三类数据库系统,难度较大。

    图3 BigDAWG系统架构

    02 大规模关系网络的管理需求

      “关系”以及实体关系构成的“网络(Network)”广泛存在现实世界和信息世界,常见的网络包括社交网络、通信网络、Internet、道路网络、生物网络、学术资源网络等。以社交网络为例,随着移动互联网时代用户生成内容(UGC)的不断发展,用户可以随时随地在网络上分享内容,由此产生了海量的用户数据。社交网络中需要表达的要素除了人物、内容、事件之外,更多的是它们之间的复杂关系,如人物与人物之间的“关注”关系,人物与内容之间的“点赞”“评论” “转发”等各种关系。以Facebook和Twitter为例,庞大的社交网络中存在数以亿计的用户及用户间好友(关注)关系的数据。2006年以来,知识图谱应用的迅猛发展,更刺激了对大规模关系网络的管理需求。知识图谱本质上是一种叫作语义网络(Semantic Network)的知识库,即具有有向图结构的一个知识库。以学术领域为例,Springer Nature于2017年推出SciGraph关联开放数据平台,发布了科研资助机构、科研项目及拨款、会议、科研单位和出版物的信息,该平台计划累计15~20亿的三元组。另外,微软和清华大学推出了OAG,旨在整合全球学术知识图谱、公开共享学术图谱数据,并提供相关学术搜索和数据挖掘服务。截至2019年1月,OAG 2.0版本包含约7亿实体数据和约20亿实体之间的链接关系。表1列举出一些由SNAP和BigDND收录的关系网络数据集,可以看出,在大规模的网络或知识图谱中,“关系(边)”不仅成为很重要的要素,而且还会比“实体(顶点)”占据更大的比例。

    表1 关系网络数据集的数据规模示例

    03 复杂的网络分析需求

      在社交网络、通信网络、计算机网络、道路网络等场景,也存在较大的数据挖掘分析的需求,包括节点分析、结构分析、路径查找、网络演化分析等。

      以AMiner学术知识图谱为例,AMiner系统收集了7 900多万条论文信息、3 900多万条研究者信息,1.3亿论文引用关系、780万个知识实体以及3万多个学术会议/期刊的信息;AMiner同时提供了领域知识发展趋势可视化分析、人才专家排名与关系分析、引文溯源等功能。这些功能的实现建立在复杂网络分析的基础上,如根据学者之间的合作关系进行学者社区发现、根据论文引用网络对学术成果进行分类、根据引文网络结构对论文进行重要性排序等。

    利用网络生物学的方法对高通量基因表达数据进行分析和挖掘已经成为生物信息学重要的研究方向。目前人们已经对各种类型的分子生物网络进行了广泛的研究,如基因共表达网络(Gene Co-expression Network)、基因调控网络(Gene Regulatory Network)、蛋白质相互作用网络(Protein-protein Interaction Network)、代谢网络(Metabolic Network)等。针对科研人员这一类网络需要提供高效的在线分析功能,如针对全球开放生物资源、文献、序列和疾病等万种数据源100亿级关联数据的知识发现,需在秒级时间内实现6步以上关联挖掘。

      在金融领域,根据资金流动情况和账户、人员信息等信息进行金融风险预测,其相关技术在反洗钱、反欺诈应用中有较大需求。在流行病防控领域有根据人员社会关系,结合路径挖掘、节点重要度计算等技术追溯和预测疾病传播链,及早介入和切断传播路径的需求。在城市运营特别是轨道交通的规划与治理中,有大量站点和路径设计、人流量分析预测、轨道交通脆弱性分析等方面的需求。

      从这些场景中,可以看出,“关系”作为一种重要类型的数据,广泛地存在于各种场景中,甚至比原始的“表记录”数据具备更大的规模,上层应用需要针对庞大的关系网络进行关系查询、计算和挖掘。然而,传统的关系模型采用分表的形式组织数据,缺少对关系的原生支持,当涉及表间数据的关系查询时,计算效率会大幅度下降,这种劣势在大规模数据下表现得尤为明显。

    3以图为中心的新型大数据技术栈

      面对多元异构数据的融合管理、大规模关系网络的管理与复杂的网络分析需求,需要采取新的技术手段并构建新型的技术栈,这种技术栈应该具有如下特征。

      1、对信息世界的数据具有高度的表达能力,能很好地涵盖或映射到现有的SQL模型和NoSQL模型,如关系模型、KV模型、列式模型、文档模型、图模型。

      2、具备灵活的关系管理和关系计算分析的能力。

      3、要自成一体,软件栈自下而上保持简单自洽,而不是多种方法的混搭。

    01 图数据模型的优势

      图数据的基本类型是G=(V,E),V是图G的顶点集合,E是图G的边集合。图的边可以有方向,即当一张图是有向图时,对于任何的顶点u,v∈V,(u,v)≠(v,u)。

      与关系模型相比,图数据模型具备如下优势:

      1、表达直观:图数据模型首先将世界里的数据表达成顶点和关系,其次再定义顶点和关系具有它们的属性。

      2、结构灵活:图的schema不需要预先定义,可以动态调整图的结构,以及增减顶点、边的属性。

      3、原生支持关系:图数据模式天然地适合处理事物之间的关系。

      对于具有M个主键的A表和N个主键的B表,关系模型可借助中间关系表和Join操作来处理两表主键之间的关联关系,中间关系表的搜索空间是两表主键的笛卡尔积,即O(mn),对B表主键做了索引后,搜索空间可以优化为O(mlog(n));而在图数据模型里,主键(顶点)之间的关联关系被直接存储为边。实现这样的查询往往只需要O(m)的搜索空间:通过一个顶点,获取到它的边,是一个O(1)的操作。

      图模型具有超强的表达能力,可以将关系模型、KV模型、列式模型和文档模型通过一些映射方法,映射成图模型,映射如表2所示。

    表2 图数据模型对其他模型的表达能力

    02 图技术发展现状

      近十几年来,图模型及其关键技术,包括图数据库、图计算、图分析挖掘、图可视化等,得到了充分发展。

      近年来,数据库管理系统的发展趋势如图4所示。可以看出,图数据库的发展势头迅猛。比较主流的图数据库系统有Neo4j、OrientDB、JanusGraph、Cosmos DB、InfiniteGraph等。为了应对大规模数据的管理,通常会采用分布式架构、副本等机制实现存储和查询。例如,JanusGraph采用“分布式查询引擎+分布式存储引擎”的组合架构,其数据存储支持Cassandra、HBase、BerkeleyDB,索引存储支持Elasticsearch、Solr、Lucene。

    图4 图数据库发展趋势

      很多图数据库系统都具备实时数据的管理能力,如TigerGraph在单个项目上实现了千亿节点、万亿边的数据规模下,支持每天20亿次的数据查询和更新;与传统的静态图不同,时序图的结构会随时间序列发生改变,时序图相关的代表有TGraph、DeltaGraph等。

      分布式图处理系统可以按其基础模型分为两类,一是基于整体同步并行模型(Bulk Synchronous Parallel, BSP)的专用图数据处理系统,二是基于通用分布式系统(如MapReduce和Spark)的图处理系统。前者如谷歌的Pregel分布式图处理框架,后者如Spark的GraphX系统。它们均采用图的分布式或并行处理方法,即将图拆分成很多的子图,然后分别对这些子图进行计算,计算的时候可以分别迭代进行分阶段的计算,即对图进行并行计算。近年来图计算框架的发展历史如图5所示。

    图5 图计算框架发展历史

      典型的图算法有PageRank、Label Propagation、Random Walk等。典型的图挖掘任务有社区网络分析(社区发现/图分割、连通子图发现)、图分类、图聚类、频繁子图模式发现等。为了使用深度学习方法有效实现图挖掘,往往需要借助于图嵌入(Graph Embedding)和图神经网络(Graph Neural Network,GNN)技术。图嵌入技术包括DeepWalk、Text-Associated DeepWalk (TADW)、Discriminative Matrix Factorization(DMF)等;图神经网络包括图卷积神经网络(Graph Convolutional Network,GCN)和图注意力网络等。

      图比其他可视化展示形式更适合探索数据的内部关系,图的可视化分析包括图数据的基本统计、检索与映射、关系发现、结果展示等任务,典型的图可视化工具包括Gephi、Bloom、Pajek、WebVOWL、PGV(Paged Graph Visualization)等。在大规模图数据的场景下,通常采取层次化摘要、步进式交互探索等方式改善显示复杂等问题。RelFinder是基于RDF数据的交互式关系发现应用,通过SPARQL找到用户选择的元素在数据集中的映射对象,在得到数据集中的对象后,选定实体间的关系,将找到的关系展示给用户,用户可以控制搜索所得数据的可视化效果。

    03 图技术应用现状

      图模型及其技术在企业信息服务、互联网金融、生物医疗、公共安全等领域都有着深入的应用。

      在企业信息服务领域,图技术得到广泛的应用。例如,“天眼查”基于政府公开数据,包括工商数据、法律诉讼、新闻动态、企业年报等全量信息,在线提供全国包含2亿家社会实体、90余种数据维度的信息, 涵盖企业名称、机构类型、地域、经营状况、知识产权等信息,并提供了查人、查关系、查风险、查“老赖”、天眼地图、高级搜索等功能。

      金融行业拥有大量的专业数据,如公司、组织机构、个人的存贷款情况,以及征信和投资数据、交易记录、消费概况,可以通过图数据模型将所有实体的属性及关系全面呈现出来。蚂蚁金服研发的实时金融级分布式图数据库GeaBase已广泛应用于其生态体系中。当用户的金融操作出现异常状况时,可以通过个人特征的监控,操作的不一致性检测,异常状况的分析,发现隐藏其中的潜在风险,进行风险控制及反欺诈检测。在生物医疗领域,Chem2Bio2RDF Dashboard系统集成了化学、生物、药物领域的关联数据,用来发现两个实体或概念之间的路径;BioNav系统能够基于本体技术有效发现药物和疾病之间的潜在的关系。

      Krebs将图技术应用到犯罪分析,介绍了如何使用互联网上新闻源提供的公开数据来绘制隐蔽网络,并针对2001年9月11日的恐怖袭击事件进行研究。通过公开数据,以19个死亡的劫机者为中心,根据嫌疑人的联系人名单绘制形成美国9·11事件的恐怖分子网络,如图6所示。通过社会网络分析方法发掘网络图中更深层次的内在联系,相关的数据分析可以揭示出这个网络最核心的联系人、与其他成员联系最广泛的人、为两个彼此并不直接联系的成员提供联系纽带的人等,从而快速找出恐怖活动的幕后策划者。

    图6 恐怖分子网络

      此外,图技术还应用到城市人口流动分析、政治意识形态检测、公共健康等方面。

    04 以图为中心的新型大数据技术栈

      综上,图数据模型具备表达直观、结构灵活、关系管理高效等多种优势,图技术的发展日趋成熟完善,图技术的应用场景也越来越丰富。基于此,本文提出以图(而不是以SQL)为中心构建新型大数据技术栈的思路。该技术栈具备如下特征。

      1、满足软件栈的层次关系:即上层调用下层的服务。

      2、面向大数据场景:区分于传统的单机、关系型数据管理场景,充分考虑到大数据时代的数据湖、数据中台等需求,同时有效兼容Hadoop/Spark生态。

      3、以图为中心(Graph Centric):提倡采用“一张图”而不是“一堆表”来构建数据基础设施,同时提供系列基于图的数据管理、处理、分析方法。

      完整的技术栈包括模型、语言、关键技术、工具、场景、应用等几个层次,设计如图7。

    图7 以图为中心的新型大数据技术栈

      与传统的SQL技术栈相比,新型技术栈的特色组件包括:基于图模型的数据湖、图数据仓库、gETL、图数据中台。

      1、基于图模型的数据湖

      数据湖概念的提出,旨在为企业提供一个完整的存储库,用以存储原始的或初加工的数据,包括结构化数据(数据库表等)、半结构化数据(CSV、log、XML、JSON)和非结构化数据(邮件、文档、二进制图像、音频、视频等)。

      由于数据湖的多源异构特征,目前针对数据湖的管理往往采用一些混搭的架构完成,如采用分布式文件系统实现非结构化文档的存储、采用HDFS存储结构化和半结构化的数据。华为云基于“云存储+CarbonData”构建的新一代数据湖,实现了实时数据接入、DB数据同步、高性能查询和分析等能力,使云化数据湖可以真正成为企业数据架构的基础。AWS于2019年推出数据湖管理工具AWS Lake Formation,对数据进行撷取、清理、分类、转换以及保护的工作,方便后续分析或是机器学习使用。Databricks则将数据湖和数据仓库结合起来,形成LakeHouse方案,并推出Delta Lake。Delta Lake采用Bronze表、Silver表和Gold表三类表分别存储摄取数据、转换数据以及特征工程数据,并维护它们之间的流转,如图8所示。

    图8 数据湖管理系统Delta Lake

      本技术栈提出基于“一张图”而不是“一堆表”构建数据湖的思路,与传统方法相比,图数据模型可以管理跨域数据、结构化与非结构化数据之间的关系,同时还可以管理分级数据之间的血缘关系。

      2、图数据仓库

      与数据湖的用途不一样,数据仓库主要处理历史的、结构化的数据。传统的数据仓库很难实现跨数据集或数据域的处理,同时提供的分析服务以多维统计分析为主,包括钻取(Roll-up和Drill-down)、切片(Slice)、切块(Dice)以及旋转(Pivot)等多维操作。

      本技术栈提出图数据仓库的概念,提倡基于图模型和图技术构建数据仓库。与传统的数据仓库相比,在多维统计分析服务之外,图数据仓库更适合对图的要素进行统计,如实体统计、关系统计、社区发现、聚类等。图数据的统计同样具有不同的粒度,可以定义上卷(Roll-up)和下钻(Drill-down)等操作。

      ETL在数据仓库的构建过程中扮演着重要的角色,为了与传统的SQL ETL区分开,本技术栈提出gETL。gETL指针对图数据的抽取、转换和载入工作,包括从原始的结构化、非结构化文本中进行实体抽取、关系抽取和预测、实体消歧等。以抽取任务为例,gETL可以将CSV、JSON、XML、SQL等格式的多源数据,转换成“顶点-边”的图数据。

      3、图数据中台

      数据中台的概念最早由阿里巴巴提出,旨在通过企业内外部多源异构的数据采集、治理、建模、分析和应用,实现One Data(汇聚企业各种数据)、One ID(数据遵循相同的标准和统一标识)、One Service(提供统一的数据服务)的目标。

      在数据中台中,基于图模型及图技术可以更好地实现One Linked Data(汇聚并关联企业各种数据)、One Traceable ID(数据遵循相同标准和统一可追溯的标识)和One Graph Service(提供统一的图服务)。图可以表达数据之间的关联以及ETL过程中的数据血缘,从而实现数据资产中内容的关联化以及ID的可溯源。如图9所示,可以针对应用的需求定制“图谱服务”,如针对某类实体的画像、针对某两类实体的合作网络、跨实体间的路径发现等。图计算后台完成这些复杂任务的调度与执行,前端的图数据应用通过服务接口的调用,即可展示出相应的界面。

    图9 图数据中台

      考虑到图在语义网、开放数据、知识图谱等知识应用方面具有较大的价值。在模型层引入资源描述框架(RDF)模型,在工具层引入RDF数据库,数据中台可以基于RDF Graph构建富含语义的知识图谱。

      综上所述,与以SQL为中心的技术栈进行对比, 以图为中心的技术栈在数据库、数据湖、数据仓库、ETL、大数据中台的构建方面具备一些特色和优势,如表3所示。

    表3 以SQL、图为中心的技术栈之间的比较

     

    4 结 语

      自20世纪70年代起,关系模型及SQL语言统治数据管理与分析的世界已长达50年之久,从数据库到数据仓库,即便在大数据时代,它们仍然以SQL on Hadoop、SQL over NoSQL、Analytical SQL等多种形态展示出强大的生命力。本文在新的技术挑战和应用场景下,结合关系模型存在的不足和图数据模型的突出优势,提出基于图模型的数据湖、图数据仓库、gETL、图数据中台等思路,并继而提出以图为中心的新型大数据技术栈。

      与传统的SQL技术栈相比,以图为中心的大数据技术栈具备模型表达能力强、关系网络分析挖掘能力强等优势,可以有效地实现多元异构数据的融合管理、大规模关系网络的管理与复杂的网络分析。然而,作为一种新型的全套方案,以图为中心的技术栈无论是在图数据仓库、gETL、图数据中台等技术的成熟度方面,还是在完整的应用生态方面,与SQL技术栈还存在较大的差距。但随着技术与应用的不断深入,这些不足会逐渐得以克服,以图为中心的新型大数据技术栈终将在企业信息服务、互联网金融、生物医疗、公共安全等应用场景发挥更大的价值。

    注:本文为部分摘抄,原文地址:以图为中心的新型大数据技术栈研究 *

    参考文献:
    [1] E, F. Codd E F. Derivability, redundancy and consistency of relations stored in large data banks[J]. ACM SIGMOD Record, 2009, 38(1): 17-36..

    [2] Codd E F, Codd S B, Salley C T, et al. Providing OLAP (on-line analytical processing) to user-analysts: An IT mandate[J]. 1993.

    [3] the Kettle open source data integration project[EB/OL]. Home

    [4] Talend - A Cloud Data Integration Leader (modern ETL) [EB/OL]. Talend - A Cloud Data Integration Leader (modern ETL)

    [5] Enterprise Cloud Data Management | Informatica [EB/OL]. https://www.informatica.com/

    [6] 离线数据同步工具/平台DataX[EB/OL]. https://github.com/alibaba/DataX

    [7] Oracle GoldenGate-a comprehensive software package for real-time data integration and replication in heterogeneous IT environments. [EB/OL]. Oracle GoldenGate

    [8] Thusoo A, Sarma J S, Jain N, et al. Hive: a warehousing solution over a map-reduce framework[J]. Proceedings of the VLDB Endowment, 2009, 2(2): 1626-1629.

    [9] Kornacker M, Behm A, Bittorf V, et al. Impala: A Modern, Open-Source SQL Engine for Hadoop[C]//Cidr. 2015, 1: 9.

    [10] Akhtar S, Magham R. Pro Apache Phoenix: An SQL Driver for HBase[M]. Apress, 2016.

    [11] SQL interface for solr cloud[EB/OL]. bluejoe2008/solr-sql

    [12] Begoli E, Camacho-Rodríguez J, Hyde J, et al. Apache calcite: A foundational framework for optimized query processing over heterogeneous data sources[C]//Proceedings of the 2018 International Conference on Management of Data. 2018: 221-230.

    [13] Arasu A, Babu S, Widom J. The CQL continuous query language: semantic foundations and query execution[J]. The VLDB Journal, 2006, 15(2): 121-142.

    [14] Cai L, Chen J, Chen J, et al. Fusion insight librA: huawei's enterprise cloud data analytics platform[J]. Proceedings of the VLDB Endowment, 2018, 11(12): 1822-1834.

    [15] Apache Kylin | Analytical Data Warehouse for Big Data [EB/OL]. Apache Kylin | 大数据分析型数据仓库

    [16] Fernandes S, Bernardino J. What is bigquery?[C]//Proceedings of the 19th International Database Engineering & Applications Symposium. 2015: 202-203.

    [17] BigQuery ML[EB/OL]. https://cloud.google.com/bigquery-ml/docs/bigqueryml-intro

    [18] Wang Y, Yang Y, Zhu W, et al. SQLFlow: A Bridge between SQL and Machine Learning[J]. arXiv preprint arXiv:2001.06846, 2020.

    [19] Katal A, Wazid M, Goudar R H. Big data: issues, challenges, tools and good practices[C]//2013 Sixth international conference on contemporary computing (IC3). IEEE, 2013: 404-409.

    [20] Gaag A, Kohn A, Lindemann U. Function-based solution retrieval and semantic search in mechanical engineering[C]//DS 58-8: Proceedings of ICED 09, the 17th International Conference on Engineering Design, Vol. 8, Design Information and Knowledge, Palo Alto, CA, USA, 24.-27.08. 2009. 2009: 147-158.

    [21] Cattell R. Scalable SQL and NoSQL data stores[J]. ACM SIGMOD Record, 2010, 39(4):12-27.

    [22] Wang G, Tang J. The NoSQL principles and basic application of cassandra model[C]//Proc of InComputer Science & Service System (CSSS), 2012:1332-1335.

    [23] Eric B. CAP twelve years later: How the "rules" have changed[J]. Computer, 2012, 45(2): 23-29.

    [24] Lu J, Holubová I. Multi-model Data Management: What's New and What's Next?[C]//EDBT. 2017, 17: 602-605.

    [25] Kiran M, Murphy P, Monga I, et al. Lambda architecture for cost-effective batch and speed big data processing[C]//2015 IEEE International Conference on Big Data (Big Data). IEEE, 2015: 2785-2792.

    [26] Questioning the Lamba Architecture [EB/OL]. http://radar.oreilly.com/2014/07/questioning-the-lambdaarchitecture.html.

    [27] Duggan J, Elmore A J, Stonebraker M, et al. The bigdawg polystore system[J]. ACM Sigmod Record, 2015, 44(2): 11-16.

    [28] Kwak H, Lee C, Park H, et al. What is Twitter, a social network or a news media?[C]//Proceedings of the 19th international conference on World wide web. 2010: 591-600..

    [29] Lars Backstrom, Paolo Boldi, Marco Rosa, Johan Ugander, and Sebastiano Vigna. Four degrees of separation. In ACM Web Science 2012: Conference Proceedings, pages 45−54. ACM Press, 2012. Best paper award.

    [30] 漆桂林,高桓,吴天星.知识图谱研究进展[J].情报工程,2017,3(01):4-25.

    [31] SN SciGraph-A Linked Open Data platform for the scholarly domain[EB/OL]. SciGraph | For Researchers | Springer Nature

    [32] Zhang F, Liu X, Tang J, et al. OAG: Toward linking large-scale heterogeneous entity graphs[C] Proceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. 2019: 2585-2595

    [33] Stanford Large Network Dataset Collection. [EB/OL]. https://snap.stanford.edu/data/.

    [34] BigDND: Big Dynamic Network Data [EB/OL]. Dynamic Network Data

    [35] Tang J. AMiner: Toward understanding big scholar data[C] Proceedings of the ninth ACM international conference on web search and data mining. 2016: 467-467.

    [36] 汪涛,蒋庆华,彭佳杰,王亚东.基因共表达网络的构建及分析方法研究综述[J].智能计算机与应用,2014,4(06):47-50+53

    [37] 黎建辉,沈志宏,孟小峰. 科学大数据管理:概念、技术与系统. 计算机研究与发展[J]. 2017(2)

    [38] Liu Z, Chen C, Yang X, et al. Heterogeneous graph neural networks for malicious account detection[C] Proceedings of the 27th ACM International Conference on Information and Knowledge Management. 2018: 2077-2085.

    [39] Jin J G, Tang L C, Sun L, et al. Enhancing metro network resilience via localized integration with bus services[J]. Transportation Research, 2014, 63e(mar.):17-30.

    [40] Seriani S, Fernandez R. Planning guidelines for metro-bus interchanges by means of a pedestrian microsimulation model[J]. Transportation Planning & Technology, 2015, 38(5):569-583.

    [41] Huang Haixing,Song Jinghe,Lin Xuelian,et al.TGraph: A Temporal Graph Data Management System [C]?Proc of the 25th ACM Int on Conf on Information and Knowledge Management.New York:ACM,2016,2469-2472

    [42] Khurana U,Deshpande A.Eficient snapshot retrieval over historical graph data [C]?Proc of IEEE ICDE’13. Piscataway,NJ:IEEE,2013:997-1008.

    [43] DBMS popularity broken down by database model[EB/OL]. DB-Engines Ranking per database model category

    [44] Valiant L G. A bridging model for parallel computation[J]. Communications of the ACM, 1990, 33(8): 103-111.

    [45] Malewicz G, Austern MH, Bik AJ, Dehnert JC, Horn I, Leiser N, Czajkowski G.Pregel:A system for large-scale graph processing.In:Proc.of the 2010 ACM SIGMOD Int’l Conf.on Management of Data.ACM Press, 2010.135-146

    [46] 图计算框架回顾 [EB/OL]. 图计算框架回顾_wjlwangluo的博客-CSDN博客

    [47] Yan S, Xu D, Zhang B, et al. Graph embedding and extensions: A general framework for dimensionality reduction[J]. IEEE transactions on pattern analysis and machine intelligence, 2006, 29(1): 40-51.

    [48] Scarselli F, Gori M, Tsoi A C, et al. The graph neural network model[J]. IEEE Transactions on Neural Networks, 2008, 20(1): 61-80

    [49] Defferrard M, Bresson X, Vandergheynst P. Convolutional neural networks on graphs with fast localized spectral filtering. In: Proc. of the Advances in Neural Information Processing Systems (NIPS). 2016. 3844−3852.

    [50] Veličković P, Cucurull G, Casanova A, et al. Graph attention networks. In: Proc. of the Int’l Conf. on Learning Representations (ICLR). 2018.

    [51] Palmer S, Rock I. Rethinking Perceptual Organization: The Role of Uniform Connectedness[J]. Psychonomic Bulletin & Review, 1994, 1(1):29-55.

    [52] Lohmann S , Link V , Marbach E , et al. WebVOWL: Web-based Visualization of Ontologies.[J]. 2014.

    [53] L. Deligiannidis K K , A. Sheth ' D E . RDF data exploration and visualization[J]. 2007.

    [54] Heim P, Hellmann S, Lehmann J, et al. RelFinder: Revealing Relationships in RDF Knowledge Bases[C]// Proceedings of the 4th International Conference on Semantic and Digital Media Technologies. 2009: 182-187.

    [55] Fu Z, Wu Z, Li H, et al. GeaBase: a high-performance distributed graph database for industry-scale applications[J]. International Journal of High Performance Computing and Networking, 2019, 15(1-2): 12-21.

    [56] 田莉霞.知识图谱研究综述[J].软件,2020,41(04):67-71.

    [57] Dong X, Ding Y, Wang H, et al. Chem2Bio2RDF dashboard: Ranking semantic associations in systems chemical biology space[J]. Future of the Web in Collaboratice Science (FWCS), WWW, 2010.

    [58] María-Esther Vidal, Louiqa Raschid, Natalia Márquez, Jean Carlo Rivera and Edna Ruckhaus. BioNav: An Ontology-Based Framework to Discover Semantic Links in the Cloud of Linked Data. The Semantic Web: Research and Applications Lecture Notes in Computer Science, 2010(6089):441-445

    [59] Krebs V. Uncloaking terrorist networks[J]. First Monday, 2002, 7(4).

    [60] Zhuang C, Yuan N J, Song R, et al. Understanding people lifestyles: construction of urban movement knowledge graph from GPS trajectory[C]//Proceedings of the 26th International Joint Conference on Artificial Intelligence. AAAI Press, 2017: 3616-3623.

    [61] Chen W, Zhang X, Wang T, et al. Opinion-aware Knowledge Graph for Political Ideology Detection[C]//Proceedings of the 26th International Joint Conference on Artificial Intelligence. AAAI Press, 2017: 3647-3653.

    [62] Christakis N A, Fowler J H. The spread of obesity in a large social network over 32 years. New England Journal of Medicine, 2007,357 (4): 370-379

    [63] Fowler J H, Christakis N A. Dynamic spread of happiness in a large social network: Longitudinal analysis over 20 years in the framingham heart study. British Medical Journal, 2008,337: 1-9

    [64] Khine P P, Wang Z S. Data lake: a new ideology in big data era[C]//ITM Web of Conferences. EDP Sciences, 2018, 17: 03025.

    [65] Reliable Data Lakes at Scale. [EB/OL]. Delta Lake - Reliable Data Lakes at Scale

    [66] C. Chen, X. Yan, F. Zhu, J. Han and P. S. Yu, "Graph OLAP: Towards Online Analytical Processing on Graphs," 2008 Eighth IEEE International Conference on Data Mining, Pisa, 2008, pp. 103-112, doi: 10.1109/ICDM.2008.30.

    [67] 车品觉.建设数据中台,赋能创新改革[J].新经济导刊,2018(10):22-24.

    [68] Wu L, Sun Q, Desmeth P, et al. World Data Centre for Microorganisms: An Information Infrastructure to Explore and Utilize Preserved Microbial Strains Worldwide[J]. Nucleic Acids Research, 2017, 45(D1): D611-D618.

    [69] 沈志宏,姚畅,侯艳飞,吴林寰,李跃鹏.关联大数据管理技术:挑战、对策与实践[J].数据分析与知识发现,2018,2(01):9-20.

     

    引用格式:

    沈志宏,赵子豪,王海波. 以图为中心的新型大数据技术栈研究 *[J]. 数据分析与知识发现, 2020, 4(7): 50-65.

    Shen Zhihong,Zhao Zihao,Wang Haibo. Big Data Technology Stack Shifting: From SQL Centric to Graph Centric. Data Analysis and Knowledge Discovery, 2020, 4(7): 50-65.

    展开全文
  • 一、形成IT思想,把各种技术融会贯通,使用时按需对技术选型。 二、对于每个知识点,框架的掌握依次分为三层。 1.会使用 2.熟悉原理 3.了解源码 三、思维导图 转载于:...

     

    一、形成IT思想,把各种技术融会贯通,使用时按需对技术选型。

     

    二、对于每个知识点,框架的掌握依次分为三层。

    1.会使用

    2.熟悉原理

    3.了解源码

     

    三、思维导图

     

    转载于:https://www.cnblogs.com/panchanggui/p/9760346.html

    展开全文
  • Vue前端技术栈

    2019-10-31 17:16:28
    TIP 前端技术栈 ES6、vue、vuex、vue-router、vue-cli、axios、element-ui 后端技术栈SpringBoot、MyBatis、Spring Security、Jwt
  • 物联网开发技术栈

    万次阅读 多人点赞 2018-04-12 10:44:17
    作为互联网技术的进化,物联网开发并非孤立的技术栈,而是向上承接了互联网,向下统领了嵌入式硬件开发的一个承上启下的全栈开发技术。 虽然我们并不能预测物联网技术栈最终的样子:统一的开发语言是 JavaScript ...
  • Web前端技术栈(送VUE)

    千人学习 2019-08-06 11:56:48
    本课程讲解了VUE技术栈中的各种技术,可以让大家用最短的时间学习最实用的VUE技术栈。 此外,为了完整的掌握VUE课程,本课程赠送了独立的VUE课程。 通过本课程的学习,大家可以学习到VUE技术栈中的各种技术,...
  • 技术栈是什么鬼?

    万次阅读 多人点赞 2019-05-08 11:27:20
    技术栈是什么鬼? 栈的英文是stack 首先,我们使用金山词霸来查一下stack的中文解释 stack有堆起来的意思,其实就是堆叠,顾名思义,技术栈就是你掌握了一堆的技术(掌握多种技术) 一般来说是指将N种技术互相...
  • 术语-技术栈技术栈

    2019-09-26 05:59:26
    ylbtech-术语-IT术语-技术栈技术栈 1.返回顶部 1、 IT术语,某项工作或某个职位需要掌握的一系列技能组合的统称。technology stack 技术栈一般来说是指将N种技术互相组合在一起(N>...
  • Java技术栈

    2019-07-18 21:40:15
    Java技术栈 我要修仙!!!我要修仙!!!我要修仙!!!重要的事情说三遍! ...
  • java技术栈总结

    2018-11-19 00:00:44
    比较全的学习笔记;涉及内容:JVM、java集合源码、spring原理、netty、TCP网络、微服务、大数据组件:zookeeper-kafka-hbase等、大数据算法、设计模式、数据库及优化、机器学习等等
  • 大型项目技术栈第八讲 Redis

    万次阅读 2020-08-18 20:16:28
    Redis Redis简介 Redis安装 redis常用配置说明 Redis的键key Redis的值value(数据结构类型) Jedis连接redis服务器 spring整合redis ...Redis是一个开源的,使用ANSI C 编写,基于内存的且支持持久化,高性能的Key-...
  • 前端技术栈梳理

    2020-02-17 23:36:45
  • 我的技术栈

    千次阅读 2015-10-22 00:25:12
    Web前端 尽量使用响应式网页设计,这样就无需为移动用户单独开发额外的网站。 如果要针对移动用户开发 APP 建议使用轻量级的框架比如 Yahoo Pure CSS 。 使用 React 和 Flux 架构,不使用 AngularJS、EmberJS 和 ...
  • 大数据技术栈

    千次阅读 2018-09-02 17:36:28
    大数据技术栈全貌 下面自底向上介绍各个层的主要项目。 1 采集层和传输层 Sqoop 在hadoop和关系型数据库之间转换数据。 Flume Flume是一个分布式的高可用的数据收集、聚集和移动的工具。通常用于从...
  • 全栈必备的技术栈设想

    万次阅读 多人点赞 2016-11-20 09:53:11
    参加今年的SDCC确实挺高兴的,向大师Joe Armstrong 当面求教,与周爱民老师同台,在我们的架构师进阶之路专场有4个七零后的老码农,瞬间没有了孤独感,甚至有一点窃窃之喜,本人这次分享的内容是 全栈的技术栈, 是...
  • AI技术栈实践分析

    千次阅读 2019-04-12 14:55:59
    人工智能是让机器像人一样思考甚至超越人类,而机器学习是实现人工智能的一种方法,它最...下面是我从主流人工智能平台技术架构的五层模型来分析技术栈。五层分别是基础数据层,计算引擎层,分析引擎层,应用引擎层...

空空如也

1 2 3 4 5 ... 20
收藏数 24,052
精华内容 9,620
关键字:

技术栈