近年来互联网的新业形态快速涌现，互联网金融和金融大数据快速发展，对经济提质增效的促进作用不断凸显。全球知名咨询机构Gartner认为数字业务创新将是未来的新常态，专注于创新的企业将利用数据和技术帮助他们创造竞争优势、降低经营成本、完成业务转型。如今，阿里巴巴、腾讯、百度等数据研发应用企业开始引领数据产业的发展。同时越来越多的企业对智能决策的需求也快速增长，他们的数据科学家使用先进的数据准备和分析工具，在海量数据中取得了卓越的发现。同时政府和科研机构也高度关注大数据，在最近的五年中颁布了一系列促进大数据产业发展的规划和方案。当前，大数据已经成为推动经济社会发展的重要力量，同时也是解决民生问题的重要支撑。大数据技术值得每个企业和个人去深入了解。
大数据生态圈经过十余年的指数式发展，各种技术百花齐放，新技术迭代更新速度日益加快。暂且抛开各种眼花缭乱的新名词，大数据技术本质上解决的是5个核心问题。
（1）采集，海量的数据怎样快速批量的采集？
（2）存储，海量的数据怎样可靠的存储？
（3）计算，海量的数据怎样快速准确的计算？
（4）查询，海量的数据怎样准确有效的查询？
（5）挖掘，海量的数据怎样挖掘出隐藏的知识？
在10月19日的线上交流活动中，围绕着大数据平台建设及各个组件的使用等方面进行讨论，也得到了各位专家的支持，大家表现出非常大的热情，在此也对相关问题及大家的观点总结如下：

一、数据存储

典型问题：
Q1：使用开源版本的elastic存储日志数据时，存在哪些局限性?
Q2：使用HBase进行业务设计时需要注意哪些方面？
Q3：影像类等非结构化数据一般如何在大数据平台存储?
问题解答：
A1-1：
ES 2.3.0遇到的问题：
1、性能问题
（1）大量数据的集中导入会导致ES性能下降，例如，查询响应时间变长、建index等命令会超时。
（2）数据量大的时候，节点重启会需要很长时间初始化shards。
2、功能问题
（1）不能实时导入数据。
（2）有刷新间隔，最低1s。
（3）没有真正的数据更新及删除功能，重新导入数据document会删掉旧的重新插入，效率低。批量删除数据时，使用deletebyquery效率也很低。
（4）ES本身缺乏安全和权限方面的功能，但可以购买elastic公司的其他工具。
A1-2：
开源ES存在功能和性能两方面缺陷，尤其在企业级运维管理方面，存在缺乏用户权限管理机制和监控等功能，因此建议购买elastic公司的发行版本。elastic公司刚在美国市场上市，市值达到50亿美元，其在中国设有分公司，负责产品销售和技术支持。
A2-1：
HBase是基于Hdfs的分布式列式数据库，所有的查询和写入都以Rowkey作为基础。所以业务设计时最重要的是Rowkey设计，需要注意的有以下几点：
1） 常用查询字段放在Rowkey前面
2） 保证数据均匀散列
Rowkey设计不合理会导致数据倾斜，从而产生数据读写热点。
3） 保证数据唯一性
HBase写入时会根据Rowkey去重，所以Rowkey不唯一会导致数据丢失。
4） ColumnFamily不宜太多，会影响数据查询效率，可以采用多个Qualifier实现。
A3-1：
大数据平台中适合存放数据量极大，而且是一次写入，多次读的应用需求，存储在HDFS分布式文件系统，采用多副本机制保障数据的安全和可靠。
影像类数据包括视频数据和图像数据，非常适合存放在HDFS中，系统将影像类数据进行切分，按照128MB大小进行切分，然后对每个128MB的数据进行多副本进行备份，这样就可以将影像类数据按照数据块的方式存放在HDFS中了。
A3-2：
如果是图像文件，根据业务需求可使用不同存储方案。
（1）如果做在线内容服务，使用FastDFS、MogileFS等分布式文件系统。
（2）如果做图片存储备份，可以使用MongoDB，或者将大量图片压缩后保存在HDFS。HDFS更适合大文件的存储。

二、数据查询与分析

