数据中台漫谈 — 数据接入

谈谈数据中台的大门口，数据接入系统，对应的领域是工业大数据，舆情大数据，

设计数据接入系统，首先不应该只局限于怎么将数据接入，而要根据整个中台的数据流向来综合考虑。

从数据中台的最终目标来看，数据中台的使命是实现价值数据流 抑或是为其他业务系统提供价值数据流。所以简单点来说，就是业务系统或者最终指标需要什么类型的数据，我就需要将这部分数据接入进来。但更深层次的问题在于，接入的数据是抽象的，是来源多样的。接入系统的设计就会和存储结构，也就是“接入”这部分的终点—数据湖有关。

所以湖的设计，应该是需要能基本hold住所有的类型或者结构的数据。但具体的湖的设计，放到对应的篇章再去细说，这里只是提一下。

另外一点就是最终价值的考虑，如果有明确的数据指标或者输出到业务系统的价值产物（比如提供给深度学习算法的训练样本）。那么就应该在数据接入时，考虑来源的数据的相关性策略，甚至于在接入阶段就能挡住一批无用数据。

下面就来谈谈具体的设计，根据各种业务和接入系统来看，接入类型可以大致分为五大类：

（一）文件导入

一般会为文件导入单独创建一个工程，作为文件导入子系统。因为这是最常见的接入类型，因为来源数据很可能是各类较为老旧的业务系统，这类业务系统只能通过导出数据或者人工记账的方式。excel是最常见的，所以这个子系统需要解析OFFICE的能力，POI相关的java开发包可以提供解析的方案。除了excel之外，可能也会有json或者csv。但是无论是什么格式的文件，数据都会是结构化或者文档型的。也就是说虽然数据在变，文件的结构也在变，但是可以根据表头来构建一套通用的解析方式。

这里的设计我做过的有两种方案。

第一种，是基于表头管理来进行解析，通过维护表头管理模块，使得用户可以手动在系统中增加修改对应的表头，也可以扩展定义多级表头。系统会根据用户定义好的表头信息，解析文件中的内容。excel就是解析指定表头行之后的数据，json就是解析对应的key，如果是多级表头就是解析多层嵌套的key，csv同理。解析完毕后再将数据与表头关联，这样就得到了源数据，就可以往数据湖中送了。

第二种，是基于模板来进行解析，将用户待导入的数据抽象为一份模板，模板定义好数据结构，比如excel模板就定义好这类数据的表头在第几行，数据在第几行。json就定义好结构是怎样的，结构有几层，等等。定义好之后，用户只需要上传这部分模板，之后就能按照模板的格式进行解析。但是这种模板的方式并不能完全hold住所有类型的数据，所以，这里还有插件的机制，也就是一段代码，用户方来编写这段代码，读取数据后通过暴露特定的接口来将数据通过插件进行特殊处理。这样的话就会比较灵活了。

两种方式各有优缺点，第一种方案对于用户方来说比较方便，不需要有代码的相关经验，也无需开发插件，系统还可以基于导入的历史表头对某一业务领域的表头关键字进行沉淀，开发自动表头识别，也就是不用为每次导入都配置特定的表头，对于一些比较标准的源数据文件，可以一键识别。第二种方案的使用对于一些会有重复导入，但是格式略有变化的场景就会不太方便。因为你需要针对每种业务场景去开发对应的插件和模板。需要用户方具有一定的开发能力。但是这种方案处理数据就更强大，几乎任何数据都能接入。

 

（二）接口调度

接口也是一种非常常见的接入方式。一般由外部系统提供。有时候就会遇到一些尴尬的问题，数据中台中有提供入湖的接口，但是源数据接口是外部系统提供的，不可能单独再针对这个接口在中台里面写一个接口入湖的程序吧，数据中台需要将入口和出口两个接口串起来。所以数据中台里就需要一套独立的调度系统。

调度系统会是一套独立的系统，它不单单是仅限于数据接入，而是横跨整个数据中台的辅助系统。这里我选择了开源的轻量级调度框架 xxl-job，当然也可以选择使用其他的方式自己实现，比如spring schedule等等。需要实现基本的时间调度功能，可以自定义的调度器，以及围绕调度过程的日志功能等等。

