券商大数据平台架构设计实践以及人工智能应用探讨总结

当前，很多券商开始尝试利用大数据技术来实现业务创新、提高企业竞争力，例应用场景如客户画像、精准营销、智能投顾、运营优化等等，加强与客户全生命周期的互动。提升业务系统运营效率是目前券商运用大数据技术的主要切入点，遇到主要问题是如何建立统一采集、存储、计算和可视化的大数据平台。与此同时，随着券商大数据应用场景的拓展与深入，人工智能技术如何与大数据技术进一步结合推进如智能投顾新兴业务的发展也是当前券商大数据架构师、AI工程师关注的问题。

本次交流分享的内容主要包括三个方面：

• 研发大数据管理平台用于解决现有大数据平台用户、权限、任务管理分散的缺点
• 研发mophling用于统一公司内部数据源采集技术方案，保证实时高效地将数据推送给数据需求方

• 统一日志分析架构实践与分析应用
  欢迎各位同行各抒己见，提出问题并积极探讨，愿我们在大数据应用之路上并肩同行。本文整理了大数据平台安全管理及部分应用知识，仅供大家参考。

  问答锦集

  问题1：企业大数据环境下，由于缺乏统一的标准管理，如何进行安全的管理规范制度？

大数据生态圈至今没有统一的安全管理标准，虽然有不少专家和公司都在研究和推动标准规范的建立，但是实施和技术落地应该还有不少路要走。这并不妨碍我们建立公司内部统一的安全管理规范，而且相对于行业或者国家层面，公司内部的安全规范更容易实现一些。安全可以划分成几个类别：
1、物理隔离
这是整个系统最外层的保护，一般都是通过防火墙进行保护。
2、访问控制
通过防火墙的认证，下面就是系统的认证，这包括用户认证和权限认证，只有通过系统认证之后的用户才可以访问集群系统，另外还要有权限分配，一般用户不可能有任意的数据访问权限。
3、实时监控
用户一旦有权利进入系统，虽然有权限使用集群，但其行为也要受到系统的实时监控，比如提交了一个非常复杂的任务，可能对集群造成了影响；再比如不断尝试删除一个没有权限的数据。系统实时监控这些行为，对可疑行为目标锁定，并告知管理员及时处理。
4、行为审计
长期保存用户行为日志，以便发现异常用户后分析其行为特征。
5、数据加密
采用加密手段，保证存储和传输过程的数据安全性。

所有的技术手段都是为了使大数据集群变得更健壮，但是作为大数据集群的管理者，更加需要具备安全管理意识和行为规范，只有两者结合，才能建立起一个安全的大数据集群环境。

问题2：企业运营过程的日志中存在的有价值信息应该如何开发？

日志中包含着非常多有价值的信息，如系统运行状态、业务处理信息、用户行为等等，通过对日志内容的分析，将对系统运营、提升用户体验等方面提供很大帮助。主要的用途有：
1.实时监控，主要用于实时报警等。
2.内容分析，获取运营分析报告。
3.日志检索，主要用于问题排查。
日志内容分成结构化和非结构化信息，传统的技术处理过程复杂且没有效率，随着大数据技术的发展，预处理、存储和计算过程都变得非常便捷，现在比较成熟的技术框架有:
1.采集
成熟的日志采集框架有flume、logstash，但领域性不强，elastic官方推出的beat家族中有一款工具filebeat，专门用于文件采集，既能保证实时性，也能保证系统可靠性，同时具有流控等功能。我们基于flume实现了filebeat的功能，而且实现了对采集点的监管。
2.存储

日志内容可分类存储，结构化数据可存储在hdfs中，非结构化数据可存储在elasticsearch中，两者都具有非常强大的分布式存储能力。

3.计算
　　实时流处理框架有storm、sparkstreaming，离线分析框架有hive和spark、impala、kylin等。

问题3：大数据和云计算如何能有效的结合，能助力业务的发展，同时未来引领业务的创新