典型问题：
Q1：在使用spark计算引擎时，如何创建RDD？
Q2：如何对多维查询场景进行技术选型？
Q3：实时计算中，Spark Streaming和Storm适用的业务场景有什么不同？
问题解答：
A1-1：
主要有以下几种方法：
（1）通过parallelize方法从集合创建RDD：var rdd = sc.parallelize(1 to 10)
（2）通过textFile方法从本地文件或HDFS创建RDD：val rdd = sc.textFile("/filepath/file.txt")
（3）其他，如：通过jdbc读取关系型数据库创建jdbcRDD，使用hadoopFile、sequenceFile等方法创建RDD。
A1-2：
进行Spark核心编程的第一步就是创建一个初始的RDD。该RDD，通常就代表和包含了Spark应用程序的输入源数据。然后通过Spark Core提供的transformation算子，对该RDD进行转换，来获取其他的RDD。
Spark Core提供了三种创建RDD的方式：
1.使用程序中的集合创建RDD
List<Integer> numbers = Arrays.asList(1,2,3,4,5,6,7,8,9,10);
JavaRDD<Integer> numbersRDD = sc.parallelize(numbers);
2.使用本地文件创建RDD（主要用于临时性处理有大量数据的文件）
SparkSession spark = SparkSession.builder().master("local").appName("WordCountLocal").getOrCreate();
JavaRDD<String> lines = spark.read().textFile("D:\\Users\\Administrator\\Desktop\\spark.txt").javaRDD();
3.使用HDFS文件创建RDD（生产环境的常用方式）
SparkSession spark = SparkSession.builder().appName("WordCountCluster").getOrCreate();
JavaRDD<String> lines = spark.read().textFile("hdfs://h0:9000/spark.txt").javaRDD();
A2-1：
根据不同的业务场景，可以选择使用不同的技术。
（1）维度相对固定的离线数据查询，可用Kylin。Kylin支持标准SQL，通过预计算将数据转换成Cube，提供高效的多维查询。然而，预计算需要事先定义好表结构和查询模型，查询灵活性较低。
（2）维度更加灵活，并且需要支持实时数据查询是，可用Druid。但Druid不支持SQL查询，与报表系统对接的难度略高。
（3）如果需要高度灵活的自定义查询，可以用Spark SQL完成数据转换、聚合等计算，再将结果输出到报表系统。
A2-2：
多维查询场景需求越来越多，但合适的查询引擎却不太多，如HBase比较适合特定维度的查询， Hive和Spark比较偏重于离线分析场景，Impala在小数据量下进行多维查询效果还不错，但是在大数据量下效率大打折扣。可选的引擎并不多，经过实践经验，以下几种可以做个参考：
1） Kylin
Kylin采用预计算的方式实现多个Cube，多维查询语句经过解析后最终会落到某个Cube中查询，是典型的空间换时间的策略。这种方案的好处是基于Kylin的查询效率极高，缺点是需要定期构建，时效性较差。
2） Elasticsearch
Elasticsearch也是列式存储，核心原理是倒排索引，所以查询效率非常高，多维度查询性能损失并不是很大，缺点是SQL支持不好，官方在6.3后开始支持SQL，但是某些查询仍然受限。所以对于简单的多维度查询，使用Elasticsearch比较适合，而复杂的查询（如多表嵌套、字段的各种函数式处理）暂时还不太合适。
3） Druid
Druid的思路有点像Kylin Cube预计算和倒排索引两个思想的结合（Kylin底层使用HBase存储），查询效率也很不错。
以上几种方案不是多维查询中唯一的选择，也不是哪一种方案就一定适合所有的查询场景，最终还是要以数据实际情况选择合适的引擎。
A3：
Spark Streaming就好比商场的直梯，是有时间窗口和分批次的准实时计算
Storm就好比商场的扶梯，不分任何窗口和批次，对源源不断的数据进行实时计算
Spark主要是基于内存的计算，适合迭代式的计算
Storm实际应用过程中比Spark耗费内存严重

三、数据ETL

