标签: etl

简而言之,我有一个20,000,000行csv文件,它有不同的行长度.这是由于古老的数据记录器和专有格式.我们以下列格式将最终结果作为csv文件获取.我的目标是将此文件插入postgres数据库.我该怎么做？

• 保留前8列和最后2列,以获得一致的CSV文件
• 在第一个或最后一个位置向csv文件ether添加一个新列.

1, 2, 3, 4, 5, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, img_id.jpg, -50
1, 2, 3, 4, 5, 0,0,0,0,0,0,0,0,0, img_id.jpg, -50
1, 2, 3, 4, 5, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, img_id.jpg, -50
1, 2, 3, 4, 5, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, img_id.jpg, -50
1, 2, 3, 4, 5, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, img_id.jpg, -50
1, 2, 3, 4, 5, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, img_id.jpg, -50
1, 2, 3, 4, 5, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, img_id.jpg, -50
1, 2, 3, 4, 5, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, img_id.jpg, -50
1, 2, 3, 4, 5, 0,0,0,0,0,0, img_id.jpg, -50
1, 2, 3, 4, 5, …

我是商业智能的新手.

我刚刚被一家公司聘用,以完成他们的网络解决方案,实施BI模块.经过大量的阅读,我想我可以了解BI流程的样子,你会发现我对BI流程的看法.

您能告诉我这是否是对所有工作流程的正确看法？如果没有,请纠正我.另一个问题,我无法在架构中看到数据挖掘的位置,如果需要,我应该在哪里使用它？

非常感谢,

我被要求制作一个ETL风格的应用程序,将信息从一个数据源传输到另一个数据源.目前,我已经决定使用三层架构,但我想了解更多关于此维基百科页面上描述的最佳实践和生命周期:

http://en.wikipedia.org/wiki/Extract,_transform,_load

ETL架构设计的四层方法

• 功能层:核心功能ETL处理(提取,转换和加载).
• 运营管理层:作业流定义和管理,参数,调度,监控,通信和警报.
• 审计,平衡和控制(ABC)层:作业执行统计,平衡和控制,拒绝和错误处理,代码管理.
• 实用程序层:支持所有其他层的公共组件.

现实生活中的ETL循环

典型的真实ETL循环包括以下执行步骤:

1. 循环启动
2. 构建参考数据
3. 提取物(来源)
4. 验证
5. 转换(清理,应用业务规则,检查数据完整性,创建聚合或分解)
6. 阶段(加载到临时表,如果使用)
7. 审计报告(例如,遵守业务规则.另外,如果发生故障,有助于诊断/修复)
8. 发布(到目标表)
9. 档案
10. 清理

我有大量的视觉foxpro dbf文件,我想转换为csv.(如果您愿意,可以在此处下载部分数据.点击2011年的交易数据链接,准备等待很长时间......)

我可以使用DBF View Plus(一个非常棒的免费软件实用程序)打开每个表,但是将它们导出到csv每个文件需要几个小时,我有几十个文件可以使用.

是否有像DBF View plus这样的程序可以让我设置一批dbf-to-csv转换来在一夜之间运行？

/编辑:或者,是否有一种将.dbf文件直接导入SQL Server 2008的好方法？它们都应该进入1个表,因为每个文件只是来自同一个表的记录的子集,并且应该具有所有相同的列名.

关于维模型中的默认值,如此处所示, 是否有人建议生成这些值的最佳实践？

您是否看到它们与数据仓库数据库或ETL过程相关？

假设我们有一个MS解决方案,您是将它们作为DW Sql Server数据库项目中的后期部署脚本,还是将其添加到ETL Integration Services项目中的维度表中？如果是后者,如何在运行时生成行？

我没有在网上找到任何关于xml标签长度限制的提及.我正在寻找构建XML Schema,作为第三方向我们发送数据的规范.

Schema(和数据)应该符合我们的自定义本体/数据字典thingy,它是分层的和用户可自定义的.

自然映射用于层次结构中的节点,用于命名XSD/XML中的类型和标记.因为本体中的叶节点名称不必是唯一的,我正在考虑将层次结构中节点的完整路径编码为标记名称,适合于XML词法规则.

因此,如果我的本体有多个'lisa'节点意味着不同的东西,因为它们位于层次结构中的不同位置,我可以使用节点的完整路径来生成不同的XML类型/标签名称,因此您可以拥有

 <abe_homer_lisa> simpsons lisa ... </abe_homer_lisa>
 <applei_appleii_lisa> ... apple lisa </applei_appleii_lisa>
 <mona_lisa> and paintings </mona_lisa>

...同一文件中任何不同'lisa'类型的数据没有歧义.

我在网络上找不到任何指定最大标签长度的东西(或标准兼容引擎的最小支持标签长度).(这里有关XML的词法规则的总结)

关于属性长度的问题也是一样的,如果标准没有指定属性的限制,那么我怀疑标签是否存在,但可能存在实际限制.

我怀疑即使是一个实际限制也会比我的需求大得多(我希望大多数时候事情都小于255个字符); 基本上,如果Java XML处理器,标准ETL工具和通用XSLT处理器都可以处理比这大得多的标签,那么它就不会成为问题.

我正在寻找pandas to_numeric()的布尔等价物我希望函数将列转换为True/False/nan,如果可能的话,如果没有抛出错误.

我的动机是我需要在数据集中自动识别和转换大约1000列的布尔列.我可以使用以下代码使用浮点数/整数执行类似的操作:

df = df_raw.apply(pd.to_numeric, errors='ignore')

我正在使用OLE Db目标批量导入多个平面文件。经过一些调整之后，我最终将SQL Server Destination的速度提高了25％-50％。

尽管我对这个目的地感到困惑，因为网络上存在矛盾的信息，但有人反对它，有人建议使用它。我想知道，在将其部署到生产之前是否有任何严重的陷阱？谢谢

有没有办法将应用引擎中的日志加载到Google Cloud Platform上的BigQuery？

我正在尝试使用联合查询来加载云存储中的Stackdriver日志文件.但是BigQuery无法加载Stackdriver编写的一些字段名称.

日志文件是换行符分隔的JSON,其记录看起来像

{  
   "insertId":"j594356785jpk",
   "labels":{  
      "appengine.googleapis.com/instance_name":"aef-my-instance-20180204t220251-x59f",
      "compute.googleapis.com/resource_id":"99999999999999999",
      "compute.googleapis.com/resource_name":"c3453465db",
      "compute.googleapis.com/zone":"us-central1-f"
   },
   "logName":"projects/my-project/logs/appengine.googleapis.com%2Fstdout",
   "receiveTimestamp":"2018-02-08T02:59:59.972739505Z",
   "resource":{  
      "labels":{  
         "module_id":"my-instance",
         "project_id":"my-project",
         "version_id":"20180204t220251"
      },
      "type":"gae_app"
   },
   "textPayload":"{\"json\":\"blob\"}\n",
   "timestamp":"2018-02-08T02:59:54Z"
}

但BigQuery在此输入上返回错误: query: Invalid field name "compute.googleapis.com/zone". Fields must contain only letters, numbers, and underscores, start with a letter or underscore, and be at most 128 characters long.

有没有办法将这种日志摄入BigQuery？

我特别感兴趣的是只提取textPayload字段.

无法找到有关Hive表的最大字符数限制的合适规范。

我正在开发一个涉及配置单元表的ETL过程，该配置单元表指定了格式的命名约定 _和提供的表名都大于30字节（pl / sql的正常限制），直接进行的Google搜索使我受到列名限制，但没有关于表名的信息。