在2017在线峰会——票选最美云上大数据暨大数据技术峰会上，来自上海云贝网络科技有限公司的 首席架构师-刘立兼 分享了基于阿里云产品，如何构建一个大数据系统，以及系统如何在实际的业务过程中帮助客户提升价值。他主要从客户价值、产品线、服务、数据中心、基础设施、数据采集服务六个方面进行了实践分享。
以下内容根据直播视频整理而成。
总体架构
上图是架构的总图，最上面的是客户价值的模型，它是为了说明我们如何基于阿里云来开发相应的产品和应用，最终在不同的商业过程中给客户提供价值。之下是五个产品线，其中包含了很多的产品模块。产品线之下是服务，属于比较中间的一层。从业务的角度来看，其实多个服务可以组合成产品线中的一个产品模块。从技术的角度看，服务具体就是指dubbo或edas的服务。服务之下主要是阿里云的产品套件，左边是数据中心，右边是服务所依赖的基础设施。最下层是数据采集的服务。
客户价值
根据客户价值来划分，左边涉及到成本，属于生产侧，右边涉及到收入，属于市场侧。按照大数据的观点来看，我们的主要客户是电商和零售。首先，我们使用的所有数据都是可积累的；其次，孤立的数据是没有用的，需要关联聚合在一起来使用。基于数加的平台，数据进行聚合变得并不难了。人工智能、深度学习可以使数据变得可被理解。如果企业把这些可以理解的数据放到一起做对于历史的回顾、对当前现状的分析、对未来的预测，那么这些数据就变成了企业的核心资产。所以数据是可以应用的：将数据应用在生产过程的方方面面，包括和上下游有关的整个供应链，那么数据就可以在生产侧提供竞争力；如果以客户为中心构建所有可以被理解的数据的话，就会形成以客户为中心的数据资产，它是可以使用在市场竞争层面的。所以，大数据从其原始数据的积累到生产和市场的竞争上来说，现在的基础设施是比较成熟的，最大的障碍反而是数据的积累、聚合。
产品线
主要有五个产品线。第一类是洞察产品线，包括报表、模板、数据可视化的大屏等。这些集合在一起主要是实现了数据的聚合、理解。所以其中有一个比较强的数据接入服务，可以把外部数据源（无论是哪种数据格式）接入，通过各种各样的算法进行理解。洞察产品线提供了客户的关键资源，最后反映到关键活动上去。
第二类是社交产品线。现在的电商和零售的客户属于终端类型的客户，客户和买家之间需要建立比较强的连接。社交产品线是维护客户关系的手段，由于很多的销售过程会在和客户的互动过程中默默地完成，所以从另外一个方面来说也可以是分销的渠道。
营销产品线包括复合营销、自动营销、多渠道营销等。其对于客户的价值也是很清楚的：首先通过大数据可以让客户更精细的去观察细分自己的客户，客户细分做的好又会提高分销渠道的利用率。营销产品线是触达客户的产品线，对于维持客户的关系也有很大的帮助。
客服在营销中占的比重是很大的，包括售前、售后等。客服产品线会改变客服的工作，原来客服的工作都是依赖于已有的客服系统或者线上平台的客服系统，这些系统其实更强调功能本身，并不在意客服本身能否沉淀数据。基于客服产品线，所有客服的行为数据都可以收集到。
协作产品线里面有一些日志、表格等东西。其主要解决关键活动、关键伙伴的问题。原来企业和合作伙伴的沟通比较低，协作产品线可以把自己的行为和合作伙伴关键的产生的数据化保存下来，可以产生更紧密的关联。
服务
数据分析服务强调的是数据的关联、统计、聚合以及算法的分析，里面是要做很多计算的。效果分析是基于营销结果的再次营销，对复合营销和自动营销有很大的支持。透视表可以实现自动报表，所有的报表都可以根据自己的需求产生。报告关联应用于统计基盘。
数据应用服务并不强调数据的转换，但是强调数据和人之间的关系，人会依赖数据应用的服务来决定自己的行为，而行为又可以沉淀到这些数据服务里面。会员筛选可以助力智能分析，推广管理支撑了互动服务模块。
数据中心
数据中心支持数据分析服务，数据中心和数据应用服务的关系是双向的。在数据TP部分，使用了关系型数据库集群、NoSql型存储集群。关系型数据库主要用的RDS+DRDS做shading来实现。需要注意的是不是所有的数据都是关系型数据，而且虽然阿里云有DRDS来做数据库的shading，但是数据库的shading要和业务有很强的关联性，要基于业务做分层。NoSql型存储集群左侧是结构比较弱的，右侧是结构比较强的。
数据加工部分，ETL工具主要用的是MaxCompute和数加的IDE，清晰的表现了数据加工的整个过程，做到了将设计和开发过程的统一。基于这两个工具做了很多数据加工的服务，比如回购周期、RFM等。
OLAP的数据库也有两种：离线报表数据库和实时分析数据库。离线数据库比较简单，但是对于数据探索的场景提供不了很好的支持。实时分析数据库中很重要的一个工具是数加的ADS。做数据的过程中会涉及到探索的场景，即分析出一部分内容需要根据内容做进一步的分析，过程一直循环下去，此场景是需要依靠实时的数据分析能力的。
上图是数据可视化分类，数据分析服务包括旋转、钻取等，可视化有多维、网络等。分析型服务是为了满足探索型场景的，数加现在的分析型数据库可以很大程度上满足这个需求，这就是数据分析服务和传统数据报表服务很大的区别。数加的ADS有一定的限制， 对于分区的要求很严格，但是已经提供了相当程度的灵活性。
左侧的数据分析引擎包括：公众趋势分析引擎（分析舆情）、推荐引擎、数据集成引擎（在做其他数据分析的时候把数据聚集在一起）。特点业务数据中心中，使用特点数据中心解决特定场景会事半功倍。
数据中心不止做了上述工作，它还提供了数据API供二次开发者、集成商、合作伙伴使用。除了数据层面，上层的服务也可以提供，客户可以直接调用底层的数据分析服务。
基础设施
基础设施主要有四个部分，分别满足技术上的三个需求：可靠性，安全性，可维护性。微服务中间件套件主要解决可靠性的问题，开发和运维套件解决了可维护性的问题，全链路安全套件对应安全性的需求。其中，微服务中间件套件是核心部分，所有的开发都是基于这些服务之上的。
微服务中间件是开发的根本，因为所有的产品都是基于服务化开发的。现在的市场有一半的规模性复制成分，也有一半的探索性成分。对于探索性成分来说，架构上最好要支持比较强的大的中台（核心的、通用的、基础的能力）和小的前台（根据客户的特定场景、特定需求的服务）的方式。微服务框架上的为EDAS，原来是用Double来做的，因为Double在运维监控上的能力比较弱，需要自己来实现整个服务拓扑的关系。下层依赖云服务器集群和可配置容器集群。目前主要是用云服务器集群，因为ECS支持可自定义镜像。分布式队列中有消息队列是很正常的，任务调度在分析类服务中则是比较常见的。
开发套件中，目前的日志记录主要是做日志的收集、聚合。阿里云云监控中可视化的日志内容不仅是开发人员可以看懂，最好的日志是带有语义的日志。在持续发布里可以集成自己的脚本使得技术人员提交代码的时候检查代码的格式风格、代码的静态质量检查也会自启动、最近提交人的责任也会更新。数据管理DMS最大的价值在于其诊断记录，对于没有DBA的团队来说非常有意义。
运维套件中的自动部署对于运维人员来说好处非常大，因为实际上有一部分的销售是基于线下的，而线下的销售对于部署是有一定需求的，把常见的部署方式提前建好，需要时就可以做到一键部署，可以降低人力投入。资源监控是指阿里云的云监控，优点是完善、所有的硬件指标都有，缺点是不能跟系统里的实际业务打通。业务监控主要提供了实时数据的聚合能力。
可靠性是通过微服务中间件套件来支持的，可维护性是通过开发套件和运维套件来支持的，安全性是通过全链路安全套件来支持的。其中，主要使用了web应用防御、移动应用防疫、服务器防护、内容安全。
数据采集服务
数据源来自于数据采集服务，其受到底层基础设施的支持，最终的出口是数据中心。从业务的方式来看，数据采集主要通过第三方自有平台、公共电商平台、公开信息平台进行的。
从技术方式来看数据源和同步之间的关系如上图所示。左侧是业务数据源，右侧是技术数据源（标准协议类数据源、文件类数据源、硬件数据）。采集方式抽象为两种：主动获得（API调用、爬虫、文件、协议）和被动推送（API推送、硬件端口、中间库）。数据采集有两种维度的数据转化：业务维度转化（从原始数据中把与业务有关维度的数据提取出来）、格式维度转化（把非数据化格式转为数据化格式）。