典型问题：
Q1：使用Spark Sql进行ETL数据抽取时如何保证Spark集群的高可用性？
Q2：使用kafka传输消息时，如何能确保consumer接受到的消息顺序与消息发送方保持一致？
Q3：如何及时发现多类数据在统一采集传输过程中的积压问题？
Q4：数据采集的工具有哪些，有哪些优缺点？分别适用什么应用场景？
问题解答：
A1-1：
spark分布式搭建方式大致分为三种：standalone、yarn、mesos。standalone是官方提供的一种集群方式，企业一般不使用。yarn集群方式在企业中应用是比较广泛的。mesos安装适合于超大型集群。
1、在使用spark sql作为etl抽取数据时，可通过程序逻辑将源表划分为多个数据段，对每个数据段分别建立spark sql数据etl任务，减小个别数据错误对整个etl任务的影响
2、建立spark sql etl抽取任务重复执行机制，出现错误后可以自动重试。
A2-1：
Kafka可保证在同一partition中的消息是有序的，producer把数据按照同一主键发到同一个partition即可。
A2-2：
如果需要确保consumer接受到的消息顺序与消息发送方保持一致，比如增删改等有顺序要求的操作，只能在topic中设置唯一一个partition，所有消息都使用同一个partition发送和接受。
A3-1：
（1）如果数据采集过程中使用Kafka进行传输，可使用Kafka Web Conslole、Kafka Manager和KafkaOffsetMonitor等工具查看生产者和消费者等流量、Topic的延时等信息。
（2）如果使用RabbitMQ作为消息队列，在RabbitMQ Web控制台中监测Unacked数据项。当该项数值大于0时，表示消息积压。
A3-2：
这一问题的出现有两类原因：
1） 网络瓶颈
当数据传输过程中某一线路出现瓶颈时，数据必然产生积压。
2） 传输节点问题
当网络正常时，某一传输节点出现问题时，数据也会产生积压。
上诉问题可统一使用生产者消费者模型解释，当生产大于消费时，必然产生积压，当消费出现问题时，也会产生积压。如何及时发现积压问题，以及是哪类数据产生了积压，比较好的方案是实时监控。在整个传输链条上的节点需要实时上报当前节点接收和消费每一类数据的情况（如数据量），上报中心收到数据后通过对比分析即可知道哪一类数据可能出现了积压，并及时通知相关人员排查解决。
上述策略在数据采集链路监控中应用非常广泛，像交通指挥大屏一样，效果较好。
A4-1：
数据采集是做大数据分析的第一环，也是非常重要的一环，为上层应用不断地提供数据养料。做大数据分析常用的数据来源包括以下几种：
1） 日志文件
2） 数据库
3） 网页
4） APP
不同的数据源使用的采集技术和工具是不同的：
1） 日志文件
日志文件常用的采集工具有Flume、Logstash、FileBeat等等。Flume和Logstash同属于采集框架，集成了很多插件，主要集中在source和sink两端，用户选择相应插件配置即可完成数据流转；支持用户基于框架做自定义开发，框架启动后会自动加载插件并驱动数据流转至该插件进行处理。但是两者都属于重量级框架，领域性不强，所以诞生了FileBeat工具，专门用于文件采集，该工具包非常轻巧，易于安装和使用，其特色功能--流量控制使得采集不会对宿主机产生较大压力。
2） 数据库
数据库数据同步常用的工具有Sqoop和Kettle。Sqoop是一个用于在Hadoop和关系数据库服务器之间传输数据的工具。它用于从关系数据库（如MySQL，Oracle）导入数据到Hadoop HDFS，并从Hadoop文件系统导出到关系数据库。以Mapreduce作为底层引擎，并行方式同步数据，效率较高。Kettle的优秀之处在于把ETL的过程可视化，数据的转换可以在界面上通过拖拽配置的方式实现，且支持二次开发，方便与大数据平台的集成。两者相比，Sqoop更注重同步，而Kettle更注重数据处理流程。
但两者属于批处理引擎，对数据库无法实时感知，无法满足做大数据实时处理的场景，所以现在有做数据库实时同步的工具。阿里的Canal可以通过读取mysql bin log实现数据的实时同步，也支持oracle部分版本的同步。
3） 网页和APP
网页和APP数据的采集技术一般采用埋点实现。开源的网页埋点工具有Piwik，只需在页面中嵌入一段js代码即可实现数据的采集和传输，后台支持插件开发，对于采集字段做额外处理，自带可视化展现工具，数据从采集到展示的时效性很高。APP埋点的开源工具较少，大部分都采用自研和商业化产品。
A4-2：
1、数据采集的工具主要分为面向结构化数据（关系数据库）、非结构化数据（设备日志）、半结构化数据（HTML网页），
2、同时还应该支持全库数据同步、增量数据同步（基于时间戳、触发器、更新标识等多种机制）
3、大数据环境下向结构化数据（采用Sqoop，关系数据库与非关系数据库之间的数据同步）、非结构化数据（flume）、半结构化数据（爬虫）
A4-3：
（1）日志采集：Logstash，可对数据进行复杂预处理。Flume，保证数据传输的一致性，部署复杂。
（2）Hadoop HDFS与数据库（MySQL）数据同步：Sqoop，部署复杂。
（3）结构化数据采集，如数据库、文件等：DataStage，高性能，简单易用，收费。Kettle，免费，性能较低。