　　云计算可简单理解为一种提供虚拟化的主机、操作系统和软件服务的技术，用户不需要购买硬件，也不需要购买软件即可获得所需服务，而大数据技术一种用于处理海量数据的技术。两者之间本身并不关联，但实际上却可以通过相互关联，最大化的发挥数据的作用。主要的合作点应该有两处：
1.大数据技术使用云存储进行数据运算，集群管理者不用感知物理硬件的存在
2.云计算技术将大数据技术云化，形成“云服务”，对外提供大数据处理能力
　　通过两个技术的结合，数据能最大化的发挥价值，共享给各个使用者。但是这些都是业务创新的技术手段，并不是业务创新的来源，真正的业务创新还是要探索新的业务模式，实际业务中，往往有些技术虽是可行的，但是其业务模式并不被允许。

问题4：大数据如何跟现有的业务系统做融合才能真正发挥出实力？

中国工程院院士、中国互联网协会理事长邬贺铨院士在2017大数据产业峰会上表示：“数据资源的流动性和可获取性是大数据应用和产业发展的基础，直接关系到大数据价值的实现情况”，由此我们可以得出一个结论：数据的融合是重中之重。
对于企业来说，数据来源也是多种多样，如何将这些不同的数据统一汇聚在一个大平台当中，这需要相当的时间和精力才能完成。在这个过程中，etl技术将发挥重要的作用。
　　其次是数据挖掘技术的融合，相比较以前某个算法在某个数据集上跑出结果的方式不同，现在的数据集种类非常多，单一的算法已经不能满足数据的处理需求，所以，多个算法相互配合才能挖掘出数据的真正价值。

问题5：如何做好数据管理，解决数据血缘、主数据、元数据、和数据质量管理？

数据源来源于企业内部各种系统数据。由于大数据技术所处理的数据种类越来越多、数据量越来越大，数据管理这个概念被不断提及，显然这是个非常浩大的工程，主要的工作在于对企业数据的梳理及标准化，需要整个企业内部各个部门协调。我们曾经在某些系统上做过试点，确实也发现了很多系统元数据定义上的不规范，但是想让所有系统按照重新定义元数据和主数据，这是挺难的事情。如果要在大数据平台上建立统一的数据管理，要有以下几个步骤：
1、建立标准
主要包括元数据标准和主数据的标准，按照字段、字典、表这个层次分别制定标准。这个步骤需要对现有系统的元数据进行梳理，确定元数据标准，避免系统之间使用相同字段或字典但是含义完全不同的情况，同时对企业内部主数据进行统一的元数据定义，如部门、人员等信息。
3、按照标准形成元数据的血缘梳理以及数据质量管理
有了血缘关系，数据之间的关系就会一目了然，如表b的a'字段由a表的a字段衍生，而且有了标准，数据治理也就有了依据。
万事开头难，企业内部由上至下得达成共识，各方齐心协力，才有可能有效完成数据管理工作。

问题6：mophling支持的采集和分发方式有哪些？

现在均只支持流式数据，源端支持文件、数据库（支持mysql和oracle）、网页点击行为的实时采集，暂不支持文件直接put到集群中的方式。在采集之后全部数据在kafka缓存中，消费者可以将数据进行分发，分发的目的地包括oracle、mysql、hdfs、hbase等等。

问题7：大数据平台与传统数仓如何结合才能更贴合大数据应用？涉及系统定位，数据层次划分，数据标准的统一等

两个平台各有优势，具体的选择还是要根据实际应用场景，选择合适的平台，具体可参考：
1、数据量
对于小数据量的olap型分析，传统数仓有着较大优势，使用模式简单，一般均采用sql，稳定性也较高，但是数据量级数增长后，传统数仓的优势就没有那么明显了，这时可以考虑采用大数据技术实现。在大数据离线计算领域，hive、spark对于处理海量数据具有较大优势，在olap方面，现在也出现可kylin、druid等引擎，实时分析的响应速度非常快，缺点是对于标准sql的支持还不够完善。
2、数据计算复杂度
在传统数仓上做复杂算法运算，效率不会很高，这时可以考虑使用大数据计算工具，如spark和hive等。
3、数据处理需求
若存在实时性较高的数据需求，则考虑使用大数据相关技术，如storm或spark streaming等。