之后就可以利用调度系统来配置一些业务上的接口调度，比如两个接口间的相互调用，从指定位置读数据等等，因为调度器是可以自定义的（比如定时执行一段java代码），所以可以适配的场景也会比较多。

 

（三）各类ETL

这里主要讲的是rdb数据采集（mysql等），以及来自其他数仓数据源的采集（比如hive，hdfs）。该选择怎样的方案取决于实际的场景。比如 湖的架构采用的是hive，那么rdb的数据采集就可以使用sqoop来做。如果是hive到hive的流向，那么则可以利用hive的thrift接口来做数据传输，再使用我们之前完成的调度系统来调度。

上面的场景如果实际中还涉及到了一些复杂的逻辑，那么单纯的调度可能并不能满足我们的需求。这个时候就需要ETL编程。当然你可以使用现有的模块工具（比如sqoop等）加上调度系统自己写逻辑。但我想说的是，从代码层面来做通用逻辑是非常困难的，大部分的ETL编程你只能开发出一次性的代码，而且需要有足够的开发能力才能胜任。所以这里就推荐使用一些开源的ETL编程组件来做，比如kettle，DataX等。目前我使用的就是kettle，因为它所支持的数据集更广，且是图形化界面操作，数据流向更清晰，且基本无需任何的代码开发能力。

目前我主要使用kettle+调度系统来进行ETL，使用carte来搭建kettle集群运行环境，再利用kettle的spoon来图形化编写好的你的ETL流程，最后只需要将这个文件提交到carte，集群就会自动执行你的ETL逻辑。而通过调度系统可以保证ETL调度节点的时间性。而kettle日志收集加上调度系统的日志以及失败报警机制，可以保证ETL异常时，错误可追溯，并能及时进行处理。

如图是kettle的主页面，支持非常多的输出输入和转换操作，我觉得还是挺好用的。

 

（四）自动收集

最后一种场景也可能比较常见。也就是日志类数据的采集场景。这类场景需要区分为两种情况，实时和非实时。所谓实时日志采集，相信网上也有很多的方案可供选择。比较常见的就是flume(cloudera底层就是采用的这个架构)，flume可以直接定义逻辑之后采集到HDFS，也可以与kafka组合实现实时的日志数据采集。而应用数据采集的架构 ELK，也是比较常用的。通过logstash采集之后可以到es上做聚合，再通过调度系统来进行非实时的写入，也是可行的。

 

（五）实时数据

对于实时数据，数据湖一般会采用kafka来做存储。那么如果是外部的实时数据接入，例如kafka -> kafka，那么可以考虑spark streaming做消息的消费，清洗等操作 并转发到另一个kafka中。如果是非实时数据的接入，那么可以使用接口调度来实现。在数据中台中提供写入kafka的接口，并通过调度系统的配置来定时往kafka中写入数据，来达到一个“实时数据”的模拟。

 

以上总结了几种常见的数据接入场景。但针对数据中台的数据接入系统，设计还应该围绕数据安全和数据治理做进一步的详细设计。例如：
针对数据安全，应考虑在接入数据时做好数据隔离，导入平台的账户权限管控，调度接口的权限管控，kafka的topic权限管控，具体的这些都可以通过系统编码和开源组件（apache ranger）来实现。这个到数据安全篇我会再详细介绍。

针对数据治理，应考虑对于数据溯源，污染处理的设计。数据治理并不是一个模块亦或是一个组件就能搞定的事。目前没有任何一款开源产品可以说做到了100%的数据治理。数据治理需要在设计整个中台架构时就贯穿其中。对于数据接入这一步，那么就需要围绕每一批次数据的写入做好日志记录。对于写入的数据结构要能够有标识进行追踪，比如对于写入hbase的数据，那么每张hbase表的都会设计data_from和update_dt字段，用来记录数据来源和写入时间，同时会有一张单独的系统级的表（或者另一个集群）来记录具体的数据接入日志信息。通过日志信息可以快速的定位某一时间某一批次的数据，以便对污染数据及时准确的进行处理。所以所有的入湖操作，都必须在中台中进行，这样中台才能在这些操作上增加切面逻辑，管控数据质量，数据安全。而不是提供hbase集群，hive，impala让下游随意写入。这才是中台存在的意义。