四、数据平台监控与安全

典型问题：
Q1：金融机构如何确保大数据平台中的数据安全？
Q2：如何对Hadoop组件进行运行监控？
问题解答：
A1-1：
主要从管理方面入手：
（1）金融机构可根据ISO27001国际标准，建立信息安全管理体系、形成制度化的信息安全规范。同时需要遵循制度实施，确保与信息安全相关的资源、技术、管理等均处于受控状态。
（2）金融机构可根据内部网络区域中信息的敏感程度和功能，按不同的网络区域划分成不同安全级别。例如：核心业务区、支撑业务区、测试业务区等，各区域之间实施严格隔离。
（3）加强相关人员等数据安全培训。
A1-2：
可以参考已经发布和即将发布的国家标准、行业标准，以求全面考量确保金融机构大数据平台数据安全的策略。
1、国家标准
“现行”和“即将实施”的国家标准
“正在起草”、“征求意见”、“正在审查”和“正在批准”的国家标准
2、金融行业标准
已发布金融行业标准
“征求意见”和“正在审查”的金融行业标准
比如，《云计算技术金融应用规范 安全技术要求（征求意见稿）》。
3、信息安全标准
A1-3：
现在很多商用的大数据产品都已经考虑了数据安全性的问题，比如多租户的引入，确保合法用户才能使用对应的数据，并且也可以通过多租户划分来限定用户的资源使用范围。
A1-4：
1、大数据平台增加安全认证，所有接入均需要认证通过才可以访问。
2、进行多租户管理，资源做好控制
A1-5：
在管理方面：
1、建立平台用户权限管理制度，按照一事一建和用户权限最小化原则
2、建立平台运维、数据使用、数据管理三权分立的制度
在技术方面：
1、使用厂商发布的大数据平台产品，如华为、星环等
2、通过网络白名单严格控制网络访问关系
3、在开发测试期间，建立数据脱敏策略，严格适用脱敏后数据
A2：
Hadoop组件包括HIVE\HDFS\Hbase\HUE\sqoop\spark\zooie\ES\等进行进行，可以通过Cloudera的 manager来实现对组件的运行和监控和异常告警
cloudera manager有四大功能：
（1）管理：对集群进行管理，如添加、删除节点等操作。
（2）监控：监控集群的健康情况，对设置的各种指标和系统运行情况进行全面监控。
（3）诊断：对集群出现的问题进行诊断，对出现的问题给出建议解决方案。
（4）集成：对hadoop的多组件进行整合。

五、数据平台应用

典型问题：
Q1：Zookeeper业务应用有哪些？
Q2：营销风控会应用到哪些大数据技术及工具组件？主要遇到的问题有哪些？
Q3：精准营销会应用到哪些大数据技术及工具组件？主要遇到的问题有哪些？
Q4：用户画像会应用到哪些大数据技术及工具组件？应用过程中主要遇到的问题有哪些？