问题8：本方案中采用hdfs与hbase持久化，分别适用哪些场景？

hbase和hdfs的区别：
1、hbase支持更新，而hdfs文件不支持
2、hbase对于特定的查询场景，性能极高，但多维查询性能低，需全表扫描，而hdfs需要分目录存储，以便使用hive或impala的分区特性，多维查询性能较高
我们现在对于两者的权衡主要在于第一点，原因是我们现在对于业务库的采集是通过数据库日志获取的实时数据，如果该表存着更新的可能，我们会优先考虑将数据存在hbase中，如果数据绝对不会更新，我们会采用分目录的方式存储数据。使用hdfs文件存储的好处是，建立了hive或impala表后，多维度的查询性能要高于hbase的查询。两者的使用需要根据数据情况进行取舍。现在新产生了一种存储，kudu，是一种支持更新且以表结构存储和计算模型，可以在某种程度上统一hdfs和hbase两种存储，但是还需要进一步测试其稳定性和性能。

问题9：采用morphling（kafka为核心）进行数据库同步，相对于传统方案有哪些优势？

kafka是一种高吞吐量的分布式的消息缓存中间键，主要用于海量日志数据的存储，它的主要优势及场景有：

1、读写分离，将采集与数据消费分离，降低耦合性
2、数据安全性得到保证，kafka可以设置较长的保存周期，数据在周期内一直保存
3、数据可重复消费，若发现消费程序问题，待解决后可重复消费该数据
4、作为数据缓冲器，若采集数据量很多，尤其是交易时间，可有效缓冲数据，不会对后端造成绝大压力而崩溃
5、数据多份消费：有些数据可能会有多种应用处理需求，kafka可非常方便地满足这种需求

问题10：以kafka为枢纽搭建的数据采集框架，如何保障数据的顺序性？

我们现在的场景暂时还没有要求全局有序，大部分场景均要求按数据的key有序即可，如果要求全局有序，可以通过只设置一个parition来实现。

问题11：采集框架中是否应具备实时数据处理能力，在morphling中未来是否有引入流计算框架的打算？

已经在考虑且试验，使用kafka的一个原因就是因为storm、spark streaming等可以非常方便地接入进行计算，通过mophling可以很容易对流式框架数据处理过程进行监控。

问题12：es与solr的选型有哪些考虑？

es的设计很不错，底层通信采用netty，而且不依赖于zookeeper做leader选举，部署方便，使用方便，性能很高，这些方面我们认为比solr更有优势。es与hadoop平台的关系也很紧密，存储和查询都可以与hadoop平台对接，而且他的开放性非常好，可以方便地与其他组件结合和定制。

问题13：在大数据平台上面建设数据集市，在做etl开发时需要注意哪些问题吗？

etl过程关乎数据共享的效果，应当通过手段保证整个过程便捷和高效，在具体开发过程中应注意：

1、流控，不能对数据源机器或程序造成影响
2、可靠性，如断点续传
3、可用性，某一节点宕掉，不会导致数据无法传输
4、可管理，过程可以自动化监管

问题14：目前的大数据平台组件hive和hbase，在进行修改，删除等数据操作的时候比较困难，请问有没有好的解决方法？

hive是基于hdfs的直接文件存储，受hdfs文件更新的限制，hive一直无法很好地支持更新和删除操作，即使现在宣称支持更新，但是性能也比较低。hbase底层也是基于hdfs的存储，不过它通过设计有效避免了对hdfs的直接更新，通过regionserver进行写入和查询的控制，底层依然采用追加写入一个新文件的方式，只是在写入时多加了一个timestamp字段用于标识该条数据是最新状态；查询时由regionserver扫描storefile，通过比较取出最新的数据返回客户端。由于hdfs对文件操作的限制，基于hfds的系统，除了hbase之外，暂时没有更好地解决方案，cloudera公司开发的kudu，设计的初衷就是解决数据更新问题，底层存储并不在hdfs基础上，看起来是个不错的解决方案，我们也开始准备测试。