问题解答：
A1-1：
Zookeeper作为分布式服务协调组件，本身也是一个树型机构的文件系统，主要提供服务注册中心、分布式锁、选举机制等
A1-2：
ZooKeeper是一个高可用的分布式系统协调框架。基于对Paxos算法的实现，使该框架保证了分布式环境中数据的强一致性，也正是基于这样的特性，使得zookeeper能够应用于很多场景。场景包括：
1) Master选举（主备模式）
通过在Zookeeper上同一目录下创建临时节点，创建成功的应用自然就成了Master，其他应用就成了备节点，一旦主节点发生变化，临时节点消失，备节点会再次创建临时节点，如果创建成功，备节点即升为主节点。
2) 配置管理
所有程序都监听Zookeeper目录，如果该目录下产生新的配置信息，会触发监听程序获取最新配置。
3) 分布式锁
与Master选举一样，一次只能一个程序成功创建节点，所以达到了分布式锁的目的。
4) 消息订阅/通知
消息订阅的方式与配置管理一样，也是通过监听消息目录获取最新的消息。
A2：
（1）离线数据的营销风控聚合数据仓库中的结构化数据，通过SparkSQL进行多维度聚合计算，结果报表展示在Tableau。活动运营人员通过报表分析异常点，总结出营销反欺诈规则。离线规则由数据库实现，在线规则部署在Spark Streaming。
（2）算法同学利用Spark MLlib对营销数据进行建模分析，模型完善后可部署。
（3）问题在于营销欺诈行为进化迅速，已有规则和模型的有效性需要及时评估、优化、调整。
A3-1：
1、精准营销需要在构建用户画像和商品的画像的基础上，实现智能的推荐，推荐又分为基于用户画像（购买行为类似的用户商品推荐）和商品画像（购买商品相似度推荐）相结合实现精准的营销；
2、要建立用户画像，首先需要梳理画像的特征值（也就是多维度的数据信息），基础上给用户进行打标签（和实际业务相关）具体的分类（例如购买习惯、购买能力等）。
A3-2：
1、精准营销需要在构建用户画像和商品的画像的基础上，实现智能的推荐，推荐又分为基于用户画像（购买行为类似的用户商品推荐）和商品画像（购买商品相似度推荐）相结合实现精准的营销；
2、要建立用户画像，首先需要梳理画像的特征值（也就是多维度的数据信息），基础上给用户进行打标签（和实际业务相关）具体的分类（例如购买习惯、购买能力等）。
A3-3：
1、精准营销通过埋点的用户行为和产品属性，生成用户标签和产品标签，并对客户进行画像，建立个性化群组，实现智能推荐的行为。任务基本采用spark处理，各类数据存储于HDFS，ES,hbase，kudu。
2、主要问题即标签模型的建立，运维过程中任务调度的优化也极为关键，集群的优化和前端查询对于稳定的营销活动和用户体验至关重要。
A4：
1、用户画像主要整合了多方面数据以及相应的工具组件，包括： （1）用户人口信息、资产和交易等结构化数据，采用关系型数据库进行存储。 （2）用户APP行为等非结构化数据，采用Logstash采集，Hadoop HDFS存储。 （3）用户的关键统计信息导入至Elasticsearch，供前端系统进行快速查询。用户群的多维cube导入至Kylin供营销和分析人员查询。
2、用户行为数据量大但价值稀疏，如何从海量数据中挖掘出有价值的特征属性是用户画像遇到的主要问题。

六、数据平台建设

典型问题：
Q1：金融企业和互联网企业在大数据组件选型时面临的业务场景和功能需求有何不同？
Q2：流程性行业质量大数据选什么方案好？
Q3：大家浅谈下自己的大数据平台建设历程吧？

问题解答：
A1：
在金融企业中，大多建设了数据仓库储存核心系统中产生的大量结构化数据，使用大数据平台存储多为历史数据和非结构化数据；而互联网企业一般不使用数据仓库，将结构化和非结构化数据存储在大数据平台中。
在金融企业，受制于行业监管和信息安全等因素，对平台安全性、可管理运维性要求较高，而对成本相对考虑较少，而对于互联网企业，除满足业务需求外，平台建设成本是非常重要的因素。
A2：
1.如果是大数据项目，底层存储肯定不能用实时数据库+关系数据库这种架构，大数据底层必须是分布式架构，存储大多数都是采用HDFS分布式文件系统
2.但是像你说的生产中的温度、电流等实时的工艺参数，最开始一直都是采用SCADA实时采集PLC和各类传感器设备的数据，存放在实时数据库（例如GE）中
3.至于你说的压缩不压缩的，对于大数据不是大问题，现在的硬盘容量已经可以足够大，而且非常廉价，大数据采用PC服务器内的硬盘就可以做存储，压缩或是不压缩都没有太大的关系。
A3-1：
我说的是医院的集成平台，技术方面没啥好说的，先期销售都谈明白了，配合干就完了。建设方面有技术参数和合同，咋的也不能偏离太多。这项目太大，工期太长，世道太险恶，绝对不能介入太深，若即若离，有条件请监理是最好的，及时抽身，千万别背锅。
A3-2：
大数据平台技术上不成问题，但对于传统制造业应用场景不好定义，最怕钱投出去上层看不到成果，这是最担心的。
A3-3：
我们在尝试自己开发平台建设，为生产经营提供关键数据支撑，及时掌握生产实际情况，力争数据不落地。